We’ve been actively working on the game for a few years now at this point. Our main focus has always been on implementing systems, seeing if they worked in game, and tweaking as needed. This meant we didn’t make a lot of external tools for prototyping or testing. We would just get a new feature into the engine and then try it out while playing.
Eventually, we added a few lightweight external tools to lookup various in-game values. This started as just center-tile content inspection, current active npc display, and some tools to jump the player around within the world. These proved to be extremely useful and led to some more in-depth analysis, mass config, and testing tools.
Each tool only took a few hours to a few days to get functional, and each proved to be extremely helpful. Below are a few of our favorites with what we did before we made the tool and what the tool allows us to do.
Hope you find this useful. If you’re in a similar position, we recommend spending a little extra time on non-game tools and saving time in the long run.
Spreadsheets (Do Them!)
This seems kinda obvious in retrospect, but we put an embarrassing amount of time into making the game before we learned this lesson. Iterating ideas in a spreadsheet is much more efficient than trying to implement ideas in the game only to change them later.
We now map out all of our tiles, items, decorators, npcs, biomes, sound effects, music ...etc in spreadsheets first so that when we go to implement them we have everything lined up and ready to go. This has drastically increased configuration efficiency and game design cohesiveness.
Never underestimate the brain's ability to forget cool shit. Write it down!
Mass Edit Tools for Config
When building a game with 50+ NPCs a small change in design can result in hours of configuration changes. The first time you do it you say to yourself “self, you’re never going to change something like this again, lets just power through it and be done”. If you are stupid like us you might do this three or four times before makeing a damn tool. So we did.. eventually...
Now, instead of hand editing each NPC with similar stats, we store relative NPC damage/health values within each NPC and then use a tool to mass set all of them to what the values correspond to. In this way, we can make “high” or “low” NPC damage mean whatever we want with a single click instead of setting them one by one.
After seeing how much time that saved us we decided to make similar tools for mass editing item stats based on rarity, attack pattern, or selection.
Weapon Leveling Stats Chart
Balancing weapons as anyone will tell you, is not fun. Initially we were making a change to a set of items and then just playing the game hoping that we would stumble across a good balance. This got really tedious. So, someone drank a bunch of beers and made life better by building a tool.
The new dialog is dynamically updated to show weapon damage outputs at any level for any item we add to the configuration. This is a much easier way to make sure things are scaling as we’d expect.
Find Stacked Decorators
Our decorator system has gone through a few iterations over the years. Initially, we only allowed a single decorator per tile. Eventually this was changed to allow multiple decorators per tile with a set Z ordering for what should stack. Our decorators also use a configurable restriction system to determine where they’re allowed to be placed. This is used to stop things from stacking that shouldn’t be allowed to.
Since this stacking wasn’t planned for from the beginning, a lot of our existing decorators ended up with incorrect Z orderings or missing restrictions to keep them from stacking on other decorators. We made two tools for this: one to see all decorators in an ordered list by their Z order (with the ability to drag and edit their Z value) and another to scan an existing game and list all unique stacked decorator combinations.
Before these tools, we would just play test and notice things out of order. We were still finding stacking or ordering issues after months of this approach.
Light Map Dialog
Similar to our decorator system, our lighting has gone through a few iterations. Testing and troubleshooting was always done in game, usually in pre-built test areas, but still required launching the game to test any changes. Viewing light color is often difficult due to the blending with in-game background tiles as well.
Our testing dialog still requires a game launch, but it shows all static and dynamic lighting in separate views with no background color. This shows the true lighting color and drop off per tile in a much clearer form and allows us to test tweaks to our lighting engine in a more controlled setting.
Visibility Dialog
We found performance issues with our initial visibility checks on low end devices. Using the same concept of the light map dialog, we built an external dialog for testing our visibility checks. This tool became a way to compare various algorithm’s results to our existing algorithm just by clicking a checkbox instead of rebuilding and launching the game after altering visibility code.
This is another dialog that would have been very useful for prototyping/testing prior to the original implementation. Yet another example of how we should have deliberately built tools in the early stages of development rather than stumbling into them later
Final Thoughts
With a few boring tools, we are now able to spend more time doing the enjoyable parts of game dev and less time doing the tedious parts. Who knows how much time we’ve wasted not doing this.
Write the spreadsheets. Make the testing tools.
Love Always,
Much Software
Comentarios