Systems and Tools Design
Although they are different disciplines, Systems and Tools boil down to similar mindsets. Said mindset being the idea that you’re designing and creating something for someone else to use so that they don’t have to worry about the lower end of the programming languages. This can include using assembly for graphics purposes, writing c code to get better control of memory, or just using c++ to create an API for other programmers to use.
Some examples of Systems include I/O management, memory management, and abstraction APIs (math libraries, os specific abstraction); pretty much any low level abstraction that has more to do with hardware and low level software. Tools are similar in that they are created for other disciplines as abstractions of programming to increase productivity. Some examples of tools are level creation tools, and rigging and modelling.
Systems and tools go hand in hand because they’re both abstractions of lower level stuff so that others don’t have to deal with the pain and torment of doing it themselves over and over
When approaching a new system or tool I initially think about what it is going to be used for. For example, on my current project I need to implement an input manager and a tool for level creation and puzzle design.
The input manager needs to work for both PC and Mobile (iOS and Android) therefore I need to be able to determine the difference between a tap/click and a swipe/mouse drag. If I have a swipe I need to know how many fingers are currently swiping. This is because I need to know if the camera is going to move (1 finger) or rotate (2+ fingers). On top of this I need to make sure that there is a way for someone to get this data easily and conveniently regardless of the platform that they are on. Thankfully we’re working in Unity and it already handles a lot of the lower level I/O for me.
Unity has preprocessor directives to determine what platform you’re on. It also has abstractions for mouse and touch input. I just need to determine when a swipe happens and how far I’m swiping. After that I have most if not all the data I previously mentioned. Once this is done I can go over it again, making sure I have all the needed information and making sure it is optimal enough for what I need it to be and for others to use. I had to rewrite it once because I was having issues determining if I was swiping or tapping cause who has 1 pixel precision when they’re tapping (no one!).
Further down the line I will need to implement level creation tools for the designers. These tools will allow the designers to create levels and add tiles to these levels without having to add additional code to the project. This will increase productivity and give us more feedback due to quicker iteration.
The level creation tools need to be able to create a tilemap, whether it be Unity’s tilemap or a personal creation, of cubes/gameobjects. There needs to be UI for a designer/programmer to determine the width, depth, and height of the map in a way that is easy to visualize and quickly iterate on. It needs to be able to generate all base tile types (water, ground, anything new). It needs to be modular so that when added onto later it is possible for easy addition of new mechanics and there isn’t a need to add 100 lines of code for 1 tile. For puzzle design tools there needs to be the ability to add any mechanic modifier (ziplines, ladders) to any tile and each tile modifier needs to work no matter where or how it is.
All of this is a massive undertaking. Good thing Unity has a lot of support for editor tool creation. I’m not 100% on how to go about creating this stuff but here is my rough how. Firstly an integer that lets you select the height of your map. This integer affects a list of grids, with either a fixed or individual width and depth. Each element in the list is a grid of width and height of something (current thought is colors with colors being different tiles). This allows the ability to edit each individual layer and gives control over each exact grid space. Then there would be a button that would delete (probably store it somewhere in case) the current level generated and regenerate based on the window input.
The puzzle design tool would be more specific to each tile. Either you have a script on each tile that allows you to change what is currently attached to it by having a dropdown of options, or it would be another editor window. If it’s an editor window you don’t have to have more scripts on more objects and it might be easier to use, but it might be more difficult to create and manage. Either way you would have to select a specific tile and change the current tile “augmentation.” There lies a difficulty in if two tile types, like a zipline start and end, need to exist for a mechanic to work there either needs to be a reliance on the tool user to be aware of this or safety put in to make sure it can’t get through and break.
All in all, these problems and challenges tend to break down into simpler problems. There’s a certain level of satisfaction getting to see systems and tools being used by others and being happy with what has been created. It’s also nice saving people tons of time and happiness when they don’t like doing these lower level things over and over again. Sometimes it even saves performance because it’s easier to optimize and pinpoint bottlenecks when things are abstracted and people have more time to work.
I’ll be updating this post later with code snippets for probably just the input manager, but I’ll try to add the other stuff too. I’m really looking forward to creating the level tools so we can really get the ball rolling on levels.