By Design: Weapons Short of Destruction
- Jdevinny
- Oct 10, 2018
- 9 min read
For many of you who don't know, I began my career path into the game industry through my time at college. It was at DePaul University in Chicago where I was able to work to turn my passion into a usable skill set. While at DePaul, I began to work on a multitude of different projects, made friends with wonderful people, and even discover new concepts to be passionate about. Yet one of the greatest assets of this school was having the tools necessary to build my own portfolio. So, as a way to learn more about who I am and how my brain works, I thought it best to kick off this new blog by discussing the latest game project I've worked on until this point. This project was a short game play prototype developed in six months that goes by the name Weapons Short of Destruction.
To begin, this project was designed to function as our final thesis for those who enrolled in a game related field. The class this project was created for was to test everything we've learned and apply it into a presentable piece. We were allowed six months to complete these games (though naturally some would begin even sooner) and have them in a state that was presentable, and possibly even publishable. You were even allowed to work with as many of the other students within the class as you wished, with some teams having as many as ten people and others being simply teams of one. I was lucky enough to pair myself with a fantastic group of four hardworking individuals, and together we formed the team known as FreezeFire Games.
The Beginning
I don't wish to delve too deeply into everyone's specific roles within the group, or attempt to breakdown each members contributions. But I do want to clarify that this was an incredibly devoted and enjoyable team who all sought to make as best a title as we could with the time we were allotted. However, the point of this blog post is to better explain my own design decisions and how close the completed title matched with the original pitch. As such, we will explore the game from it's conception and the changes that were made along the way. It's best that we start then with the game's origination.
WSoD, from the beginning, was not one of my own ideas. As a group, we all pitched concepts that we could build a game around provided the limited time and resources. Deciding on an idea wasn't easy for our team, and while I attempted to argue for my designs as best I could, the decision came down to an early prototype one of the team members made and a need to make a choice. The prototype was a first person shooter where the main mechanic was blowing away objects with shots of force. The idea was simple, the code existed, and so the decision was made. This left me in a position I was unfamiliar with, the idea of being a designer on a game I never originally designed.
Suddenly now, I had to own this idea and care for it as if it was my own. It's as if a newly born child was left on my doorstep like some fairy tale. Originally, I was left confused and a little disheartened, yet quickly my mind began to race with ideas on where I could take this concept. It was surprising how fast I was able to adapt to this new scenario. I believe the reason for this was likely due to my fascination with designing game mechanics.
Mechanics, the abilities that players have within a game, are one of the most interesting facets of game design that I love building around. Thinking up a player's ability, how that ability is visualized, and how that ability impacts the world around them is a core facet of designing an interesting game. The potential in my head for WSoD was huge, and I immediately began writing whatever ideas came to my head in terms of player weaponry, level architecture, and movement options.
When it comes to initially designing around a new concept, I tend to write out my potential ideas in full before attempting to capture it into an official document. Usually these ideas are put into a journal, and I try to write in it whenever something fresh comes to mind (usually late at night when I can't sleep). These ideas aren't solely limited to just player mechanics, however, as they can also include general world building and pacing. Once though I feel I have a solid grasp of where I'd like to see the concept go, it's at that point where I move into the documentation phase.
A proper Game Design Document (or GDD) is crucial in conveying what the purpose and goal of the game should be. It requires having a solid understanding of the kind of game you hope to make. To be able to have everyone on a team understand the vision and what they're building towards, a GDD must be as in-depth as possible. This means breaking down things like mechanics, levels, user interface, setting/characters, etc to be as simple to understand and descriptive so as to act as a guidebook for team members to look towards. This doesn't mean everything's set in stone however. GDD's go through many changes over the course of development, so as to better reflect needed additions or corrections. Because WSoD was meant to be small, the GDD only meant to cover the necessities. This included topics such as game play mechanics, environments, match rules, and even story at one point. Like mentioned before however, very little was set in stone.
Gameplay
Game play mechanics took the longest to nail down initially. The initial pitch for the game mentioned Halo style game play, so I looked to games like that (such as Halo, Team Fortress 2, Overwatch) for inspiration to see how the controls and weapons should follow. What I figured was that this was gun play that was not only fast, but also allowed for a lot of player choice when it came to movement and weapon combinations. With that knowledge, we led with controls that highlighted speed and a satisfying jump motion. Character and environment hit boxes (how they collide with other objects) also needed to be adjusted in order to nail better feeling movement. It was something to work on at the start to get a sense of what to work towards. Something that needed even more consideration, however, was the shining feature that was intended to be the game's core component. The idea that weapons attacked indirectly.
We had to make the core mechanic of being able to attack another player indirectly work within a multiplayer game. This ended up becoming the most difficult hurdle to cross as the game continued development. We settled upon the idea of environmental traps, that players with their weapons would shoot others into deadly parts of the level. It seemed like a great idea that allowed us to to push our game's personality even further. Suddenly the environment itself acts as another player within the game. Before we were able to truly evolve the idea however, time began running out and we had to limit ourselves a bit more. This is one of the reasons why you see so many spike traps in comparison to more unique ideas like man-eating trees or giant venus fly traps. Yet these traps wouldn't matter without players being able to use weapons that took advantage of them.
Weapons were where most of the early ideas went towards, and where most of the ideas were scrapped. It was important for the game that every weapon had its own personality and feel. That each weapon was able to enforce new methods of play at a fast pace. Such weapons included a force cannon, a tornado launcher, an energy tow cable, robotic gnats, and a gravity dome. The weapons also were designed to fit into two categories: pushing weapons (orange), and pulling weapons (purple). This design choice was meant for fast and simple weapon identification. It also helped with players being able to quickly identify how the weapon is intended to be used, instead of wasting time attempting to figure it out. The design of the weapons was one of the most fun parts of the project for me, yet with the time constraints there was only time to implement two; one push and one pull. The design goal for the weapons was accomplished, just to a lesser capacity than what we envisioned.
Level Design
Level design was another facet of the game that was important for me to get right. In order to nail the fast pacing of the movement and gun play that we wanted, as well as accompany for our four player count, I designed the initial level to be smaller and more compact. The small size was to ensure that there was always some form of conflict between two players occurring at all times. Having, at any point, long drawn out battles between players was undesired.
Another design method to ensure player conflict was level flow. Proper level flow is being able to sculpt and place areas of the map in an attempt to influence player movement/decisions. If there's a specific area that you want players to go to or fight for, that needs to be properly conveyed through the level design in a way that feels natural. One way that I feel I accomplished this was the naturally sloping area. Everyone begins at the top in a circular map, then eventually proceed downwards in search of others. Reinforcing this flow was the idea of weapon pickups as well as traps. There are no pickups or traps at the top of the map where players spawn, instead they lie in various locations at the bottom of the map. This decision naturally solves how to properly orchestrate player conflicts in a way that makes sense within the level.
The design choice of having the level be sloped downwards also feeds into encouraging more interesting movement from the players. I explained how we wanted the movement to be fast and varied, but if the level was designed as a flat area with random columns strewn about, for example, then we would have seen players move much more cautiously. Verticality is important in allowing for varied movement options, and it also allows for more choice in how players plan their routes.
(Left: Early level sketch - Center: Rough level prototype - Right: Finished product)
Systems/UI
Proper player feedback is very much essential in ensuring a satisfying experience. Feedback can be one of those areas of game development that can be truly difficult to nail down. The player needs to know what things are good, what things are bad, and whether they are currently doing well. You have to be able to tell the player all the rules of the game, without writing out all the rules of the game. The way we accomplished this in WSoD was through proper point allocations as well as a dynamic camera system.
Each trap within the game had their own point values assigned for when a player successfully forces another into them. Common traps like the spikes would award a minimum amount of points, where more difficult traps like the tree or plants would be higher. Point values were also assigned for when a player might trap themselves. These points would be subtracted from their overall point value.
In order for players to understand that they were defeated, we implemented a camera system that would display exactly where/how they died. Upon a player hitting a trap, their camera would cut away to reveal their death and then they'd be allowed to respawn a short time after. This system was to reflect that of Team Fortress 2, where the player's camera would switch perspectives upon death. This design choice works to remove any possible confusion upon a player suddenly dying and then respawning.
Lastly, I worked to partly design the menu system for the game. Being able to navigate from the title screen into gameplay needed to be fast and simple to reflect the pacing and size of the game. Upon getting past the title screen, player 1 is immediately displayed as being a part of the game. For any other players intending to participate, a simple button press will display their character and that they are also ready. Having characters being visually displayed lends back to the idea of proper feedback.
Upon all players being ready, they progress to the game options. Player 1 is able to make changes on the fly by selecting either left or right for game mode, and then using up or down to select win conditions. The visual style of the main menu also was designed to reflect what little story was presented. i.e. Players taking on the role of test robots.
(Left: Main menu - Center/Right: Design sketches for menu navigation)
Weapons Short of Destruction was one of the longest projects that I worked on while at DePaul. The game allowed me new experiences and new design challenges that I never worked around before. After seeing the final product, I believe that my team and I managed to create something we were truly proud of that stayed true to our original pitch.
I want to thank anyone and everyone who decided to take the time to read this blog post. I thought it would be a great idea to breakdown examples of my game design philosophy. I intend to do similar posts in the future with some of my other projects. I felt the desire to do WSoD, however, as that was my latest game. I owe a lot to my school that gave me the resources, and my team members who worked to see this game get finished.
Thanks!
Comments