Big Game Project #2 – Using game development engines vs coding from scratch

During our game project we used the Unity game development engine and it was a good choice of engine because of it having many built in features. If you are unfamiliar with Unity, it has an asset store where game developers can upload assets in order to help others by sharing features and sometimes make money from it, having the assets cost a fee. Another fact that made Unity a good choice for our development team is that the engine has existed since 2005. Because it has been around for nine years there are plenty of tutorials and help to be found on the internet when having trouble implementing features.

It helped us during development that the C# programming language can be used with Unity which is similar to the C++ programming language that we have learned through several previous courses in the University program.

We had some trouble using Unity as well. The engine crashed often caused by several different triggers, mainly when changing scenes. We had an issue with the engine crashing when trying to build an executable (if the engine crashed when trying to change scenes, it crashed when trying to build). We found no solution to this, it just seemed to work sometimes and sometimes wouldn’t but fortunately it did not hinder us to a degree that sabotaged the project as a whole.

A problem that I find using Unity and other game development engines (Side note: I have also been involved in a project using Unreal Engine) is that I don’t have full control over stability. Crashes often occur when using development engines and/or features within them that is out of my control. The payoff is that engines have such a great amount of features and using them saves development time. Also, the features are often better executed than if one would design them oneself. This is also true for using code libraries if developing a game from scratch using C++.

I think that the payoffs that come with using game development engines outweigh the problems of not being able to control everything, at least if in a small to medium sized development team with a limited amount of time and money. I see it as a risk though, since not being able to control the stability of the development engines could hinder development greatly.