top of page
Systems Prototypes
A collection of small scope systems prototypes.
-
Team Size: Individual
-
Role: Designer, Programmer, Artist
-
Tools: Unity, C#, Photoshop, Maya, Google Docs
-
Development Time: 3 weeks
Logic System:
Celestial Navigation
By creating a navigation system where players need to use logic to determine their position and the
direction to their destination, I intend to create an experience where players feel more of a sense of
exploration and discovery compared to exploring via the traditional map system, which always shows
players where they are and in what direction they are facing.
Intent:
Video:
Research, thesis and process:
When playing most open world, exploration focused games, I always thought it would be interesting to have a navigation system that didn't show the player's exact position at all times. While systems which do show the player exactly where they are and in what direction they are facing allow the player to easily navigate around the game environment, it also removes a substantial element of logic and pathfinding. My goal with this system is to make players think more about the world they are navigating through, and to make the journey the focus of the adventure, rather than what lies at the start and end points.
While building this system, I did a significant amount of research on the process of celestial navigation and the math behind it. Though celestial navigation is very intereting, the whole process takes a substantial amount of time. When designing my system, I did not want to make the player go through the detailed mathematics needed to actually calculate their position.
My solution to this was to make this process as intuitive as possible, and to automate the most dificult parts, allowing the player to focus on navigating and pathfinding. The players do need to use the sextant to find their position, which is arguably the most interesting part of the process, and they still must correctly identify their position based on circles of position that are drawn on the globe.
VDD:
Postmortem
What Worked
I think that I've created something unique with this system, and I am happy with the amount of progress I was able to make in 3 weeks. It's a cool method of navigating, and makes for a fun challenge. Navigating through a game world is often fairly easy, so it is a nice change of pace.
What Didn't Work
In my prototype, testers found the size of the world to be too large, as it takes a very long time to move around it. Especially when the player is in the open ocean, it's hard to get a sense for how far they have actually traveled across it.
Conclusions
The underlying system of navigating by the stars is an interesting way to pathfind through the world.
IIt's a navigation system that I think could add a lot to an open world game, and I have a lot of ideas on things that I could add to start to push the exploration aspect more.
Firstly, I think that storms and weather could help to give some more variety to the ocean sailing. Right
now, the player is always able to see navigational stars. It would be an interesting challenge if the
player ran into a storm, and was not able to use the stars to find their position. The player would need
to find their way out of the storm, or wait for it to blow over before being able to find their position.
Of course, a more interesting end goal than “get to the location” would also add some much needed
variety. The player could be a merchant, and could buy items in one location, and them sell them in
another location. Towns and ports, as well as natural landmarks could be added to give the world
unique locations. Some sort of supplies system could also add more depth to the gameplay, and would
challenge players logistically. If the player gets lost, they might not have enough food to make it to a
port, so they might plan their journey in a way that always puts them close to land.
Technical Challenges
Problem
When I began creating the environment for my world, I started by simply making the world very large, and the player and ship very small. This led to a lot of stability issues due to floating point precision errors, which became worse and worse as I continued development. When I added the globe, the issue became so bad that I realized that I needed to approach the problem from another direction.
Solution
After researching floating point precision, I found this very helpful talk, given at Unite 2013 by the creators of Kerbal Space Program. In it, they showed how they were able to render a large scale universe without any floating point precision issues.
One of their solutions to this problem was to use multiple cameras to render different parts of the scene. There's a camera to render everything close to the player, a camera for distance landscapes, and a camera which renders the planets and moons in the background.
Taking this new knowledge, I created two cameras. One to render the boat the player is on, and another to render the world and stars. In the image below, you can see that the player and boat aren't even located on the earth. It's all essentially an optical illusion, which works very well, and solved my issue with floating point precision.
Feature List:
-
Find your position and navigate using the stars, a sextant, and a globe.
-
Circumnavigate and explore the whole world.
-
Speed up time during travel to quickly cover large distances.
-
Randomized player and goal starting locations every time the game is played.
-
Team Size: Individual
-
Role: Designer, Programmer, Artist
-
Tools: Unity, C#, Photoshop, Maya, Google Docs
-
Development Time: 3 weeks
-
Platform: PC
-
Download Link: itch.io
Logic: Celestial Navigation
Social: Rafting
Social System:
Rafting
By creating a system where all players equally influence the movement of the group, I intend to make an experience which encourages communication, cooperation and teamwork.
Intent:
Features List:
-
Unique party game where up to 4 friends work cooperatively to navigate down a river.
-
Physics based raft movement based on combined paddling of players.
-
Intuitive paddling controls which mirror paddle movement with the rotation of a joystick.
Video:
VDD:
Research, thesis and process:
While trying to think of ideas for a social game, I began by brainstorming different ways in which players could be encouraged to work together. In most successful social games, I have found that requiring communication and having a common goal for players to work towards as a team are core components of what make the experience fun and engaging.
I have always been interested in exploring different movement mechancis, so I began to think of ways that I could encourage player communication as the group moved through an environment. With this in mind, I started designing a system where all players had an equal impact on the group's movement. This would mean that each player is an equal part of the whole, requiring players to cooperate and coordinate with each other.
After deciding to make a movement system, I began to think about what that system would entail. As I was trying to create a system which encouraged social interaction, I decided that making the game accessible to players of all backgrounds was a top priority. From any point in the game, players needed to know exactly what their objective was and how they could accomplish it.
Eventually, I decided on creating a rafting themed game, as white water rafting is a great example of a group of people working together to move as a single unit. This context also fits in nicely with my focus on accessibility, as even if you have never gone rafting before, the actions involved such as paddling and swimming are easily and intuitively understood.
Now that I had the basic context of my system, I began to think about the controls. To keep the game accessible, I focused on designing a simple and intuitive control scheme which allows players to easily pick up the controller and understand how their inputs will translate into actions within the game. To do this, I made my controls use as few inputs as possible, while also mimicking the real life action of paddling.
After introducing the mechanic of being able to fall out of the raft, I added the 'A' button which is used to both enter and exit the boat. To ensure that this was clear to players who may not be used to Xbox controllers, I implemented a button prompt which appears when the player is able to use 'A' to climb back into the raft.
In order for the system to remain intuitive, the paddle's interaction with the water needed to be consistent; player's always need to know how their actions will impact the game. Not only can players paddle forward by rotating the stick, but they can also paddle backwards by reversing the direction of rotation, or even slow down the raft by holding the stick off to the side. This all works in line with a general understanding of what it is like to paddle a raft, which makes the system easy to use and understand.
Bouyancy Script
To give the player's avatar's some character when they were outside of the raft, and to make them more engaging to control, I wrote a bouyancy script which causes the player's to bob in the water. Before creating this script, players were colliding with the water in a way that seemed strange. To fix this, I disabled their collisions with water and implemented the below script.
This script is in FixedUpdate, as it is dealing with rigidbody forces. Updating in FixedUpdate means that this function is called at a consistent rate, and will not change based on framerate, allowing for uniform physics behavior.
Line 1: Initializes the layer mask for the water layer. Using bit shifting, this layer mask will only detect collisions on the water physics layer.
Line 6: Sends out a raycast up from the player character, which only collides with the water. This checks to see if the player is underwater.
Lines 8 - 12: If the raycast hit water, the player is underwater. An upwards force is added to the player. The magnitude of this force is based on how far under the water collider the player is. The deeper the player, the greater the force.
Lines 15 - 18: Reduces the player's velocity if it is over the maximum limit.
Postmortem
What Worked
Giving each player the same amount of influence over the group's movement created an environment where team success was determined by their ability to effectively communicate with each other. At the start of the game, all of my testing groups were disorganized and didn't make much progress, due to their lack of communication. However, all groups quickly realized that communication was key to their success.
The simplicity of the game allowed players to quickly and easily communicate their goals to each other. For example, most players used phrases such"right side paddle", "left side break", "lets go this way", etc. The easily understandable goal of getting down the river and the simple mechanics allowed for quick back and forth communication, keeping the whole team involved and engaged with the game.
Though testers didn't note it, I think that a lack of a loss state helped to make a friendly atmosphere where players are only held back by their own lack of communication. Players are never forced to reset or start over, which otherwise could be the source of conflict and frustration within the group. The absence of loss states keeps players engaged with the game, even if they aren't being as successful as they could be. The friendly and light-hearted atmosphere, coupled with the forgiving gameplay helps to create an environment where players are encouraged to work together.
What Didn't Work
The biggest flaw with the system in it's current state is the camera system. It doesn't help the player's
know where they should be heading, and in some cases it gets in the way and makes it much more
difficult. It occasionally swings rapidly around the raft, which can lead to disorientation and confusion.
To improve upon this, I would implement a camera system which is tied only to the velocity of the raft
and players, so that the direction that the raft is going is the direction the camera is facing. Currently,
the camera is parented to the raft, which causes it to rapidly swing around as the raft spins.
I also think that there is a lot of improvements that could be done to the paddling physics. Currently,
dragging the paddle creates a bit too much drag, which can cause the raft to rapidly spin even if the
paddle is in the water for only a second. At fast speeds, this can cause the raft to jolt and spin around if
someone puts their paddle in for too long. Taking a deeper look into creating consistent paddling
physics would help to make the game easier to understand, and more enjoyable in general.
Conclusions
Creating a system where players equally and collectively control the group's movement provided an
experience which emphasized group communication. Because each player has an exactly equal impact
on how the group moves, each player is just as critical a member on the team as the next. This
incentivises team cooperation, and makes for an experience where working together means
acknowledging that success can only be achieved through a coordinated group effort.
-
Team Size: Individual
-
Role: Designer, Programmer, Artist
-
Tools: Unity, C#, Photoshop, Maya, Google Docs
-
Development Time: 2 weeks
-
Platform: PC
Altered States: Ramiel
Altered States System:
Ramiel
By creating a vehicle movement system where all player input is reflected by changes in the control
surfaces, and where visual feedback is used to communicate the current state of the vehicle such as
speed and g-forces, I intend to create an immersive and engaging experience where players will feel
like they are in the pilot seat.
Intent:
Features List:
-
First person game where players take control of a high speed aerial vehicle.
-
Player input is mirrored by the control surfaces on the aircraft, such as the joystick, yaw pedals, and ailerons to create a sensation of control.
-
Visual effects such as particle systems and camera shaders, as well as audio cues like the doppler effect create a sensation of speed.
-
Neverending terrain which allows the player to fly indefinitely.
-
Enemy AI which follows the player and attacks them with two unique weapons.
Video:
VDD:
Research, thesis and process:
While playing a race car driving game, I was disappointed by the lack of speed that I felt while driving around the track. It was hard for me to tell the difference between going 20 mph and 60 mph, which made it hard to determine when I should speed up or slow down. I began thinking of the elements that would make up a system that would communicate to the player both control of the vehicle, as well as the speed that the vehicle is currently going.
One thing the racing game that I played did do successfully was to make me feel in control of the vehicle. The steering wheel turned when I pressed the inputs to turn left and right, the pedals moved as I accelerated or slowed down, and the gauges on the dashboard moved realistically. My first step in this project was to incorporate this into my vehicle, in this case a futuristic aircraft.
To create a feeling of control, I ensured that the player could always see some sort of visual change reflecting their input. The aircraft's throttle, yaw pedals, ailerons, elevators and joystick all move to mirror what the player is inputting.
After developing this feedback system, I started working on implementing movement. To do this, I used Unity's rigidbody physics system.
-
Line 1: All forces are added to the Rigidbody in FixedUpdate rather than Update. This is because FixedUpdate is called at regular intervals, whereas Update is framerate dependent. This allows for consistent movement across varying framerates.
-
Line 3: Checks with the GameStateHandler singleton class to make sure that we are only adding force during gameplay.
-
Lines 5 - 11: Adds pitch roll and yaw forces based on their current speed, which is calculated based on player input.
-
Lines 15 - 18: If the player is moving faster than the maximum speed, a limiting force is added in the opposite direction.
-
Lines 19 - 22: Adds a minimum force to the player if they are moving at a speed below the minForwardSpeed.
-
Line 24: Adds force based on current player input if the player is not moving too fast or too slow.
-
Lines 27 - 31: Calculates the change in rotation based on a value that is saved at the end of the last frame, which is used to slow the player down as they turn more sharply.
After developing the movement, I started focusing on the feedback system which would communicate to the player the current state of the aircraft, including speed and g-forces. To do this, I took inspiration from both other games, and real life videos from helmet cams in fighter jets and race cars. Using my research, I developed a system comprised of a combination of particle effects, camera shake, and shaders.
Below is the snippet of code which handles the camera shake effect.
-
Line 4: Determines the magnitude of screen shake based on how fast the player is moving.
-
Lines 6 - 9: Creates a target for the camera to move to based on a random number within a defined range.
-
Line 15: Determines magnitude of screen shake based on g-forces on the aircraft, which is determined elsewhere based on the change in the player's velocity.
-
Line 17: Determines final magnitude of shake intensity.
-
Line 19: Applies the camera shake by interpolating between the camera's current position and its new target.
To wrap the prototype up, I worked on creating an interesting context for the player to make use of the mechanics. I created an environment comprised of tall thin plateaus, which challenge the player with manuvering the vehicle through tight spaces at high speeds. This terrain is infinite, and allows the player to move around the world indefinitely.
I also created the enemy to test the player with an additional obstacle. I decided to only create one so as to not overwhelm the player, but made all of its attacks destroy the player with one hit to make the encounter tense and challenging.
The enemy's beam attack was created to clearly communiate to the player when it is about to fire, shown by the thin line. This helps to make the game less frustrating as players always know when the enemy is about to fire.
To prevent players from simply flying above the plateaus without a challenge, I implemented a secondary attack to the enemy which seeks towards the player. If the player flies too high, this weapon will fire, and won't stop chasing the player until it either reaches it's target, or hits the terrain.
Postmortem
What Worked
I think that the biggest success in this system is the amount of feedback. The effects, sound, and mirroring of the player's controls with the game controls help to engage the player and bring them into the game world.
The particle effects, shaders and sounds give the player a sense of speed, while the mirroring of inputsin the game allowed for a sense of control, and the game is challenging enough to make for an engaging experience.
What Didn't Work
One of the issues with the prototype in it's current state is that the difficulty ramp is too steep.
Immediately the player needs to learn how to pilot the ship, avoid the obstacles and the enemy. In a
game as fast paced as this, it's a lot to take in at once. Adding a starting section where players fly out to
the enemy first would be useful for this.
Similarly, it might help ease players into the game by making it so that players can bump into the
terrain at lower speeds without immediately dying.
Occasionally, the forces that are being added to the player camera lead it to clip into the side of the
vehicle, and in certain cases, the ship can block the player's view of what is going on. The challenge I
found with this system was in balancing the competing forces on the player's camera, and making sure
that the player always had a good view.
Conclusions
The sensation of control and speed in a virtual vehicle is the result of many different layers of both
audio and visual effects, the mechanical (player movement and physics) and observable changes (speed particle effects, motion blur) to the game as a result of the player's input, as well as the layout of the environment that they are maneuvering through. I think the prototype was successful in making players feel like they were traveling at fast speeds, but there is still a lot that I could add to help push the effect.
One of the key components for making this system work was in balancing all of the effects to make
sure that they consistently communicated to the player how fast they were going. Especially with the
speed particle system (white lines streaking past the camera), it was easy to create an optical illusion
which made it feel like the ship is moving much faster or slower than it actually is.
As noted above, the difficulty is pretty unforgiving, so introducing the player more slowly to the
mechanics would help make sure that the player is not overwhelmed and frustrated. The fact that
everything is a one hit kill also adds to the difficulty, as players immediately fail after making a single
mistake. Adding some sort of shield or health system might help newer players become better at the
game more quickly, and be more forgiving of their mistakes.
-
Team Size: Individual
-
Role: Designer, Programmer, Artist
-
Tools: Unity, C#, Photoshop, Maya, Google Docs
-
Development Time: 2 weeks
-
Platform: PC
-
Download Link: itch.io
Physicality System:
Wall Ball
Using "click and drag" based mouse input to choose the swing direction of a racket, combined with an over the shoulder view and an agile character, I intened to create a tennis game that is both visceral and intuitive, which is easy to learn and rewarding to master.
Intent:
Features List:
-
3rd person tennis game.
-
Intuitive controls which mirror the movements of swinging a tennis racket.
-
Click and drag the mouse to bring the racket back in a direction, release to swing.
-
Easy to learn, but hard to master.
Video:
VDD:
Research, thesis and process:
I really enjoy the sport of tennis, and have always wanted to create my own version of the sport as a video game. While playing popular tennis video games, I realized that they all focus heavily on the strategical parts of the game, such as choosing which type of spin to put on the ball and where to hit it to catch your opponents out of position. Though I think that these games are successful at creating an experience which challenges players with strategical thinking, I don't think that the games convey a sense of the physical nature of the sport, such as running down the ball, and timing the shot.
These major tennis games share similarities in camera and controls. The camera is generally located above and behind the players, close to a top down view. It always faces straight across the court, regardless of the player's orientation. This ties into the controls, where the player must press and release a button which is tied to a spin type to swing the racket, and can use the left stick to aim the shot, relative to the screen.
When starting to design my system, I thought of ways that I could change this formula, and decided upon a third person, over the shoulder view which rotates with the player, and click and drag style controls to choose the swing direction.
Camera:
I decided on a third person camera scheme because I felt it communicated the spatial awareness that is required to play tennis. I experiemented with a first person view, but didn't like how the player wasn't able to see their racket when it was drawn back. This view also made it more difficult for players to tell when their racket would make contact with the ball.
To give the player more feedback, and to push the physicality aesthetic of the system, I made the camera dynamic, making it pan in the direction that the player is swinging, and fade out at the edges. This helps the player line up the shot, as the center of the screen is where the racket will swing, and the vignette helps the player line up and focus on the ball.
Controls:
I took a lot of inspiration from games like Mount and Blade, and Chivalry: Medieval Warfare for the control scheme. Both of these games, which are centered around medieval combat, use a click and drag mechanic which allows players to draw back and swing in 4 directions, all based on mouse input. I found this to be a satisfying way to give the player control of their actions, so I incorporated it into my design.
Court Builder Tool:
To quickly balance and tweak the court size for the level, and to allow for the easy creation of various court dimensions, I created a tool which creates a court based on input from the user.
The above code creates a grid of falling tile prefabs based on the users input.
Postmortem
What Worked
Overall, I think that I was successful in creating a system which challenges the player with the more phyiscal aspects of tennis. Testers found that the system was satisfying and intuitive to use, and felt that they were able to become more proficient as a result of playing more. They also felt that there was room for them to improve, which shows that the system was easy to learn, while also being challenging to master.
What Didn't Work
Currently, I think that the biggest thing that is missing from the prototype is more feedback, especially regarding sounds.
Similarly, I think that while giving the player 3 jumps allows for some satisfying acrobatic manuvers, the amount of jumps they have is a bit arbitrary. Adding some sort of indicator to communicate to the player how many jumps they have would help make the system more clear to players.
Conclusions
I think that my tennis phyiscality system was a great success, and I would love to build on it more. The controls are intuitive, and also give the player more of a visceral connection to the game. Rather than just pressing and releasing a button like in the other tennis games, the click and drag mechanic mirrors the movement of swinging a racket, which helps to make it more immersive and instinctual.
The camera helps to bring players closer to the action, and makes players feel more like they are actually running around on the court, rather than watching someone else play.
The next step I would take with this system is to develop a simple AI for the players to play against, as well as implement a more traditional court and scoring system so that players could play an actual match, rather than hitting the ball against the wall. I think that this would help to identify any weak points of the system when trying to translate it to a more traditional tennis experience, and would also show if the system continues to create a more intuitive and physical tennis experience.
-
Team Size: Individual
-
Role: Designer, Programmer, Artist
-
Tools: Unity, C#, Photoshop, Maya, Google Docs
-
Development Time: 3 weeks
-
Platform: PC
-
Download Link: itch.io
Physicality: Wall Ball
bottom of page