Long time software developer and occasional game maker. Out of practice with the latter part, trying to get back into it.
Ludum Dare 28
Ludum Dare 27
Ludum Dare 26
You Set Us Up The Bomb is chain-reaction style game with lots of explosions. It takes place on a military robot base, and you know what? Robots are dicks. It’s time to bomb their metallic rears back to the industrial age. You only get one bomb, but you get to drop it anywhere, and as luck would have it, pretty much everything on a robot base is darn explosive.
What Went Wrong
Time ran out
Oh, this old chestnut. There’s always a list of what I intended to get in there. I’ve never not run out of time in a jam, it’s just a question of will the game be playable before I finish. Even as an old coder I still have trouble with time management. I’ve never been the fastest coder on the planet, so it’s a wonderful feeling to complete a jam. But complete is relative. My first jam I didn’t even submit it; I had these monks walking around an empty procedurally mapped abbey with nothing to do. Since them I’ve improved my focus and priorities, and also my workflow (see what went right), so games get completed, but damn if I’m not jealous of those people who knock out these home runs with time to spare. I feel like I’m getting better, though, but I have to wonder if jams are like speed chess? In Searching for Bobby Fischer, the chess coach Bruce Pandolfini chastises the student for playing speed chess in the park because it’s teaching him all the wrong things: tactics and intimidation, rather than long term strategy. Will Pandolfini yell at me for learning all the wrong things from jams? I actually took a chess class in college and he was the instructor, but this topic didn’t come up…
Bugs in the base code and libraries
You only get 48 hours, you don’t want to spend any of that time fixing bugs in your base code or third party libraries. I must have spent about 10 hours tracking down numerous issues. None of these issues were the fault of my game code – that’s not to say I didn’t have bugs there, but those bugs resolved themselves rather quickly. First I had to isolate the code in my game, and if that didn’t reveal a bug in my game, I had to test Flaxen, my base code which relies on two other libraries. I found some bugs there that were head scratchers. But worse then I had dig deeper into my dependencies and found several issues in HaxePunk, which I either fixed or made a work around. That’s 10 hours I could have used polishing my game.
Didn’t hit all of my core feature list
Remember I said I had a list of what I intended to get in there but I ran out of time? Well, first, I wanted to have trucks go on patrols between tents, bunkers, and stockpiles, but instead they just wander randomly, which actually makes some of the middle levels a little harder than the early or late levels! I intended to show damage on all objects, and set them on fire if they were going to explode. The robots themselves were supposed to run screaming before exploding, and I wanted their body parts — notably their heads – to fly up toward the camera with some funny quips before landing. I also wanted shrapnel – when something exploded, parts of it could fly randomly a large distance, potentially hitting another object and setting that one off. It’s still playable without these things, but I think the game would be much more exciting with them. Also the game should get harder – each level requires like 65% of all “points” to be exploded to pass to the next level. That number should rise as the levels rise.
What Went Right
Sticking with familiar tools
I think I’ve finally got my process down. Photoshop and Filter Forge for the art. Audacity, a mic, and bfxr covered my sound needs. I would have used Renoise to compose some music had I the time, but with five minutes to spare I sang an improvised song about not having time to create a song and hooked it into the main menu. Hey, you gotta move quick in the last hour! I used Sublime and Haxe 3 for development. Flaxen, the framework I used preciously for LD27 came to use again here, except this time I separated out the code base and put it up on GitHub. Flaxen ties together an entity component system (Ash) with a game library (HaxePunk). It’s actually really fun to start throwing components and systems together.
Focusing on the making it playable first
Several times I stopped myself from going down tangents before the core idea was even playable: polishing art, tweaking sounds, working on higher level code elements. And it’s a good thing, too, because it took me much longer to get the core idea playable than I anticipated. This was the difference between a incomplete but playable game, and a more fleshed out idea that’s not at all playable.
Explosions are furn! Ehrmegerd!
Despite everything that didn’t get implemented, the core explosions and destruction are actually fun to behold when you get a good chain going. The effect turned out pretty well, I think, layering a randomly rotated explosion image (shown at the top), applying a layer of fire particles, and then after a pause a layer of smoke particles over the top. It’s especially fun when you get beyond level 14, where the game starts repeating with the maximum number of objects on the screen. Why are you waiting for the perfectly timed bomb drop? Just drop it already, the game gives you another bomb if you fail to meet the quota, just destroy some shit already, will you???
You can play You Set Us Up The Bomb here.
I’m making some progress. Right now you can drop a bomb on the robot army, and if the blast radius intersects with something explosive, that also explodes. Now it’s time to get the jeeps and robots patrolling about.
I wasted a good chunk of time dealing with particle emitter bugs I introduced into the library. (Oops.) When the explosions start chaining it makes Flash chug a bit, but I have to tweak the particle effects later anyway; I’ll probably trim the particle count and add some pre rendered bits. Another time waster was fiddling with the art instead of just using temporary art. If I had placeholdered instead, I’d be at the halfway mark with balanced game mechanics instead of just starting that. And I also wasted energy putting together a random level generator, which is cool, but it’s not very balanced, and it took several hours to do. Someday I’ll learn…
Now that it’s 8:30pm where I am, here comes the difficult decision: Do I caffeinate???
Okay, I’ve got three ideas. I fleshed them all out, went over all the pros and cons of each. Partially I’m looking for the funnest game, but more so I need the one that I can best picture completing. My designs tend to have some gaps in them, and it’s a crap shoot to fill in those details later. Maybe the details fill in nice, in time, and it’s great, but I’d rather not have a moving target when it’s a 48 (er, 45.5) hour deadline.
I first kicked out the idea of the one-legged ass kicking competition simulation. The mechanics of figuring out how to keep a guy hopping and kicking without falling over sounds like fun but will require a lot of balancing, which I may not have time for.
Next I eliminated “Brat Attack,” the game about a toddler who wreaks havoc after being denied a second piece of candy. This one is probably funniest, and while I can picture an opening cinematic that makes me chuckle, there are considerable gaps in how I will render this first baby shooter in pseudo 3D. Ultimately, if I completed it, I think it would be regarded as a humorous take on the terrible twos, but perhaps fall shy in the fun department.
That leaves my ultimate choice, “You Set Us Up One Bomb.” It’s a derivation of those chain reaction games, but with a few more moving parts that I hope folks will see as adding innovation instead of recycling. We’ll be dropping a bomb on a base and the enemy and materials getting destroyed, on fire, and flung as shrapnel. I originally envisioned the enemy as human, and that just started to seem gruesome after a while, so now you’re going to be killing robots. If I have enough time, I would like to record some robot interjections as their heads go flying. Should be entertaining.
So get started coding, would you? Okay fine, I will, stop harassing me.
Due to the holiday season, I’m not sure if I’ll be able to commit to the entire 48 hours, but I’m in baby, I’m in. Compo.
Editor: Sublime Text 2
Language: Haxe 3/OpenFL
Frameworks: HaxePunk and Ash-Haxe (ECS)
Base code: Flaxen
Visuals: Photoshop, FilterForge
Audio: Audacity, Bfxr, Renoise and some plugins
Version Control: GitHub
Good luck everyone!
Yay. [Disclaimer: 10% more yay than traditional yay.]
I was playing a 48-hour compo game called Ghost Voice, which is a game about frequency analysis that plays this haunting ghosty 60 second sound for you to analyze. On the entry page, the author credits http://www.freesound.org for the audio track, and in the comments someone clearly and correctly points out that this is against the rules to use pre-made content. I thought to myself, yeah man, you can’t use pre-made content whole sale, unless you modify it first… wait, what? What was I saying? Modify it? Where did I get such a notion?
I went over the rules page and it’s fairly clear there too. “All game code and content must be created within the 48 hours.” Base code and content generators are allowed, but that’s it. And I thought back to my own game, Offspring, and realized I have had this persistent fallacy in my head for months. For some reason I had the idea in my brain that it was okay to use other content as a base if you modify it. For example, shrinking, outlining, pixel fixing, cropping, distorting, and normalizing audio levels. It finally hit me that this is plainly incorrect. Ah, damn. Regardless of how anyone else interprets or follows the rules, I don’t like to feel like I’m cheating, so this is my full disclosure.
For graphics, I extensively used Filter Forge – an art content generator I really like – to produce some sprites and fill in backgrounds and shapes I drew. I believe this to be in the rules, however I used modified free clip art sources I found to make 9 out of the 30 sprites in the game. I shrunk them to tiny size, did some heavy pixel editing, color shifting, and applied a number of stroke and shadow options in Photoshop to get the effect I wanted. This was against the rules.
For sound, I had 15 files. 7 of the effect sounds were sourced from Free Sound. Using Audacity, I trimmed out the most relevant snippet from the sources, applied some audio filters, normalized the sound levels (poorly), and adjusted some peaks to get the final result I wanted. This was also against the rules. I gave attribution to these sounds in the readme on GitHub. Of the remaining sound effects, I recorded one of them, used bfxr for another two, and modified that output as well. The music was made using Renoise to lay down some notes and a couple of plugins I own to provide the instruments. I believe this to be okay as well, although I know some folks balk at this because it makes it easy to create great sounds with little effort. I used the Microtonic synth plugin for one track of the end game screen, and the others used Z3TA+2. I also applied some DSPs to the tracks.
The font I used with the game came from 1001 free fonts, with a free license. The base code was pre-declared on GitHub and then later I used that same repository to share my source code. The base code is a framework I put together for integrating HaxePunk (a game library) with Ash (an entity component system) , and also adds some additional game support tools. I know some folks don’t like base code either but this is the sandbox I want to play in, and you can see what I’m using on GitHub, so I feel perfectly okay with this stuff too.
I apologize if this irks folks, I didn’t mean to cheat. It won’t happen again. If anyone wants to make a stink about it to the admins, feel free, and I submit to having my game moved from the compo to the jam or being disqualified outright, if that’s their ruling. It seems unlikely I’ll get in the top 100 let alone the top 10, so maybe wait to make a stink until then?
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.
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
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.
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:
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:
The second issue was another Flash issue. The game looks right on the Mac target, but the Flash target isn’t rendering HaxePunk Tilemaps properly. The problem only comes up when I change a space of the tilemap to a tile that has alpha in it. The resulting screen shows that the canvas is not being erased before rendering the tile, so the alphas just all pile on each other. Since this works properly and expected on the CPP targets I think it’s probably a software rendering issue in HaxePunk. The hack workaround in my GridView:
tileMap.setTile(x, y, g.get(x, y));
Offspring is playable now, and you can win although the path there is inscrutable and unapologetically vague. But it IS playable, and I can certainly post spoilers to the entry page. I’m going to spend a couple hours on sound, then I’ll revisit the rules XML. Thrillz! Anyhow here’s a snap shot of a game in progress:
This shows the game about halfway done. I hit the planet with meteors to leave mineral dust all over, which feeds algae and leads to the formation basic cells. Algae has produced several plants on land, and the seeds from those plants evolved into trees. This isn’t exactly super-scientific folks. You can see by the grove of trees a naked caveman evolved from an herbivore. He’s just one click away from human-dom. The reptiles below are also one step away from becoming carnivores, and then they’ll become humans if they could just get some meat! Later, the nearby trees will help the humans build dwellings, form cities, and eventually launch a spaceship. Into SPACE!
Seriously, you’ll find this game confusing.
An obvious benefit of insomnia is it keeps you working on Ludum Dare well into the night/morning/next day. I think I’ve got the kinks knocked out of my rule system, and I’ve got my static object art done. Next step is to flesh out all of the rules in the XML file (which will probably necessitate further changes to the rule system, gak).
In Offspring you’re playing father time, or more specifically, father minute. You have six children, each spanning ten seconds. Although the text at times makes it seem like you’re the children and not the father, but uh ah don’t worry about that right now. Look behind you, a bear. Anyhow you can use any one of the six children to make “massive change” in any space of the map, and this change will only take 10 seconds of real time because, you know, you’re time itself and that’s how long everything takes for you.
The game is a sort of planetary evolution simulator. You’re trying to as quickly as possible bring about intelligent life on the planet and get them to launch something into space. You can use one of the six children to, for example, force meteors to crash into the planet so that minerals land upon the ocean surface, or force cells to evolve into algae. It takes about 20+ steps to turn a space of molten lava into something like a spacecraft launching facility, and many changes will only happen due to neighboring spaces. For example, if there is too much lava next to water it will turn into steam, or vice versa.
Your journey is timed, so you’re goal is to reach space as fast as you can. First time out, though, it should feel more like exploration, as you discover the ruleset through trial and error. This all sounds like an interesting idea to me, but we’re approaching the halfway mark! I still have to complete the rules xml file and draw another 17 objects or so, and then after that there’s music, sfx, fx, and remaining bits of polish. So what am I doing still talking to you? What the hell, man?
The game is called Offspring. All I’ve got to show for five hours is an idea document, a description of screens and required assets, and this rules.xml file. I have a pretty good notion of the kinds of interactions I want to happen in this game, but I know the actual rules will need lots of tweaking. So my hope here is by putting all my rules and triggers inside an xml file I can spend Saturday putting in the framework and art, and tweak the hell out of all the rules on Sunday. This is a bit of a game of exploration, especially for the first time player, until you discover all the rules — well, presuming I finish in time.
2.5 hours later I have the idea I want. My girlfriend didn’t like this idea as much as my other one, but I think I’ve worked it out to be simpler to implement. Zoinks! Now I have to spend another hour or less documenting the list of objects I need and how they’ll interact. Then … oh I dunno .. 21 hours to build it?
Make way! I’m busy here! Why am I posting?!!?!!!111111oneone