Ludum Dare 28
Ludum Dare 27
Ludum Dare 26
Long time software developer and occasional game maker. Out of practice with the latter part, trying to get back into it.
I may have gotten cocky.
I failed to complete my first Ludum Dare compo (LD #25), but I learned from that experience. Since then, I focused on a single set of tools (Flaxen), rejected ideas that relied on new skills, and focused my work on leveraging my code base rather than altering it. Since then I submitted games into the next three Compos and a MiniLD.
Maybe those experiences went to my head. This time, I broke all my rules and never got close to a bare prototype, let alone a finished game.
I spend the first hour of the compo just brainstorming. I have a cigar, walk the dog, sit on the deck, maybe have a little drink and just ponder. I turn the theme over in my head, rejecting what I think will be common interpretations, applying the theme literally and figuratively, looking for the things that live beneath the surface or things trying to escape it. In this case I came up with several ideas, here were the top three:
- A plant simulator, where you plant seeds that develop roots through the various minerals of the Earth, taking what they need to grow, poking through the surface if they need sunlight or rain. Each plant sufficiently tended to would grow a different seed, which would grow a different type of plant. Figuring out how to grow Plant #10 was the goal. I loved this idea, but it seemed a bit similar to my LD#27 submission Offspring, and designing the plants and growth system might be complicated.
- A giant worm that travels through the Earth and is hard to steer (similar in complication but different in mechanics to a Flappy Bird/Whatever). This would be an endless game, as you tried to maintain speed, avoid obstacles, conserve energy and eat! You could leap out of the ground (losing steering) to try and bag a land mammal for your supper. This was a fun concept. I thought the worm might be tricky, and the success of the game would depend entirely on how good the steering felt.
- A prospector on the frontier falls into a well. It’s a long way up. This is a climbing simulator. You drag one limb at a time from hold to hold, risking losing your grip or slipping if you put too much strain on one limb. This was a simple game, and there was some opportunity for me to add some comedic lift by having the prospector narrate his climb and use audio to indicate what limb was under the most strain. Since this was the simplest, and this was Melissa’s favorite of the three, I went for this idea.
However the third idea had a serious caveat – I need to implement some rigid body physics, which I have little experience in. I decided to do a little exploratory prototyping to see if I could refit Flaxen to support some basic rag dolling. After a number of false starts and failed attempts, somewhere along the line I realized the day was gone. Despite my plan, I spent the whole day trying different approaches to squeeze physics into this engine. I was reasonably certain at this point that it would require a major refactoring to add this support.
Here was the end of day one. I could have picked one of the other ideas, but to do them in 24 hours was an uninspiring limitation. I decided to instead focus my time on a third party physics engine for Haxe. If I was lucky, I would pick it up in a few hours and be somewhat back on track with the Prospector. I researched a bit between Nape, Box2D, and PhysAxe. Nape seemed to be the most popular, so I went with that one. I discovered several things: Nape is cool. Nape is complicated. Nape is not doing what I want.
I spent most of today messing around with it. Integrating Nape with Flaxen was very simple, just adding a System that loops through all entities with Nape components and using the data therein to update the associated Position and Rotation components. After some time I was able to get my model which I assembled in Spriter to show up statically in Nape. However I spent the rest of the day struggling with constraints and joints, failing to get them to work as I expected them to. I’ll keep plugging on, learning the Nape way of doing things, because it’s a very cool tool to add to my repertoire. But as for this compo, it’s time to shut down!
Good luck to everyone who submitted a game, and particularly everyone who is racing to complete a game before the deadline.
As it turns out, creating a rigid body physics system from scratch during a 48-hour game jam is not such a great idea.
My idea stars a prospector on the frontier, who slips and falls into deep chasm. He survives, but has to climb out. To do this, you control the limbs of the climber, dragging them from hold to hold. Ideally the game would calculate how much strain each limb was under, and he could lose grip and fall again. I picked this one because (so I thought) it was the simplest of the ideas I had come up with. Here’s the art I did for it. Ignore his missing limbs, they would just be mirrored in the game.
Unfortunately, Flaxen (my base code) doesn’t handle hierarchical transformations, let alone joints and rigid body constraints. I’ve wasted hours today just getting a positional transform to cascade, but this is worthless without also handling rotation. (And scale? Fuhgeddaboudit!) I’m feeling stupid for even trying.
So at this point, I’m going to do a cursory search for some rigid body physics libraries for Haxe, but it seems unlikely I’ll find anything that will integrate quickly with my library Flaxen, let alone the dependent libraries of Ash and HaxePunk. Then I’ve gotta decide if there’s enough time for a plan B, or do I just call up my friends and say never mind, I’m coming with you.
Man! I waste so much time updating my framework to add new core functionality, when I should be building the game. My base code doesn’t handle nested position/scope very well, but ?!@$*! this isn’t the time to be fixing that! Gotta get back on target…
Ludum Dare always seems to arrive during busy moments in my life. In this case, we’re moving to another state in about two weeks. Things are busy busy busy. So, at this point I feel like I’m in, but there’s a chance I’ll have to bail.
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
Regardless, have a good LD, everyone!
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: