First, let me show you a trailer of the game. Don't worry, it's only 1:24 minutes long.
Want to play?
Here is the download link. (in-game hold T to turn on a car)
Contents:
- Introduction
- Technologies used
- Coming from the web developer world
- A word about game engines and Unity
- Challenges (mostly in math)
- A few words about the deadline
- What went good
- Recognized mistakes made
- 9 learned lessons
- Looking at the game a few months after
- A word about the beautiful tool - Git
- Final word
Disclaimer
It isn't so much of a technical blog, although the whole source code of a game you can find here.
The blog should teach you the lessons a programmer from outside the game-development world learned developing his first game ever.
Beware, it's licensed.
Introduction
It's a 3D race game with advanced manual shifting.
The game was done in less than a month by me and my colleague, and this is my (but also his) first game ever made. The game was made for the competition contest.
A lot of new has been learned, and I think that this blog should give you a few lessons which I learned along making this game.
Technologies used
The game engine is Unity.
Scripting is done using C#.
For the versioning system, I used Git (and Github) of course.
Coming from the web developer world
I've been working mainly on full-stack projects on the web, so this was a new challenge for me.
Coming into the gaming world has been a beautiful experience in which I learned a lot.
It is fascinating to me how the whole system functions in games, and how much knowledge is required to bring entertainment to the gamers.
A lot of the same problems arise in the both web and gaming world, but I noticed that it is a lot easier to hit hardware boundaries accidentally in game development.
A whole new world has been open to me upon learning the cycles in which Unity operates.
Although I don't enjoy gaming that much anymore, I would like to say that this was enlightenment and that I'm impressed.
A word about game engines and Unity
The most interesting to me was the execution order that is run by Unity.
Upon learning that, I had, and still have, a lot of questions - where to put my piece of code so it doesn't bug the whole game down.
I have a lot of questions - about shaders, meshes, and all that magic stuff. Although the game can obviously be made without knowing a lot of the answers (at least in depth that I respect as the "good" answer), I don't feel the satisfaction of knowing all the inner details - how it functions under the hood.
I know that a big part of game engines is based on linear algebra, and although I know the operations - I didn't make my own engine, and I don't think there's a better way to understand a game engine better than to make your own. Making the game engine isn't my priority now, but maybe someday I will try to make my own for fun.
The question could be referenced for a lot of things - you know how to write code but don't know the assembly it resembles, why don't you learn that also? The answer to that maybe lies in the curiosity of the programmer that is reading this - which depth satisfies you?
Anyway, learning the execution order is the crucial thing when working with game engines - and before you realize that upon not being able to optimize a game to a playable level, maybe it is better to learn the execution order beforehand, so you avoid a lot of the headaches.
Challenges (mostly in math)
My part about the game was to make realistic manual shifting. I enjoyed it.
The thing about the manual shifting could be seen in this photo:
Force applied to wheels isn't instant (in internal combustion engines, of course), and, as you can see, it is being carried over the line that looks very similar to a sine wave. I have done exactly that in the code, so that part feels realistic. To get that skewness in a line I scaled the angle passed to the sine wave function.
Also, when shifting from e.g. 1st gear to 5th gear - the car should turn off. Torque is being carried between adjacent gears. How I've done that part can be seen below (it's a sketch obviously, but it conveys the message):
Solving heat challenges was also interesting to solve. Feel free to take a look.
It was also interesting to tackle audio problems, which I solved using audio pitch and audio intensity, so it sounds realistic.
A few words about the deadline
The game was done during the semester, so it was stiff and tense with the time. A lot of things could be implemented and fixed, but - time is the final judge. It was done a few days shy of a month with no prior experience in making games.
What went good
Before self-criticism, it's important to acknowledge what went well. So here it is:
- I've worked with Git seamlessly, also following the Gitflow concept (more about it here)
- math become sooo useful (simulating torque with a sine wave, transforming audio pitch...)
- delivered a game that works
- got my hands dirty in game development, which I have never planned
- tackled a surface of problems with graphics
- orientation in 3D space
- how torque works in internal combustion engines
- how the input system is done in Unity (beautifully btw.)
- deeply understood the benefit of separation of configuration from code (e.g. you can change the whole configuration of a car in JSON, even when the game is installed)
- stood on the shoulders of a giant - working with free assets provided by the Unity community went unimaginably easy
- video editing could be done really fast if you don't have a lot of time left
Recognized mistakes made
Huh.
- sometimes audio of an engine doesn't catch up (there's some bug with coroutines)
- an opponent car shouldn't be driving in a "God mode" (it was a quick solution though)
- the graphics aren't realistic
- a better indication that the car is turned off
- it's a bit too hard
- there should be more obstacles, so it could be more interesting
- a car should be able to drift
- a car should be able to roll over
9 learned lessons
1. There is a lot to be learned from developing games, even though I don't plan to develop games professionally.
2. Math is hugely usable in game development, I mean a lot.
3. Unity has beautiful, useful tutorials and a big community.
4. It's incredibly easy to meet opportunities to manifest your knowledge about data structures, algorithms, and design patterns in game development because pretty quickly you'll hit performance boundaries, which is nice.
5. Pick a Git strategy or pattern, choose conventions and follow them, you and your team - it's worth it.
6. It's possible to make a game with no prior game-developing experience (although with a few years of programming experience) on a level which is Manual: Desire, or better said - beyond that level, because you have this blog, and I didn't have it.
7. C# is cool (although don't quite know why it has a lot of unneeded syntactic sugar, myb it's better to focus on performance, but anyway - it rocks).
8. Developing a game is a fun challenge.
9. The realization that it's just magic and we're all incredibly lucky to live in a time where you can portray realistic 3D games on a computer that, in the end, only recognizes 0 and 1.
Looking at the game a few months later
It was fun. It could be done wiser. A lot of new has been learned. Saw a completely new world.
I will hit graphics boundaries in another sector of IT, but it's good knowing that a lot of challenges and lessons could be tackled in this field.
Glad that the project was finished just one week off the estimated time, which could be seen as the biggest win.
A word about the beautiful tool - Git
I "learned" Git sometime before, but never had practice with a team.
This was an eye-opening experience, finally, a lot of lessons came into play. I rocked Git only through a console and let me say - it's wonderful.
Knowing how to use Git beyond basic commands is like having magic power at the tips of your fingers, like you obtained a crystal that controls time - or better said: versions.
The next step is to deeply understand Git internals, although I skimmed through internals, there is more to reach, there is more to explore.
Final word
Thanks for reading.
Although it wasn't technical as I like it to be, it was worth writing. A few months passed by, so a lot of technicalities have been forgotten, sorry for that.
Fellow experienced game developers - if you are reading this for whatever reason - leave us your tips below in the comments, we will surely appreciate it.
If you want to - feel free to contribute, with ideas or with the code.
Top comments (2)
This is great! a bit similar to my experience building (incomplete) games in Unity as a web developer. One thing I've noticed is that game development is not as straightforward as building a web frontend even for seasoned gamedev professionals, maybe theres still some need for dev tools improvement.
Thanks for sharing!
Syed, thanks for the nice words and for your consideration!
I agree that there's some room for improvement, but also see that as a big challenge - because it surely won't be easy to build it without losing too much flexibility.