{"author_name":"scriptorum","cat":"LD #31","comments":[],"epoch":1418273400,"likes":2,"metadata":{"p_key":"22146","p_author":"scriptorum","p_authorkey":"17811","p_urlkey":"57511","p_title":"Post Mortem: Fireman vs Fire vs Snowman","p_cat":"LD #31","p_event":"LD31","p_time":"1418273400","p_likes":"2","p_comments":"0","p_status":"UPD5","us_key":"17811","us_name":"scriptorum","us_username":"\/author\/scriptorum\/","event_start":"1417737600","event_key":"26","event_name":"LD31"},"text":"

Fireman vs Fire vs Snowman<\/a>\"instructions\"<\/a> is an avoid-the-bouncing-obstacles game with a\u00a0rock\/paper\/scissors twist. \u00a0The game\u00a0takes place on three TV screens,\u00a0each only showing the same picture but with the objects all different (e.g.,\u00a0whereas one TV shows a fireman, the second shows a fire, and the third a snowman). \u00a0You control which one screen is active. On the inactive screens objects\u00a0blissfully ignore each other, but on the active one\u00a0you control\u00a0one of these objects and if it confronts another object something violent\u00a0happens: either\u00a0the object kills you (the object’s\u00a0predator), the object stuns you (a matching object), or you kill the object (the object’s prey). To know\u00a0what 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\u00a0there are some tricks to make it easier.<\/p>\n

This game was written in Haxe 3 using Flaxen<\/a>, which combines an\u00a0entity component system (Ash<\/a>) with a game library (HaxePunk<\/a>).<\/p>\n

<\/h1>\n

<\/h1>\n

\"playerTiles\"<\/h1>\n

What went wrong<\/h1>\n

So … some things went wrong.<\/p>\n

Ran out of time<\/h2>\n

My usual #1 item from “what went wrong” is running out of time.\u00a0I fancy some day might occur where everything I put together works perfectly the first time out. I’d\u00a0be done in four\u00a0hours 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\u00a0a great way to focus\u00a0and reduce bugs, but\u00a0continuous refactoring is possibly a luxury in a game jam. \u00a0Also 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.\u00a0I 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\u00a0ten times better than anyone else’s.” That’s\u00a0what I call an affectionate slap. How do I\u00a0get faster? Reuse of methodology. I’m always coding in different\u00a0languages\u00a0with different toolkits in different industries. If I just focused on one way of doing things\u00a0since I started coding,\u00a0by know I’d be the fastest coder on the planet. It’d be in TRS-80 Color Computer extended basic, but I’d be\u00a0the fastest in it…<\/p>\n

Lack of animations and special effects<\/h2>\n

Are these things important? Honestly having sound effects and a musical queue for the\u00a0titling and between levels was far more vital, but how much better would this have looked with some\u00a0more graphics? The fireman could actually hose the fire and leave\u00a0rising steam. The fire could\u00a0spread over to the snowman\u00a0who 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.<\/p>\n

Not a pixel artist<\/h2>\n

Some of the pixel art from LDJAM participants\u00a0is 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\u00a0art, where I can just\u00a0go crazy with boxes and circles and photoshop filters,\u00a0but\u00a0in this game the main characters were so small there was no way around it. As such the fireman looks more like a hunter, making\u00a0his relations obscure. (Hunter shoots fire?? Snowman\u00a0beats hunter with own rifle??) I should practice it more, as it would help my programmer art all over.<\/p>\n

Lack of final gameplay tweaking<\/h2>\n

Although the game was playable\u00a0at the end of Saturday, it was hard to visualize what the experience would finally\u00a0be 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\u00a0changes to\u00a0the difficulty ramping.<\/p>\n

\"tiles\"<\/h1>\n

What went\u00a0right<\/h1>\n

You know, I submitted a game to the compo in 48 hours, so by that very\u00a0notion my game was a great success. \":)\" But there were some things\u00a0that stood out.<\/p>\n

The right\u00a0idea<\/h2>\n

As usual, I\u00a0drum up three ideas for a jam before I start developing. I rejected the one that was easiest to develop because it bored me, and\u00a0after conferring with my significant other also rejected the most exciting one because it would have been\u00a0hardest to develop. Yay for mediocre?\u00a0Nah, instead I look at it as a simple balancing issue.\u00a0The 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,\u00a0later. In retrospect, the\u00a0idea\u00a0I chose was also the one I understood the most, mechanically. Those kinds of ideas are easier to prototype.<\/p>\n

Focus on playability<\/h2>\n

I\u00a0set my goal as having a playable game by the end of Saturday. \u00a0As a consequence, I\u00a0stopped designing even though I didn’t have a fleshed out thematic layer for my idea. I had a list of 15 possible\u00a0rock\/paper\/scissor replacements but didn’t like any of them. So I delayed\u00a0that decision and focused\u00a0on the\u00a0mechanics. 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\u00a0R\/P\/S icons and a dull, lifeless game frame, and got to the core gameplay by my self-imposed deadline.<\/p>\n

I also was better with my time management.\u00a0I kept a prioritized checklist on Sunday of things I needed to do and what could be\u00a0eliminated. I came down to decisions like “do I need\u00a0two distinct sound effects\u00a0for these two\u00a0variant events, or just one?”\u00a0and “what’s more important,\u00a0trying 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\u00a0snuck the tune\u00a0in.)<\/p>\n

Honing my tools before the comp<\/h2>\n

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\u00a0all that time, and could sense the rust on me. \u00a0I updated all of my Haxe libraries. I forgot how much of my library\u00a0Flaxen<\/a>\u00a0works, so I\u00a0some time to improve the documentation while reminding myself of this\u00a0toolkit. I fired up\u00a0Renoise, which I hadn’t used in a year, to discover it was no longer operable. Redownloaded the latest version, found\u00a0the\u00a0license key, and then stared at the screen and blink while I tried\u00a0to recall my workflow and any of the shortcut keys. I throw together some basic\u00a0tunes just to\u00a0stretch my old muscles. I\u00a0should <\/strong>have\u00a0spent some time putting together a practice game, but\u00a0this was the next best thing.<\/p>\n

Making the theme my bitch<\/h2>\n

I did not like the Ludum Dare theme “Game Entirely On One Screen”\u00a0all that much. \u00a0It\u00a0seemed like a very polarizing theme.\u00a0I generally vote against themes that imply any sort of design limitation, as that can lead to too many games\u00a0exploring 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\u00a0ways:<\/p>\n

    \n
  1. My game does not scroll, have separate backgrounds,\u00a0does not have ancillary pages. My instructions are right on the screen the whole time.\u00a0There is no main menu. The title, like the instructions and the UI, is\u00a0made up of wooden signs that sit in the upper-right quadrant. Even the start button and “you died horribly” message are signs\u00a0that\u00a0peek out from under the pile and slide out when needed.<\/li>\n
  2. The game actually contains three TV screens, but\u00a0because only one is active, the game is entirely on one screen at a time<\/em>. 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\u00a0while simultaneously thumbing my\u00a0nose at it. And I have a considerable proboscis to thumb.<\/li>\n
  3. I added a snowman.\u00a0Many Ludum Dares have a mascot, or some recurring\u00a0popular secondary theme (potato, for example, in LD #26), and unofficially snowman was it for LD #31.\u00a0Some might see this as me\u00a0expressly NOT\u00a0meeting the theme, but I see it as just another way in\u00a0which I’m awesome. (YMMV)<\/li>\n <\/ol>\n

    It felt really good to complete a Ludum Dare. I hadn’t\u00a0done 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<\/a>.<\/p>\n \n

    Tags: Ash<\/a>, Flaxen<\/a>, haXe<\/a>, haxepunk<\/a>, LDCompo<\/a><\/p>","time":"December 10th, 2014 11:50 pm","title":"Post Mortem: Fireman vs Fire vs Snowman"}