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
Alright, I gotta say it’s not my favorite theme because I think we’re going to see a hundred McPixel clones, but you could all prove me wrong, and then I’ll be all stupidy so and so for saying it. Okay, let’s do this! I’m game. Gonna find that box, think out of it, and then smash it with a wrench and set it on fire. Then gonna grab another box, say from some homeless dude, and burn that box too. I mean I’ll make sure it’s empty first, I’m no murderer. But all boxes must burn! BURN!! Sorry I burned your house, dude.
I’ve set up a GitHub repository for my LD27 entry and populated it with base code. Go ahead and compile it. Running it shows a blank screen. EXCITING!!! So many thrills in one little repository.
It’s compo time! This will be my third compo (four if you count a two-week mini-LD, which you probably don’t, you big meanie). I failed to complete my first LD comp and barely scraped together a working single level for my second LD compo. Right on. The mini-LD was alllllmost fully working, but still key things got dropped proving that I will always code up to the time allotted…
Editor: Sublime Text 2
Language: Haxe 3/OpenFL
Framework: HaxePunk, HaxePunk-AI, Ash-Haxe (ECS)
Visuals: Photoshop, FilterForge
Audio: Audacity, Bfxr, Renoise and some plugins
Version Control: Git … maybe
Base Code: GitHub (older) and zip (latest).
For base code, I’ll be borrowing as needed from my LD26 entry, which is on GitHub, or more likely I’ll be borrowing from this zip. That’s pieces of my fugly source code for reRocket — an attempt to flesh out my LD26 entry Mass Splitter into a fully playable game. I’m still working on it. Of course. The zip has most of the render/input/util frameworky entity-component-system stuff I’ll probably use and regret doing so.
I’m severely sleep deprived at the moment (thanks, insomnia! wooo! you rock!), which I hope to a’right by the time the weekend rolls around or my entry might wind up terribly silly.
Good luck everyone!
A week has passed since LD48 and it’s a good time to take a deep breath and reflect. Rub our sore muscles. Think about what’s next. Weep uncontrollably. Whatever you need. In my case, Mass Splitter went out the door without a hitch! Well, rather, it was well under the maximum number of allowed hitches. It was within hitch tolerance. In truth, there were three hitches: I didn’t get in a main menu, I didn’t get in a tutorial or at least an instruction page, and there was only one level. But all these hitches pretty much have the same cause, that of running out of time, so how comes I haz runs out?
What Went Wrong
Architect hat mostly unworn
I spent a bunch of time trying to get some view components working with HaxePunk. HaxePunk handles origin a little differently than I would think it should work, so I spent a few hours on my View class, getting the Scale, Origin, and Position components to all work together. Great, they now work together.
I did this because my game has orbs in it, and the active orb has a tube spinning around the outside edge of it. You hold the spacebar to shrink the active orb and start growing a new orb on the other side of the tube. After I got the tube spinning at the right radius around the correct center point I then went to add the new orb. This new orb also needs to be placed at spinning radius from the center, so how do I get the true position of the edge of the tube?
Well I can’t. The tube’s actual position is derived inside the view class, so it doesn’t exist at the component level. So now I’d have to either hack into the View objects to get this information (which horrifies my MVC sensibilities), or just calculate the orbital position myself, which I did. Well gosh, that was easy. And now that I’ve done that I can position and rotate the tube using the same logic, so the tube stops scaling along with the size of the active orb, which is a better look I like anyway.
In essence, I looked at just one next thing to do, rather than the broader landscape. Without putting on the architect hat, I spent a few hours going down a rabbit hole I didn’t need or want. On the other hand, I’ve got a cooler View class now.
Failed to take the time to split up complicated classes
I didn’t universally fail this, but I could probably attribute a few hours of wasted energy because of failing to do this early or at all. In particular my firing system is doing several things rather than breaking it up into different systems. See Ash Entity System / What Went Right.
Not putting more of my personality into my game
Friends often tell me I’m funny. Even fine, up-standing strangers — if not calling me that — have in the least called me irreverent. I try not to listen to other categories of people whose job is to be offended by everything. Anyhow – you wouldn’t know these things about me from playing Mass Splitter. Sure, I don’t have to make humor a central aspect of all my games, but a) it’s clearly desirable in a competition where there’s a category for it, b) there are many kinds of humor besides pratfalls and puns that can serve a dramatic cause. Heard of irony? Sarcasm? Deprecation? Pathos? Impudent contempt? Not that Mass Splitter is a deep example of erudition (it’s not), but it’s better for one’s self esteem to believe your personality is a strength. And if it’s not … well, you should work on your personality. Are you trying to tell me I should work on my personality? Stop staring at me like that.
What Went Right
Ash Entity Framework
Richard Lord’s Ash Entity Framework is really good. It’s an entity component system. I used the Haxe port maintained by Dan Korostelev. It was really fun to learn how to use an entity system and put it into practice. For those who don’t know, apparently those folks at AAA game houses have been using these things for years. The idea is to eschew traditional static object hierarchies for a data-driven composition approach. Richard has some great articles about it on his website.
Everyone seems to approach an entity system differently; in Ash the entity is a fairly generic object. You create a new Entity instance, optionally give it a name, add components to it, and add it to the engine. Usually it’s the job of a factory to create the entities with the components you need, but that’s up to you. Components are simply data-holders that you create, with little if no logic in them. Ash components do not need to derive from any base class, any object could be a component. All the behavior for your game goes into the systems you write, derived from the System class and added to the engine instance driving your game. When you call engine.update(time), all your systems execute in the appropriate sequence. Although Ash provides a signaling capability, Richard recommends you use boolean flags or components as markers to indicate when events happen, so that a component event (such as “this changed”) is only responded to by a system when it executes. Using engine.getNodeList(MyNode) a system fetches a list of entities from the engine that are relevant to it. Nodes are classes that contain one or more components; only those entities holding the components you specify will be returned.
I enjoyed using Ash quite a bit and encourage you to look at my source on Github if you’re interested in seeing one possible way of using the library.
Last compo I thought I picked a small idea but apparently it wasn’t small enough because I couldn’t get it done in time. This one was doable — juuuust barely. I tried to get a playable prototype as soon as possible; I would have liked to go to bed on Saturday night with it playable. Now, that didn’t work. Pthbth. The prototype wasn’t playable until Sunday afternoon, but imagine if I wasn’t striving for earlier! Suck-sess.
I’ve had previous practice with HaxePunk, and I started messing with Ash in a previous game I attempted to complete for the 7-day Roguelike. Even though THAT attempt was a failure, it gave me crucial practice that made this submission possible, and also gave me base code to pick at for Mass Splitter. Of course, more practice would be better, so I shouldn’t wait four months for my next game…
This audio tool is available in several forms; the one I used is BFXR. Sooooo convenient. Sure, all your sounds do tend to sound video gamey retro screechy crunchy if you don’t post-process them, but a lot of people go for that, and damn if it isn’t quick to pump out some placeholders. (… that wind up being the final sounds when you run out of time)
Shut up, good enough, it’s playable
Shut up, I say! It’s good enough. It’s playable. I’m just happy I got out a game. Would I have liked to get those extra things I conceived of? Of course. Over time, with practice, I’ll be able to meet the goals I think I should be capable of. (I’m a damn perfectionist. I’d be faster if I wasn’t always trying some different way of doing things.)
I finished something playable in time that some people actually liked. Next time I’ll do even better.
I’m in for the compo. Too bad about the potato theme, though…
Editor: Sublime Text 2
Framework: HaxePunk, HaxePunk-AI, Ash-Haxe
Visuals: Photoshop, FilterForge
Audio: Audacity, VLC, Bfxr, Autotracker-py
Version Control: Git
I’ll be using the Ash entity system. I’ve written some components, systems, and views in a prior game that I may want to
pilfer leverage for the compo. You can find that base code on GitHub. Dead Grinder is not really a game at this moment, so much as it’s a pile of code that could theoretically be reassembled into something resembling a game given additional effort.
Good luck everyone!