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.



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.


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.


The full “Design Document”


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.


#1GAM September: “Hello, Alien!” released on Google Play

For the September One Game A Month challenge (#1GAM), we decided to polish “Hello, Alien!” and release it for Google Play. We previously had problems publishing on Google Play, but we finally had access to a credit card, so we went for it. You can still get it on too.

Some might say, that this doesn’t qualify for a #1GAM release, as we didn’t even port the game to another platform, just release it on another marketplace. But we updated it quite substantially and setting up a Google Play Store Page was a whole new challenge for us. So I would argue, it still counts.


We polished the artwork, streamlined the HUD, added more visual indicators, refined all the levels, made small performance improvements and fixed many bugs.

Screenshot from 2016-09-25 11:55:38.png

Old VS New HUD

Despite all this changes, I’m still not happy with it. Everywhere I look, I see flaws, some tiny, some large. Yet, in the spirit of the #1GAM challenge, I just published it at the end of the month, instead of spending an undefined amount of time trying to make it “perfect”. I guess this challenge is not only about learning to hit deadlines, but learning to “let go”.

This #1GAM reports have usually been about the Good, the Bad and Lessons Learned, but I think I’ll cut it down to just the Lessons Learned, as they are the most important thing to take away from this challenge, and it makes this easier to write.

Lessons Learned

Marketing is hard, good Marketing is even harder (and takes a lot of time)

We all know the hardships of marketing: providing a good first impression, evoking interest and finally convincing the potential player, that your game is worth their time. This also holds true if you provide your game for free.

Some things to take away (and how we failed them):

  • Have a video of gameplay. Videos are the best way to show what your game is about. I sadly never bothered to record a video, partly because recording and editing a quality video is difficult and partly because you need surprisingly good hardware and software. But having a video is essential to conveying prospective player a feel for your game, especially if your screenshots aren’t telling much. Speaking of which.
  • Provide your best screenshots. The screenshots are the first thing a player is going to see when they visit the store page. Out of the whole game they will only see mere snapshots of it, so make sure that those are the most appealing moments of your game you have to offer. But I honestly have no idea how to create the most awesome screenshots. If somebody finds out, please tell me.
    Looking at our own screenshots, I doubt it would convince myself to play the game. I’m not really proud about the artwork and the kinda incoherent artstyle.
  • Screenshots and recordings can expire. So you spent one day making all those great screenshots and recording gameplay and whatnot, and probably feel pretty proud of yourself. Cool! Then you go and rework the HUD, delete some levels, add particle effects and maybe update the player sprite. Great! Now all your previous hard work has been invalidated, rendering everything outdated, not representative of the final state of the game.
    Sometimes that’s no big deal, because the player probably won’t notice small details. However, if a screenshot shows a level that isn’t really in the game, it somehow feels like lying to the player. Sometimes this means placing a disclaimer with “beta footage”, and sometimes it just means straight-out redoing everything.
    Don’t be a fool, record gameplay last. (Note: I’m talking about screenshots/videos/trailers on store-pages, where you present your game, and what’s in it. Having outdated screenshots on Development Blogs and Social Media is totally okay, if not even mandatory.)

Google Play is powerful but setting up a store page can be complicated

The Google Play Developer Console is a really powerful tool, providing a lot of statistics and ways to manage your game. It can be overwhelming at times, as you can literally spend weeks reading documentation and help pages. There are so many things I never even knew I could think about, that suddenly need a decision.

  • So many regulations. You need to fill out a questionnaire to find the proper content rating for your app. Suddenly tiny details matter. For example, there is one question, whether there are references to alcohol in your game. And I know for a fact, that there is exactly one line of text that one alien says, that indirectly references drinking alcohol. Suddenly questions appear like: Should I remove that single line to avoid having to rate it as containing references to alcohol? Should I just remove all the silly text? Will anybody notice if I just don’t tick that box? Does anybody even care about the content rating? I know I’ve never cared about it.
  • Banners and icons. Not only is it an own science to create appealing ones, they also have to be of specific sizes. The launcher icon is even needed in multiple sizes.
  • Think about localisation. In an attempt to have an international or even global reach, I use English in my games. But this completely neglects all the geographically local players, that don’t speak English (or prefer not to), but prefer my mother tongue instead. I could easily translate the game to German, without having to hire a translator. It would most likely be worth the effort to implement internationalisation, but I never bothered to. The least I could do, was to provide a German store description.
    Of course, the best approach is, to explain your game without using words, just with interactive tutorials that use symbols and graphics.

This post is slowly getting out of hand, and there is still so much to talk about. Maybe I’ll write more about this another time, and cut it short here.

When you think something is obvious, it isn’t

Having played the game quite some time during development, you start to internalize how things work. That’s why it is absolutely mandatory, to watch other people play your game, to get some reality check.
Whenever you give your game to play testers and you have to interfere and help them or show them how something is done, your design has failed. Note down those things and improve on them. It’s your job as a designer, to educate your players through the game itself, be it through tutorials or intuitive design.

Make tutorials interactive, don’t only SHOW them how something is done, make them actually DO it. “Show, don’t tell.” becomes “Let them do what you show.”. And provide feedback, whenever the player does something right. Reward them with flashy particles and let them know, they did it right.

Avoid sunken cost fallacy

There have been lots of features, that I spent a long time implementing, that didn’t turn out great. It’s really hard to cut those features. Humans tend to think, something gets inherent value because they spent a lot of time on it, and it would be a waste to throw it away, but that’s simply not true. Ultimately, if it really isn’t that awesome, the game is worse off because you stuck to it. *insert joke about polishing a turd here*


Really late “monthly” blog post this time, but I’m slowly catching up. The next one will follow shortly, accompanied by an update to Pixel Soldier. I guess this is the part where I should advertise our Twitter, so you don’t miss it.

August #1GAM: Failure

Month #2 in the “One Game A Month“-Challenge. For this month I started working on a turn based tower defense game, just seeing how combining this two ‘genres’ would work out. It got to the playable prototype stage, but it’s far from a Minimum Viable Product.

What went Well:

  • Tracking Tasks Online: We started to use Trello to track tasks, and I think it is a massive improvement over text files with tasks synced over Dropbox. For a small team it has enough features but is still simple enough to not be a hassle to use. We will see how this will work out in the months to come.

What went Wrong:

  • Scope Small: It’s like a running gag, but it seems like software developers just really like to either underestimate effort, or overestimate their capabilities… Either way, the scope was again too large for one month, I have to learn to really change my mindset, lower my expectations and think smaller. I could have probably cut a lot more features to make the scope more manageable.
  • Learning New Tools Can be Taunting: I intended to learn to use Overlap2D, a visual ui/level/content editor, for creating the UI and importing it to libGDX. I had to jump through some hoops to get it to start on Linux, then toyed around with it a bit, and also read some documentation, but didn’t really know where to start, so I postponed it for later, but never got to it again.
    I’m still interested in using Overlap2D to make creating UI easier, but I really gotta plan in some dedicated days just for learning how to use and integrate it into my toolchain/workflow.
  • Sleep Well: Previous week I never got more than 6 hours of sleep, causing me to be sleepy by the time I got back home from work in the evening. But I didn’t want to go to sleep because I didn’t to much Game Dev the last day, but I couldn’t work efficiently, because I was exhausted from sleeping so few hours, which caused me to waste hours I could have better spent sleeping, continuing the cycle the next day…
    Essentially a whole week was lost through this. Few hours of concentrated work are better than many hours of working while desperately trying not to fall asleep. So do yourself the favor and go to sleep!


In Other news, we finally set up our twitter account, now we just gotta use it. We will probably be tweeting about game-releases, blog posts and stuff under the handle @aawesomestudios. (Yes, that’s the maximum length for twitter names. Yes, any similar/shorter names have already been taken.)

We have been at the Game Dev Days Graz. It has been an awesome experience, talking to other game developers, playing their games and listening to all the talks. Maybe next year, we will be there showcasing our games. Who knows.

For the next month we are going to focus on polishing up some older games.


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


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.

A month, a game

Finishing a game is difficult. Whether it’s an unfinished prototype done in a day, or an abandoned project that has been dragging on for months and eventually falls victim to feature creep. I keep on doing all this work, but still have nothing to show for it.

That’s why I decided to join the One Game A Month Challenge. I think it’s a really great idea to set yourself deadlines to not lose your goals out of sight and stay motivated to push forward. The games don’t have to take a month to complete. Some will be made within a few days for a game jam, other times I will finally complete a half-finished prototype that’s been lying around for months. The challenge is to complete a game by the end of the month, no matter how I get there.

Dealing with Failure

I often toyed with the thought of joining the challenge, but this time it’s serious. Starting with July I vowed to make a game every month. That’s right, it’s already August. Of course I start off by missing the first deadline. I’m still unsure how to handle the failure situation with this challenge.

  • If I just postpone it to next month’s challenge, it’s no real deadline, and it will keep on growing the same way as always.
  • If I just stop working on it by the end of the month, it will stay an unfinished game like all the other prototypes.
  • If I just release it unfinished, well… then it’s not a finished game, and that’s not point of this challenge either. (Still, trying to reach an unachievable “perfect” state has to be avoided.)

This time I decided to go with option 1. I keep on working on it for another week, because that’s what I felt was still needed. Meaning tomorrow I should have it “finished”. But this approach is with its pitfalls, because I caught silly me trying to add in more features as I felt the pressure of the deadline moving away, although the features already present weren’t finished yet!

Starting this month I will try the following approach: If by the end of the month, the game I’m working on still isn’t finished. I stop working on it, and I’m not allowed to work on it again, before I haven’t finished another (preferably smaller) game the following month.

Worst case scenario: I’ll keep adding to my heap of unfinished prototypes, rather than working for months on projects that lead nowhere. Best case scenario: I’ll actually start to finish games.

Documenting the process

I plan to write at least one blog post about every month’s challenge, about the game itself, the things that went well, the stuff that didn’t go well and lessons learned. No matter if I actually finish the game or if I fail.

I’m also planning on taking an active part in the community. The Gamedev community doesn’t seem to live anywhere in particular but Twitter seems like a good starting point to share progress and post announcements to and such.


The goals I want to accomplish by joining this challenge:

  • Learn how to tackle larger games, by finishing smaller ones first.
  • Learn how to create an MVP (Minimum Viable Product) to actually finish games.
  • Learn to fail faster.
  • Learn to effectively fight Feature Creep.
  • Learn to accurately estimate Scope and Effort of planned Projects and their Features.

There are many guidelines and tips for reaching this goals, now the only thing left is actually executing them.

Next Steps

Next steps include setting up a twitter account and deciding where I’m gonna host my monthly games. ( and Gamejolt have been great so far, but maybe Newgrounds could be the right place?)


This actually turned out waaaay longer than I expected.

Retrospective of 2015

What, we are already over two months into 2016? You mean 2015 is already over? Wow, it’s really easy getting into the mental-trap of saying: “I’ll post some progress update later, when I really have something to show.”  Another week passes, again nothing happens… And suddenly the year is over!

2015 was a pretty exhausting year for me, I had many months where I just couldn’t bring up any motivation for game development. So, what did I manage to do in 2015 besides moping and starting game prototypes that led nowhere, let’s see:


~February: I found some time to participate in MiniLD #57 with the theme “Reverse”. Created a reverse Match-3 game. It’s playable, but mostly proof of concept. (And couldn’t get the web-version to work.)


~March: Made a quick joke “game” called Infinitris. It’s tetris on an infinitely large playing field. I was motivated to finally test out chunked maps, which allow for (nearly) infinite worlds, and it works pretty well. There are so many possibilities this could be going, but it is a fun toy as is.

~Juscreen_1457547820.85.jpgly: Participated in the IndiesVSGamers Game Jam, hosted by GameJolt. The theme was ‘Arcade’ the time limit was 72 hours and the ambitions were high. Therefore the game “Space Scrap” was born (naming things is hard), a shmup were you assemble your spaceship from spare parts lying around on planets while under constant time pressure, fleeing from a supernova. The original 72h version plays and looks horrible, but I’ve been working on it on and off, and it starts to be a really kick-ass game. I’ll try to focus on it next, getting it done soonish.

That’s my first game hosted on GameJolt, and I have to say: I like it. It makes adding highscores and trophies a breeze and provides a clear and professionally looking game page.

thumbnail_small.png~August: Participated in MiniLD #62 with the theme “Final Boss”. Created a simple platformer, where you play a robot with a sawblade, using it to attack, defend, cling to surfaces and push yourself around. Had lots of boss ideas, but only managed to implement two of them. It’s unhandy to play with keyboard, but plays fluently with a gamepad.


~December: Participated in LudumDare 34, which had a tie between the themes “Two Button Controls” and “Growing”. Didn’t stop us from ignoring both of them, to create a random RTS about managing your Space Colony and sacrificing your people to calm the wrathful gods. This is absolutely missing a proper tutorial, so playing it can be confusing, and trying to win is a real challenge.

So, that wraps up 2015. With a post only over half a year late, I hope,that in the future I manage to convince myself to post progress updates more often. Now go play some games!

Survived Ludum Dare 31

The last few days have been intense, but we present to you: Hyper Soccer

Hyper Soccer GameplayIt’s what happens when you let placeholder graphics get into the final game, but there simply isn’t time for everything. The gameplay turned out fun, that’s what matters most (to me at least).

The Theme for LD31 was “Entire Game on one Screen”. Nothing really inspiring, but at least I managed to make a game that follows the theme for a change.

Hyper Soccer Grapple Match

It’s a local-multiplayer game with gamepad support. Play with as many friends, as you have gamepads!

So, go grab some gamepads, call some friends, and enjoy the madness that is Hyper Soccer.

Web-Build and Making-Of will follow later.


Release of “Hello, Alien!” – For real this time

So, now the “Open-Beta” has ended, and “Hello, Alien!” is ‘finished’. Or at least, development on it has stopped for now (except for bugfixes of course).

What if you make a game, and nobody shows up?

“Open-Beta” went relatively…. well, let’s not say bad… we’ll just call it underwhelming. The same holds true for the October Challenge. Apparently nobody will show up to a party, if you don’t tell anybody. (Who knew, right?)

At least we can boast 207 views and 38 downloads. (While nearly all of the traffic comes from, the only other site I’ve posted about the game.)

I just understood the importance of marketing. The next step will be to try and get the word out. I’ll have to investigate on some good ways to get some people’s attention. I heard twitter is good at those things…

In other news

We are currently working on a small game started for the MiniLD #55 last weekend. Just testing out some things I usually neglect (trying out some nice shaders) and it seems like it will finally be playable in the browser (rejoice). I just hope we finish in time before LudumDare #31 will start this weekend. Also let’s hope the theme won’t be .


What makes a game fun to watch?

There was a game jam last weekend, ‘Indies VS PewDiePie‘, with the theme ‘Fun to play, fun to watch’. But, isn’t a game that’s fun to play automatically fun to watch?

This was supposed to be a post about why a game that is fun to play is not automatically fun to watch, but the more I wrote, the more I contradicted myself, and it started to make less and less sense. I suddenly came to the conclusion: Yes, everything that makes a game fun to play, also makes it more fun overall: avoiding repetition, having a good story, giving a lot of feedback to player actions (making a game “juicy“) and having great depth. But there are other factors that are important when watching someone play a game.

Silent Let’s Play of Tetris anyone?

What’s really important are the circumstances under which you watch a game. Are you watching a speedrun or flawless run or somebody playing it for the first time? Is there any commentary or is it just the game? Are you watching live and in person or are you watching a video/stream? Why are you watching? For the music? Some gameplay tips? Or do you simply want to have a laugh? All this things determine how the game is perceived.

An example: You are playing Portal 1 at home for the first time with a friend watching, and that friend has already played through the game. He is watching you struggle to do a puzzle, and he is trying to be a smart-ass offer his help, but you are refusing, because you want to find out the solution yourself. This makes it frustrating for both the player and the observer. (Not that anything similar has ever actually happened to me.) But watching a Portal speedrun, is just mind-blowing.

Also playing Guitar Hero with your friends is a lot of fun [citation needed], but when you watch a video of somebody playing a song flawlessly without any commentary, you could just watch your media player for similar effect. But when all you want is listening to the music, then it’s probably fine for you.

There is more?

Still, there are some factors that make some games exceedingly good games for “Let’s play” material.

  • Randomization: How do you ensure that there won’t be much repetition, and every playthrough will be different? Through high amounts of randomization! Rogue-like(-like)s are great when it comes to doing Let’s Plays, as every run will be different, meaning you can be sure to always see something new and unexpected. Other games, on the other hand, achieve the same effect with a neverending flood of player created content.
  • Absurdity: When a game is different, unique or simply absurd in any way. This can be story wise or gameplay wise. When there is something unique or silly, this makes not necesarilly a good game, but gives a lot of potential for funny commentary. This is essentially what PewDiePie got big with.
  • Depth: When there are a lot of options and possibilites available to the player then it’s really interesting to see what pro players do in certain situations. Or seeing how new players get crushed completely.
  • Competition: Watching humans playing against other humans instead of AI adds a whole new meta-layer to everything. People can cheer for the side they like most and fanbases can develop. The players can become even more important then the actual games they are playing. This is true for e-sports as much as for regular sport. This is the reason why there are millions of people watching other people play Football or DotA.

Does every heading have to be a question?

I think, that for #indiesvspewdiepie one of the most absurd games will probably win.

I wanted to participate in that game jam myself, but unfortunately, inspiration had not struck and I also had a lot of other things to do.

Having said all that, great commentary can make even the most boring gameplay video interesting. Even watching someone die for the 1000th time at the same place can become entertaining.