Why a GameDev needs a toolbox
After you have chosen an engine you will likely need to consider the ecosystem which surrounds the platform. This ranges from your operating system to the the dev tools you will depend on over the course of your project.
But why do you need a toolbox?
Identifying the capabilities you need to successfully deliver your game is an exercise that should begin before you write a single line of code for your game. This can be through a detailed roadmap which explores a range of conditions including return on investment, or a database, and even scribbles on an A4 sheet of paper.
Planning for projects, identifying risks and building structure into the project is central to actually delivering the end-result – a stable, working and popular game.
This includes your toolset, after all without such considerations you will find your studio – be it one person or many – scrambling to identify and procure tools when you inevitably are missing an urgent capability.
It does not do to leave a live dragon out of your calculations, if you live near one.
How to build a toolbox
In terms of practical ways to build a toolbox the most straightforward way to do this is to draw up a spreadsheet or database and identify the capability you need.
We say this because you simply need to capture the bare information on what the capability required is, and the vendors who can provide this. It is central you do not marry yourself to any one vendor because they may not always be the best for your needs at any particular time.
If you choose to start implementing these systems then you may want to also include a matrix for dependencies e.g. Asset Suite x depends on Engine version y.
In a spreadsheet you want to at least begin to capture:
- Engine (even if built in-house)
- Engine Version [+End-Of-Life Date]
- Operating System
- Operating System Version [+End-Of-Life Date]
- Development Tools and Processes e.g. OpenShift, DevOps, etc.
- Assets bought from External Vendors + Dependencies
- Security e.g. DevSecOps, Intellectual Property, IT Security, etc.
- Testing e.g. CI/CD, network-emulation, closed-Beta, etc.
- Cost per user/license (if applicable)
- Number of users/devices
In the event you decide to spin up a database you can be much more detailed in your evaluation of the capabilities you require and build a more complex matrix. Your time has value so be sure to invest in project-management to save time in the long-run.
A database is much tidier than a spreadsheet, but even loose-planning is better than no-planning so don’t be afraid to initially start with a spreadsheet.
The above list is about the foundations; you may have specific requirements for lighting, scale in an open-world, multi-platform publishing, et al. which you can also list with specificity and conditions.
It is central not to forget the monetary aspect – you are running a business, it never hurts to drop an enquiry to a vendor such as Unity Technologies or a neutral-publisher to ask about how they can help you market or monetise your game.
Finally for those who feel that building your toolbox early on is an idle exercise, we will end on this quote:
A man who does not plan long ahead will find trouble at his door.
