Posts Tagged ‘Ash’

Post-mortem: Flappy Monster

Posted by
Friday, August 28th, 2015 1:55 pm

Flappy Monster is a nod to helicopter-in-a-cave style flight games, and turns them sideways. More popularly known as “Flappy Bird” games, the thrust/gravity/navigation mechanic has been around for a while. In my twist, I gave the monster ineffectual wings. Flapping makes him angry (because he can’t fly) so he runs, runs faster, through buildings and forts of humans civilization who desperately lay down sharp pikes to stop him.

WHAT WENT WRONG

Idea waffling

I start each game jam by walking the dog and talking to myself like a weirdo. I run through the possible interpretations of the theme, what I think others might do, and how I might distinguish myself. When I get back, I have a drink (this time it was Remy cognac), sit on the porch, smoke a cigar and brainstorm. Normally by the end of the evening I have several ideas fleshed out and I’ve at least picked one, with the core mechanics designed. But this time, I was flustered, and was waffling between two ideas until 4AM.

The first idea was an homage to The Thing where you were accused of being the monster (but not actually). It was somewhat a logic game, where you knew little facts about the other people that clued you into who was the monster. Anyone left alone with the monster could become infected, and then you had two monsters. You assigned characters to do tasks which revealed more clues about who’s the monster. Characters would have trust levels with each other, making this task harder, and ultimately putting suspicion upon you, perhaps leading you to becoming infected yourself. I loved the idea, but I spent hours researching logic puzzle design and failed to nail down precise core mechanics.

The other idea was a chasing game. People thought you were a monster and chased you, and you responded nonviolently. If they grabbed you, they held you in place until you shrugged them off. If you stayed held long enough (perhaps because several people grabbed you), your health would begin to drop. The twist was when your health reached a lower threshold, you’d explode with rage, killing everyone on the map. So ultimately you are the monster (albeit provoked), and your goal is to survive long enough. I eventually settled on this idea, but I was still analyzing mechanics in the morning, trying to figure out how to make the chase exciting. Ultimately when it got to noon, I acknowledged that this design had too many issues and no time to work on them.

I came up with the Flappy Monster idea as an alternative, as something I thought I could build with the time remaining.

Poor prep

I generally code Haxe using the Sublime 3 text editor. It’s not an IDE. It has support for templates but I don’t use them. It has support for completion, code style, and shortcuts using the Clemos Haxe Bundle but I had trouble getting it working properly and stopped using it a while ago.

Under the hood, Flaxen uses Ash-Haxe as an entity-component system. The benefits of this system are only realized if you actually use systems and components to address states and behaviors in your game. These things require some boilerplate code. Not a lot, but when I’m coding under the gun, the extra minute it takes to set up this boilerplate and locate the file in the appropriate location seems like forever.

So instead I start hacking. The code base gets ugly, cluttered, and hard to extend very quickly, and by the end of the 48 hours I’m fighting kode krud in my desperate attempt to cram in one more feature. Next time I’ll put together some templates and macros to make this process quicker, and keep me leveraging the ECS.

Also, I had little practice with Spriter. While I love the ability to do custom animations in it, it’s a buggy and very quirky app. Between Spriter and TexturePacker, I was trying to discover an efficient art pipeline that wouldn’t drive me nuts. In the end, I barely escaped a Lovecraftian descent into insanity. Seriously Spriter, I have to enter my custom rect every time? You can’t save that shit in the scml file? Jerk.

Ran out of time

This “what went wrong” is always on my post-mortem list. And every time it’s my fault. Because I know I have 48 hours and only 48 hours to make a game, yet I “blow the time budget” at various points. I have to be more ruthless in my time management. Unknowns are a killer and a time sink, so prepare as much as possible, and if the design is not coming together quickly – ditch it!

As one gets to the end of the deadline, things stop dropping off your to-do list in favor of more critical priorities. In my case music and more special effects never happened. And the game would have benefited immensely from another hour of playtesting and tweaking. But that’s alway the case!

Users complained that the pikes were hard to see, the difficulty was brutal, the RNG was unfair, and the monster took too long to slow down. All true, my friends, all true.

WHAT WENT RIGHT

Knowing when to scrap a bad plan

I’m glad I switched ideas.

The chase game was still stuck in design, and I’ve been bitten before jumping into development without thoroughly understood gameplay. The idea I came up with was a twist on Flappy Bird, placing it on its side. Instead of flapping for height, you flapped for running speed. Instead of the “height” of a hurdle to get over, buildings of different sizes required a minimum speed to run through (or you get knocked back and your game ends). And to simulate a “roof” to duck under, I added pikes in the ground that you could only tiptoe through; if you ran too fast, you’d trip and get impaled.

It’s a decent twist. It doesn’t quite provide the same depth of experience as a flying game. For example, when flying you may have to fall half way down the screen, but in Flappy Monster (where the running speed correlates to flying height) there are no pikes that require a max of “half” speed. All pikes require you to go pretty slowly, so as a result pikes right before buildings can be quite punishing.

Completed!

Out of 9 Ludum Dares, I’ve completed 6. That’s a terrible stat that shows I have persistent issues with time management. In some cases I’ve hit the deadline very close to a playable game, which I consider a minimum requirement for submitting. (Some people don’t.) Despite my fumbles, I (eventually) leveraged my ability to recognize when plans needed to change, I identified and shifted priorities, and most importantly, I placed utmost priority and focus on the goal completion. Without that, no game!

Working on a Post-Compo version

When the compo ended, the game had only JUST become truly playable, and I was entering a groove where adding features and juice was eminently satisfying. So why stop there? I branched my code and kept working on a post-compo version, albeit at a more-relaxed pace. I added scrolling grass, shaded the monster, cleaned up and animated the pikes, added a demolition rumble effect, smoothed monster movement, tweaked the RNG to be less cruel, and gave the monster an increasing deceleration for faster and more dramatic slow downs. It’s more playable. And I’m still adding things to it. It gives interested players a change to look at something closer to “what I was going for,” and rewards them with a better experience as appreciation for looking. And I get to put in those missing elements that make me happy. :)

That’s a quote from the most excellent Muppet movie Muppets: Most Wanted, and it has nothing to do with this compo entry announcement. I just can get the songs out of my head.

Editor: Sublime Text
Language: Haxe 3
API/FrameworksFlaxen (HaxePunkAsh-HaxeOpenFL)
GitHub Version Control: Base Code and Game Source
Visuals: Photoshop, FilterForge, possible Pixen
Audio: Audacity, Bfxr, Renoise w/VST plugins
Animal: Bad frog! Bad frog!
Fräulein: Evilen froggen! Evilen froggen!

Thank you, Kermit, no more questions.

Time for plan B

Posted by
Sunday, April 19th, 2015 7:49 pm

As usual, I spend the first few hours of Ludum Dare coming up with several game ideas and evaluating them, choosing the one that has the best balance of interesting and completable. This time I made some major gaffs, picking ideas that were required major design work, replacing a good premise with goofy abstract puzzle mechanic that does the original inspiration no justice, failing to focus properly on a day one prototype, and getting distracted with third-party and not so third-party bugs. As such, although it’s almost time for submission, it’s still not actually playable. So, out of eight LDs, about I’m about to fail my third.

It kind of surprises me, falling into the same old traps, but that’s what it is. I had fun doing some pixel art, learning a bit from Derek’s great Make Games Tutorial.

specialist-red bookresearch-green

 

 

 

I’m mulling over the possibility of continuing to work tomorrow and entering whatever I get working into the Jam, but right now I’m tired. Good luck everyone!

Screen Shot 2015-04-19 at 8.29.44 PM

Jam This!

Posted by
Tuesday, April 7th, 2015 9:42 am

It’s that time again to make a public announcement that I’m ready to embarrass myself enter the compo!

Editor: Sublime Text
Language: Haxe 3
API/FrameworksFlaxen (HaxePunkAsh-Haxe, OpenFL)
GitHub Version Control: Base Code and Game Source
Visuals: Photoshop, FilterForge, possible Pixen
Audio: Audacity, Bfxr, Renoise w/VST plugins
Cheese: Cheese? Why are you bothering me about cheese at a time like this?!

Jam on, fellow ludophiles.

Post Mortem: Fireman vs Fire vs Snowman

Posted by
Wednesday, December 10th, 2014 11:50 pm

Fireman vs Fire vs Snowmaninstructions is an avoid-the-bouncing-obstacles game with a rock/paper/scissors twist.  The game takes place on three TV screens, each only showing the same picture but with the objects all different (e.g., whereas one TV shows a fireman, the second shows a fire, and the third a snowman).  You control which one screen is active. On the inactive screens objects blissfully ignore each other, but on the active one you control one of these objects and if it confronts another object something violent happens: either the object kills you (the object’s predator), the object stuns you (a matching object), or you kill the object (the object’s prey). To know what the interaction will be you need to be aware of which screen you’re on (which determines which object you control) and which objects are predator or prey. Killing something causes two new things to spawn, so it can get hard quick! But there are some tricks to make it easier.

This game was written in Haxe 3 using Flaxen, which combines an entity component system (Ash) with a game library (HaxePunk).

playerTiles

What went wrong

So … some things went wrong.

Ran out of time

My usual #1 item from “what went wrong” is running out of time. I fancy some day might occur where everything I put together works perfectly the first time out. I’d be done in four hours that way. Partially it’s caused from rustiness, partly from not having a clear architecture in mind and trying to use agile development. Iterative coding is a great way to focus and reduce bugs, but continuous refactoring is possibly a luxury in a game jam.  Also to blame is trying to take shortcuts that I eventually have to undo anyway, along the way these shortcuts introduce bugs during development that eat up an enormous amount of time. Also, frankly, I’m old and slow. I used to be young and slow, but I’ve never been a fast developer. I was told by an employer once, “You’re slow, but your work is ten times better than anyone else’s.” That’s what I call an affectionate slap. How do I get faster? Reuse of methodology. I’m always coding in different languages with different toolkits in different industries. If I just focused on one way of doing things since I started coding, by know I’d be the fastest coder on the planet. It’d be in TRS-80 Color Computer extended basic, but I’d be the fastest in it…

Lack of animations and special effects

Are these things important? Honestly having sound effects and a musical queue for the titling and between levels was far more vital, but how much better would this have looked with some more graphics? The fireman could actually hose the fire and leave rising steam. The fire could spread over to the snowman who falls apart before melting. And the snowman could freeze the fireman, blowing a cold wind and turning the fireman into crackling ice that then shatters. How lovely that would have been. Ah well. NEXT.

Not a pixel artist

Some of the pixel art from LDJAM participants is freakin’ amazing. I’m very envious. I’m not one of those people who believes you can’t learn, and I’ve done some pixel art tutorials in the past, but I have not practiced. I’m fairly bad at it. I’m better with non-retro art, where I can just go crazy with boxes and circles and photoshop filters, but in this game the main characters were so small there was no way around it. As such the fireman looks more like a hunter, making his relations obscure. (Hunter shoots fire?? Snowman beats hunter with own rifle??) I should practice it more, as it would help my programmer art all over.

Lack of final gameplay tweaking

Although the game was playable at the end of Saturday, it was hard to visualize what the experience would finally be like. On Sunday, I never really got to a point where I said, “Okay, here’s the completed game. Play it for 30 minutes, see what needs changing.” I had an idea that the game would be improved with wave system, bringing out a certain number of enemies at a certain rate, and giving a pause for the next wave while you feel a sense of achievement. But I had this idea too late, and if I got to play it as much as I did in the past couple days, I would have had tested a lot of changes to the difficulty ramping.

tiles

What went right

You know, I submitted a game to the compo in 48 hours, so by that very notion my game was a great success. :) But there were some things that stood out.

The right idea

As usual, I drum up three ideas for a jam before I start developing. I rejected the one that was easiest to develop because it bored me, and after conferring with my significant other also rejected the most exciting one because it would have been hardest to develop. Yay for mediocre? Nah, instead I look at it as a simple balancing issue. The idea has to be interesting, and realistically achievable in the time frame. And this was both. I can always go back to developing the “exciting but difficult” one on my own, later. In retrospect, the idea I chose was also the one I understood the most, mechanically. Those kinds of ideas are easier to prototype.

Focus on playability

I set my goal as having a playable game by the end of Saturday.  As a consequence, I stopped designing even though I didn’t have a fleshed out thematic layer for my idea. I had a list of 15 possible rock/paper/scissor replacements but didn’t like any of them. So I delayed that decision and focused on the mechanics. This meant I could go straight to coding, and it also meant I wouldn’t spend a lot of time on art, and would spend no time on animations, sounds, or special effects until the game was playable. I put together some crappy R/P/S icons and a dull, lifeless game frame, and got to the core gameplay by my self-imposed deadline.

I also was better with my time management. I kept a prioritized checklist on Sunday of things I needed to do and what could be eliminated. I came down to decisions like “do I need two distinct sound effects for these two variant events, or just one?” and “what’s more important, trying to throw together a short music track in 20 minutes or adding a rumble to the screen whenever you’re stunned?” (I chose the former, and barely snuck the tune in.)

Honing my tools before the comp

I moved this May and we sort of took an extended vacation to settle into the Charleston area. We were hosting visitors every other week for a while there! I stopped developing for all that time, and could sense the rust on me.  I updated all of my Haxe libraries. I forgot how much of my library Flaxen works, so I some time to improve the documentation while reminding myself of this toolkit. I fired up Renoise, which I hadn’t used in a year, to discover it was no longer operable. Redownloaded the latest version, found the license key, and then stared at the screen and blink while I tried to recall my workflow and any of the shortcut keys. I throw together some basic tunes just to stretch my old muscles. I should have spent some time putting together a practice game, but this was the next best thing.

Making the theme my bitch

I did not like the Ludum Dare theme “Game Entirely On One Screen” all that much.  It seemed like a very polarizing theme. I generally vote against themes that imply any sort of design limitation, as that can lead to too many games exploring similar ideas or implementing the same mechanics. Also I look to the theme to inspire, much like a writing prompt. Some folks said you shouldn’t let the theme stop you, but you do get rated on theme. I did not realize that this year you’d be able to exempt yourself from categories, although I’d probably feel dirty for not meeting the theme. To cover my bases, I met the theme in three ways:

  1. My game does not scroll, have separate backgrounds, does not have ancillary pages. My instructions are right on the screen the whole time. There is no main menu. The title, like the instructions and the UI, is made up of wooden signs that sit in the upper-right quadrant. Even the start button and “you died horribly” message are signs that peek out from under the pile and slide out when needed.
  2. The game actually contains three TV screens, but because only one is active, the game is entirely on one screen at a time. Some folks felt the need to point out that 3 > 1, as if that feat of mathematical comparison had slipped my attention. I think the three screens was my way of meeting the theme while simultaneously thumbing my nose at it. And I have a considerable proboscis to thumb.
  3. I added a snowman. Many Ludum Dares have a mascot, or some recurring popular secondary theme (potato, for example, in LD #26), and unofficially snowman was it for LD #31. Some might see this as me expressly NOT meeting the theme, but I see it as just another way in which I’m awesome. (YMMV)

It felt really good to complete a Ludum Dare. I hadn’t done so in a year, since LD #28. I failed to complete my game for #29 and I was unable to participate in #30. Thanks Mike.

I’m in for the compo. It’s been a while since I’ve completed one of these things, but let’s give it another go, shall we?

Editor: Sublime Text 2
Language: Haxe 3/OpenFL
Frameworks: Flaxen (HaxePunk and Ash-Haxe)
Base Code: GitHub
Version Control: GitHub
Visuals: Photoshop, FilterForge
Audio: Audacity, Bfxr, Renoise and some plugins

I do enjoy working with an entity component system like Ash, even though the Haxe port hasn’t been updated much this year. I haven’t done much work on Flaxen lately,  so I really should spend a little time this week to take it for a spin and make sure everything works rather than wasting my weekend fixing my tools. Good luck, everyone!

Debacle shutdown commencing

Posted by
Sunday, April 27th, 2014 2:50 pm

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:

  1. 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.
  2. 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.
  3. 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. :)

spriter

You Set Us Up The Bomb: Post-Mortem

Posted by
Friday, January 3rd, 2014 7:31 pm

explosionYou 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

bombTime 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…

bombBugs 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.

bombDidn’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

bombSticking 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.

bombFocusing 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.

bombExplosions 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.

Ludum Dare 28 Entry Announcement – now with 10% more fanfare

Posted by
Saturday, December 7th, 2013 4:29 pm

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.]

Offspring Post-Mortem: So You Want to Make a God Game?

Posted by
Tuesday, August 27th, 2013 1:43 pm

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.

17811-shot3    17811-shot1  17811-shot0-1  17811-shot2

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

 

Offspring’s application of theme considered harmful

Posted by
Saturday, August 24th, 2013 3:01 pm

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?

Offspring

Posted by
Friday, August 23rd, 2013 11:15 pm

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. :)

Screen Shot 2013-08-24 at 2.07.03 AM

The XML file driving a rules based system

10 seconds … 9 … 8 …

Posted by
Friday, August 23rd, 2013 6:35 pm

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. :(

It’s time for that thing again

Posted by
Wednesday, August 21st, 2013 3:30 pm

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.

Think smaller

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.

Toolkit practice

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…

BFXR

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.

Once more into the breach

Posted by
Friday, April 26th, 2013 2:53 pm

I’m in for the compo. Too bad about the potato theme, though…

Editor: Sublime Text 2
Language: Haxe/NME
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!

[cache: storing page]