But, following the stereotype, I was lying awake one night, pondering the Roman Empire, and I had an idea. Roman life, especially in popular fiction, was full of intrigue and mystery, could this be the basis for a similar sort of game?

Now, I want to be absolutely clear. I am absolutely not claiming to be creative here. This, moreso than any of my other ideas, is cribbing directly from existing games. Mafia, Werewolf and Blood on the Clocktower are obviously very close in design to this. There are some features which are quite obviously just me going "oh, that's a good idea". If you're interested in this, I highly recommend supporting the games that have actually put effort into this. This is just a small experiment for me, and something I compulsively felt the need to write down.

Gravitas is a game where players need to collaborate to ensure that their team wins. They are randomly assigned roles, which can either be Republican or Conspirator. The current state of the republic is represented by the number of 'chaos tokens' in play. The more tokens are played, the more unstable the republic gets. The republicans win if all conspirators are eliminated before the republic collapses. Conspirators on the other hand either need to entirely erode the republic, or alternatively manage to kill off all the Republicans so they can have free reign.

The basic setup is similar to other games, players get roles assigned at random at the start of the game, and then the game itself is split into a recurring two-phase structure, the first phase is "public" and the second phase is "private". In other games this is "day" and "night" but in Gravitas, this is called the Forum phase, and the Shadows phase. Is this needlessly pretentious and changing the name for the sake of it? Maybe. And for similar reasons, the person running the game is referred to as the Censor.

In the setup, players are told in private their roles, and Conspirators are shown to each other. Also shared privately is patronage. Patrons are shown their clients, and vice versa. During the Forum, players can have discussions either as a group, or splitting off into smaller discussions. Unlike other games, there is intentionally no knowledge learned, the discussions are intended to be posturing, bluffing, and social reads. It is also possible that players can approach each other and request patronage. At the end of the Forum, then players have the option to perform actions. This will usually be bringing a motion to execute a player. Some roles may have other actions they can take.

The concept of patronage is one that I wanted to bring into this. The idea is that there is a social contract between the patron and his clients. A patron may veto any execution on their clients if desired. In return a patron may request that a client support any vote they make. There is specifically nothing saying that either party have to adhere to this, it is a social tool, not a binding rule, but if they don't, then they leave themselves open to retribution later. A client should feel somewhat protected by their patron, and a patron should feel more secure, with the voting power of their clients. It is possible for a patron to have multiple clients, patrons to have their own patron, and patrons and clients to be on different sides. The idea is the conflict between split loyalties and goals, creating difficult decisions for any player.

Voting on executions happens in one go. Any living players, including the one being executed, can vote to execute. After the vote has been successful, the execution may be vetoed. This will usually still cause the same increase in chaos as if they had been executed, but can keep a voting player in the game, at the additional cost that their patron is likely to be under scrutiny.

Rome hangs by a thread. Almost any action can destabilise the public. This is tracked by using chaos tokens. These can be coins, glass counter beads, or whatever you have to hand. The game starts with 0 chaos tokens in play. Any death, or vetoed execution, will add one chaos token to the pile. When the pile reaches a threshold, currently set as one less than the amount of players, then the republic falls. (NOTE: As with any numbers in this design, I have tested absolutely nothing. It may be that the numbers need to be changed considerably. The chaos threshold is definitely one, I have no idea how long a game this would end being. Current goal is maybe 45 minutes). Conspirators have abilities which can hasten this unravelling.

After the execution, whether is was successful or not, or if players decided not to execute, then the Shadows phase begins. This, like in other games, is where the Censor can talk to players in private without other players knowing. If nobody was executed in the Forum, then Conspirators may each choose whether to add one chaos token each. Sometimes Conspirators may choose to not add tokens, to obscure how many are remaining. Additionally there are three roles which have parts of their ability available in the Shadows. Once this is completed, the game returns to the Forum.

Creating roles for this game was the most fun. I specifically wanted to have unique roles as in Blood on the Clocktower, rather than a small amount of reused roles. Thinking of rules which might synergise well with each other, be unique, and add to the Roman flavour was entertaining. I also decided to add in one 'neutral' character. Neutral players win if they are alive when the game ends, regardless of which team wins. They do not count in the final tally. The roles then are as follows.

Republicans start with the Orator. This character can help to stabilise the republic, they have the love of the populace. When they speak, people listen. Once per game they can remove up to two chaos tokens from play. The amount of chaos tokens can never go back to zero, so it is important for the Orator to attempt to stay alive for long enough to make the most use of his ability.

Next there is the Senator. They have the ability to, in any vote, leverage their clients for extra votes. Corruption has a cost however. Each one of their clients that they do this for, not only counts as two votes rather than one, but also adds an additional chaos token.

Then we have the Vestal. They are immune from execution. They can however only vote or veto once per game, although they can implore their clients to vote on their behalf. Their veto is not limited to their clients, but can pardon any player. Any execution they vote on, or veto, the cost drops to zero chaos tokens, regardless of any other modifiers. If the Vestal is assassinated, they add three chaos tokens.

Another role that can veto anyone is the Pontifex Maximus. Their decree, while respected, does destabilise the republic, and repeated use of their power can be expensive. Each subsequent veto will add an additional chaos token. The fourth Pontifex veto therefore will add a total of four chaos tokens.

If you need to get rid of one character, a good choice would be the Scapegoat. Their execution will add zero chaos tokens. If they're assassinated they will still add one token however.

The Praetorian can, once per game, choose to either kill, or arrest in the Shadows. Killing will add an additional chaos token on top of any otherwise expected from the kill. Arresting results in one chaos token, and the chosen player is automatically nominated for execution the next day and cannot be protected by their patron's veto.

The neutral character is the Gladiator. The Gladiator must have a patron. Once per game, if the Gladiator's patron was nominated for execution, the patron may choose, in the Shadows, to exact vengeance on someone. This does not necessarily have to be the player that nominated them if they feel that someone else slighted them. The Gladiator is informed of this and has a choice. They either will kill the chosen character, or accept punishment and death themselves. Choosing their own death will result in two chaos tokens. Choosing to follow their patron's order will result in one additional chaos token over the regular assassination (meaning, usually two chaos tokens total) and the Gladiator's role is publicly announced in the next Forum.

On to the Conspirators, the first one would be the Martyr. If they are executed, then they add a base of three, rather than one, chaos tokens. If they are killed in the Shadows however, they do not add any chaos tokens.

The next is the False Tribune. They mimic the Orator, in that they can, once per game, reduce the amount of chaos tokens in play by two by invoking their ability. Unlike the Orator however, the False Tribune will choose a player in the Shadows, and that player then becomes a conspirator. They don't change role, and their abilities remain the same.

And finally we have the Assassin. They work very similarly to the Praetorian in that they can choose someone to die in the Shadows. They do not add any additional chaos tokens though. They also cannot arrest players.

I will reiterate some of the disclaimers for above. I have no experience with playing any of these games, and I have not had the opportunity to playtest this, and I don't expect I will for a while. Absolutely none of the numbers in it are likely to be right.

An additional thought that I have had while typing this up is to clarify exctly the decisions behind this and why I think it might, or might not work. Again, re-re-iterating, I am not claiming that these are good or that they will work, just that they were ideas. The initial idea when considering the game was whether it would work to remove the "information gathering" roles in Blood on the Clocktower, and build the game entirely on social reads, bluffs, and paranoia. The intention is that even the Republicans will be bluffing as each other, and being unsure what they can do, and who might stab them in the back on the ides of March. The addition of the patronage system was to add another layer to this where the insecurity would mean that players would be tying themselves to other players who might not be on the same team with the same goals, and they would be struggling to find out what is going on.

I have a bit of tidying up to do with the rules, to attempt to clarify them a bit, but the rules are currently available as PDF here, and the source available on git. As with previous game designs, I may consider some expansions, which would be additional trifold leaflets, in this case I'm thinking of calling them "campaigns", although that in a game context sounds more like an extended game with multiple sessions. The idea with those will be to maybe add a couple more roles, maybe some special rules, and a narrative intro.

I have already had feedback on the initial rule set, before publishing this post. As I am unsure which feedback to work into the rules, at least until after some play testing, I shall leave this post as-is, including the "old" rules. This is not as a slight to those who have provided feedback, which is very much appreciated, it is just to stop me from going mad, juggling different rulesets in my head while writing it. This therefore is about the initial (v0.1.1) rules, and things may or may not change in future.

The idea behind the creation of this game is that no game systems feel like they are fully compatible with the lore and feel of the X-Universe. However, it would probably result in being entirely unused if it required consuming an unwieldy tome to understand how to play. The idea therefore is that the core set of rules can be presented in a single A4 tri-fold leaflet. This was also chosen for stylistic purposes, as a black/white leaflet like this feels like something that would have been distributed by friends photocopying it in the past.

In order to condense a game system to such a small amount of space on the paper, some decisions had to be made. Firstly, personal combat would be omitted - this isn't possible within any of the X games to date, so it could be argued that it is in keeping with the game. Secondly, ship to ship combat will also be omitted, while this is a large part of the X games, creating a comprehensive one would overshoot the budget. However, these could be re-added with expansions.

One of the ideas that I really wanted to work on is to make this modular. The core rules should be enough for a party to visit the universe and sightsee, do some missions etc, but expansions should be able to add things such as combat systems back in, and should, ideally be able to be added to a game in progress. It should not require the group to start again, just because they decided to start allowing ship combat. The core rules however are intended to be enough to immerse a group in the X Universe, and be able to craft stories while they are there.

When it came to considering stats, and how saving roles would work, a few different systems were considered but as X4 already has a 5-star system for characters, it seemed fitting to reuse this. Therefore, in most situations the rolls work by establishing a difficulty on a scale of 0-10. This does not need to be a whole number. The player then rolls a D6, and adds the relevant stat, which is a number, usually from 0-5 (but can in rare cases be negative). If this combined total is greater than the difficulty, then the roll was successful. If the total was lower than the difficulty, but higher than the "difficulty floor" (ie the "whole" part of the difficulty) then the roll was a partial success. This system should allow for some very hard rolls, requiring a skilled character (eg difficulty 9-10) but also allow some nuance in the character's build, as even having 0.2 more skill in a certain area might be the difference between survival and abject failure.

It also seemed quite important to have some difference between the players' characters, and for there to be some reason for choosing faction over another. The factions therefore do affect the base status a little, meaning it is more beneficial to be Terran, if you're making a pilot, or a Split if you're wanting to get into combat more. Additionally, the characters then get a role that they play on the ship, captain, pilot, engineer, quartermaster and marine. These boost stats in addition, so it is possible to create a well rounded character, or one that exceeds in only one area. Advancement was considered, but it felt too complex to build in a level up mechanic into the core rules. This is contrary to X4 itself, where NPCs can be trained, either on the job, or via seminars. It is possible that this would be added in with a later expansion or rewriting of the rules.

Crew roles also had a perk that they could use. This was usually to work in synergy with the preferred stat for that role. For example, a captain is expected to have fairly high morale, so can choose to take morale rolls for his subordinates (by "bullying" them into succeeding the roll). Additional perks might be added later.

As the player advancement is not an important part of the game, then a sense of progress or success needs to be found elsewhere. As this is the X Universe, the obvious answer is trade. Trading works in a slightly different way to other rolls. A base price is given by the game master, which will be able to be sourced from trade tables (tbd), and then players can roll to negotiate. It is possible for a player with low management skill to fail so badly that the price increases (or decreases when trying to sell) however it is likely that the crew will have someone skilled enough at negotiating, such that they get a good deal.

This led to a bit of a dilemma whought. If the players are buying and selling bulk goods, such as shipping energy cells across Argon Prime, who pays for that, and who pockets the profit? If it's a shared pool, would players feel enough connection to this to care about the number going up? What if they want to buy equipment for themselves. A system was therefore added, that the group/ship/company would have its own "account" and all bulk purchases would be made from there and sales get transferred back. Additionally all mission rewards would get paid into the shared account. At that point, players can discuss what they feel as a fair split, whether this is an even split, or someone feels like they deserve more for the work they have done. They also should consider leaving more money in the shared account so they can continue to buy in future. If there is a disagreement, a vote is cast. The voting is done by each player rolling with their morale, and the final value being the value of their vote. It is therefore possible for someone with high morale, eg the captain, to overrule the rest of the crew. This may lead to disagreements, but this is then left to the players to sort out. Mutiny is always an option.

To be clear, I am definitely not suggesting that anyone play this - the rules are untested, so I cannot guarantee any kind of fun. Feedback is always welcome however, but I'm not sure how that can be done, as I don't have any kind of commenting system here and, as I have moved away from using github, issues are not possible either. I will look into solutions and update here.

You can follow the project here and download the latest PDF here.

No, not really.

And at the same time, yes. Very much so.

I have come up with a few ideas, and tried fleshing them out for a month, but never got something which I could really feel like they were going anywhere. My plan initially was to write them up and release them, regardless of how bad they were, just as an exercise for myself, but this didn't happen, because there just wasn't enough there.

Making games is hard. I knew that when I started. I didn't expect to make the next best selling, critically acclaimed game. I'm someone with no experience. But I was hoping I could come up with ideas that, while not good, were at least playable. I'm not overly surprised, and I'm not disappointed. I have tried some things, and I will continue trying. I've learned things that don't work, or that I am not interested in developing further.

I'll just qickly go over the two games that I poked at a bit, and give a quick description of why I stopped with them.

After Treasure Isles, I asked MiniNisturette for a theme for another game, "pets". What I came up with was a card game, where, over successive turns, you construct pets. One card might have a Pomeranian head, the next might be a cat's forequarters, and the last might be a micropig's rear. I tried a few different ideas for how the actual gameplay would work. Points for matching the correct animals would go against the entertainment of making odd combinations, but enforcing odd combinations seemed weird too. I had an idea where it might be a frankenstein pet shop, and a customer comes in and says "I'd like a pet that is [7] cuddly and [3] defensive to guard my underground lair" and you have to make pets to match the requirements. That might have worked, but the biggest stumbling block was the cards. One of the core, and important concepts behind Treasure Isles was that anyone (especially the child in question) could create all the parts and be involved. With this idea, creating what would have to be tens of different cards lost its appeal very quickly. We made a good go of it, but as I couldn't get a game to make sense, we dropped it.

The other concept had even less time put into it, partially because of the frustration of not getting anything the previous month, and partially because I was busy with other things. There was a vague idea about creating a garden. It was a hex tile based game where you could place tiles, and then resolve the effects. Some of the tiles would cast shade, stifling growth, some would grow specific plants etc. I think it was actually a decent idea, which I may flesh out in future, however I just didn't get to a point I was happy to continue yet.

Another update to this is, I got a cover image for Treasure Isles from my friend Rose Loughran. The idea behind it was that it should be black and white, to look a bit like it could have been produced at any point in the past 40 years, and photocopied to be distributed between friends. At the same time, given the intent behind the game, it was also chosen to be this way so that it could be a colouring page for a child, to again let them be involved with the game. Overall, I think it came out great. I still have to request covers for the expansions, but I will do this when I revisit this. There are still a few more things that I want to do to polish and balance, especially the expansions. Also I want to provide a quickstart PDF of parts. They can all be hand drawn (as we have done in our games) but I can see it being desirable to just have something to print and go.

So, what next? Well, I do want to come back to Treasure Isles, like I have said, I want to maybe look into the garden game when I have time and a bit more motivation to do so. Right now though I'm tinkering with a game set in Ancient Rome, this time this game, while I will be making it for MiniNisturette to play too, it will be primarily to see if I can poke some nostalgia for playing Caesar II.

So, I have failed to make more games, but I've learned a bunch of things, and I will continue trying in future!

I have created a game.

Not a video game, a tabletop game. I'm not saying it's amazing and everyone should run out and play it, but I think it's definitely worth me talking about, because it's something that is important to me right now. This post, while about the game I've made specifically, is more about what I am doing as a whole.

I try not to share too much personal information in these posts because I think that it's not relevant or important, but I'll share something now. I have a daughter (MiniNisturette from this point on) and she is currently 4 ("nearly 5!") and she is getting into board games in a big way. This makes me happy, as I have a few that I'd like to play more of. She also loves painting, and I am frequently printing models that we can paint. I think it's finally time where she is old enough to combine this, and I introduce her to the world of miniature tabletop gaming.

There are a few reasons behing this, some more selfish (I want to have someone to play with) and some less so (I genuinely think that she will get a kick out of playing with miniatures she painted) so I set about looking for a suitable entry level game. Initially I was disappointed, and frustrated. Everything I could find that was specifically aimed at kids seemed like it had no interest to me, and that she might grow out of it quickly, no room to grow, limited replayability etc. The games that were not specifically for children were either far too complex for someone of her age to understand, or they were very violent (I mean, most of them are WARgames, so I guess it's to be expected) or, most likely, both.

I should point out that I'm not massively against some violence, there are some ways to portray it, in defending what is right etc, plus a lot of kids TV does have some degree too. I'm not suggesting that bubble wrapping kids is a great idea, but at the same time, I don't want to introduce a 5 year old to a game whose core premise is to dismember your opponents.

So I did what every sane, well adjusted person would do, and I fixated on the problem. It started with the simple thought "why doesn't anyone make a game like…" and then blossomed into a game concept.

In the time since I started this, I have been recommended several games, some look promising, so I am not claiming that no games that fit my criteria at all exist, but at this point, things were already set in motion. Also we started playing the Kids Mode of the amazing game Gaslands. Both MiniNisturette and myself strongly recommend this for anyone.

When I sat down to actually write the game down, I came up with a few requirements.

1. The game must be interesting for MiniNisturette to play.
2. The game should be interesting for me to play.
3. The game must be simple enough for MiniNisturette to understand.
4. The game should play with miniatures that MiniNisturette can paint.
5. For playtesting purposes, the miniatures should not be required.
6. Ideally, the game should also be allowed to grow and become more complex.
7. Ideally the game should be a gateway to playing other tabletop games.

I quickly settled on the theme of pirates. While they are infamously violent and overall not swell guys [CITATION NEEDED] I believe that they are universally enough appreciated that they can make for an interesting enough topic for kids and adults alike. Also I believe that you can censor them enough and not go into the violence in their history, but still maintain the same interest.

While I have said that I did not want violence in the game, I have maintained ship combat. I feel that not having that ability in the game would have detracted too much, but I have heavily disincentivised it by making the core game rules give aggressor and defender equal chance of succeeding in any conflict. Also, the abstract nature of this combat, which might even result in "sinking a ship" I think is understandable by kids, but doesn't feel like it is glorifying the violence itself, even though as adults we might understand that such an act would result in loss of life. This is not a hill I'm willing to die on if anyone disagrees, but at the moment it feels like a fair compromise.

While writing the initial rules, which I just slapped in a pastebin to share with people for feedback, I always had two thoughts tugging me in separate directions. On one hand, I wanted to simplify it as much as possible, because adding different polyhedral dice, modifiers, classes etc, would drown MiniNisturette in rule minutae that would basically make it unplayable for her. On the other hand, not adding in some of these things made me feel like the game just felt too restricted. So as I was writing it, I came up with an idea. I would write the game in three parts. The core rules would be the stripped down version I could teach MiniNisturette, and then I would provide supplements, or expansions, to add more rules and create more depth in the gameplay.

I will go briefly over the rules, as I think it's important to explain my last point, but as I said, this post isn't intended to be about the game rules themselves.

Treasure Isles provides basic rules for movement for pirate/trading ships. It provides the stats for a single class of ship, and no way for the player to obtain more ships. There are rules for trading, and exploration, and of course the aforementioned combat. Finally there are two victory conditions (get X gold, be the last un-sunk ship). All of these rules use a single D6 with no modifiers. Treasure Isles: Port of Nassau provides two new ships classes, plus ways to upgrade ports, another trade good, and boons granted by your home port. Treasure Isles: High Seas provides another two ship classes, ship capture mechanics, NPC ships, and a method for creating dynamic trade routes. For an older player, they can play with one or both of these supplements and have a more rounded experience, but when you're just starting, you start with just the core rules.

At this point, there have been several playtests of the core rules, but neither expansion have had any playtesting done. The numbers in there are entirely made up, but are representitive of what I want from the expansion.

So, have I succeeded in making what I wanted? I don't know. I don't know if it's got long term playability. MiniNisturette and I cut out the pieces we needed from card, and had a playtest yesterday. She understood the rules fine. She also loved making something that she could play with. Then today, she even asked specifically to play it again. So I think it is hitting at least some of my goals.

So, what about the future? Will I continue refining this ad nauseum? Nah. This has taught be a few things. One of the main things is that I am categorically not a game designer. There are a few things which came up in the playtest which I should have known wouldn't work. What that means is that I should do it more. I have given myself a late new year's resolution. I am going to try to create one game design per month for the rest of the year. I'm not going to be overly strict about this because life always gets in the way of things like that, and I don't need another thing causing me stress, but I will try. The goals will mostly be to create games that I can play with MiniNisturette, but if I have other ideas then I might make things just for myself. I like tabletop games, and I want excuses to paint miniatures with MiniNisturette, but some of the games might be card games, or more traditional board games. I will also probably try to keep the rules to the same form factor, a single A4 trifold leaflet, but maybe some will be more complex, some less. I just don't know where this will take me.

All I know is that I am excited, I have several ideas in my head already for things that I can try to nail down. All games I write will be published on github, and be released under a Creative Commons license, so anyone is free to have a play around with them if they like.

I like story in games. It doesn't have to be particularly long story - I don't have time to play through Final Fantasy games any more. It also doesn't have to be deep and meaningful story - I play games to relax, and having my brain driven to insanity by disecting nuance is not what I always want. The sweet spot for me comes in the form of Point and Click adventure games. They tend to only take about 2-4 hours to complete, the story is enough to keep me clicking through, and the puzzles are not too difficult, but still leave you with a sense of achievement when you figure it out. Of course some games, I think are practically impossible to complete without a walkthrough because of having to think sideways and upside down to figure out the puzzles.

I am also quite keen on Film Noir, and especially the hardboiled detective trope.

My first attempt at writing the game started with me thinking, maybe I'd make a "modern" one. Maybe it would be 3D. Maybe I could create a new dialogue system. I wrote prototypes for a bunch of different systems, including the dialgue system. I started bringing it all together into a game prototype. There were two issues with this though. The first is that I had, and still have, a tendency to want to write everything from scratch. I didn't use Unity, Unreal, or any existing engine (actually, for a short time, I did fork and hack on an open source engine but I didn't keep using that for long) which meant that progress was slow. The second point makes the first one irrelevant though. I am not an artist. I cannot art. Not at all. Not one bit. I would have to rely on other people to provide art for me. Asking for free art, I discovered gets you nowhere. While plenty of people will offer, it's difficult to get what you want, when you want it. People end up ghosting you etc. This is expected, it's not their project. But still meant that I was left with a game I couldn't make. I could pay for assets, but at the time, it wasn't really an option.

My second attempt was then to address this problem sideways. I figure that my strength is that I can code, and I'm also pretty good and making systems and tools. I could write a system by which I don't need assets until much later in development. I thought I could even make this into a general purpose solution for others in a similar position. The idea was to make a game system, initially to create a text adventure/interactive fiction. This sort of game should be easy to make with suitable tools, just having an idea of the story. The designer could then iterate on the story at this stage, without the need for any art assets at all. The game could be tested, or even released like this. Then I remembered a game I had on my Atari ST, The Pawn by Magnetic Scrolls. This was a text adventure game, but had "pull down" images of the current location. I thought that this would be the ideal next step, a single static image for each location would be fairly cheap to commission to prove out the feel of the game. From there, you could convert the game, or scenes in the game at least, into a visual novel by adding character art, and finally into a point and click adventure. The idea behind this being that it is easy to create and iterate on the important part, like the story flow, without spending development time, effort, or money, on assets which may become redundant if part of the story was chopped or changed, plus it would give a way to get confirmation, and even get funding, as you could demonstrate a solid concept at each stage, and the next had clear requirements. Of course one of the driving factors for me is that it gave me a lot of programming to do. I still honestly think that this would be a great idea for a project. There are people who are good at writing stories, but have no technical ability, nor want it, who would be able to use a system like this to get their ideas into games. Maybe I'll try again at making this.

She Wore White is not dead. It's just sleeping. I am not frustrated that it doesn't get finished, I would love to do so, but every time I pull the game out and start working on it, I learn new things, and that is really what I want in a project.

I expect to write some more posts on the game. Which iteration, and on what specifically will depend on whether I get tempted to restart the game, or the story system, if I pull out the Atari ST, or decide to write it for a modern computer. Only time will tell!

This site isn't for you, it's for me. If that seems a bit rude, it's not intentional. I am putting the thoughts online so that people can see them if they are in any way valuable to them, the same reason that (almost) all of my personal projects end up on my github. I would love for my random tinkerings to be of use to somebody, but the reality is that it is unlikely.

But I do want to do something with this website. I do not intend for it to be just a bunch of inane, disconnected ramblings. As with all of my projects, this has a goal, which is probably far loftier than I can ever achieve. I am going to use it as a test ground to improve my writing. It will be difficult because I cannot easily get feedback on things - I refuse to put a comments section because I made this mistake on a previous incarnation of this site, and it just got flooded with spam, too much hassle for any benefit. So I will be limited to the echo chamber of my own mind. I will continue to write more posts.

I don't know yet what topics I want to cover, I still have a few more topics to cover in my Lisp series, including going over the obvious thing I've missed in the post on my experiemantations, OpenGOAL. Also I think I may want to cover my personal game development project, which I have been working on off-and-on (almost entirely off) for the last decade, as well as other thoughts on game development.

But are they?

Before I get to that, I will first address the Unix purists who may be reading this. I complain about a lot of pieces of software which try to do too much and, in over-stretching themselves, fail to do one task properly. I realise that the Unix way is to do one thing, and do it well, and to achieve complex behaviour by composition of parts. I not only agree with that, but I also design my projects around it. Emacs seems to be contrary to this ideal. I could make the argument that the separate packages/.el files consitute these small parts, rather than Emacs as a whole, but the reality is: I don't care. As far as I'm concerned, Emacs is the exception that proves the rule. It does what I want, and it does it well, so I don't mind that it breaks the Unix paradigm.

I was not always an Emacser, I actually started off on the vi/Vim side of The Great War, but in roughly 2008 I tried Emacs and it changed my life. Since then I have used it to write code, to write my dissertation, to write my CV, to read and write email, to connect to IRC, control my music playback, and to harness the power of the butterfly. Could I have done all of this with separate tools? Sure. The difference here is the magic word: integration. At the most basic level, having access to the emacs kill-ring betwen everything I'm doing has changed how I work a lot. For those unaware, this means copy/pasting… "but-" I hear you say, "you can copy and paste between different programs as much as you want" and this is true, but the kill-ring is not just a simple copy/paste, but it stores the copy/cuts in a ring buffer, so you can cycle back through many different things. It sounds like such an inconsequential thing, something you could do by just going back and re-copying the thing you wanted, but honestly, once you start using this, it makes a big difference and you never want to go back. Of course this is not the only way that the integration helps, but it is the easiest to explain to those who don't use it.

So, what about these missing features then? Well, two that I've been asked about most are: HTML rendering in emails in gnus - this one is valid, but I have yet to actually find an email where I cared about this. I can easily open attached images in an external image viewer with a key press, and nothing else has caused me issues. IDE quality of life features, like jump-to-definition, or refactoring, or, or, or. You can bet that most of these, regardless what they are, already exist as packages that you can pull in. Those that don't are either because you're asking the wrong question, or that they're so trivial to do that they don't deserve a package.

But how about the things that I can't just do by installing a package? Well, as I said they fall into two categories. One is that you're probably asking the wrong question - this sounds like a facetious response, but it's fairly accurate. A number of times I have tried to find "how do I do this thing I'm used to doing in Visual Studio, in Emacs" only to find that you cannot, because you do something else in Emacs. Emacs doesn't necessarily adhere to modern standards (i.e. anything standardised in the last 3 decades) so to get the same result, you probably have to change the way you think to the Emacs way. This isn't to everyone's liking, but it works for me.

The last category then is trivial things. I have left this to last because it can make you look like an Emacs guru by doing very little. It is well known that Emacs is extensible. Editors like Visual Studio Code dream of being as extensible as Emacs. If you know how, you can change pretty much every single thing about Emacs. It is basically just a Lisp environment, in which someone has built an editor. As I've mentioned before, I cannot lisp, so I have done only the bare minimum needed to customise Emacs, but even so have a far more comfortable editor. To compile a project, you run `compile`. This you can do with the Tools menu at the top, or typing `M-x compile` (M- being "Meta", or the Alt key, sometimes Esc) but this is a bit clumsy, so I long ago bound it to F5, to make the most of my Visual Studio muscle memory. Since then I have extended this to four different key combinations, depending on what I want to do (just compile, compile and debug, compile and deploy to Steam and debug, or just debug) and none of these were things which Emacs could do, but just took a few lines of Lisp to add the functionality. I cannot overstate how freeing it is, when you have one of those "urgh, why does it do it like this? I wish it did X" moments, to just go and change the way it works. It is not a scary thing at all. There is plenty of documentation, and decades of examples.

I use Emacs because it makes using a computer fun.

And yes, this website is written in Emacs.

Table of Contents

2. GOAL

I mentioned previously that I didn't really have a project I could sink my teeth into to properly learn lisp. This isn't strictly true. I do have one, but it is so large that I don't dare start it until I understand more first.

I want to write a game.

Thankfully I have a bit of experience in making games, so I know what a mammoth undertaking this is. That is also why I am worried about starting it.

So the first question here would be "Why lisp? Why not a language you're familiar with?" and there are many complicated answers to that question, but there's one which is the primary subject. Naughty Dog did it.

I played a bunch of Crash Bandicoot, and Jak and Daxter when I was younger. Both of these games were made in lisp. Specifically they were made by an in house version of lisp, in the case of Jak and Daxter, called Game Oriented Assembly Lisp, GOAL. From what the developer, Andy Gavin, describes, this had many high level quality of life features which were not really common in console development until years later. While a lot of these are more common now, at least on desktop development, such as edit and continue, they never seem to work perfectly.

4. Progress

While I have had a few attempts at doing something along these lines, there are two which are worth documenting. For these I have taken two different approaches, and had different problems.

My first attempt was to leverage an existing system. I had come across Scheme48 which, while being interpreted, did use a subset of scheme, Prescheme, in which its VM was written, which compiles to C, and from there to native code. There are several limitations in Prescheme, but I hoped that I could hack in some of the features I wanted, and extend it within the language for the rest. To this end, I forked scheme48 and started hacking around. I have mostly made some changes which allow linking to external C libraries more easily, and have them written some test applications, such as a quick implementation of tinywm, albeit missing some of the callbacks, because of currently not being able to access child records/structs in prescheme.

While this attempt was successful in being able to create executables which did what I wanted for the most part, and I do continue hacking on it, it always feels like I'm fighting the system, and forcing it to do things it does not want to do. I will continue to do so, I think it is unlikely that this will ever be anything more.

My other main attempt was to do what I do best, and reinvent the wheel. I started off a project which I called yoctolisp due to how incomplete it is. It is actually based on a miniature lisp interpreter which I used to have in my CV. The idea behind this one was that I would write a bootstrapping compiler, and I would not only be in control of everything which happened from the ground up, but I would understand it all because I'd written it. Of course first I had to fix all the bugs and add missing features in the interpreter, which is an ongoing task. Then I could start work on the compiler. It's intended to be a multi-stage compiler. Stage0 is the interpreter, which just needs a C89 compliant compiler on the system. I would then write a minimal compiler which runs on the interpreter, Stage1, which would then immediately compile itself, so that it can run more quickly. The native Stage1 compiler would then be used to compile Stage2, which is the full language, including standard library. The language dialect across the 'stages' would be identical, so anything written to run on Stage0 would run on Stage2. The inverse would not be true however as Stage2 would implement additional features. This would mean that once Stage1 was built, Stage0 would be unneccessary, and a previous Stage1 build could be used to rebuild Stage1 in future. Similarly, an existing Stage2 could be used without the need for any initial stages.

Of course, like I mentioned, fixing issues in Stage0 is an ongoing task, and I have not yet got anything functional in Stage1, let alone Stage2. This is in large part due to my almost zero understanding of how lisps functioned when writing the original interpreter, leaving me with some head scratching design decisions to work around or refactor. There are some great things that have come out of it though, the way I wrote the interpreter's parser, it 'just works' to parse the Stage1 file into an AST that I can traverse with almot no additional code.

5. Next steps

I am not going to abandon either of the above attempts. I have learned a lot from working with them and that doesn't seem to be stopping. I don't believe that either of these solutions with be "the next GOAL". Now I better understand lisp, I would probably be better off going with SBCL or maybe Chez Scheme both of which appear to support the majority of my requirements.

While I am undecided which direction to go for a 'production' solution, I will continue hacking around with these two projects. I may also fork off yl's stage0 into a separate project if I can think of a purpose for it, although I already have a bad lisp interpreter project so maybe that's unneccessary.

This post is the second in a series of lisp-centric posts. The previous post can be found here. The next post will be linked once it has been published.

I cannot lisp.

As confessions go, it's a pretty weak one, but maybe I should explain myself.

For years now, I have been a fan of lisp, and advocating for its usage. I have used emacs daily for a decade and a half. I have several projects on my github which are lisp oriented in one way or another. I have written three minimalist lisp interpreters, and hacked around with two existing lisp projects.

Sure, I know how to do the basics, I can do a basic Hello World in a handful of dialects without looking up syntax, and can comfortably write more complex functionality in them if I have some reference. I still feel like I don't really get it though. Which is a very strange thing to say, considering I advocate for its usage.

There are a lot of the core features and the ideas around which lisp is designed which I approve of, and more that I want to explore more. My problem is that in my day job, I am a C/C++ developer. I have tried to find uses for lisps in my projects, but I have never found anything where I can realistically use it in anger to actually get comfortable with it. When I've tried on some projects, I've always been stumbling at the "I know how to write this in C, and could write it much quicker." I can see the elegance of lisp, especially compared to a language like C, I just don't get it yet.

And I think that is the biggest problem. Programming in lisp needs such a different way of thinking about it than programming in a C-like language, whether this is a procedural language, or an object oriented one, that it is difficult to do so.

I will not go into depth about why I believe lisp is elegant. I may tackle it in another post, but that is not the point of this. I will, however, say that it is worth everyone having a dabble with lisp, and any language, regardless of whether it is directly useful for your career or what you want to do. Different programming languages give you different outlooks on problems. Some tasks are remarkably simple in one language compared to another. Being able to think in different ways about problems can therefore turn a problem which might otherwise seem overwhelming on its head, and you realise that you can take what you learned, and solve it in a different way.

I cannot lisp, but I'm going to keep trying.

This is the first post in a series about lisp. The next post is available here,

Table of Contents

NOTE: This page is a work in progress

tlmmProgram* prog = tlmmInitProgram();
tlmmParseProgram(prog, "x^2+x+12");
float y = tlmmGetValue(prog, 2);
tlmmTerminateProgram(prog);