Offspring is a game about guiding a new planet. It starts out inhospitable to life, but through your mad clicking you’ll make it habitable, create life, evolve that life into sentient humans, and encourage those humans into starting the space program. I admit proudly that this game has been called overwhelming, tedious, and complicated! However it’s also been called interesting, a lot of fun, and a great idea! So I got that going for me.
What Went Right
Reusing a (Semi) Tested Framework
I built a framework using Haxe (language), OpenFL (graphics API), HaxePunk (game API) and Haxe-Ash (entity component framework), and used this framework during the LD26. Since then I’ve used it to make two other games, expanding it along the way. Being familiar and comfortable with your tools is so important. I felt much more comfortable with the time limit this time, and although I did code right up to the wire, the finished product was more fleshed out and polished in a few areas.
Built a Rules Parser/Evaluator
I built a rules parser. I started by defining two types of rules, what happens when you click on a thing, and what happens when certain neighboring conditions are met. I then drew up an XML structure like this:
<object type="steam" audio="steam.wav">
<click result="clear" message="Cooling some water"/>
<trigger neighbor="lava" min="0" max="2" result="clear" message="Some steam cools into water"/>
</object>
The object tag defines an object, which has a corresponding image in the sprite file. When any such object is created in the world, the associated audio file is played. When an object is clicked upon, a message is given, and usually the object is transformed into something else. And at regular intervals the trigger lines are evaluated. The neighbor attribute defines what neighbor is required for the trigger to go off, in this case lava. The min/max default to 1-8 (orthogonal and diagonal neighbors are checked), but in this case anything up to two lava neighbors will trigger the result. It’s also possible to put a chance=”###” attribute on there, which applies a randomness to the trigger, once all the other conditions are met.
Although I can now certainly think of numerous ways this format could be improved, coming up with the format quickly and committing to it meant I got a rules parser working quickly and (eventually) correctly. It also meant I could add new objects and rules to the xml file at any time to get new behavior, which was very helpful in testing.
The idea
I freely admit the idea of this game — the promise of it — is better than what I built. 
Correctly balanced, with proper achievements and discovery aids, this could be an awesomely fun game for fans of exploration and god games. Forget the fact that the game I built itself lacks these things (balance, proper achievements, discovery aids, etc), I can see a future game in here. And this game — with all its flaws — came out way better than my expectations for a 48 hour time limit. It’s still fun to play! Sure, it can be inscrutable at times and press your patience, but this is just as much a game for Ludum Dare as it is a possible prototype for a future (and better) game.
What Went Meh
The Theme
I got mixed reviews on the association of the 10 Seconds theme. I felt that everyone and their mother would be making McPixel and WarioWare clones, and everyone else would be implementing 10 second game timers, so I wanted to do something where the connection was more abstract. I figured here you are, Father Time, and you give birth to some time children, each of these ten seconds in duration. Then you send the time children out to the world, and they cause eons of change, growth, and evolution but take in real time 10 seconds. Sounded good to me, I started working on a god game.
One reviewer said the theme was “loosely fit.” I don’t know if I agree with that, but it’s definitely abstract. I mean, if we have to implement a 10 second time-pressure mechanic, then that’s not a theme, that’s a mechanic. I voted down any “theme” that sounded more like a mechanic, including this one, but hey it’s all good. If you don’t work out of your comfort zone you don’t improve.
The Triggering Implementation
The TriggerSystem is responsible for evaluating all triggers. I arbitrarily decided on the following implementation:
1. Read all triggers from all objects and store them in defined order in an array.
2. Every update loop, maintain an accumulator so that it only ran once every 50ms.
3. Execute the current trigger.
4. If the trigger passed the condition, execute the result and keep this the current trigger.
5. Otherwise skip to the next trigger, looping back to the top of the trigger list if needed.
I was concerned about bottlenecking the game so I put in this throttling mechanism that I don’t even know was necessary. It worked more or less, so I can’t complain about that. But it had some consequences.
First, the amount of time in between a trigger executing after its last failed trigger was variable. Different terrain conditions could lead to a trigger running repeatedly while the other triggers stall. This problem was made more acute with the introduction of the chance attribute. How do I put this — I’m a programmer not a mathematician, so I may be using this term wrong, but the standard deviation felt like it was pretty high.
Second, the randomization element was not scaled to time. If a trigger missed it’s 5% chance, it would execute again the next time the trigger came around, which was — when? It depended on the other triggers, whether they triggered or not, leading to an extra degree of uncertainty as to when that rodent was going to finally eat that damn plant. Plus any time I added a new trigger to check, all trigger rates went down because another trigger meant more time until the next eval. Now that I’m thinking about it, I guess I could have stored the last check time of each trigger, and then the chance variable could have some specific per second kind of meaning, like 5% chance of triggering any given second. Ah well.
What Went Wrong
The Rule Set Needed an Overhaul
I did lots of minor rule tweaking, but I never got around to an overhaul of the rules. Essentially whatever “promotion path” I came up at the onset of design is the path that stuck. Rodents and Humans multiplied on their own and all other creatures did not. Humans, trees, herbivores, carnivores, and meteorites decayed and died if clicked on, where others promoted or did nothing. Algae required minerals or would starve and rodents could be eaten by reptiles, but almost everything else survived statically.
The inconsistencies of design contributed a good deal to the frustration of the players. The goal was for them to explore the ruleset by trying different things, but they were not consistently rewarded, and oftentimes punished, so the joy of exploration is dimished. I had two hours left at the end of the day and opted to work on other things, like implementing a “child timespan” control and testing.
I don’t disagree with that decision — I was afraid if I started rewriting the ruleset at that juncture I would have too many errors crop up without enough time to fix them. But I should have started that rewrite on Saturday night instead of putting it off. If I did so, I probably would have adopted some patterns:
• Clicking always promotes and never kills.
• All things have kill conditions. So if a promotion is too soon you can de-volve to some degree, making it so the user is not punished heavily for trying.
• All lifeforms have favorable conditions for multiplying.
Minor Shit
Everything else that went wrong was minor shit not worth bitching about. Overall, I’m happy with what I built.
Some Water Evaporates Into Steam
For those who’d like to try the game, here’s the entry page:
http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=17811
Be forewarned, you will probably need to read the spoilers and have some patience, or just have lots of patience.
For those who want to look at the source or modify the rules set and compile it yourself, it’s all available on GitHub here:
https://github.com/scriptorum/LD27
Tags: Ash, entity system, haXe, haxepunk, LD #27, postmortem
