This article will describe all the lessons I took, my mistakes and achievements during the process of creation of my first publicly available game for Android called Unholy Showdown.

Also please take a look at the “Post-Postmortem Article” for some additional thoughts about Gameplay.

Preface:

 

Everyone knows that the first step is the toughest. Many however do not realize how tough it is and that you will probably fail the first couple of times. I like to think that there is no failure – just feedback. Each time I fail – I learn so next time I fail less. I am 100% sure that even though this game is rather mediocre the next game will be definitely better. Too soon to give any numbers as I have not promoted it yet. I don’t know if I should, though…

 

What is Unholy Showdown?

Unholy Showdown is a game I and my Fiancee made for Android Devices available on Google Play here: http://bit.ly/unholy_showdown while we worked our day jobs and lived our normal, busy everyday lives. Game is available for free with ads and optional donation. I was working on the project since April 2016 and Justyna joined later in September.

 

Lessons took:

 

  1. Prototype until awesome but get feedback as soon as possible
  2. At some point you must decide to stop, freeze design and cut
  3. No, Pixel Art is not easy.
  4. Don’t do art before the gameplay is flawless.
  5. No, you don’t have infinite amount of time.
  6. Refactoring and Code Reviews are the best way to level up the coding skills.
  7. I know so little…  but knowing that fills me with even more determination

 

Prototype until awesome but get feedback as soon as possible

Prototyping is critical, however the main mistake I made was showing my “awesome” idea much too late to the first testers. I remember that I showed the first “so-so” looking build to folks during Pog(R)adajmy event in Bydgoszcz and they literally smashed my design with feedback. That was 2 months after I started developing the game. I was afraid to show it to early since it happened before and I even got some sort of label of a person who speaks way too much compared to what I actually do. Too late to explain that – yes, I talk much but I also work 3 times as hard as ordinary person. This is part of my character. I am also a great fan of personal development and self learning.

 

Yes, this game was THAT ugly 5 months ago and was meant to be a rythm game. Yeah….

I am about to deliver my first game to public. Dont expect much as this is not meant to be a commercial success. It's a personal challenge. "Unholy (disco) showdown" is a mobile paper/rock/scissors microgame with local multiplayer for people on the move wanting to kill some time. It's a tribute to B class horrors and my gift to awesome and supportive #indiedev and #gamer community. One player plays as a Disco Girl possesed by demon and the other plays as Elvis Exorcist. Free, no monetization, no IAPs. Just pure fun and ridiculous humor. I'm currently closing last features and soon starting closed beta to improve the quality. If you wish to help me to deliver a better quality game please do drop me a line so I'll add you to beta. I'm open to any constructive feedback. PS. I must have been too tired to notice that issue with TAP ON SCREEN sign. Damn.

A post shared by Krzysztof Orzędowski (@fid_is_the_one) on

 

Nevertheless I lost 2 months of time but I’ve learnt couple of things – UI is critical and answering questions like: Who is your target audience? Where the game will be played? What is actually critical in Rock / Paper / Scissors type of game?

One of the testers (Hi Wojtek!) told me that for him R/P/S game is all about psychology and and guessing what will the next move of his opponent be. He also noted that UI at that current stage was not fit for Local Multiplayer on a small phone screen. He pointed out that real time fighting was not a wise decision as people would simply button-mash instead of thinking about strategy.

 

I even considered adding more “fighters”

 

 

I continued the gameplay iteration through out all the alpha stage and I got a real mixed opinions. Some of folks did say it’s awesome (maybe they were just trying to be nice?) others said it was pretty boring. Most of them however complained that the game was missing the random factor and could not play them as single player.

 

At that point I had to decide whether to kill the project or continue with whatever I had. Normally all the business factors has proven that this game should never leave the prototyping stage. Most of the Biz Devs would kill it much earlier. However “making money” was never on my list of priorities for this project. I needed a closed project and finished game to add to my portfolio / CV and I wanted to focus on quality and improve my technical skills.

 

At some point you must decide to stop, freeze design and cut.

After a huge code refactor (thank you Vigrid!) and closing all the major features like Basic AI, Microtransactions and Ads I’ve decided to go into Beta and iterate on Assets quality. Here I got help from my Fiancee who is a Graphic Artist. She did an awesome job and worked hard after her day job improving my ugly sprites. My decision was to stop implementing new features and focus on iterate whatever I already had and add some juice (screenshake, particles, post processing, etc). At some stage I also wanted to add sort of a bonus round to add that mythic “random effect” or chance factor. I tried various approaches but in the end I’ve noticed that this does not improve the gameplay so I’ve decided to cut the feature. That was a good decision. The whole beta phase lasted at least as long the alpha phase and this is another lesson learnt.

 

No, Pixel Art is not easy.

This is a common misconception that pixel art is the style chosen by programmers since it’s easy and even people with no art skills can produce something tolerable. Well… nope. Moreover frame by frame pixel art animation is terribly time consuming and does not give decent effects. On top of that it was a great challenge for my Fiancee to draw pixel by pixel since she was used to classical drawing. At some stage we decided to change all the assets to more hi-res. That was a good decision as this produced better effects and I could animate the assets using Spriter with bone animation.

Fight! #indiedev #gamedev

A post shared by Krzysztof Orzędowski (@fid_is_the_one) on

I also spoke with Robert Podgórski, known as Blackmoondev on Twitter, who is a veteran Indie Developer from Poznań and he gave me a great argument not to use pixelart:

Pixel Art is no longer unique. Every indie dev now wants to make a pixel art game. Some even made their pixelart so good that it’s beyond the level I will ever reach. So why bother if I have an easier, more accessible solution which gives more options?

 

Don’t do art before the gameplay is flawless

 

Oh… The time I lost drawing those ugly pixel art sprites … all that precious time I could use on making the gameplay better or improving the quality of code. Most of the art from early stages is gone already. Unfortunately I am not a “one man army”  and “know it all” man. I am flexible, I learn in a quick way but I guess I must accept the fact I will never be a great graphic artist and should invest time and resources in teaming up with someone more skillful than me.

I don’t do drugs, really… not even once… but check this out. Something is seriously wrong with me.

Hammer Time!

A post shared by Krzysztof Orzędowski (@fid_is_the_one) on

No, you don’t have infinite amount of time

 

I planned to close this project in July. Well… I closed it in December and only because I forced myself to do it and because I could have taken holidays from my day job. Next time I’ll be making a game I must add necessary time buffers for “life events”. Such as family matters and meetings, conferences and other social events. This sounds trivial but guess what – no one wants to live in a monastery while making games. There is no such a thing as a small project.

 

Refactoring and Code Reviews are the best way to level up the coding skills.

 

The best way to learn coding is to code. However sometimes without descent guidance of a senior developer you may end up in a dead end. I fortunately was lucky enough to meet Marcin Seredyński, a.k.a. Vigrid who helped me with proper mindbending and code refactor. No he did not code the game for me. By asking proper questions and giving useful feedback he made me refactor the code on my own. I still suck big time but at least I suck less. I know that I should focus more on coding methodologies, algorithms and maths in general.

 

During the dev cycle I also met some cool folks learning C# for corporate purposes. I must admit that enterprise coding is not my cup of tea, however the course gave me a better understanding of OOP basics.

 

I know so little…  but knowing that fills me with even more determination

This game was a great educational experience. I realize how little I know and that there is a long way ahead of me. However by finishing this project I got a great confidence boost and a proof I can achieve any long term goals. Sooner or later I’ll get there. Persistence is the key.

 

What next?

I came to a point I must specialize more in technical skills to become hirable in game development. I figured that I should focus more on coding but develop game designing skill in a same time as well. I think I could find a place somewhere as a junior C# gameplay programmer or game designer with prototyping skills.

I’ll stick to my “be water, my friend” approach and stay agile. However I need at least 1 strong dev skill + maybe 2-3 secondary features and c# coding in Unity seems to be a good bet.  Instead of switching engines and moving to UE4 as many of my colleagues are now doing I’ve decided to master Unity, learn how to make shaders, improve maths and algorithmic thinking. I’ll see if I can make some proc-gen or 3D games. Life will show 🙂