Devlog 004 - Planning For More Tooling
When developing a game in Unity, one of the most useful things you can do is develop your own custom tooling. Think about it, when you make your game, you've got your own ideas, methodologies and plans. I've already made a couple of simple tools, but I need more tools for later in the development process. This would also be a good excuse to get some much needed exposure to more complicated tooling UI within Unity.
What Does Tooling Look Like in Unity?
Unity provides us with a library for editing the editor, rather than just the engine. When people think about Unity, they might think about it as a piece of software that does everything for game developers, who just needs to drag things into the right places, so long as they have the assets. This is somewhat true, but it doesn't account for some of the more tedious processes, such as applying components to GameObjects, using widgets to understand how things will interact and so on.
You can import the editor library with this import declaration at the top of a script:
using UnityEditor
The UnityEditor library is great for making tools for game development. When I say tools, when anyone says tools really, we tend to mean functionality that is used to help build the game. Whether it's a widget in the scene view to let developers see where GameObjects are in relation to other GameObjects, or it could be a component which has a bunch of custom editor elements (For instance, making some properties available in the editor).
Why does this matter?
In the long term, the goal for Skell's Quest will be to get it to a state that I can rapidly build the levels and have to do minimal code changes. That's why, once I've got this big dungeon update out, I will be working on assets and code changes from then on will be for new features. But once I've made assets (models, textures, shaders, audio, animations etc), I'd like to import them and generate enemies and characters with a simple build process.
At the moment, every enemy requires me to do the following process:
- Setup a path for the enemy's data to reside in
- Create an EnemyStats scriptable object
- Drag the asset into the Scene view in Unity
-
Apply the following components to the new enemy:
-
Enemy
- Ensure each field is updated
- Rigidbody
- Colliders
-
Enemy
- Create a prefab out of this enemy
- Create and place a 'spawner' GameObject with an EnemySpawner component.
- Ensure the new prefab enemy is selected as the spawned enemy.
This isn't a lot of steps for an enemy, but thinking about this, the game may end up with 100 unique enemies. Those steps 100 times sounds tedious... And enemies are not the only thing that needs semi-complex setup. For example, items typically need an in-game model, as well as their own stats. These are all things I can make easier by having the correct tooling in place.
At the moment, the only tooling I have consists of taking csv files and converting them into scriptable objects. This can save me a lot of time, by working on a stats csv spreadsheet then uploading that csv file to a directory and hitting go. With just around 100 items, this already takes the machine about a minute to do everything, so this is only going to get harder as time goes on - And if it takes a machine that long, imagine how long it'll take me personally?
Nothing much else to say for today though, I just sort of wanted to give an idea of what areas I'm going to be working on next.
Until next time everyone, much love and happy tinkering - Timlah