Foreword
Hi fans! It took me a really long time until I decided to write this post mortem for my most successful game Dogfight Aces. The game is a 2D side scroller shooter and is focused on post-World War I era combined with fiction. The goal of the game is to become the best WWI pilot by participating on dogfight tournament. You can read the brief game description here.
At first I’d like to dedicate this post to all players that like Dogfight Aces and people who sent feedback to make the game better. Special thanks goes to my friend developer “Shajby” from Little Big Play whose advices significantly influenced the development of Dogfight Aces. In this post I’m gonna reveal the chronology of game dev progress and designed mechanics the players even didn’t notice. By describing the technical solutions this post could be useful even for indie developers who love to create games, just like me. At the end I’d sum up what went wrong and what I learned and will try to avoid in future projects. Ok let’s go for it! I hope you won’t throw up while reading this post written in my non-native Engrrrish 😀
The origins of Dogfight Aces
It is year 1995, I’m 14 and I play Dogfight Simulator with my 2 friends on my AMIGA 1200.
It’s a simple game but the intensity of fun is simply overwhelming. The game had a engine stall mechanics that allowed to maneuver sometimes in really odd and creative manner.
Two years later I started to attend highschool with a programming as one of the subjects. We learned Turbo Pascal coding language that time and after I got the basic skills in programming I tried to create Dogfight game in this language. I simply wanted to play with my schoolmates. The game used Pascal’s build-in routines for drawing lines and fills and it was terribly slow on PC286. However when switched to wireframe graphic mode it was playable and almost the same fun as the original on AMIGA (but with crap visual art :))
More than 12 years after I’ve spotted that Flash has developed into a decent platform to create games. The decision what game to try to design was simple.:) “Let’s make Dogfight again, so I can play with my colleagues!” After creating few useless example projects in Flash the game implementation started.
This is it’s approximate chronological order:
Development
March 2008 – Prototype
First very simple prototype. Pretty useless, huh? 🙂 But at least, it was a proof that Flash could be the good platform for creating such a game.
ActionScipt 3 looked like a new technology for me so I’ve chosen ActionScript version 2 because I’ve already did some coding in it and I was lazy to learn new things (well, this was the first bad decision, see the What went wrong section).
The next year I’ve spent with coding, debuging, struggling with Flash and ActionScript 2. Ok that’s the code but what about the art? I have an art feeling and some drawing skills but definitely, I’m not an artist?! Well, after short meditation I knew that retrace some pictures in Flash would be enough for pretending my great drawing skills 😀
Creating art without being an artist
Many indie devs are great at coding but fear when they have to make a good game art.
If they have no artist, they usually create such crap pixel/voxel art like Crossy Road has…just kidding 😀
If you are developer and you do not feel comfortable drawing art, but you would like to create it by yourself, just use this simple retracing process I used:
Prerequisities: Find an artwork on Google for inspiration
- Put it into flash as background
- Retrace the artwork using lines
- Use the eydropper to get the fill color and fill that damn holes encircled by lines! To enhance the depth effect, you can use gradient tool with combination of two colors got from eyedropper.
- Everything has been filled with color gradients? Great! Now remove the lines and artwork background!
Viola, done! Next object to retrace!
Using this process I drew all of the game art: backgrounds, airplanes, clouds etc (see below).
Drawing pilot portraits was a bit different task, since I had to distort the original artwork first (2), then
colorize (3) and filter out tiny details to achieve a comic look (4). No retracing in flash has been done this time.
Just as a remark every pilot portrait has been created from the original pilot picture (see below).
March 2009 – The first playable version
One year later, the game contains basic art and is playable by 4 people in hotseat mode.
There’s still no tutorial and menu nor shop is implemented.
The game is still considered as a hobby game for me and my colleagues to have fun during free time.
It contains already few bonuses (screwcutter, gun berserk). Only machine gun weapon is implemented.
In this version where the inter-airplane collisions are incorporated and they are absolutely frustrating!
May 2009 – Menu
First simple menu is designed. Finally I’ve decided to try to sell this game on FGL, once I finish it of course!
July 2009 – AI & Stats
The first version where bots controlled by Artificial Inteligence (AI) prototype has been implemented. AI uses weighted forces that makes the airplane to adjust it’s tilt according to them. However it’s not a really good approach and bot in some cases reacts strangely.
The game now has 2 modes – HOTSEAT where players can choose airplane and controls and INSTANT PLAY is a single player against 3 AI controlled biplanes. It also introduces some stats from the battle (inspired by DOTA :)). These are evaluated at the end of each round and resulting rank is computed from them (see below).
October 2009 – Music
The look and functionality of the menu is extended. Some buttons for sponsor and my company logos have been added.
Note that the game title is still not final and is now called CRAZY DOGFIGHT 🙂
In this game version I have added music from Antonin Charvat. Currently it was one single track, but
I’ve decided for another approach. Music Sequence Looper has been introduced!
What to hell is it?
Game Music
Maybe you have already noticed that the game music is not looping as one single track but is split into several parts – music chunks. These chunks are repeatable in a seamless loop or some of them transite smoothly when played one after another. Chunks are organised into an oriented graph (see image below) where each transition from node to other node (music chunk) is defined by it’s probability weight.
The system gets a random number and decides which transition to go e.g. which chunk will be played next. Each node has one more infomation: How many times that node (chunk) is repeatable.
Example:
Imagine you have 4 chunks of music that fit together one after another 1-2-3-4.
Let’s define the repeatability:
chunk 1 – repeat min 2 times, max 4 times, only even number of times
chunk 2 – repeat max 2 times, any numbers
chunk 3 – norepeat
chunk 4 – norepeat
Next transitions and its weights have to be defined:
Transition 1->2, weight:1
Transition 2->3 weight:1
Transition 3->4 weight:1
Transition 4->1 weight:0.5
Transition 4->2 weight:0.5
Oriented graph of music chunks
The Music looper is then able to play this sequence 1-2-3-4-1…
or 1-1-2-3-4-2-3-4…. or 1-1-1-1-2-2-3-4-2… etc. depending on the generated probability.
This creates a feeling that the music doesn’t repeat as just a 4 min track, but feels like the music
is much longer and not so repetitive.
When I first started to test this piece of code I came to a really annoying thing. The chunk transition has been noticable by ear due to some strange time delays. I knew that this is not an issue of the chunks since they have been looped perfectly. Nor the problem was caused by lossy compression because I used the wave files. I tried to investigate and I found the cause, FLASH sound mixing! The bad thing is that when playing sound in FLASH, each start of the sound is aligned to a time window of 2048 samples (e.g. 46ms if sampled at 44kHz). That means that if you play a sound consisting of 3000 samples the next sound can be played at 4096 tick which means 4096-3000 = 1096 samples of silence between the sounds. Perfect! 🙁 After some googling I’ve found this post that helped me to code a decent workaround (see image below).
It works like this:
Preparation: Add 500 milisecond silence before each chunk and save the chunk like this (in waw files of course).
Algorithm:
- Start the sound.
- Each let’s say 100 miliseconds trigger an event that checks how long will the current sound last to it’s finish.
- If close to finish, let the current sound ring and start another sound (chunk), but from the precomputed time offset instead of zero time.
Music chunk syncing. Result before and after coding the workaround.
As you probably deduced, the time offset and earlier start of the second sound eliminated the silence gap between
the two music chunks. Problem solved. Hooray to me! Big minus for Flash 🙂
August 2010 – Physics
Introducing the centrifugal force into flight model
After putting the incomplete version to FGL I received a lot of valuable feedback. One of the complains were on the physics since it wasn’t realistic. Previously, the airplanes rotated in a simple cirle only. I did a test prototype that implements a centrifugal effect on the airplane. If the plane turns, the centrifugal force ( green line) slides the plane outside of the rotating circle. If the biplane stops turning, the centrifugal force still drifts it away off the rotating circle for a while. The collisions between airplanes have been definitely removed due to many complains of the testers that the game is too annoying and difficult to play.
October 2010 – First bidding
Version v0.9 released, uploaded to FGL and placed for bidding for the first time.
The game contains Single player mode with not very smart AI and Hotseat multiplayer as well. Unfortunately the bids are low to accept them, only one of the offers looks promising. One of the sponsors asks for exclusive license with complete code and all assets. Intention of the sponsor is to use my game as a sequel to their popular game TOP DOG II. I’m really fond of this offer, but I got enough feedback from other developers and players that made me to completely rework the game and create a mission based single player with tons of adjacent content. I convinced the sponsor to wait for a new version. He promised to wait…
December 2010 – Damage model
Great changes introduced in this version. New damage model that allows to damage tail, engine, gun and pilot separately. Damage of each part affects the
controls of the airplane. Tail damage affects turning speed, engine affects velocity, gun affects cooldown and pilot hit means instant death. Some hints and tips of the day has been introduced into the game as well (see below). However, the hint of the day has been later removed or let’s say moved to briefing dialogs before each mission.
Oh one more thing! The game look and menu has been significantly improved when I drew new clouds, wow!
May 2011 – Single player
Another huge HUGE changes contained in this version. The whole singleplayer (20 + 1 levels) has been added. The levels have been designed on the paper first, you can see some of the sketches below.
Besides the level design even weapons, new backgrounds, weather, night missions, tons of GUI (weapon shop, briefing, stats +medals) had to be designed as well.
This is how the shop development progress looked like:
The game now contains 4 modes out of 5 implemented.
Tutorial, single player, single level, balloon defence (see below).
It’s a paradox that Hotseat multiplayer mode, which was introduced as the first mode in the early game dev phase, has been removed for now 🙂
October 2011 – Mochi services & new AI
Very close to release version. Mochi achievements/leaderboards/coins have been coded. I’ve spent several weeks integrating the Mochi services, mostly the microtransactions (MochiCoins – see the yellow buttons in game below).
Unfortunately MochiCoins never worked in the game because of the error on Mochimedia side. I mailed them and Mochimedia tried to fix it. Few weeks later they replied that they shut down MochiCoins service due to some troubles. Damn…several weeks of development gone 🙁 I had to remove the MochiCoins from the game, but at least achievements and leaderboards remained.
AI has been completely reworked. Now it uses Finite State Machine approach and has 4 levels of “inteligence”, from DUMB to NIGHTMARE. Reacts pretty good and I’m finally satisfied with the AI.
Design sketch of Finite state machine controlling the airplane bots.
Huge performance improvements have been done once I realised how to correctly add videoclips in AS2, lol my mistake.
If I were using AS3, such performance stuggles would never appear. 🙂
March 2012 – Polish and second bidding
Before placing to bidding process I did tons of polish work that FGL guys adviced me. Thank you very much guys! It includes reworked tutorial, more intuitive shop and tutorial dialogs explaining the game mechanics each level.
Finally done and prepared to put the game to bidding process on FGL again. I had to explain FGL that the game is completely different from the first version, however they stated it is not possible to bid on the same game twice. So I was forced to rename the old game and place this new version for bidding as it was a completely new game.
May 2012 – Sponsor version
It took approx 2 months until I accepted the best bid on FGL. Unfortunately, sponsor that wanted to buy exclusive rights with code one year before didn’t respond 🙁
Tremor Games offered the best terms. I accepted the primary licence for $1850 with possibility to keep Mochi and Kongregate versions.
So I started to design and code some stuff needed for sponsor’s website. It included sponsor’s own API integration, new achievements etc.
Release and revenue
Tremor Games version was released on the 19th of June 2012. Until now it had 150k plays and belongs to the top 40 played games on the website.
Mochi, Newgrounds and Kongregate versions followed 2 weeks later after sponsor’s version release. Since the MochiCoins functionality was shut down I could only rely on revenue from Ads.
The Mochi version peaked 4 days after release earning $22 in a day. Arter 1 month the Ads revenue dropped below $1/day and stabilized between $6-10/month until Mochi shutdown in march 2015. Until that time, the Mochi version got more than 2.6 milion views. The best performant countries were from South America – Brasilia, Argentina etc. After the shut down of Mochimedia in march 2015, I had to rework mochi versions and distribute it to websites where the game was played at most – manually. I have changed the Ads to CPM star. Nowadays the game earns less than $1 in a month.
Kongregate version was a dissapointment. Since the game wasn’t designed as casual, it got even bad reviews, the people were upset due to complicated controls. The game rating is now 3.6 out of 5 stars and has only 60k views.
Newgrounds version got just weak 10k views until year 2015. This was the less successfull version.
There are even chinese versions for YouYouWin and 7k7k, but without any significant impact on revenue.
There’s one more version – sitelock bought for $500 from AddictingGames.
Addicting Games version was released 09/20/2012. At the end of the 2015 it got 750k views and rating of 69%.
Feedback
To sum up the feedback from players I feel the game worked like a double edged sword. Some people were loving it very much asking for sequel, some players were annoyed and upset. The reason was mainly because the game wasn’t targeted on casual gamers since it needed some skills to master the controls. Probably the problem of bad ratings was caused by wrong setup of the game age rating before publish. If I constrained the age to let’s say 15+ probably the game would do better, especially on Kongregate. But this does not filter the casual players. Since this was my first big project released (the very first one was Lost Toys of Santa), I didn’t have so much skills with distribution. Nevertheless, once the game got into skilled hands, it had a and still has high retention due to its complexity, tons of content and endless mode called “Balloon defence”.
What went wrong
3,5 years after release I’m definitely able to sum up what were the bad decisions on this projects.
Here are the most significant ones:
1. Endless development
The game took 4,5 years to complete. The reasons why did it take so long are several. The first one is the lack of any design document and scope which dramaticaly stretched the development time. The second reason is described in point 2 and 3. Spending too much time ineffectively by designing just one game affected my health as well. Much sitting at work then at home, less movement and then wrong movement damaged my cervical intervertebral disc. And this something you cannot repair anymore.
Lesson learned: Paper and pencil is your best friend in all phases of game design. Don’t be too keen on coding, design as much as possible on paper, write some documents first and set a scope and deadline that you will try to reach. The time effort spent on paper desing will return back to you multiple times.
2. Actionscript 2 chosen as coding language
I started to implement game in AS2 since I was hesitated to learn Actionscript 3 which is a bit different in several areas (Events, display lists). After I realised that AS3 would be better it was too late and It would take additional 6 months to rework the game into AS3. This had the greatest impact on sell price of the game. The reason is that in 2012 when I placed the game for a bid, almost all game websites used the AS3 achievements API instead of AS2. If it wasn’t possible to implement their API into the game, they refused to place higher bids. After MochiCoins was shut down I could implement other microtransaction system into the game, the GamerSafe for instance. Unfotunately GamerSafe supports AS3 only 🙁
Lesson learned: Consider the time when developing the game. Could be the current technology obsolete when you release the game?
3. No use of Flash game framework
This is related to both 1) and 2) points.
I created the game without any framework, any third party piece of code., everything is just my code, letter after letter. If I used any game framework made in flash e.g. Flixel, FlashPunk, Starling or other one, it would be possible to create the game much more faster. The more, If I chose starling or other GPU accelerater frameworks I would be able to port the game to mobile devices e.g. to another big market = more revenue.
Lesson learned: Before creating game make a large survey to choose proper game framework. Don’t be lazy to learn, but be lazy to code. Learning new things will slow you down at the beginning but will burst your development in later phases.
4. No community acquisition
Since I didn’t have any website that time that game fans could meet together, the community
wasn’t concentrated on one place and remained scattered accross the game portals.
If I created my website and other channels to communicate with fans I could have a bigger
audience for my future projects.
Lesson learned: Make your fanbase grow with every game released. Create a place which your fans could visit and are able to communicate with you or between each other! Website, Twitter, FB page is just a minimum!
Future
Mobile version
Since the Flash web-based games are dying I thought about to create a mobile version of the game. However, it is not possible to port AS2 Flash project easily. The only solution would be to completely rework the game whether in Starling or other GPU accelerated frameworks based on Flash AS3 or implement into Unity engine. There are several essies that I will have to solve. The first one is the time, because it means to completely create whole game in new technology. The second one would be the time to think out and redesign the business model of the game to be able to monetize the game as much as possible. And this would affect the whole game design. So regarding the mobile version of Dogfight Aces I would leave it open until I have enough time or financial resources to realize the project.
Sequel
I’ve been thinking about the sequel since I released the game in 2012. Everyone expects that potential Dogfight Aces II would move to WW II era, but I cannot get rid of nostalgia about the biplanes. I think that a decent sequel would be still set in WWI era, but the game principle would be completely different. As a good solution I consider combining 2d shooter as Dogfight Aces is with trading game like Elite / Frontier. The player would complete missions and get money, buy new stuff as better weapons, airplanes, buy wingman, whole squadron etc. But this is just a music of the future 🙂
Conclusion
No matter how successfull the game was and how did it earn, it was a great school of game design for me. I’ve learn enormous amount of various things. Game desing principles and coding were just a peak of the iceberg. It the beginning it started as an innocent project for few people and ended as a game that played milions of people. From my point of view, it was definitely a good decision to create Dogfight Aces. What I regret is that due to my lazyness I didn’t avoid some bad decisions I was able to avoid. In some cases I have paid a very high price for them. To sum up the lessons learned I can write one more remark at the end:
Lazyness is good and evil thing on mankind. The main point is to recognize when it could help and when it could hurt.