What do you want from a Game Engine?
What Game Engine you choose to deploy and develop on is critical to the success – or failure – of your game. Because the Game Engine is the foundation of the rest of your assets, code and combined work of your studio, it is critical to look long and hard at this from the beginning.
It may not be the most alluring part of an adventure, but the right shoes and socks may well determine if you reach your destination at all.
Three core things to consider when looking at an engine are as follows:
1. The type of game you intend to create e.g. 2-D, 3-D, VR, tabletop, etc.
2. Which platform/system e.g. Sony Nintendo, XBox, et al. or is it multi-platform?
3. Your familiarity with potential engines and their learning curve i.e. if you are planning to innovate as a team is the engine a barrier to entry to this?
Evaluating skills and programming languages
It is okay not to have certain skills with the engine of your choice, however not recognizing this and failing to categorize this risk for your project is more troublesome.
As a GameDev you have a particular set of skills, as do those you choose to work alongside with. These skills do not encompass a multi-billion pound industry – nor does any studio or vendor, or individual: it’s impossible.
The ability to build on your existing knowhow and learn completely new things is what ensures your studio remains innovative. Conversely, not evaluating the skills of available resources can mean a project either balloons in cost or stops entirely.
There are a variety of ways to develop the skills and programming languages you have at your fingertips:
Self-education through platforms such as FutureLearn, Newsletters (e.g. from Unity) or formal qualifications. Our founder wrote a LinkedIN article along these lines.
Reaching out to industry to learn from peers, such as this UKIE piece on game engines is also worthwhile. UKIE represent the industry and so membership is highly advised.
Looking at courses and related material by choice vendors, such as learning how to code in C#, does cost time but can improve retention if you allow your staff to upskill.
Each of the above is a listening exercise: doing a stock-take and finding what cards you have to hand, and what more you need to be able to make your project succeed.
If your studio has staff then there are ways to take this further:
Developing in-house skills through apprenticeships is a brilliant way to take on new talent, and for projects that last more than 24 months you can expect a Level 4 apprentice to give back many times your investment in them.
Speak to the National Careers Service, UKIE, or Apprenticeships service for details.
Secondments, working along other studios – even competitors – so that your team can see how others in the industry operate and learn from them. Share, learn and grow.
Engaging freelancers so that you can draw on and learn from their diverse skillset implemented across industry. Be sure this is set out in your terms of engagement.
Building an Engine
Sometimes as a GameDev the engines available either cost too much money or don’t fulfill your requirements, so you opt to build your own.
This can be achieved by devs large and small, from Kojima Productions‘ Fox Engine to Shining Rock Software‘s self-made engine for the game Banished. It can be done.
It can be done, BUT you must evaluate your expected Return On Investment (ROI); if the engine is going to multiple-years of use through your pipeline this improves the chances of a good ROI, you should also evaluate how you intend to tackle technical-debt over this period to avoid unexpected costs.
Using the Unity Engine
You may have noticed in our previous piece how we admit to rather liking the Unity Engine. It works as the core foundation a range of products across sectors – from architecture and design, be it buildings and cars, to a range of Video Games large and small.
If you haven’t used Unity yet here is where you can find out how to install it. Note that Unity works on both Windows and Linux systems, meaning it is a vendor-neutral engine that lets you work the way you deign to. If you need help setting this up we’re happy to help, and if you want to learn how to code try the Harvard CS50 course.
The Unity Engine is also very pluggable, and many GameDevs choose to build extra tools on a stable foundation such as Unity rather than build an engine from scratch.
We recommend using the Unity Engine on Red Hat Enterprise Linux, so that you have most stable system available. Couple this with Red Hat OpenShift for access to more than 300 dev-tools and languages, and a Unity Build Server for your heavier workloads and processing and you’re set.
You can run a secure, agile and efficient studio quite readily with the Unity Engine, as set out above, and it is much more cost-effective than many of its competitors.
Building tools for an existing Engine
Finally we will touch on developing tools for an existing engine – as a GameDev you don’t need to re-invent the wheel, but you can make your vehicle to success your own.
One of the reasons we recommend the use of Red Hat OpenShift is because it facilitates development in a secure cloud – be it a private cloud or one which is hosted for you. OpenShift enables coding easily in Git, C# and a range of other languages on a single unified platform. On AWS Red Hat OpenShift offers a 661% ROI in five years: well worth it.
This in turn enables you to say we need this functionality and it doesn’t exist, so let’s build it. Software Developers are fundamentally problem-solvers (bugs notwithstanding) and keeping the option of in-house tools open can be a lifesaver in the medium-turn.
Earlier in this piece we said it is totally fine to not know some things – to lack certain skills. This applies to additions to your Game Enginer as well: you don’t necessarily need to take your studio’s development time away from the project to develop bespoke tools.
