top of page
Gameplay
Overthrown is a fast paced PvP game. Where the players are tasked with finding "The Core" and keeping it safe from the opposing team while at the same time draining it of energy (points). The first team to reach the maximum points win the match. "The Core" also respawns after it's depleted of energy, bringing a high tempo to the gameplay.
My role
I was in charge of Game Design together with one other person in our group. My initial task was designing the first iteration of rules for the game in our Game Design Document. The rules needed to be based on the game idea that the group together agreed on.
The first iteration of rules needed to be implemented quickly, in order to get feedback before for the continuation of the project. That included the point system, the basic character movements and weapons design.
Design for an online environment - The challenges
Designing for an online environment created challenges that I had not faced before. Since this was the first online game for many in our group, the development of our mechanics took longer than I had first anticipated. To not get behind schedule I made the decision to scrap some of our gun designs and instead focus on a smaller variety of guns, that complimented each other better.
Melee weapon
From the beginning I knew that we wanted to provide the player with a melee weapon that would always be available to them. However I wanted to try and design something different compared to a "ordinary" melee weapon. The other Game Designer in our group made this first sketch:
The idea was that the weapon would be a sphere around the player, hurting everything that came in contact with it. After prototyping this and play testing it, we realized that the weapon was both unfair and required no skill to use. Even after tweaking the parameters as rate of fire and damage I made the decision that we needed to redesign the whole mechanic.
I had a back up plan which was a more "traditional" weapon, and in the end it looked like this:
As the GIF shows I moved away from the sphere and opted for a more cone like hitbox.
In the end I am happy with the final design of the gun, it requires more skill in aiming and forces the player to actually think about when they are using it instead of just button mashing.
I managed to redesign the gun after feedback from our play tests, just because I had an idea about how the mechanic would work it's not always something that the players would like. Being adaptable on either iterating or redesign something completely is a skill I feel like I have improved a lot on during this project.
Pick-Ups
I worked on both the rules for the pick ups (eg. Respawn times, amount of pick ups and their specific rules) as well as the placement of these in the levels. I had a rough draft of how many pick ups I wanted. One thing we noticed during play tests was that players often found themselves waiting for cooldowns for certain pickups or weapons. My solution for this was to reduce the cooldown for them, as I didn't want to clutter the levels. Lowering the wait for cooldowns worked well, and in the later play test we got a more positive feedback from the players about this.
I worked closely with our level designer to find the best spots in the levels for pick-ups to be placed and how we could design the level around having pick-ups, what kind of gameplay we created and what areas we wanted to draw the players to.
QA
I also took on the role of QA in this project. I, together with one of the developers, created a workflow for reporting bugs and balancing issues that we found during testing.
Since the game is played online, that made the testing process more challenging, as we had to build the game and play online for every test. That meant that my role became less of a Game Designer and more focused on QA as the project progressed. However, I always made myself available to playtest when needed.
Usually, we tested and documented both bugs and balancing issues on Post-its, which we then transferred to the Trello board seen below.
Depending on the issue, both developers and artists took on tickets and fixed them.
During the project, I was also in charge of our four major game tests, open to people outside of the development team. For this, I both did preparation by writing the forms for people to answer and decided the questions in them. Afterwards, I broke down the answers into different categories (bugs, balancing, art, etc.). I then presented and discussed the feedback with the different roles.
It was important for me to analyze the results after the tests and break them down for the different roles. I did this to optimize meeting times and to discuss the issues more in detail with the specific group of persons in charge.
Finally, I was also in charge of ensuring our builds were solid and up to standard. In our case, this meant setting up hard deadlines two to three days before our major playtests and presentations. I did this to give us time to playtest and fix bugs. In retrospect, we should have taken even more time for this; sometimes, we didn't have time to fix certain bugs, and if the playtester then noticed this, almost all the feedback given was colored by this, which led to the feedback not being as relevant for us since we were already aware of the bug in question.
Producer/Project Management
During this project, I had the role of producer and was also in charge of project management. The role included responsibility for our sprint planning, communication between different disciplines, and ensuring we met deadlines. This was my first time in the producer role for a project, which meant I learned a lot; in retrospect, I would have ensured we allocated more time to planning in the beginning.
This would have saved us from sometimes encountering bottlenecks. I think we could have identified these issues earlier if we had spent more time planning, both for the entire project and each sprint. In the end, I felt like the group as a whole was quick on our feet, and we managed to work around each bottleneck.
I felt like my most significant task as a producer was making final decisions on design questions and filtering information to the other members of the group so they could focus on their tasks.
Having the role of project manager also helped me grow as a designer, as I had to communicate more with members of other disciplines. I gained a much better understanding of their work and how much time is needed to code a mechanic or model a certain mesh.
bottom of page