Dev Diary: Stranded in the Stars 8: Programming, Testing and Balancing/Polishing
As our team was nearing the submission deadline for our project... there was a lot still to be done. Fortunately I have a passing knowledge of Unity and C# and started helping out our programmer.
First off, I fixed an error preventing us from making a build of the game and implemented a credit szene which would automatically switch to the main menu after a certain amount of time. Now that we could finally export the game, we officially began with player testing.
For testing, I first conducted a private testing session with a few close friends who are experienced gamers. It was a bit sobering. It took them about an hour each to complete our game which has an expected runtime of about 15 minutes. Our game was clearly too difficult and apparently quite rage-inducing. In about two days, we rushed to make some adjustments too fix the most egregious of issues before the official playtesting session. Using the initial feedback of the private testing session as a basis, we handed out a feedback sheet as well as printouts of the level so that testers could mark problem areas. This testing session had players of all skill levels and went a bit better - though the game was still too difficult overall and still a tiny bit rage-inducing. We will go into the specific feedback and the fixes further below.
Unfortunately at this point, a few things went wrong. The person responsible for game design and balancing went on vacation and our lead programmer stopped doing any work. Meaning that most of the bugfixing/balancing/polishing work fell on me, the only other person who was familiar with Unity. For some reason I was terrified of telling our programmer that he wasn't doing enough work, but after a few days of working on my own, I bit the bullet and asked what the heck was up. It turns out that he thought we had one more week before the submission deadline and was taking it easy. Cue a week of late nights fueled by caffeine and crunching together on Discord. On the upside, it was the best teamwork we ever had.
As per the feedback from the players I implemented the following fixes:
Some jumps seemed impossible because of the placement of the damaging spikes. Some spikes were damaging players even though they touch them.
Changed the placement of certain spikes and adjusted the hit boxes of the spikes to be pixel-perfect.
If you died, you had to start from the beginning - which was very frustrating if you were already trying for an hour. Checkpoints were requested.
I implemented checkpoints where player would respawn once they passed them.
The difficulty jumped too much from the 2nd to the last level. The boss enemy was too fast and almost impossible to outrun.
I lowered the speed of the boss. Still challenging, but not punishing to the point of failing one single jump.
The small enemies were stationary and almost completely non-threatening.
I created a behaviour script for the small enemies so that they would patrol and follow the player if close. I also tripled the damage that the player would take so that they would die after touching the small enemies three times. This encouraged players to outmaneuver the enemies using timing and to use the wall jump strategically.
The level design had some entirely useless paths.
Fixed by a more strategic placement of the enemies, collectables and respawn points.
Testers found the level change by collecting the key item "sudden" and didn't understand how it narratively related to the level change.
While picking up the item was still a requirement to finish the level, I implemented "teleporters" to explain the level change itself.
The text on the screen was too slow and disappeared too fast to read.
I increased the text speed and let it remain on screen for longer.
The jump sound was too loud
I lowered the volume of the jump.
The boss enemy was missing sound
I created trigger zones so that the boss would play certain sounds when passing them.
That was how much we were able to fix just before the submission deadline.
At this point, our game felt a lot more like a "game". Awesome!
Unfortunately, as I wasn't nearly as experienced in programming as our lead programmer, there remained a few bugs that I couldn't solve before publishing. Moreover, some of the new features introduced bugs of their own.
First of all, as it turned out, adjusting the hit boxes of the spikes to be pixel perfect didn't entirely fix the problem of players "getting caught" on them. Part of the problem was the player's square hitbox itself, which I didn't know how to fix at the time.
Also, if you revisited previous checkpoints, it would overwrite your "newer" checkpoint and it wouldn't correctly respawn the collectibles.
Further, enemies could get "stuck" between following their patrol path and following the player and just remain in place.
And these are just the big bugs that I am aware of. There are probably loads more. Looking back, a lot of those bugs were mostly due to my inexperience. I have grown a lot as a programmer since then and it's funny how much I struggled with such simple problems.
This post became entirely too long. If you made it this far, why not read the last part of the series below:
Part 9: Cover Art and Conclusion
turnnoffyourmind
jbbartram-illu
prguitarman
discoholicmusic
2087
snowghoul