Post-Mortem

The long lost #1GAM October Report: Gameboy Jam Post-Mortem – Pixel Soldier

We participated in the Gameboy Jam in the beginning of October last year. The challenge was to create a Game Boy themed game, using only 4 colors and a screen-resolution of 160×144, within a week. I additionally constrained myself to the original Game Boy input scheme, consisting of only a D-Pad and two primary and two secondary buttons. And thus, Pixel Soldier was born.

Getting the Idea

Ever since I first saw Vlambeer’s incredible talk “The art of screenshake“, I wanted to make some “prove of concept” where I just deliberately implement everything from this awesome talk. So I started to ask myself how would my game differ from any other side-scrolling shooter and somehow the idea of replacing jumping with something more interesting emerged. After having settled on shooting and dashing as the main mechanic, I can’t deny that I have been heavily inspired by Alien Soldier. A game I absolutely love, simply one of my all-time favourite games. It can be boiled down to being a boss rush, with very short stages followed by action packed boss-fights.

pixel_soldier_boss_collage.png

Ratings

The jam itself went pretty great, hardly any progress for days, and finally doing 90% of the work mere hours before the deadline. One day I’m going to find out, what causes the surge in productivity shortly before deadlines and I’m going to use it to boost my every-day productivity, although it’s probably just an unhealthy dose of adrenaline and stress.

The game got 12th place in “Overall Gameplay” out of 398 entries, which is quite a feat. Despite the crappy graphics, it was apparently a lot of fun for the people playing it. “Graphics” was the second weakest aspect, but no wonder since it was essentially full of place holder art.

artwork_comparison.png

Left: First boss in the Jam Submission.  Right: First boss after revamping the graphics.

The weakest aspect was “Gameboy Feel“, which is very understandable, because a game with as many sprites as this, would have never run on an original Gameboy. But historic accuracy was never the intention anyway. The intention was just to make a fun game within the constraints given.

But enough of that, let’s talk about the lessons learned.

Lessons Learned

Improving Sound design

The talk “Why your Death animation sucks” has tips for game polish (or game “juice”) and is just full of awesome advice (not only for sounds) and is up there in quality with the famous “Juice it or Lose it” talk.

It was very difficult to balance the sound effects of the main gun. Make it too loud and it gets annoying. Make it too silent and the weapon feels weak. I think the weapon turned out a bit too weak, but better than the alternative of being annoying.

Having multiple shooting sound effects with different pitch was also essential in breaking up the repetitiveness, since the player is hearing that sound effect A LOT.

Multiple Difficulty Settings multiply the Testing Effort

It might seem obvious now, but including multiple difficulty settings seemed as a quick way to add replayability and add options for people of different skill levels.

But every difficulty setting has to be balanced and individually tested, which obviously increases the effort required significantly.

Limit Feature Creep from the Beginning

I deliberately limited myself to exactly one page for the “Design Document” before I started coding. I think this helped immensely to keep the project scope small enough for the jam. One might think that this restriction is too harsh, but despite this I still ended up cutting most of it, since things always take longer than one anticipates at first.

gbjam_idea

The full “Design Document”

Checkpoints

Another jam, another far too hard and punishing game. After having played hundreds of hours during development, it seems like the difficulty is alright. No, it’s not. Make it less punishing. Just add in checkpoints, don’t force everyone to play it in one go.

The Future for Pixel Soldier

After the jam I kept working on it and released an update in January. Even after working on it for months I still enjoy playing it and I’m still excited about the potential of all the features I had initially planned.

There are so many ideas scrapped and so many new ideas emerging while working on it, that I really want to make a proper sequel with everything in it. Weapon Power-ups, different stage layouts, epic multi-stage bosses and generally just more of everything.

But for now I have planned some updates to Pixel Soldier, polishing it until it’s a nice vertical slice of what the sequel could be. Expect some updates in the near future.

-Anton

#1GAM July 2016: Turtle Trouble

The Game

The Game, called Turtle Trouble, is hosted on GameJolt and you can play a web-version or download the desktop version (Windows/Linux/Mac). It’s a short platformer with six levels that will take you about 10 to 15 minutes to complete.

 

For my first monthly Game I decided to create a simple platformer, doing my part of the job to reinforce the indie cliche. Additionally I wanted to focus on the player controls to feel good, and I’m quite happy how they turned out.

It was planned for July but I only finished it now, because it was far too ambitious and far from “simple” for a month long project. I’ll consider it a delayed fail for the July Challenge. I intend to do a small bullet point post-mortem for every monthly challenge, so here it goes:

What went well:

  • Cut it out: I wasn’t afraid of cutting out a lot of features I initially thought were absolutely necessary. It’s really shocking when you realize, that the game is perfectly fine without them. But those features were cut out too late, out of necessity, instead of in the initial planning phase (see the bad points.)
  • Mario-like physics: There are some awesome people out there that completely reverse engineered the physics for the original Mario games (and also Sonic). The physics for Turtle Trouble are loosely based on the physics of Mario, and it really helped making it feel quite responsive and fluid.

What went wrong:

  • No MVP: There was no real point during development where I thought: “I could ship this now, and nobody would notice there are things missing/not properly done”. Instead of finishing one feature after another, I half-assed a bunch of them and only completed them by the very end.
  • Level Design not fully explored: It’s surprising how there are still a lot of interactions/combinations of existing features that are missing and could be explored. But to keep scope small I decided on a small amount of levels. There are two player abilities that are only really needed once (stomping, sliding), and that’s the time they are introduced. Other objects that would have interacted with this two abilities were cut, which makes them feel like tacked on. Further strengthening the point that it’s better to have a few fleshed out features, before you start implementing new features you don’t even know you need yet.
  • Art isn’t my strong point: I spent far too much time on sub-par graphics. I should either decide on a less graphics intensive art style, have someone else make the graphics (or get pre-made ones) or else I’ll have to plan a lot of hours on graphics alone (which eventually turn out to be mediocre).
  • Abrupt ending: Another thing that was cut, was the bossfight that should represent the finale. Not having a bossfight is ok, but there is nothing to provide a proper conclusion. The difficulty at the end is not especially harder than the rest of the game. It sort of just suddenly ends, making it feel almost incomplete.
  • Crunch Mode: Approaching the last week of the month I started crunch mode, working unhealthy hours on it, just to try and get the list of features working in time (before I eventually cut scope in half (again)). This was due to underestimating the amount of work needed for the scope I came up with and overestimating the amount of hours available in a day for Gamedev when already working a 40 hour week. (Just writing this post delayed everything another day, aaaaaahhhhhh)

Lessons learned:

  • Create a Minimum Viable Product:
    • Less is More: Boil the features down to the bare minimum. All those fancy features you think you will need, are actually completely unnecessary. The complexity of adding new features seemingly rises exponentially, as new features will interact with every other part of the game already present.
    • Vertical instead of Horizontal Prototype: Fully implement the current feature, before starting another. It’s better to have one complete level, than a hundred incomplete levels.
  • Quick Animations: If you can’t draw well, go for quick animations with a high frame rate. The individual frames don’t have to look that pretty and fluid animations look a lot better than “fancy” choppy animations.
  • Reduce Scope Even More: There are far less hours in a day than you think. Don’t plan on having to do Crunch to complete your scope, but reduce scope beforehand instead. There are other things in life than Gamedev too.

Conclusion

A lot of these points are actually nothing groundbreaking. They are tips that can be read over and over again. I literally linked to a video going over most of them in my last post, and yet I keep forgetting about them. That’s why I’m writing them down, as I think having to put them in your own words helps appreciating them.

Any time now I’ll have an twitter account set up, I swear. It’s just that naming things is really hard.

Also I have yet to find a way to easily record Gameplay GIFs on my Linux machine. As the handy GifCam is only available for Windows.