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). 

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.