Lessons From Making My First Videogame — Part I

What follows is a series of three posts filled with our collated advice on some key technical decisions and necessary mindsets cultivated for developers who are starting — or thinking about starting — an independent game project. Below we address the key considerations in deciding the most appropriate development platform and code technology for your indie game.

Quicksand GamesLab is an independent project team which sits within the wider studio. Together, our small team has been developing a ‘point and click’ adventure game for nearly 4 years now. To our great pride and delight, our efforts culminated when we were recently greenlit by the esteemed gaming community on online gaming platform Steam, and we are now planning to share our final version with the world sometime in the near future.

www.antariksha.in

Building Antariksha Sanchar was a significant investment of time, effort, and soul, and the experience pushed us to learn a great many things in the course of doing. The value in learning-by-doing is that the knowledge sticks, but nothing consolidates that knowledge like writing does both mentally and in a physical manifestation.

~ Unity vs Unreal ~

The choice between Unity and Unreal was easy: Unity just seemed so much more accessible to us, as amateurs. Unreal is an incredible game engine, and so many good games (e.g., ) have been built on it, perhaps the inaccessibility of Unreal is just an illusion, but we began our experiments in Unity because it seemed quicker to prototype on this platform. There are game engines other than Unity and Unreal, and some of these are great, but our team didn’t have experience with any of them. We had worked with Unity before on small projects, and had played around with Unreal a little.

We never regretted the decision. Unity is an extremely powerful game engine, which is practically free for Indie developers. It has an engaged community, features comprehensive documentation and tons of tutorials (both free and professional).

A large game development project features so many components that an engine as popular as Unreal is bound to have strengths in some areas that other engines do not. Additionally, you are certain to come across workflows in Unity that are unnecessarily convoluted, or are simply lacking proper definition. Having said that, when you begin, Unity seems forgiving and inviting whereas Unreal does not. This for us was the most important differentiator.

~ C# vs JavaScript ~

It can sometimes be silly to compare programming languages, and I strongly believe that you should program in the language you are comfortable with. If you have worked with C++, C or C# before, you will feel at home programming in C# for Unity. If you are coming from a web background then JavaScript may work better for you. For someone with little programming experience, Javascript will seem more accessible.

Overall, when working in Unity, a lot of things are very similar. Realistically, you will spend most of your time as a Unity developer (in a small team) writing Unity code. It is far more important to understand the nuances of writing code for the Unity platform than it is to debate abstract qualities of C# vs Javascript. To elaborate, there is a certain way that Unity works based on design choices that are being made by the developers of the Unity platform. It is important to understand this background design and align with it. The more you work with this design, the less the engine will fight with you and the easier your life will become as a programmer.

We began writing code for the game in Javascript. We did this for about about 7–8 months. Then over the next 3–4 months we replaced all the Javascript code with C# code and never looked back after that. There is pretty much no Javascript in our game anymore. What happened? We began with Javascript because we wanted amateurs with little programming experience to contribute as well, and knew that C# would immediately scare away these contributors we wanted to engage with:

1. First of all, we didn’t find many amateurs to help us and the ones we found struggled with Unity programming in general. The fact that Javascript tended to be less verbose mattered little when you were struggling to cope with the structural complexity of a large codebase and the Unity infrastructure.
2. Secondly, as we began to delve deeper into Unity, most examples we came across were written in C#. Plugins we bought were mostly written in C#, and as we got into the programming details on these plugins we learnt a lot about Unity through code written in C#. So we began writing some code in C# and realised that the enhanced verbosity of C# was actually great for us. We found it easier to comprehensively understand the code we were writing in C#. It seemed more clear and, dare I say, more native to Unity.
3. Thirdly, C# was so much better documented because of the MSDN documentation.

The general sense seems to be that about 80% of Unity users program in C#, about 20% program in Javascript and there are 5 people who program in Boo. There is little doubt that a committed Javascript or Boo programmer can contribute to an excellent game without writing a line of C#. We were just not so committed to Javascript. Or to put it another way, we found it easier and more rewarding to commit to C#.