1GAM

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 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 Itch.io 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.

get_it_google_play

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!

News

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.

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.

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.

Goals

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. (Itch.io and Gamejolt have been great so far, but maybe Newgrounds could be the right place?)

 

This actually turned out waaaay longer than I expected.