Polyspace
Dev team size: Two people
Time spent on Project: One Month
My role: Designer, 3D artist, Programming assistant
My first video game!
Polyspace was the first video game I had ever made with a team. Back then I knew I wanted to join the video game industry, but I didn't know what role I wished to play. To help me decide I joined a summer video game camp program. Thus, through its creation, Polyspace, acted as my guide guiding me into the field I eventually stuck with, Game Design.
I used to be an artist?!(not really though)
At the beginning of development I was the 3d artist and was tasked with all of the asset generation used within the game. Given that I had never used Maya or Blender before it was quite the learning curve and experience.
Despite this lack of experience I was able to model five different ships as well as three different stages of the home base. This was mainly due to the fact that I spent a large quantity of time learning Maya and thus I eventually got the hang of simple model creation.
Since I made all of the assets we needed so quickly other teams "hired" me to make assets for their games as well. I remember making a destroyed lighthouse, a "car" (no real 3d artist would call it a car but hey it worked). Looking back now I might not have made the best of models, but hey they looked alright for someone who didn't really know how to use the programs and they worked great in our little demo games.
Team Issues and overcoming them
Since this was a team made game there were of course issues among teammates. You may have noticed that I listed that only two people worked on this game, me and a gameplay programmer. Originally we started out with five different team members each with their own unique role such as sound designer, 2d artist, and more. The first week of the project, we lost one of members due to family issues. Thus it was down to four of us at the start. This loss didn't effect us that much since we all had the desire to create something special and thus we pushed on.
For the first couple of weeks everything was going well, we met to do scrum meetings so everyone was informed of other disciplines work. Yet, what caused the most drama among the team was argument between the gameplay programmer and the sound designer. The sound designer didn't want to use certain sounds given they were copyrighted, but since we never were going to sell or market the game, the gameplay programmer said it didn't really matter, thus the split began.
The gameplay programmer asked the camp mangers and they said it was alright and thus using this added the sounds to the game. This angered the sound designer and thus he stopped working at all. Not wanting to be down to three people, we held multiple meetings to try and solve the issue, but the sound designer wasn't having it despite the rest of the teams attempts to remedy the situation. Thus for the rest of the project the sound designer refused to help and thus four became three.
Which wasn't helped by that the fact that only two people were really working on the game, me and the gameplay programmer. I say this because that the 2d artist at this point hadn't really contributed. Yet, all of these drawbacks never affected the gameplay programmer and I and we kept spending day after day working on the game. To help the programmer out a little I began to design the combat interactions between the player and AI as a QA tester as well as a designer.
Combat and Enemy Interaction Design
Since I finished all my art assets early and given the depleted state of our team, I wanted to do more to help the programmer given they had told me they were beginning to tire of programming and testing everything alone. Not wanting to lose the last working person on the team and the fact that I had created a good friendship between the programmer and myself I agreed. This began my journey of designing and testing Polyspace. As stated above, I stated that I created five different ship types. One of those ships was the player ship, but the rest were enemy ships and were meant to be different enemy archetypes.
Yet, there was a problem, we didn't have enough time to implement every ship that was created and thus a choice had to be made which enemy type would fit the best. At this point in the game, the programmer had implemented one of the enemy types, a sniper type enemy. This AI was programed to spawn a certain distance from the player and snipe at them from range. At first these ships were way to powerful as they would destroy the player to quickly. Thus we decided to nerf their damage a little bit to see if that made tad easier for the player. The testers kept getting destroyed too rapidly. Taking this new data into account we changed the way the enemy ships shot at the player. This meant changing the enemy lasers from being hit-scanned to actual projectiles.
This update appeared to help a little bit, but the overall accuracy of the sniper ships was still to high. Therefore, we nerfed their accuracy so they wouldn't consistently hit the player. Yet, there was a problem we hadn't quite realized at this point. It didn't matter if we made the ships slightly less accurate when the player had to dodge shots from ten different ships in a big ole cruiser.
We soon figured this out by the fact that players would be fine until a certain point in time where no tester, even us the developers, couldn't make it past. For at this point there were too many ships to make it possible for even the most skilled of testers to make it past. Therefore we nerfed the spawn rate of the enemy ships. The last change we made to enemy ships was how much health they had. Given that their design of being more destroyer-class ships aka being smaller and less armored, but with larger killing potential we altered their health to fit their design.
After this health change the player could kill these ships in three to four shots. Another reason this was done was given the range that the were from the player and the travel time of the player's shots compared to the enemy shots it just made the game even more balanced. All of these changes were pretty well received by the testers as now they had a higher chance of beating the game. Yet, this game wasn't just about shooting ships it was all about upgrading ones HQ.
World Interaction Design
One of the largest hurdles when designing the game we had to overcome was how on earth was the player going to interact with the world we were building them. Since we all knew that we were building a space game it should be something related to what future or even current humans would do in space. After a long meeting we came up with a solution, we decided that the player would interact with the world in a couple different key manners. The first way was to fly around shooting and mining asteroids that were randomly placed around the game map. Some of these asteroids would drop material that the player needed to collect in order to progress.
Once the player had mined some asteroids by shooting and blowing them up, they would hopefully survive the journey back to the HQ. Once the player reached their base they had a couple options of what they could use their mine material for. If they had taken a large amount of damage or any damage at all they could spend some material to fix their ship. If they had taken no damage or wanted to progress they could use their materials to upgrade the HQ to the next level. There were a total of three HQ levels each one looking slightly differently as to represent the upgrade.
Furthermore, the more the player upgrade their base the more material the next upgrade would require. For the first HQ upgrade it took five material, then doubled to ten for the second, and for the third it cost 15 material. Given that the player was in the UI menus during this time and we didn't want to fully pause the game, the HQ had a forcefield around it to protect the player from being shot by enemy ships while in the HQ UI menus.
If the player was feeling risky or believed they had to the skill to survive, they could scrap parts of their ship for material. They could do this nine times, each scrap taking a tenth of their health. This was also added as another method of gaining material that wasn't just mining and thus making the game slightly more dynamic for it added an element of player choice. Although this change did add something that many designers dread and that players finding the most efficient manner of playing or the golden path.
This golden path, once discovered, took away many elements of difficulty from the game for many players would get to base level two by doing normal mining and then would go out one more time to get as much material as they could before returning and scraping their ship so they could more easily get to base level 3 and win the game.
Therefore instead of removing the ability to scrap we buffed the enemies a little bit more and changed their spawn locations as to best combat this manner of play. This worked a little bit, but once a golden path is discovered it is hard to remove without heavily altering the game.
Yet, we were okay with this golden path for the most part because it showed to us that players were willing to go the extra mile to find the best possible manner of play and thus must be enjoying the game and that's what its all about, making a game that people will enjoy their own way even it if is min-maxing.
Movement Design
The last aspect of Polyspace I wanted to discuss was how we designed the movement and more specifically the feel of the movement. Due to us making a 3D space game, the gameplay programmer wanted to generate a more realistic or simulation-esc feel for the movement. What this meant was that instead of the player feeling as if they were driving a car through space, they were sailing through the cosmos aboard their trusty spaceship. Thus, the gameplay programmer built in a system were the player could pitch and yaw the ship as well as us designing and incorporating a slower and heavier movement feel.
We kept running into issues where the player was to slow and the enemy ships, even after being nerfed could easily pick off the player. Thus we went back to the drawing board to think of ways of keeping the heavy feel to the ship, but give it some means of avoiding or tanking enemy fire. We went through a couple of ideas such as increasing the ships health, adding a forcefield ability, as well as a boost of sorts.
Adding more health to the ship didn't feel right for it felt more like a janky sort of fix to the issue. The forcefield ability seemed like a cool idea, but then we would have to spend a large portion of time we didn't have balancing how it would work as in would it be a single use or rechargeable, would it last until it was taken down by the enemy ships or would it be more time-based?
Not wanting to go down the forcefield design rabbit hole despite it being a interesting design problem to fix, we decided to add in a boost that would propel the ship forward at a much greater speed than the default speed. This boost made it harder for the enemy ships to hit the player and it added another element to the game that wouldn't be to hard to balance given we already had a good idea of how it would be implemented.
If the boost really helped the player become so much more survivable, why not just boost the whole time? Well, the main draw back of the boost was that it made maneuvering the ship more difficult. Which sort of made sense to us given it would be harder to perform "quick" turns at such a speed with a massive ship.
Furthermore, it made fighting back against enemy ships tough for the player could aim as accurately at such speeds. This combination of a upside/downside made the boost one of the easier to balance aspects of the game. When we tested it most players used it as a method of faster travel if their target was far away as well as a means of avoiding fire. Yet, when the player wanted to perform a maneuver they would stop boosting, and would coast of their gained momentum to turn or rotate. This created some pretty insane moves that players began pulling off such as barrel rolling around enemy fire.