My first game project taught me a lot about programming in C# with Unity. When I started my project I didn’t know what to expect, I just made a list of things to code then learned how to code them. I learned about a lot of tough stuff like basic AI, polished collision detection, and building menus.
But the most valuable things I learned were the softskills: Non-programming/Unity related skills that amplified my programming work.
These skills are pretty easy to learn and implement but have been a tremendous help to my programming studies. I didn’t really see too much value in these at the beginning of my project, but near the end I was very thankful that I had put these into action:
1. Have a Feature To-Do List
“Floating health bars above all objects with an HP pool. This bar should only display when current health is <= 99%”
“A UI pause menu using Unity’s Object-based UI system. Three button options: Unpause, Restart level, and Quit to main menu. Restart level must deduct 1 life”
My first project had a massive feature list that I’d add to almost daily. Whenever the list got low I’d spend the beginning of the next day brainstorming a ton of ideas to learn how to code and implement.
After a few weeks I had realized that I could maintain a very high level of focus with my feature list. The minute I finished a task I would immediately switch it to “done” and pick the next thing on my list. I wouldn’t get stuck thinking “What am I going to do now?” which would have crashed my momentum I had built up.
Ideas aren’t too hard to come up with if you’re game-savvy. The majority of your time will be spent learning how to code and implement features that are universal to your game’s genre. Most of the features in a game are features that define the genre itself, so copying some ideas is okay. A trick I use is to just find 3-5 games similar to the game I’m making then I just literally copy what they did (not copy-paste code, but learn from scratch how to implement the same feature).
When I wanted to make a platformer, I simply tried to copy the majority of the features in Mario. When I got to a point where my game was a generic platformer, I spun it into my style a bit more and added some of my own ideas and features. If you’re working on a genre you aren’t familiar with then I recommend you go spend an hour or two playing some classics of the genre and making a list of all of the features they got right. Use them as a reference as you create your to-do list.
Don’t be afraid to fill your list up with things you’ve never done before, you should be doing that as much as possible. I knew how to implement absolutely none of the tasks on my first feature list, yet I implemented everything on it. It was very fulfilling to shrink the list down to nothing each week.
If you don’t know how to implement things you’ve never done before, check out Phase 3 of my other blog post How to Get Started Programming in GameDev with Unity C#. The idea behind it can help you even if you aren’t using Unity or C#.
I recommend using Trello for planning a feature list.
2. Version and Back-Up Every Day
Google Drive Zip file: “Platformer Project 4/27 v0.25”
- Set the Unity project’s default graphics quality as “Normal” with Vsync enabled
- Implemented a gameover UI with a Game Over soundtrack attached to the UI object. This UI is called when the player dies with lives at <= 0.
- This is not called when the player’s Continues is <= 0″
Please back up your project at least once a day. It’s only a matter of time before you experience a computer crash, a game engine crash, a harddrive failure, an IDE crash, or just a project that corrupts itself mysteriously. You should assume it’s going to happen at some point, because when it does you’ll be very thankful that you’ve made back ups.
You should have a library of previous versions of your project available for download from cloud storage. Each version should have at least a version number listed on it.
You should have a version list of what you added to the project each day so that you’re aware of what you’re rolling back to. This will also give you a clear idea of what you did each version.
When I started having people test my game they all reported various mild bugs. When I implemented a few more versions over the week and began testing I suddenly had universal reports of a game-breaking bug.
It took me moments to find the issue by rolling back versions until the bug was gone. I then looked at my features list for that version to determine what was added. I then narrowed down my changed until and found what had caused the problem.
Also, on TWO occasions I’ve accidentally deleted important scripts in Unity instead of an object (this is unrecoverable). Good thing I made a backup just an hour earlier.
3. Detailed Documentation
Build your own database of detailed, searchable reference material
I make sure that when I spend a good long time learning something new, I spend extra time to carefully document exactly how I did it. Every difficult unique feature I’ve implemented in any of my projects can be searched and found in my Microsoft OneNote notebook. I’ve slowly built a library of small how-to’s that I can reference in future projects. This is excellent for refreshers on how I did something in the past.
Being reminded of how did something is nice, but it’s not supposed to be a crutch either. This is where I think the real value is in writing detailed notes.
“I have found that the only way to truly learn something (and by this I mean to have that true in-depth knowledge of a subject, one that does not fade with time) is to teach it.” — Simple Programmer, “Learning to Learn”
Here’s a good trick I use for solidifying knowledge: write it as if you’re trying to teach someone else. I try to write how-to’s as if I’m teaching my past-self how to do it (before I had spent the previous 2 hours experimenting, googling, and searching Unity Answers). My notes are at a quality where I can literally copy and paste them to somebody to teach them how to do it.
This isn’t as good as outright teaching the subject, but I feel this way of taking notes will be very valuable to you when you want to remember something.
I recommend OneNote because if it wasn’t obvious, I use OneNote a lot.
4. Let Your First Project Be Small
“2 to 3-week practice project. Create a mario-esque platformer to teach myself the basics of practical gamedev” — My First Practice Project
If you’re going to start your first project, start small. You’re likely going to make more mistakes than you ever will make in your gamedev career. Be ready to make them in a project you’ll be able to toss, and do this for a few projects until you’re good enough to handle a big one.
This teaches you end-to-end project management, which is a lot better than 1 long messy project. Quantity of projects, not quality, is how you’ll improve faster right now. Just be sure that you’re constantly improving and laying a better foundation each time.
My first plan (seen quoted above) was very simple: make a small game and then force myself to stop in 3 weeks. My features goal changed a few times, but I settled on finishing it with 4 short levels and 1 boss fight. It played decently enough and felt like a demo for a game. I squashed every known bug and polished it off so it was how I expected it to be. It was a fun player experience and people said I did a great job.
It was a nightmare dev experience. Since I was just a rookie programmer, I had begun to slowly drown in my own code. Looking back on it, the code under the hood was a complete and utter disaster. I had written every enemy from scratch, I had a God object with 300+ lines, hundreds of lines of code were copy-pasted instead of inherited. As I polished it off and released the final version I breathed a sigh of relief, thinking “I’m glad I don’t have to dive into that mass ever again”.
This “drowning in mistakes” feeling forced me to become aware of a lot of different superior ways to implement my code. It had me asking a lot of questions on how to improve. It also eventually taught me how to plan a detailed project with classes and methods before I even start coding.
When you beat yourself up with a couple bad projects, you will naturally find ways to be smarter and cleaner with your next projects. I don’t know how long your first project should be, but it’s probably over when you have to rebuild it almost from scratch just to add a couple things.
Good code allows you to maintain and improve things at a rapid pace, so it’s much faster to purposely start clean a few times as you learn.
friends, co-workers, family, classmates, social networking followers
Just because it’s your first project doesn’t mean it’s not good enough to give to a few testers. Testers will give you a very valuable, unique perspective on your project. They will provide you with a ton of bug awareness that you can never get alone. Testers will also teach you how to provide for a target audience, as you’ll frequently hear what features they’d like to see in your game.
Here’s an example of how a tester made me more aware of the flaws in my game:
I’d been working on my project for around two weeks. My mind was stuck in work mode, my creativity was poor. I started to see it as an endless series of code wrapped up into features and bug-fixes. I saw a bunch of 1’s and 0’s that needed maintenance, not a fun game that needed more fun stuff.
When I sat down to think of features to add, I felt like I had a pretty good priority list. I couldn’t think of more basic things to improve upon, so I started doing extra stuff like scenery and music. I didn’t realize it, but I had a tough time seeing my project from a gamer’s perspective instead of a programmer’s.
When I presented my game to my friend for the first time, he immediately started calling out every broken mechanic that I stopped noticing after my hundredth test. “Is the character supposed to get stuck to a wall when you jump against it?”
Errr… I forgot that was even a problem.
I had tested my project so many times I had actually forgot “getting stuck to a wall” was even an issue. I just got used to it, avoided it, then forgot about it, eventually thinking it was “normal”. It was kind of like switching from an HD 1080p monitor to a 720p one for a week and a half, then slowly forgetting what 1080p looks like.
This happened a few times during my project. To the amusement of my testers I profusely thanked them for making me aware of my game’s most obvious and biggest flaws.
Testers will also find a ton of bugs and nitpicks you’ve never heard of. I once spent a day and a half solely on bug-fixing. I then tested my full game three times from beginning to end. I sent the version to 4 testers before going to bed that night. I was ending the project in 3 days, but I was pretty confident it was done and bug-free.
The next day I get emails and IMs from literally all four testers saying there’s a game-breaking bug in level 2 and the game was “unbeatable” because of it. What the heck? I just played the entire game three times yesterday! It’s almost as if there were bugs that evaded me on purpose. Thanks again, testers!
One last little tip I learned from looking at my tester’s feedback. Two of my testers were occasional gamers (<5 hours week) and two were dedicated gamers (40+ hours a week). The dedicated gamers found 5 times the amount of bugs than the casual gamers, and they found them all on their first play through. So try to find some game-savvy testers in your target audience, they will be a lot less gentle with your game.