Week 5 - Preparing for Testing
Week 5 - Preparing for Testing
This week we will be conducting a testing session amongst the teams, and with the voxel generation taking up so much time, it was a scramble to get everything completed and working in time. I left off last week a stack of bugs that needed to be fixed, the most notable was that the player would not move across the platform anymore. The issue was caused by some jank collisions between the player and the surface of the platform, which was now made up of hundreds of box colliders. I initially tried to implement one circle collider, which would shrink it's radius to match the platform, but the circle collider is only intended for use in 2D games, and so has no option to rotate it horizontally to match the platform. I also tried generating a composite collider, but updating this in real time was extremely taxing on performance, so I scrapped it. After several more, unsuccessful attempts at fixing it, I figured the player only needs to know whether it's over a platform, not literally be colliding with it, so I could disable collisions entirely and just use a raycast to check the grounded state, and constrain the players Y movement based on that. This took a few tries to get working correctly, but I eventually managed to fix the issue (and got a slight performance uplift from not checking all those collisions, too).
After fixing all the bugs (that I knew about), I started improving the player controls further. I tweaked the values for movement until it felt responsive, and while doing so I found the player collision to be kind of, boring. It needed some knock back, so they players would bounce around instead of just push each other off the edge. A pretty easy addition and it made a huge difference to how the game played. I also wanted the players death to be a bit more dramatic, and because I was going to have the final player model be made of voxels, I made placeholder version with a cube that breaks apart when it hits the killzone. I even got a small "explosion" effect for free, since the knock back got applied to all the voxels when they were activated. I think it fits in nicely with the rest of the effects I've added so far.
I was pretty happy with how the everything was working now, so I decided to take a break from programming and work on creating a kart model for the players. I initially tried doing this in Blender, first by stacking cubes (which was way too tedious) then by trying to voxel remesh a regular polygon model, which kind of worked but ended up looking pretty half baked. So I turned to a different program, MagicaVoxel, 3D modelling software tailor made for creating voxel models/artwork. This was of course far quicker and easier to use for this than Blender, and after taking some time to learn the basics I tried to model the kart. I soon realised however, that I am just as bad good at making voxel art as I am at pixel art, so I need some inspiration to base it off. I looked around for a while until I found a kart model that was, coincidentally, made by the same person who created MagicaVoxel, @ephtracy. I liked it enough to try replicate it myself, and I think I got pretty close. Turns out ephtracy's version isn't actually symmetrical, so I had to make a few changes to make it look good as a kart model.
Now I had a kart model, I had to find a way to import it into Unity. Of course, in MagicaVoxel, each cube is an individual object, but once converted to an .obj or similar format, it becomes a single mesh, which kind of defeats the purpose. After searching for ages, I found an extension for blender that can import .Vox files with the option to have each voxel be imported as it's own mesh. Once I had the model imported into Blender, I had to separate all the meshes, and give them each individual origins, and then I could import that into unity as a .blend file with hundreds of individual cube meshes. After a little more configuration in Unity I was able to replace the default cube with a kart model made of voxels.
Now that was done, I wanted to add a bit of "Juice" camera shake to the game. I was able to reuse a script I wrote for my previous KIT109 project for this - it's super simple and works really well to add some oomph to the bomb explosions. While doing this though, I had an idea. I had initially wanted to have the platform break apart when the bomb exploded, and whilst I couldn't see how this could be done in the exact place the bomb went off (it meant recomputing every voxel every frame), I could cheat a little and modify the existing script to break off a fixed amount of voxels from the outside edge. The force applied would make them look like they were broken off by the bomb, and there was no overhead to it at all. So I modified the voxel generator and bombs scripts accordingly and I much prefer it to having the platform constantly break down.
Dodgem.io was almost ready for testing now, it just needed a UI and a proper game play loop - you know, to be an actual game. So with the testing session happening the next day, I hurriedly put together a simple start screen and some score counters, and made changes to the game manager to properly handle the current state of play, including restarting the game. Getting each player to control their own UI individually was a bit of a headache, but I got it working by that morning, and uploaded a build of the game to itch.
I was a little late to the testing session, so the rest of the team fielded the initial testers. When I joined, I was told they had to upload a previous of the game because people were having issues getting the most recent version to start. I was initially unsure why, as it had worked fine up until now both in Unity and on itch. We redeployed the "broken" version of the game and I watched some people play to see if I could figure out what was going wrong. Turns out, the game worked fine, but in my haste to get a working UI I had overlooked providing some sort of que to press start/enter to actually start the game. Without this, many of the playtesters were "soft-locked" and thought the game had just frozen. So, I stayed up all night working on a version that was never played, which was a little frustrating. Thankfully, the version most of the testers played still had the same game play, just no game loop, so we were still able to gather some useful feedback.
The initial feedback was largely positive, with the vast majority rating it a 4/5, and praising the voxel art style and effects. Opinions on the controls were generally good, people found them intuitive and responsive, but some suggested including (well, re-adding) the use of the analog stick for player movement. Nobody encountered any bugs during testing (thankfully), but there was one significant issue - lag. By far the biggest criticism was an excessive amount of lag, especially when using the bombs. I figured this might be an issue, as I hadn't yet tested the game on a system without a dedicated GPU, and wasn't sure how it would run on other hardware. The game mostly ran smoothly without the use of the bomb, which gave some insight into what the problem was. Lastly, we asked people what they would like to see added - many people suggested power ups, new levels ideas just cool things we could add to make the game more exciting. One idea I particularly liked was making 4 stages themed after seasons, with different properties for each. There were some suggestions for the inclusion of AI, which while it would be great to add, is likely beyond the scope for the remaining time in the project. Some people also wanted to see the platform destruction be improved.
Heading into next week, there are several things I plan to work on. Based on the feedback we received, there's still have a lot more optimisation to do, especially for the bomb. I have several ideas for how to further improve the performance, but I'll elaborate more on that in the next devlog. At the same time, I am determined to get proper platform destruction working, as well as add more cool voxel effects that people liked. I will of course, also rework the UI to make it much more intuitive to use, and would like to add the ability to select the kart colour, stock count etc. at the begging of the game. Lastly, I'd like to model an actual stage to replace the level generation, to make things look and feel more interesting.
- Cody.