Game Development

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.

Player Motivation in Below Earth

My first plan for Below Earth was, to procedurally generate levels, and generate different set of levels the further you advance. Quite similar to Spelunky‘s level system. But since I didn’t have much content I made a prototype with only one type of random generated levels to test it. But there was no motivation to explore levels or engage enemies, as all levels seemed similar and the only goal was to get a high score. And score doesn’t mean anything, if you don’t have any global or friend leaderboards ready and an interesting mechanic for amassing points like combos or chains. Just making a counter go up is (most of the time) not something you feel motivated to do.

In Spelunky on the other hand, you have a set amount of levels and you can find items and collect gold to buy even more items at the shops. This way exploring the level becomes a viable option. So you have to decide if you want to risk fighting against that enemy to maybe find some item or gold or leave it and try to advance further. But for Below Earth I didn’t want to have shops and lots of items. I wanted to keep the scope small (considering it’s a Ludum Dare entry), so I had to find a way to make it engaging despite it being limited in complexity.

That’s why I switched to a fixed amount of hand-crafted levels. Of course this would also be possible with generated levels, but hand-crafted levels are faster to get good results with. So the new goal for players was to advance to new levels to see what new content and what new situations await at the next level. I also thought keeping the score system was a good idea back then, but in hindsight it only felt slapped onto the rest of the game, as score only played a secondary role. There still were no leaderboards or combo system, so your score was essentially the amounts of enemies you killed. Not interesting.

So either you go the arcade-y point centric system of player motivation all the way, or don’t go it at all. One recent example would be Bastion, as it has a separate story mode and score-attack mode. In story mode, there is absolutely no score system to distract you, it’s just pure story. In score-attack mode it’s all about piling up points, the current score is permanently displayed on the screen, there are combo systems in place and after every level you can compare your performance to the global or friend-wide leaderboards. That’s score done right.

Finding the right way to motivate your player can be pretty tough. For the Below Earth post compo version I’m planning to completely drop the score system and instead rely on advancing levels, boss fights and maybe some items as player motivation. Speedrun leaderboards could be an alternative to the score system.

-Anton

Plans for Sommer 2014

Business or not, it’s important to have short-term and long-term goals. Also telling other people of your goals makes you more likely to actually try and achieve them. So, what could be a better way of telling everybody than through a public website?

Future projects

We will participate in every upcoming Ludum Dare just for the fun of it. This also includes the next Ludum Dare 30, which is on the weekend of August 22nd to 25th.  Ludum Dare always provides an excuse to try creating something new, and is a welcome variation to everyday life.

Current project

At the moment we are working on refining another Ludum Dare entry.

I participated in Ludum Dare 29 and entered a small game called ‘Below Earth’. It’s about running around in a cave and throwing around bombs to blow sh…stuff up. We decided to further develop and polish it, so that it could count as a full game. We would like to be finished with it before Ludum Dare 30 starts. For no particular reason, but you have to set yourself deadlines to stay motivated.

The current downloadable builds (and the original LD entry) and the source code of ‘Below Earth’ are available on Bitbucket. Free for everyone to download and try out.

We will talk in detail about this project and its progress in future blog posts.

-Anton

Let’s get this started

Hello everyone,

this is Accidently Awesome Studios and we are hobby game developers, dedicated to their craft. We enjoy creating small but fun games and taking part in game jams.

This blog is intended to provide some insights into our projects and keep us motivated. We will most likely create weekly posts (or monthly posts (or probably something in-between)) talking about our projects, game development, game design, games and maybe also other topics, but primarily about games.

Having said all that, let’s get this thing started.