About hazzen (twitter: @hazzen)

Entries

 
Ludum Dare 28
 
Ludum Dare 25
 
Ludum Dare 23

hazzen's Trophies

hazzen's Archive

Postmortem: Save Yourself

Posted by (twitter: @hazzen)
Thursday, December 19th, 2013 12:05 pm

I went into this LD with a bit of a cloud; the past two LDs I attempted did not end well. For LD25, I let my ideas run far, far, far ahead of my deadline and ended up with an incomplete grab-bag of ideas. For LD24 before it, I completely burned out trying to make a point-and-click adventure game. I’ve never made one before; I don’t even play the genre much. I, honestly, had no clue what I was thinking.

I came into LD28 with one goal – to come up with a single mechanic and make a game of it. Similar to Doggone, the better of my two previous entries. I think Save Yourself does a good job at this goal. As a game, it has some definite shortcomings.

Briefly, the game is an arena shooter (Robotron, Geometry Wars). When you die, time rewinds to the start of the level and your previous life replays all of its actions. You get another ship and must kill whichever enemy killed your previous life, as well as not dying. As long as you prevent your past life from dying, and live past when you originally died, you can do it again – you never died in the first place, after all, so you can still go back in time. Fail to save yourself and it is game over.

 

What went right:

  • Scoping: I picked a genre I’ve built games in before and then went for a mechanic. Just a mechanic. No upgrades, no branching paths, no difficulty modes. First make it fun, then go for more.
  • Lazy solutions: On death, I could have implemented a cool rewinding animation to go back in time; I thought this would take an hour or two and decided it was avoidable polish. Good idea. Also, my “deterministic” update loops aren’t, really. They are close, but not perfect. So, if a recorded player would ever die before it should have, I just flash a “desync” message on the screen and don’t do anything. Your recordings are invulnerable to everything but the single enemy that killed them.
  • Taking it easy: I kept a normal schedule; hell, I called my game down with something like 9 hours left in the compo. I could have done that rewind animation, or added sound, or upgrades, or even something like progressive difficulty. Instead, I slept and was happy.
  • Simple graphics: While this was my first compo game in WebGL, I’ve been toying around with it for a while. I made sure my (hand-built) engine supported normal maps and called that good. Comparing the sprite sheet to the in-game graphics shows how much detail that gets:

spritesIn-Game Shot

What went wrong:

  • Visual aides: I tweak the color of any enemy that caused a previous death, but it really doesn’t highlight the difference and it isn’t obvious what is going on. Sure, I can tell, but I’m not sure others can.
  • Graphics glitches: I was really lazy with my graphics; I’m using texture atlasing, but not doing anything to prevent mipmap bleeding. I could have taken the lazy solution and just put some padding in my atlas, but I thought the glitches didn’t look too bad. Also, my alpha is just completely wrong. Whoops.
  • Features/balancing: I guess I decided not to do this, but the game could really have used either some form of ugprades, or a difficulty curve. As it is, the easiest way to survive a long time is to die, intentionally, every 5 seconds or so after your previous death. That lets you clear a bunch of enemies in your life, while not allowing too many to build up before your next life will come in.

In again, with lessons learned

Posted by (twitter: @hazzen)
Tuesday, August 7th, 2012 10:32 am

In again, after completely failing for LD #17 then taking a break and actually entering something in LD #23. Not a complete game, mind you, but still something. This time, I hope to make something that has a win or lose condition, not just a toy.

Doggone Postmortem

Posted by (twitter: @hazzen)
Tuesday, April 24th, 2012 1:59 pm

My entry long ago submitted, time for a postmortem/wrapup/etc.

My original plan was for a god game in the vein of Populous. My final game was a dog running around a tiny circular world and catching frisbees. A lot can change. I spent ~13 hours, total, on the submitted game. It is written in Javascript with a custom “engine” – I pulled in keyboard handling and 60fps rendering/game loop code from a previous 48h comp but otherwise had no pre-built engine. All assets were created in Pickle and modified with Paint.NET and Gimp, depending on my needs. Music and sound effects were created in Aviary’s Roc and tweaked/trimmed in Audacity.

The Populous game ended up being a waste of the entire first evening – I spent too long making something look good (it didn’t) without considering the game, the fun, anything. I went to bed with a triangle mesh sphere that couldn’t rotate north/south and thoughts of just quitting and enjoying the weather forecasted for the next day. Instead, I got an idea that morning for a quickly implementable game and ran with it – run around as a dog, catch frisbees. I had way more ideas than I had time or desire, so I ended up with something far different than the original idea. Which was this:

You are a dog that runs around a (circular) world. You must contend with a basic simulation of running as a dog such as taking a while to turn around and worrying about slipping. There would be pits, obstacles, mud, and other things to hamper the running. A frisbee would spawn, thrown by some unknown entity and a inset hud element would show up like in a space sim; it would contain the velocity, position, spin, and tilt of the frisbee. Having to contend with the wind on top of the environmental hazards, you would attempt to catch the frisbee. Rinse and repeat.

Everything from that but the dog and concept of catching a frisbee got cut – it became about peacefully running around this little planet, getting some air off of hills, and nabbing frisbees. You can see a general progression of the game’s graphics:

The biggest change was the final level of polish. Each segment of the world had, up to that point, been colored by randomly selecting a green in a specific range of colors. Two adjacent segments could be colored randomly and would clash; I modified the coloring to pick a random segment, permute its color by a small amount, and then spread that to the two left and two right neighbors of the segment, falling off a bit at each. The camera also moved up – the ground is boring and plain beyond the hills, but the sky is interesting. Also, when in doubt, look at Mario – he is usually towards the bottom 1/3 of the screen. I also added a “shadow” world behind the main segments to create some fake depth; I initially had it parallax, but this was distracting so it rotates at the same rate as everything else.

What went right

  • Polish. Polish polish polish. I spent a long time on “feel” and “style”. Having the dog get air when running off a tall hill; making the dog get a little “ahead” of the camera when running; clouds moving at slightly different speeds. In my (only) previous 48h game, I spent maybe 3/4 of the time writing engine/game rule code; the rest of the time was spent on feel and polish. Here, it was close to 50-50 if not even more time spent on polish.
  • Aggressive cutting of features. This was helped by deciding to not spend 48h on the game. I think I spent 13h on it (plus a previous 6-7h on my initially thrown away idea). I took breaks, I sat in the sun. This was a boon, though it also means the game was short on game. But, if anything took more than an hour, I said whatever state it was in was done and I moved on to something else. I might revisit, but an hour was the most time to spend on any one thing. Most times it was 30 minutes or less.
  • Simplicity. I didn’t use any engines; only some previously-written (and published) keyboard handling code and canvas2d setup/framerate code. My only collision detection needs were deciding which side of a line a point was on and colliding two arc segments (which is the same as two line segments, hence a single line of code). The previous 48h game, I had a full 2d collision detection engine that did mid-frame detection. It was buggy as hell and entirely unnecessary to write for the jam.
  • Knowing my tools. I had previously written an HTML5/javascript/canvas2d game and done simple sprite work in Pickle + Paint.NET + Gimp. The only tool I learned during the jam was Aviary’s Roc for the music/sound effects. Saved a few hours at least by doing this.

What went wrong

  • Motivation. Throwing away a night of work, going to bed late and grumpy, and waking up to 80 degrees and sun was hard. I had, in fact, sent an email to my partner saying “you won’t be a code widow this weekend, lets enjoy the weather”. Only to go for a jog, get hit by inspiration, and say “never mind”. I still spent much of the weekend not coding, so the game was short on everything.
  • Lack of paper-and-pencil time. I spent barely any time thinking or writing away from the monitor. It is easy to get into a rut or logic loop and lose 30 minutes running in place. You also need to validate your ideas; when you just start coding, it is easy to spend hours working on something that would have taken 5 minutes of thinking-time to decide wasn’t fun.

In for the jam

Posted by (twitter: @hazzen)
Wednesday, April 18th, 2012 9:26 am

The rules say I should “publish” my hand-crafted “engine” on this board to qualify – so https://github.com/hazzen/pidgine is my planned base of code, a minimal set of stuff based on my Molyjam entry. Other tools: paint.net/gimp, vim, sfxr if I decide to do sound.

[cache: storing page]