Some important lessons I’ve learnt on game development

Hello everyone! First of all: I’m back! I know I haven’t posted in a very long time (since September, to be exact) but it was for a very good reason.

As I explained in my last post, these past few months I’ve been taking a pretty demanding course to learn game development in Unity. This course, together with my freelance work, which has been piling up like crazy lately, hasn’t left me with a lot of free time for personal projects. However, the course finished yesterday, which means that I will now have marginally more time and will be able to post here again. Yay!

To begin with, I wanted to talk a bit more in depth about what I’ve learnt and share some thoughts on Unity and game development in general. In order to do that, as is customary, I’ve compiled a list of important lessons on game development. Most of them are pretty predictable and I know there’s lots of compilations like this one on the Internet, but coming from a place of personal experience and understanding, those lessons hit a lot differently now. Hopefully I’ll be able to transmit some of that understanding, so this article can be useful or inspiring to somebody.

Now, to the lessons!

1) Yes, when they say that you should start small, they are right. But “small” doesn’t have to mean “Pong” or “boring”

We’ve all heard this old, oft-repeated advice: “in order to learn how to make videogames, start by programming a Pong clone“.

Now, this might’ve been useful advice forty years ago, even twenty or fifteen years ago, when game development was a lot less accessible, we didn’t have widespread WYSIWYG game engines and almost everything was done purely through programming. Nowadays, however, most people who start learning how to make games are going to use a generalist game engine like Unity, Godot or Unreal, or a beginner-friendly engine such as GDevelop, Stencyl or Construct, or even genre-specific engines that are even more accessible, like Ren’Py or RPG Maker. When you’re using a visual game engine, projects which are more programmaticaly complex than Pong become, in practice, equally as easy (or difficult) to develop.

Let me give you an example. During the course, the first project we were asked to make was a 2D platformer. That platformer included, among other things: a player-controlled character who could walk, jump, die and throw projectiles; enemies that would walk left and right or move up and down, and would die when hit by the projectiles; coins to be picked up; a final boss; a timer, which on reaching 0 would trigger a game over; moving platforms; a HUD with a life bar, and a finish line. The game had to include three levels with different decorations and kinds of enemies.

Is this game objectively much more complex than a Pong clone? Absolutely yes: it requires a physics engine of some sort, simple AI and/or animations, complex colliders, a tilemap system and so on. Programming such a game from scratch as a “first project” would’ve been insane just a few years ago. Yet most of the people in the course could finish the project and achieved pretty acceptable results, even with no (or almost no) previous experience in game development. How is that possible?

Consider the following:

1. Unity (like any modern game engine) has its own physics engine, so we didn’t have to code our own.
2. It also handles input, audio, graphics, etc., so we didn’t have to interact directly with the machine in any way.
3. We had a teacher guiding us.
4. Everything was done using simple Unity Components and C# and by following the teacher’s instructions, so most of the game logic was already solved for us.
5. Unity has a visual interface and an easy way to compile and play the game almost instantly, so we received constant feedback from the machine and could check the final results easily.

Taking all of that into account, making a small 2D platformer game as a first project in 2021 doesn’t seem so crazy anymore, and it’s much more interesting and inspiring for the students than making a more simple and “dry” game project such as Pong or Asteroids, for example. Not that I have anything against those games, and certain people might find them motivating enough as first projects, but that won’t be the case for everyone.

So yes, start small, but work on something that engages you. I’ve personally spent years upon years working on “dream projects” that have never reached a remotely playable state, and yet during this course I’ve finished 7 games in the span of three months. If you find yourself in the same situation, I heartily recommend taking a more practical approach to gamedev: put that “dream project” aside for a while and work on some smaller things that you find interesting or fun and (most importantly) FINISH THEM. It doesn’t matter if they’re imperfect or buggy, just do your best in a limited time frame (a week, two weeks, a month at most per project) and then drop that project and move on to something else.

Do this a few times and you’ll find not only that you suddenly have a portfolio of finished stuff to show off, but also that you’ve learnt a lot and feel much more motivated.

2) You can make a playable game in a week, but you’ll need months to polish it

So yes, making games is actually very easy and fast, if you have the right tools and know what you’re doing (or follow the right instructions, in case you’re under a teacher’s supervision). Making a 3D racing game in a week? Check. A 2D platformer in two weeks? Check. A 3D action platformer in three weeks? Check (I’m particularly proud of that last one… it’s buggy but fun. I will share it on itch.io eventually).

However, have you heard the old saying of “the last 10% of development is actually the last 90%”? Well, it’s true.

As I said before, if you’re learning, experimenting, growing a portfolio or prototyping to find ideas that you like, the best thing you can do is finish a lot of games and do it as fast as possible. Don’t linger on the details; don’t be a perfectionist. In those cases, “finishing” doesn’t actually mean “reaching a marketable state”. It just means that the games look and feel more or less as they should and they are somewhat playable, which no glaring bugs at first sight.

Actually finishing a game, as in getting it to work as intended on most machines and for most users and being able to sell it or distribute it without being hit with a legion of bad reviews and refund requests… now that’s another story.

All the games I’ve finished during this course are mere prototypes, full of bugs (some of which I’ve noticed, most of which I’m sure I haven’t), untested by other people and on other machines, with design mistakes and so on. So, on the one hand, it’s good to “finish” prototypes fast and I feel very proud of them, but on the other hand I know that, if I ever want to actually finish a polished project, I won’t be able to do it in just a week or two.

3) Unity: chaotic neutral

Now, even though I’ve learnt a lot about game development during this course, and that’s probably the most valuable knowledge I’ve acquired, the reason why I took it in the first place was because I wanted to learn Unity, specifically. Unity is the industry standard nowadays for indies and for mid-size companies, so even though I don’t plan on using it for personal projects, I found it necessary to learn it, in case I participate in projects that make use of it.

Barely a week into the course, I published an article talking about Unity and comparing it to Godot, which was the engine that I had the most experience with. At that point I didn’t have much to say about C#, for example, because I had barely used it yet, and I hadn’t delved into the most complex parts of the engine, so the comparison wasn’t entirely accurate (even though I still agree with many of the points I raised). Now, after three months of very intense use of Unity and finishing 7 prototypes with it, these are my main conclusions:

1. Unity is very versatile and you can do basically anything with it, but its strength lies mostly in 3D. So if you plan to focus on 3D development and don’t require the level of realism and power that you can achieve with the likes of Unreal, Unity is an excellent middle ground. Particularly if you want to target consoles and Android, since Unity 3D games can achieve a quite acceptable performance (for an engine) if you optimize them well.
2. Stay away from Unity if you want to make pixel-art games or, in general, games that rely on pixel perfection instead of physics. It’s absolutely NOT the right engine for that, unless you’re already well-versed on Unity and prefer to code workarounds instead of switching engines. Pixel-art games are much more straightforward in purely 2D engines.
   Non-pixel 2D games, on the other hand, are quite comfortable to make in Unity, although I’d still recommend a 2D engine for that over Unity.
3. The Unity Asset Store is very useful for learning and prototyping, since there’s lots of free resources (graphics, code, scenarios, etc.) and using them in Unity is a matter of plug-and-play.
   However, using store assets can quickly turn your game into a gigantic mess, with inconsistencies both in code and assets, and lots of unnecessary bloat. There’s also many assets that provide functionality that would work much better as an actual engine plugin (instead of a hacked-on solution) or a core feature of the engine.
   So proceed with caution. Using store assets can help you a lot during the prototyping and beginning stages of development, but it might hinder you during the polish stage.
4. Coming from a more DIY-oriented and open-source background, the main things that bother me regarding Unity are:
   1. How bloated it is. Honestly, I have a reasonable gaming PC and it still would stutter and even crash when working on small projects for random reasons.
   2. The fact that the source isn’t available and development is quite opaque.
   3. How over the place its design is. For every little thing, there’s at least half a dozen different ways to implement it, which is made worse by the “patchy” nature of many store assets.
      Unity feels at times like a mix of many features that work well in isolation but not so well together. From my perspective, it appears that Unity devs have put a lot of effort on developing certain specific features over the years, but not on maintaining them or making them converge into a coherent workflow, which has led to chaos and tools being all over the place.
      This is something that I had read many times before, but it wasn’t until I used Unity that I saw it for myself.
      Not to say that Unity is a bad program overall. In fact, it has really great systems, excellently-coded, brilliant in cases, and it can do almost anything. It just has no design consistency.
5. C# is quite good (reasonably easy to use and with lots of functionality, considering how widespread it is in the industry) and the integration between Unity and Visual Studio is pretty good as well. Sometimes Visual Studio would disconnect from Unity for some reason but it was easy enough to fix. Overall the coding experience was comfortable.

I understand why so many people use Unity. Its physics engine, 3D capabilities, animation system, etc. are quite robust, and together with the Asset Store it provides a wide variety of pre-made systems that, for free or for very cheap, that make it much easier to develop games in any genre. It also has easy support for exporting to many platforms. All-together it’s a time-saver for many people, and time is money, so I get the appeal.

On the other hand, there’s some aspects of it that I find personally irksome and clash with my workflow: I prefer more focused software with a clearer design/concept, lighter and more optimized, less bloated, even if it means having to code and set up a bit more stuff. I also admit to having a soft spot for smaller and/or open-source software: there’s several underdog alternatives to Unity that would suit my needs perfectly well and I will favor them whenever possible. I’m also not a professional game developer, which means that I have the privilege to be able to choose. Not everyone has that choice.

Take into account that all of these are just my opinions, based on my personal experiences. If you’re wondering about Unity, my advice is: try it! Try it for yourself and see what you think! If you don’t feel ready to tackle it alone, enroll on a course, on Udemy or locally if available or elsewhere, and see where that takes you. Almost all gamedev knowledge is transferable in some way, so, even if you don’t end up using Unity, it will be time well spent.

Conclusion

Off the top of my head, that’s all the advice/thoughts that I can think of. I hope this article was useful to you, or at least an enjoyable read!

Personally, I don’t plan on getting back to any personal videogame projects anytime soon. Instead, I will keep studying for a while. Since I now know much more about Unity than Godot (which is amazing, considering I’ve only been using Unity for three months, but boy were those months intense…), I want to get my Godot skills up to par. I’ll start by taking GDQuest’s Godot courses, which I’ve been eyeing for months, and then I’ll probably learn some basic 3D modelling with Blender, which is something that I’ve been meaning to do for years… we’ll see.

I’ll keep absorbing knowledge for a while and hopefully making more game prototypes, so when I tackle a bigger project again, I’ll have a much better understanding of the gamedev process and a wider set of skills.

Thank you for reading and Happy New Year!