Creating Playtest Tools

So over the last couple of days I've been working on creating a tool to playtest more effectively. Something I quickly discovered after building the first few levels is that it's very hard to predict what will feel good to play through. Unlike a traditional platformer, the physics based nature of this game means that the player's swing cadence and launch distance are highly variable depending on factors like clearance to swing, space since last grapple point, momentum from previous grapple points etc. , so designing a level that would work is simply difficult. So I created a playtest tool. This required me to learn how to handle a whole lot of things I had never touched before.

First, a save system. I have -never- tried to handle saving or loading files. To make things harder, I didn't want a save system, I wanted a save system that would let me dynamically create saves automatically, sorted by level. Figuring out the logic for the save file's name was difficult, you can't easily store data between playsessions, and creating a save file to save the number I needed to keep track of how to save my savefiles seemed...silly. Luckily, File.Exists is a thing! If you load in a path, it tells you whether the file you're specifying is real or not. So my save function simply checks if level[currentlevel]save0 exists, if so then it checks for level[currentlevel]save1 and so forth, and the first save that doesn't exists gets chosen as the save name. I hooked the save system to activate on player death, or when the next level is loaded.

Next, I had to figure out how to store the data I wanted.  Unfortunately, binary files cannot handle vector3 data . Luckily, vector3 data is just an array of floats when you get down to it, so I created a function that would add the players x and y coordinates to an array every x seconds, which was then added to a list of arrays, and then saved in binary. Figuring out the logic for this was quite difficult, because as a beginning programmer I barely understood how to work with lists or arrays and avoided them as much as possible, but something clicked as I put this together and it just made sense (finally). 

Lastly, I needed to figure out how to correctly load and then display the data. This wasn't too hard, I just needed to run through the list of arrays, assign array[0] to the x of a new vector3, array[1] to the y of that new vector3, and assign the z to 0 since it's a 2d game. Then add that vector3 to a new array, which I loaded into a Linerenderer for this result

Which is a good start. Unfortunately, it was polling player position too infrequently, leading to a level of detail that was almost useless. So I increased the polling rate and found that saving player position every .1 second gave a good balance between performance and resolution. I also added a gradient to the linerenderer to show movement over time, which was nice

However, this method came with a serious drawback: I have to be in playmode in order to see it. This seriously slows development down, since loading into playmode takes time and the play -> stop session -> start  session -> view saved paths -> tweak level workflow was just too tedious. There would be ways to streamline it, but not enough. So I decided to use gizmos, which can be drawn in editor mode, and was quite pleased with the results

You can see here that I decided to have different paths drawn using different levels, chosen in the inspector, each in a different color. This was decidedly more useful. It is sad to lose out on the gradient, but the usability is a fair trade off. Some more tweaks to make it a bit more pleasing to use

and it's all done! This should allow me to create much better levels and rapidly playtest and tweak them.

In the future I'd like to go back to using the linerenderer method at the end of the level so the player can see their path to the end, but that's for the future. I'll spend the next few days designing and redesigning levels with (hopefully) frequent new builds, and then I'll start refining mechanics again. Priority features include an end level scoreboard, and environmental projectiles so the explosion finally has purpose.