It has to be said that we adore the core gameplay loop in the original Gravitar game, so it had to stay as close to the original idea as possible, so how did we embark on a journey to enrich the experience? We broke the whole game into three key pillars and set to improve each of them individually.
First off, there was the artwork. Gravitar is a game set in space, so naturally, we had to transmit the feeling of ample, expansive space from the art side. This was implemented by creating a massive sun a player has to navigate around looking for a planet to explore, giving it a sense of scale we haven’t had before.
We have also introduced the visual cues a player would receive when exploring the planets. For example, the space-themed environments included stars and planets in the background, full of asteroid fields and dust flying around. This communicates that there’s more open space, and the player is free to fly around, but also, there would be less or virtually gravity. At the same time, the mountainous terrain indicates that gravity will pull the player down toward enemies and objectives.
After that, we tackled the main game design principles of the planets and the missions involved. The original iteration of the game had a fantastic camera effect when getting closer to an environment where the players’ view would zoom in closer as the player would move through a large environment without knowing how big it actually was until they zoom out again.
This is precisely the way to capture the scale we were striving for, so we decided to expand the environment for the players to explore and allow them to search for collectibles, encounters, and power-ups. We felt we could do a bit more, so we added two new environments that were not present in the original game – the space station and the battlefield.
While we were at it, we also fiddled with the spaceship controls. As the player is constantly affected by various gravity levels, we had to balance the difficulty just right. The spaceship felt challenging at first but very rewarding when the player gets the hang of it. We were testing it manually a lot. Trust us, we know.
Finally, there was the technical nitty-gritty because we knew we had to rewrite the code base. We were experiencing similar issues when submitting games for review. Even if the code base remained the same throughout the series, adaptations made during the development stage would skew the project, as each game had its separate repository and all of the changes had to be transferred manually. In such a situation, it is relatively easy to lose track of the changes made or even solve the same problem differently in different games. To fix this, we have decided to make all other games on a single repository and a single Unity project, separating each game in the engine with the ability to switch between them. This way, the game checked the platform it was being run on and applied the implementations such as controller support and button callouts accordingly.
We have also restructured our repository into even more different branches to fit not only the implementation tasks but the other platforms as well. Learning from our mistakes, we were even more careful when merging everything back into the main development branch each time.