Intro
Now that my first game has been released I wanted to collect my thoughts and lessons learned during the experience to share and hopefully help some other aspiring developers out there. While this project is a game, I think that the lessons learned are mostly universal for software projects and likely any product you wish to take to market.
A bit about myself: I work professionally as a software engineer for a large engineering company in Canada. I love building software and in particular enjoy working on anything that has a large graphical component and focuses on the end user experience. Prior to this project I had little to no experience building games aside from an Asteroids clone I wrote in university and some small hobby projects in OpenGL.
I am the sole developer and designer of Ninja Gold Rush. The following post is the story of how the game went from concept to execution, the initial release and lessons learned in between. If you're interested grab a cup of coffee, sit back, relax and let me tell you a tale of Ninjas, Gold and how I spent the bulk of my free time and weekends over the past year.
The Concept
I was looking for new ideas for a mobile game. I had been meeting with a few friends who were interesting in taking on a project in their spare time and we were pinging ideas back and forth. I've always been interested in mobile technology because a) the distribution is handled by the respective app stores and b) there is a huge potential market, particularly with games, which continue to be the most profitable and downloaded app category. This by no means is to say it is easy to succeed on the app store, far from it! But at least there is a potential for scale and some of the logistics (like distribution, payment, etc.) are handled for you.
We each took an action to come up with some game ideas and meet again the following week. I immediately started playing with my phone and thinking of what would make a good mobile game. I knew it had to have a simple control mechanism and should have a cartoonish feel to make it most accessible and target an audience of early teens. I wanted to make a game they could challenge their friends to and play while on the bus, in between class, etc. Basically something simple, low investment, pick up and play.
I'm a firm believer in looking at those who came before you for inspiration so as I was fiddling with my phone I was also remembering games from my child hood and seeing if could extract anything interesting. I remembered in particular a game I played a lot as a kid called "Shinobi" for Sega Genesis. The game itself isn't too relevant (although it was pretty sweet at the time) but this game had a bonus stage where ninjas ran back and forth across the screen on raised platforms. I remember it being super hard but also fun and rewarding, especially as a kid. The simple mechanics lent themselves very well to mobile and I started to think how the game could be re-imagined in 3d.
As will happen my memory was a bit distorted from reality and I recalled the ninjas moving on a sort of assembly line toward the user. I liked this idea both for its simple mechanics as well as simple execution. There was a problem though, I, nor anyone on the team, had any experience with 3d modeling tools or game engines and I knew we would need to use both for what I was envisioning.
I started looing at some game engines and in particular Unity, which I had heard mentioned a few times before. I also knew that Blender existed as a free and open-source modeling tool but had never used it because it looked extremely complicated to use. On closer inspection, both of them did! Determined to show something more concrete for the next meeting I put aside my reservations and started googling some Blender tutorials. After about a day I came up with this render to help the team visualize. Even better was that I had a simple animation where the knees and elbows slightly bent and it looked like he was breathing heavy, waiting for action. I was pretty pleased with my progress.
So I took the render and some notes to the next meeting and proposed "Ninja Assembly Line" or NAL. I sketched up the concept of a simple grid based level scheme where the ninjas are moved along a series of conveyer belts and you need to knock them off before the allotted time runs out. The group was sold, the wanted to start building it. We started brainstorming features and writing them down. We agreed to meet the next week and start developing some of the core capability.
I was pretty excited about the project so I got to work right away learning Unity and put together an initial level with my model and the ability to throw shurikens to hit the ninjas on a conveyer belt and a simple counter. The game was pretty rudimentary but the vision was taking form. The others didn't really take it as seriously and quickly began dropping off. Soon it was obvious I was going to either need to build the game myself or let it die. I chose the former.
It's interesting to look back at how the game progressed from this idea into its current form. It really all evolved from prototyping and playtesting, initially just with friends. The final release stayed simple but was quite a bit different than the initial concept. Even though my original partners didn't directly contribute much to the development of the game they contributed a lot in terms of ideas and I have to say without that collaboration "Ninja Gold Rush" would probably never have been finished because I don't think "Ninja Assembly Line" would have been received well enough during public playtesting to warrant proceeding. The counter was replaced with the concept of life, represented by gold in the center of the screen that the ninjas can grab and steal away. Each level you would replenish your gold and hence your life. The conveyer belts were removed and the ninjas were animated to run across invisible paths through the level. The ninja model became more cartoonish and more appealing. Rag doll physics were added, the game became much more polished.
The Concept : Monetizing the Dojo
The final important design decision was how the game would be monetized. I think in order to make a game fun and profitable your monetization method needs to be conceived from the start and not just tacked on as ads at the end.
I hate intrusive banner ads. It's bad enough to have them in apps but if you are playing a game, you want to be immersed in that experience. You don't want to be distracted by flashing ads for "Angry Bird Transformers" while you are bashing evil ninjas.
I also don't like games where all the fun abilities are only available by purchase. I ended up using what I believe a happy medium where the game can make money without annoying the player.
Again looking to the past for inspiration, I came up with a strategy already familiar with those born in the years of mall arcades and physical pinball, the "Insert coins to continue" method. Essentially, you can play the game (the whole game) for free but you only have a set number of continues. Once you run out you have the choice of buying more lives or watching a short video ad (since the game is over it's not interrupting the gameplay) in order to continue from the current level, or else you can simply restart the game from the start.
I think this method works particularly well for difficult games with that "just one more time" type of feel. Again similar to the old style arcade games, which were extremely difficult but addictive.
Challenges:Defining Scope. What is the Minimum Viable Product (MVP):
As a one-man game studio (if you could call it that) you need to be wary of biting off too much early on. For me, I had no drawing skills, no modeling skills, and no real knowledge of Unity. Looking back all of these seem like valid reasons not to start the project! Instead of getting frustrated I started really looking at the scope I could realistically deliver.
I started by writing out a list of ideas and initial feedback along with sketches of the concept. This included potential levels, enemy types, weapon types, different actions, power-ups, boss fights, menus, level transitions, animations, social integration, leaderboards and various other cool things that could happen in the game.
The whole point of the MVP release was to see if I could get people to download the first release and if they liked the concept. I knew I would get feedback asking for additional features but this was the validation I was looking for. It didn't make sense to me to spend my limited time implementing a ton of features if most people didn't like the core product or if the product wasn't marketable.
With this in mind I went through my idea list and decided what was critical and what was nice to have. Things like social integration and leaderboards were marked critical as I felt they were necessary to market the game. The nice to haves would be things I'd add if development went really well but more likely saved for a future release, these were things like additional animations, cool menu effects, etc.
I iterated over the list a few times until I had what critical features I thought would constitute my bare MVP. I then organized the critical features in order of when they would be planned for completion. This list became my feature backlog. The order was based primarily on which features were most important to indicating if the game had any promise (core gameplay, level design, etc.). Some features like the social integration, ads, leaderboards and IAP were all deemed necessary for the MVP but weren't core to showing the game off or playtesting so I left these till the end only to be done if the initial testing showed promise.
The game, like I imaging most, started off very rudimentary. I set up a square room based off my initial level concept and popped in the first ninja type, a basic red ninja who just ran across the screen. Added a swipe control to let the player throw shurikens and then let a few people play the game and started to gather feedback. Early playtesting indicated the game showed promise as a simple mobile time killer and also brought a lot of cool ideas that seemed like they would make the game much more successful. I recorded all the feedback and quickly went over each proposed feature performing a cost vs. benefit analysis in my head between how long I thought it would take to implement and how much better the initial release would be. Some ideas, like ragdoll physics, got added to my "critical" list and added to the feature backlog.
As development progressed it quickly became apparent that even though I envisioned the initial release of the game as a pretty simple arcade style shooter, it was still going to take a lot of time to finish by myself particularly since I had no experience in the tools I was using or any experience building a game really. That and I could only work on it outside of my full time job.
I started to look at some other successful games on the app stores and it was clear that above all polish mattered. I decided that it was better to have a polished product with smaller scope than a turd with a bunch of features. I decided to revisit my "critical" list and started a second backlog for a second release if the initial release showed promise. I then started to move items from my MVP backlog onto the second release and focused all my efforts polishing the remaining features for initial release.
The process was by no means perfect and I had plenty of setbacks. Some features, like multiple weapons, kept getting brought up while playtesting so I started to work on it. I made a few revisions with the multiple weapons but found it actually detracted from the simple fun of the game. The pretense for the game was that it is quick reflex arcade shooter. As soon as I started adding the ability to change weapons I found I couldn't keep the same pace in the higher levels. There was too good a chance you would die switching weapons. I also find mobile games in general work better with as small a number of unique controls as possible since screen real-estate is so limited, particularly on the phone. I think this kind of prototyping is inevitable but in this case could have been done much more effectively. I could have taken a MVP approach to the testing of this feature as well, initially offering only one other weapon and some quick hack code to get it to switch in order to test it out quickly with some beta testers. Instead I implemented 3-4 new weapon types and built a weapon management system to toggle between them. The bulk of this code got tossed after playtesting. Mistakes like this take a big toll on a lone wolf project.
The takeaway here is that unless you have unlimited resources you need to have a clear definition of your MVP and not stray from it. The MVP may fluctuate a bit in the very early phases of playtesting but the sooner you can lock it down the better. Focus on polishing a smaller scope project than distributing a jack-of-all-trades, which does no one thing particularly well. Continue to gather feedback but only let really important items get added to your feature backlog for the current release. If you add something you will likely need to remove something to maintain schedule so think long and hard and make an informed decision.
Development – Lessons Learned:
Venturing outside the MVP
I’ve already discussed the importance of defining the MVP at length but I really want to drive this home. It’s tempting to start focus on all the cool graphical stuff to start but this really isn’t a smart approach. Many times these are sink holes that take the longest amount of time to implement and are normally not even critical for an MVP. For instance, I initially thought I needed a separate scene when the game began for your settings, hitting play etc. While I did need these options, I could have kept it simple. But instead I had envisioned an impressive gate, covered with moss, surrounded by two torches and leading into the Dojo. When you hit play the doors would burst open and you would sort of warp into the main room of the dojo and into the action. It seemed awesome in my head and I started building it but it never looked or felt quite right. I burned a lot of time on it and eventually tossed it for the simpler, cleaner integrated menu that made the final cut. Mistakes like this take a big toll on a single developer / small team project. Leave the bells & whistles until you are making some money, then you have the resources to do it properly without affecting schedule.
Prototype Early – Don’t Get Caught Up on the Details
When is too early to playtest? Never. While I may not recommend releasing an unpolished product to the general public too quickly there is a great community of developers out there who are willing to give feedback on early prototypes. Even if you don’t have any cash to pay playtesters there are free options available.
Check out Feedback Fridays on reddit r/gamedev and offer some other developers feedback on their in exchange for some in return. I got some excellent feedback here and on forums such as gamedev.net from other indie developers for free.
Playtesting from strangers will give you a much better indication of problems in design, control, etc. than will playtests from your friends. Everyone knows this but there seems to be a reservation about playtesting too early. Don’t fall into this trap.
Looking back I would have submitted for playtests much earlier in the design. The earlier you get feedback the more likely you are able to action it.
If you have a budget for paid playtesting then I would encourage you to make use of a testing service. Although I had no budget for paying playtesters some services such as the “Beta Family” offer free trials. Taking advantage of these trials gave me some of the best playtest feedback I received. The feedback generally comes with decently written reports and some demographic information. If you can afford it this is the quickest way to get meaningful information from people outside your social circle.
Play to Your Strengths, Outsource Your Weaknesses!
Don’t just outsource your weaknesses, outsource anything you can afford to and don’t have time for!
Next to the importance of maintaining your MVP, this is probably the biggest lesson I learned while developing this product. As I mentioned early I had no experience with 3d modeling programs, or graphic design in general. While learning the tools was fun at first and I think the level design and models came out decent, this took a tremendous amount of my very limited time. Far more time was spent into polishing the game with new textures, updated gui’s, tweaking animations, etc than went into coding the game logic.
I spent numerous hours watching Blender tutorials, Photoshop tutorials and watching videos of actual artists creating concepts, promo-material and animations. Even though I learned skills in these tools, which has proven useful for tweaks and small-scale assets, I also know that it’s far more efficient to outsource the creation of these assets. I tossed a lot of the assets I made which were not production quality.
My initial hesitation to outsourcing was two fold. First, I initially wanted to do the work, I thought it would be fun. This is a good reason and if it’s a hobby project and you don’t care how long it takes than by all means continue down this route and build your own assets. Cg cookie is by far the best tutorial site I found for Blender, Photoshop & Unity. It’s not free but it’s worth the money. However, if you want to release a product, I highly suggest you don’t try to do everything yourself.
Secondly, I thought it was going to be expensive to buy art assets. Things changed when I read a blog somewhere about buying icons and art from a site called Fiverr. For $5 I was very skeptical I could get anything production quality… I was very surprised when I checked out the offerings. While most services on the site involve “extras” you will need to pay for to get what you want, it is still extremely reasonably priced. I got all the promotion material for Ninja Gold Rush (such as the Banner on the Play store) along with the sound effects for under $100. I also met some great people on there who continued to support me like Collin Scudder who I’d like to give a big thanks for contributing the in-game music and bulk of the sound effects.
In addition to paid services the indie community can be a great resource for assets. Even outside of other game devs people just genuinely interested in the indie scene may reach out and see if they can help. As an example, I made a post about where to find some music on the reddit game dev channels and Jefferson Apply volunteered to let me use a version of his “Hidden Blades” track for the game trailer and even performed some custom modifications on it to fit my needs. You just need to get your name out there.Wherever possible use 3rd party libraries.
This isn’t so much a lesson learned for me during this project since I had the mentality to do this based on my years of professional development experience. The reason I bring it up is because when I talk to (particularly new) developers they seem to have an aversion to using someone else’s code. I only write this to point out there is no shame using a library which someone else produced (provided you have their permission of course). It doesn’t take much of my time spent on a problem before I can justify a $20 library or plugin and many libraries are actually free!
Take advantage of these libraries wherever possible but be aware in some cases they may be a two-edged sword. Other software upgrades such as iOS / Android updates may break compatibility with a 3rd party product. Even if the product is open source it’s likely very difficult to fix the problem since you aren’t familiar with the code base so keep this in mind. Though in general I recommend always at least researching 3rd party products before attempting to build your own solution. This way you can take advantage of the work others have done and spent the rest of your time building your unique solution.
The Release: How to get discovered:
This is probably the biggest challenge as I’m sure most indie devs who have released a product can attest. There are some pretty discouraging stats and posts out there that if I had of read before I started may have made me think twice about even pursuing this project.
As of right now I haven’t done much promotion and I don’t plan on paying for advertising. I plan on chiming in on some forums and try to throw in some shameless plugs. I’m hoping the promo art has a good enough hook to get people to click and maybe download. I’m hoping that people enjoy the game enough to share.
It seems obvious now but something I never really considered was that mobile consumers typically don’t search for a game by name they just check for what’s trending in a particular category. This is why once an app starts to rise it continues due to the increased visible, etc. It’s why the same apps seem to be forever on top. This is a major hurdle to cross as an indie particularly without deep pockets or connections. You really have to just try to get the word out as much as you can, hope people share and get people to search for your product by name!
This is why it’s a tough balance to keep your MVP attainable while also making sure it’s functional enough to retain customers and get recommendations.
Pending the outcome over the next few weeks I may devote another post to my promotion of the game and ultimately how successful I was. For the time being, like so many other indies, I don’t have the answer.
Where to go next:
Regardless of its level of success “Ninja Gold Rush” has certainly been an experience I won’t forget. Whatever project is in my future I’ll be able to draw on the experience of this project and the lessons I have learned and have yet to learn from it.
I encourage anyone who has an idea they believe worth pursuing to take immediate action. Don’t be afraid to fail, worst case you will certainly learn something.
One thing is for sure. It’s been a fun project to work on. I hope you have the chance to check it out leave me a comment and let me know what you think. You can reach me at: hurlbz@gmail.com
Ninja Gold Rush is available now on Google Play: LINK and will be coming soon to iOS.
