4 Things You Should Know as a New Programmer on an Indie Game
So you've gone through a couple of Unity Tutorials, and made a couple of minor games, and you think that you're finally ready to start on your first big project. Working on a big project with a team is very different from making a sandbox game by yourself. When Pattie and I first got together to talk about The Girl Who Sees, I was interested in working on it because I saw her leadership capabilities, and I knew that would give me the opportunity to really learn how to program in Unity. I've learned a lot while working on the code for this project.
1. Communicate in pictures
This isn't necessarily Unity-specific, but it is a good concept to keep in mind whenever you are working with a team on a game. When you're working with other people, it can be hard to determine exactly what you mean without visual references. Before working on anything, it is a good idea to make sure that you have some visual references to work from. This can mean bringing up games of a similar genre (our team has certainly had our fair share of time looking at tactical RPG grids!) or drawing out the diagrams of systems and interfaces. It is so much easier to work with a picture than with a description. This is also important to keep your mind on the goal when making user interfaces. In Unity, using the UI system can sometimes be tough, as until you have a lot of experience with it it can be difficult to determine where your UI elements are going to end up. Having a diagram to work from keeps you focused on developing a user interface that is beneficial for the players, rather than simply one that represents where the layout ended up because you couldn't figure out how to get the panel just the place you wanted it.
Diagrams with behavior descriptions are very helpful when creating and planning User Interface (UI).
Taking pictures of bugs and errors provides clear info to developers.
2. Use existing systems
One of the great things about Unity is the asset store. When I first started programming our game, I was building everything from scratch. Of course, I learned a lot about building systems, but a lot of that time could have potentially been used elsewhere. Instead of trying to get a Tactical RPG system from scratch, I found a free system available on the Unity Asset Store (Turn Based Strategy Framework). I am very grateful that someone would take the time to make such an extensive system and make it free for use. Of course, I had to make adjustments for the elements of our game, but having a system to build on not only cut out a lot of the low-level system work, but also taught me another programmer's style. As a new programmer, learning from other programmers can be very helpful. In addition to the Tactical RPG system, we are also using Fungus for dialog and other event handling. This system is very fleshed out, and although there were some interfaces needed to interact with our systems, it was a fabulous base to work from and cut out a lot of the manual work of creating a dialog system. Using template systems early on can really improve the quality of your work, but as you develop the game more it can be harder and harder to implement template systems, so it is important to start early. If you are making a game, and you need anything that you would call a "System", always make sure you check the Asset Story for "X System" before you start programming it yourself. It may be worth it to pay money for a pre-built system rather than try to build it by yourself.
3. Don't be afraid to refactor
As a new programmer, you are going to write a lot of code. A lot of the code may not come out well, and you may encounter some parts of your code that you regret returning to. While it can be tempting to always be working on the next feature or fixing the latest bug, it is important to take some time to go back and map out the systems that you have created and how they connect. For a really good exercise, try drawing all of the interactions between your various classes, you may be able to find a good way to organize the code and cut out a lot of the junk that accumulates as you test out new ways to add features in your scripts. I have redesigned the main systems at least twice, as I gained skill at programming and learned better techniques.
4. Always version control
I manage version control systems at my day job, so using Git comes naturally to me. As a new programmer, you may find that you program yourself into a hole that becomes impossible to dig yourself out of. I have had many cases where I create a branch for a complicated feature, and I wind up having to throw out the entire branch and start over. If I didn't have version control set up for the game, I might have left the game in a broken, unplayable state for a long period of time. My practice for committing is as follows:
By using version control, I can erase my mistakes without having to worry about creating duplicate projects and taking up space on my disk for the game project. As of this writing, our team has 399 commits to the Git repository for the game. My committing practices have prevented me from tearing my hair out many times over. One caveat: Scenes don't merge well. If you are working with a team, try not to work on the same scene at once. One way to get around this is to give each individual a "sandbox" to test out implementations of features, then one person can be the designated "merger" to bring the changes into the primary scene.
Conclusion
Hopefully these tips are helpful for anyone else out there who is a new programmer in Unity. I've only been programming in Unity for about 400 hours, so I've still got a long way to go to be really effective at making games with Unity. Making games is quite an adventure, and hopefully these tips are helpful for anyone else who is starting out.
Nathan Hahn is the Lead Programmer for The Girl Who Sees, a video game currently in production led by Pattie Umali.
