5 Game Development Tips From a Solo Developer
I have been developing games for a year and a half, and the last few months I have dedicated to creating my first completely independent project. I did not have such experience, since I previously participated in the creation of games as a Unity developer, and the scope of my tasks was limited. And now I have to do everything myself. Although I am making a game for mobile devices and the web, I clearly feel that its development has dragged on.
In this regard, I began to think often about the reasons for my slow pace and was able to form several pieces of advice based on my experience. Some of them may seem obvious and obvious to you, but I believe that it is still better to “say such things out loud”. I would like to immediately note that everything written below will be mostly useful only for beginning solo developers or young teams of two or three people.
Don't neglect documentation
In general, I have long ago made it a habit to keep notes on my phone and write down absolutely everything: from a banal to-do list or grocery list to my ideas for games. This frees my head from intrusive thoughts and allows me to concentrate on things that are important at the moment, and then return to what I wrote down.
Therefore, no matter how big your project is, don’t be lazy and write a design document. Even if you want to “knock together” a game in a week to match some trend. Take some time to outline the main features — this will make development much easier for you later.
Let's say we want to make a game called “Roll the Balls”, a simplified clone of the popular Going Balls. A small design document can be written anywhere: in the same Rider or VSCode, or even on a piece of paper.
![Screenshot from Going Balls Screenshot from Going Balls](https://habrastorage.org/getpro/habr/upload_files/576/778/30e/57677830ea208dbcba5b0dea66ca83db.jpg)
![Screenshot from Going Balls Screenshot from Going Balls](https://habrastorage.org/getpro/habr/upload_files/fd7/e31/18b/fd7e3118bb088dab38d8645b6f1efebc.png)
Now that the main points are written down (see screenshot above), we can evaluate and form a rough structure of the project and start asking questions:
Will we make an alternative control option, for example, a joystick or a gyroscope? How will we determine a loss – by the ball falling below certain coordinates in space or will we use colliders under the platforms? Why should we collect coins? Maybe the player will open the next levels for the collected coins? What system will the player use to score points for the level completed? What colors will we use? Will we create thematic levels?
By writing a document like this, you can more clearly visualize the game in your head and see both potential problem areas and areas for growth. And later, you can add to your notes or mark completed segments, making it much easier to track progress.
Work closely with references
Study as many successful games as possible, not only in the genre of your game, but also related ones. Borrowing successful solutions is absolutely normal.
The most important thing is not to just copy blindly, but to try to decompose this or that element and understand why this solution seems good to you, what mechanisms attract and retain users and you yourself.
The more references you collect and the more closely you work with them, the better the final result will be. You will be surprised at how quickly new ideas will start to come to your mind. At this point, it is important to return to the previous point and start writing everything down.
It is important to note that both of these points should be applied in the “pre-production” stage, before you start active development. A good job at this stage will save you weeks, if not months, of development time.
Don't be afraid to give up on some ideas
It's okay to abandon ideas during development. After all, only things you're confident in should make it into the final version of the game. It's important not to get too hung up on one idea and experiment, preferably early on and as much as possible.
I lost about a month because I was stuck on a certain visual style that just didn't work for me. I couldn't put all the elements together and was constantly redrawing something. Until suddenly, not without the help of my wife (but more on that in the next point), I decided to move as far away from the original style as possible and start experimenting.
In the end, over the next 3 days I drew 90% of all the graphics I needed, and I like the end result much more.
![My first attempts to draw a Background for the scene My first attempts to draw a Background for the scene](https://habrastorage.org/getpro/habr/upload_files/d9c/23a/c9b/d9c23ac9b371652b9226fb0629c37947.png)
![Background for the scene, drawn in a new style Background for the scene, drawn in a new style](https://habrastorage.org/getpro/habr/upload_files/7aa/c70/6c6/7aac706c6bbd8a013f88462d5d75965d.png)
Returning to our fictional game “Roll the Balls” from the first point, let's assume that you decided to abandon the leaderboard and scoring system. This can be justified in different ways: you do not want to waste extra time, you have not figured out how to implement the feature, or you are simply not sure whether this mechanic is needed in the game.
Feel free to cut this feature, nothing good will come of it anyway. If something in the game development process frustrates you, either abandon the idea completely or try to look at it from a different angle.
Start showing your game as early as possible
When you work on something alone, especially for a long time, you gradually begin to lose touch with reality. It is not always clear how good the idea you have implemented is. Is it interesting to other people? Is it understandable?
If you work in a team of at least two or three people, the situation becomes a little better, but still, any decision requires an outside perspective. In large companies, this function is performed by play tests, but in our case, there are simply no resources for this.
In such a situation, the best solution is to turn to the community. In the Russian segment, there are a huge number of resources (forums, groups and channels) where you can post your project and get quality feedback, including from professionals.
Based on my experience, I can assure you that the game development community is very warm and responsive. To be honest, I am even a little ashamed of some of the questions asked on various forums and groups – they were so stupid, in my opinion. But at the same time, I always received an answer to them and never encountered arrogant judgment.
In addition to feedback from the community involved in the games, be sure to show your creation to your loved ones. Especially if they don’t understand anything about games. This way, you can see the reaction of the average user, for whom the games are created, and benefit from it.
For example, my wife helped me find the visual style of the game. I told her about the essence of the project, what emotions it should evoke, and then asked how she imagined it. To be fair, it’s worth mentioning that she has been working as a UX/UI designer for several years. Yes, yes, I know, I used a cheat code. But don’t rush to devalue the experience of your friends and family — even if they are not involved in game development, they can still surprise you with great ideas.
However, it is important to remember one single thing – all key decisions in the project should be made ONLY by YOU. People's opinions can be contradictory, professional developers can give completely opposite advice. Your task is to learn how to work with this feedback correctly.
Don't be afraid to ask for help
You don't have to take on a ton of responsibilities and do absolutely everything yourself. You don't have to write your own game engine when there are plenty of open and free solutions. You don't have to suffer in Photoshop, Illustrator or Blender if you're not an artist – use ready-made assets.
Use ready-made solutions for creating mechanics – a large number of programmers post their developments in the public domain. The main thing is to always clarify the terms of use of certain things.
Going back to the previous point, don't be afraid to ask other developers for advice. After all, we're all doing one big thing.
To sum it up, I would like to say that if I had followed these tips myself, I would not have spent a lot of time reworking the main mechanics, I would not have lost a month of development because of my fixation on one visual style. I would have come to successful solutions in my project faster if I had started showing it to other people earlier.
I hope this material will help other developers create games more efficiently and avoid making my mistakes.
I recently started personal blog about games and developmentso I will turn to the last point of my article and ask you to subscribe to it if you liked this material. I will also ask you to leave feedback on the article and share your “best practices” in the comments.