My name is Steve and I am the founder of LoOnar Forge. We got some news: The Watch – Midnight Bronx has hit the milestone! We are out of the Alpha stage and we are getting close to publishing our game. But enough about our game, this article is about what mistakes we have made, and what we have learned while getting to that stage. Hopefully, others will benefit from our lessons and mistakes that we have made. Like we had learned from countless tutorials and articles while making our 2nd mobile game. Without the support and selflessness of the community members road to here would be much harder and longer, and the final product would be very different. I think it is crucial to stress out that this is what makes it possible for most of the fresh developers: support from others, free assets and the massive amount of tutorials and courses available for everybody. Also having an amazing game engine like Unity for absolutely free helps a bit! Big thanks to the UNITY team for their constant work and a massive amount of improvements and new content. Right, let’s jump into it, we have few things to talk about. This are the lessons that we have learned, from the beginning of our second project until today, a few weeks before the release.
Lesson number one: TIME REQUIRED
You have heard it a lot before, the time needed to finish a project will be significantly larger than what you have anticipated at the beginning. Even after you have added an extra 3rd of the initial time required on top of it, and extra few months just to be sure. For us, the biggest single delay was the day job. Ahhh that bloody day job is messing everything up. It might not be the case for everybody, but if you don’t have to go to work, chances are that you have some budget that will run out of or you have parents that will run out of patience and tell you to get a paid job! What I am trying to say here is that you need to be pessimistic when planning how much time is required. Assume that you will need much more. Give yourself a target date to aim for, one that feels right, one that is ambitious, that will keep you on your toes and force you to work fast. The date can coincide with some event or time of the year, big companies tend to release their games at large events like E3 or before X-mass, but us, little ones need to aim to publish in between so the gaming portals and influencers can focus on your game, and not on the release of FIFA 2069 (Read this and that for more info about choosing the right release date). Sometimes you will spend days trying to implement a tiny future that normally should take less than a few hours. On the other hand, encrypting our saves in The Watch took me maybe 2 hours all together. I was petrified when I decided to implement it into our game. I thought it will be a coding nightmare, but no, it was straightforward. Just be prepared, if it is your beginnings chances are you won’t time it right and you will have delays. Assuming that you will need more time to finish your project will help you also when you feel tired and you had enough of all the issues while creating your game. Knowing that you are months behind already makes it much harder to carry on.
Lesson number two: SCALE OF THE PROJECT
Do not start with a multiplayer, cross-platform, real-time simulation of the Universe. Think about those, plan for those, but do not start them, not just yet. I am sure you have heard that before, but the reason why I am mentioning this is that there is one more very important thing to add to it. So, you have listened to the more experienced developers, you did carefully plan your next (or first) project, that is reasonable and absolutely doable in a relatively short time and you have started. Great! But then as you develop and iterate, a new idea comes up, and you decide that your cool yet simple top-down action game will be much cooler with the achievements, and maybe a little page in options with few game stats, or maybe a lot of stats, and then, of course, you need tutorial that is very comprehensive and at least three tiers of items for both male and female players, and… and here it comes again. That need to go big and to add grandeur to your project will hunt you till the moment when you press “PUBLISH” button. Just be wary of it. I am not saying to stick to your initial plan and discard any changes or additions right away, far from it, as I said game development is an iterative process and you need to change and adapt as your game takes shape, just remember not to bloat your project, we are creative types, it is not the problem to come up with the most awesome mechanics, at that stage of your, hopefully, very long career it is the time that is your enemy.
Lesson number three: GAME DESIGN DOCUMENT
“A game design document (often abbreviated GDD) is a highly descriptive living design document of the design for a video game…” (you can read more about it here). Did we have one? No! Did we need one? Hell No!! Why? You may ask. Because what I had in my head when the idea first came to me, compared to when I was thinking about the details before starting the project, compared to when I have started actually implementing all the ideas I had, compared to when I have realized what I can and can not do, when I saw how much time it takes to put certain ideas to life it was all different than what I thought it would be at the beginning. Pheew… To make an educated decision and plan successfully ahead you need to be educated in the first place. If you are a small team or a solo developer starting one of your first projects, you are not experienced enough to make a right GDD that is worth the time. Think about one, as you go. We did. Think what information do you need beforehand to make your life easier and progress quicker for your next project (I am sure you know already what will be your next game. You should, anyway!). When we started on The Watch we had a list of various ideas for the game mechanics, looks, UI and controls. As the game developed some of them were scrapped, some of them changed drastically and also new ideas were born as we could see what our game is becoming. I am not saying a comprehensive GDD is a bad thing, but you need to know if it is worth your time. There is no need to spend two days describing what feel do you want to achieve with the music and sounds when you are a solo dev. You will know right away the second you hear the right theme! Summarize most important ideas and characteristics in bullet point form and get your hands dirty!
Another way that we have used to collect and share ideas was Pinterest. For the visual part of the game of course. It is so easy and simple to add new images, when you are sitting on the bus (or at the boring dinner at your uncle’s place), just scrolling down and looking for new inspirations, in no time you collect quite a large collection of images that will shape into a visual representation of what do you want to achieve, complemented by your list of ideas and core game mechanics. Feel free to visit LoOnar Forge Pinterest page here. There is a bit about our current project but we have already collected nice folio for our next two projects. Check out folders named “Sheep Happens” and “Traffic Jam”.
Lesson number four: ITERATION AND CUTTING STUFF OUT
This lesson is short and sweet. As I have mentioned above game design it is an iterative process. You can’t plan ahead too much because everything is interconnected. When one tiny thing gets changed it can (and probably will) affect almost everything in your game. Do not be afraid to change things. The quicker you realize that something is wrong the easier it will be to change it. If you think something does not fit entirely. To Hell with it! Get rid of it. We have scrapped quite a few ideas simply because they didn’t feel right once in the game but seemed legit in theory. Also, we have scraped some ideas because they proved to be taking up too much time (It was the case with Google Play achievements). It would be great to have it, both for the players to enjoy and for our studio to see how far people get (we use Unity Analytics instead which are relatively easy to implement to track players progress), but we ran into too many problems with it and it took almost two weeks so I have made the decision to skip it for this project. If the game is doing good, we can always add in the update! No problem, move on.
Lesson number five: GOOD CODING PRACTICES
You can write a whole book about it and people did. Keeping your code clean is paramount. When you do things from lesson four, clear code makes it so much easier and quicker! What I have found to be the most important is:
You need to describe your code! Making commentaries about your code is crucial, each method should have a short but clear description of what it is doing. Make the name of said function descriptive as well. Do not abbreviate too much. Some of our function and variable names are as long as 20 letters or more! If it has to be long to be easy to read 2 months later, then it is fine. “PwrBtnTP“ is obvious when you type it, but trust me, in two weeks time you will get back to your own code and you will have no clue what it is meant to be doing. If you name it: “PowerButtonTeleportOnOff“ you won’t even have to think for a second to know this function’s purpose.
Naming conventions. If you didn’t have much to do with coding before and you dig into C#, you will think that the naming people are using is crap. It isn’t. You will get used to it and it will all make sense one day. But if you insist to change it for whatever reason, stick to it. Do not change it again in the middle of the project. You can always make changes to the way you write your code when you start your next game. But for the clarity of the project, keep it uniform.
What I like to think when I am coding is that it has to be clear enough for a guy, with the same amount of coding skills as me at the time when I wrote the code. If he took over from me, after a quick glance at the code he should be saying something like: ” Ahh I see, so this function is doing this and that and …” If it took you a long time to get a script working because it was something more advanced, put a decent comment to clarify most of the things. Trust me, this isn’t for the theoretical new guy that will start working at your studio. This will be most helpful for you!
As I have said before, this subject is huge and I am definitely not the authority on it. If you are hungry for more, check those articles out, they will get you started:
Lesson number six: BACKUPS
Back up, back up and back up again, and then back up your backups. Buck up few times a day on your computer if you make significant changes to your game and code. Sometimes you will change too much and you will get lost. If you copy your project folder just before you tackle a new functionality that changes 15 scripts and you get lost and mess things up, it will take you 1o minutes in total to restore it. You do not want to use back up from the two days ago and lose all the progress that you have made since then. It hurts a lot! Get into the routine of copying your projects folder after finishing a certain amount of work. I have usually 4 backups of the project that I override as I progress, named something like: “The Watch new”, “The Watch”, “The Watch old” and “The Watch very old”.I make a new back up once or twice a day, or even more often depending on how much work I have done. Sometimes a bug or mistake can come out much later, that is why it is worth to have a few older backups still on your hard drive. Also every few days I will take the most recent version of the project, pack it with Win Rar, and copy it onto the external HD and to the dropbox (I know, I am mental).
Lesson number seven: REMEMBERING ABOUT THE FINAL GOAL
One of the biggest factors that have slowed down our design progress so far is fear of tackling a new problem or getting to the new stage of the development, like going public or implementing new futures that you have no idea about. I have caught myself spending the whole day adjusting locations of the lamp posts, for no real reason because I knew that the next thing to do on my list was difficult. Procrastinating about your project, from what I have seen from other game devs stories, is our biggest downfall. Another thing that was/is battling me is the fear of going public. “It is not ready yet.”Just a small screenshot is fine for now, I will show them more later. When I am ready.” “I don’t want to talk about it…” SHUT UP ALREADY! Being public about what you do is an integral part of the process, one of the most important ones as a matter of fact. At the early stages of the devs career, it will bring critiques of your work. Some of it might be mean but you need to listen to it. Firstly you will learn what you are doing wrong and secondly, you need to learn what people out there think about your product and what do they like to play. It is them who will play it, buy it and decide its future. You do not do games for yourself if you are serious about it. You make them, others play it. If they enjoy your game, hopefully, you will enjoy the process of its creation. It is not easy, you will be petrified about what people will say, but you still gotta do it. Period.
Amongst the hundreds of little targets, that game dev has, like getting music and FX fit the rest, promoting your game, getting a fan base, making sure it is sorted out from the legal side, securing funding, finding name, time, logo, balance, QA, animations, clean code, visuals, testers, achievements, multiplayer, platforms, blah blah blah. There is a single most important one that seems to be overlooked or rather lost between the others. Do not wait, do not stop, do not look back. YOU NEED TO FINISH AND SHIP YOUR GAME! At this stage of your career, it is paramount to finish your project. You have limited knowledge, limited time, limited resources and limited patience. Use it well.
Before I have started writing lesson six, I went for a lunch. I was roaming through Reddit while eating and I have found a post of a guy saying that after almost four years of the development he gives up now (Four years!). I thought, damn, it must be a massive project after four years, so I checked it up, I was wrong. I thought maybe his project was too weird and no one liked it, I was wrong, it had 2000+ followers. I thought maybe he ran out of money or had some issues outside of the devs world, wrong again. He has been procrastinating, switching to different projects and abandoning them over and over again after he finally decided to shut down the main project as well. Do not do that. FOCUS! Think about future projects, gather some concept art, think about it while standing in the queue, but do not let it distract it you from your single goal:
YOU NEED TO FINISH THE CIRCLE AND SHIP YOUR GAME! It is not a board game or a car. You can always make an update. If you feel like you had enough, you can release a demo version, or 50% of the levels intended and ask people for the feedback and then decide to carry on or not. Finish the circle. It starts with the idea, and its basic implementation, then it is all nice and pleasant. As you progress, more grim jobs await you: bug testing, quality control, legal stuff, promotion and more. We devs don’t like it, but it has to be done. Pace yourself and finish the project. If you look at the previous lessons, almost all of them convey the same message but in the greater details: Scale your project accordingly to the time and skills that you have, be ready to alter it to get to the end and be prepared to come back to it. Maybe it will turn great and you will want to make a sequel or a DLC.
It is not your last project. Maximizing your time and making games from A to Z is crucial, that is how you will progress. I am not saying to publish crappy game every three weeks, we have enough of those. Just don’t get caught in the endless cycle of bettering your product in the basement. With each and one of them finished, you will know more. You will need less time. You will have greater results and better tools. Your team will grow and you will know more people. Maybe then we will be all reading about your success.