Over the past week, we've been deciding what last-minute features we really want to make sure get into SunBots and get incorporated into the entire scope of our gameplay. We're looking into new mechanics that can add depth to our gameplay and level design without drastically increasing the scope of our project. We've also begun testing our game in the QA labs, and have tester feedback to begin responding to as well.
With both these general goals in mind, I did two main things. First off, I built a prototype for a system suggested by designer Remy Vogler. He suggested that planets do more than simply generate energy if charged; instead, he felt their gravity should increase proportional to how charged they were, giving an extra layer of dynamism to the gameplay. Making a proof of concept for this was not too difficult; our code architecture is set up quite well, making it easy to change one or two things without upending everything else. In this case, I wrote some extra functionality for the planet's energy generator script that fired a message to the gravity script telling it to change its base gravity value when the energy value hit certain thresholds. We've already begun using this feature in a new level, albeit in reverse (more energy = less gravity), since the gravity values at different thresholds are all customizable in editor, allowing for positive, unintended functionality.
QA feedback was generally positive, as is often the case with a game featuring a unique mechanic such as ours; since most of our players are first-timers, the uniqueness of the concept carries the experience. However, it was generally observed that players had a hard time knowing when they ran out of energy to shoot, or even that they could run out. We currently have a GUI with an energy bar graphic representing how much a player has in reserve, but it's up in the corner of the screen, and easy to miss if you don't know to look for it. To solve this we looked to Mario for inspiration. In recent games, certain collectibles turn into white dots that zoom into their respective GUI element to show the player the connection between their on-screen actions and the important stats they change. A good example would be the Star Bits from the Galaxy games, or the reserve power-ups in 3D World.
I made a prototype to do the same thing for energy in our game. The biggest challenge was setting up their path. I wanted to create a white object with a trail renderer to approximate the Mario effect, meaning this needed to be a gameObject that moved in world space. However, its target was the upper left corner of the screen, meaning I would have to translate between screen space and world space. Unity thankfully has some built in calculations to help smooth out this process, but when you add in the complication of the camera moving during this object's lifetime (changing the world-space position of the object's goal) and you can get some inconsistent behavior. Right now the system works generally as intended, although the paths have some small variance depending on how much the player moves during the lifetime of the object. If testers respond positively to the prototype I'll sit down and figure out a solution to the camera translation problem, but it could prove exceptionally tricky, since I don't think there's a painless way to 'convert' a gameObject into a GUI object. If this system is kept and iterated on I'll post an update.
No comments:
Post a Comment