Simon Wagg
Design and Code for Games
Live/Wire
Live/Wire is a multiplayer competitive FPS, which features fast mobility and a unique ammo management system.
Roles: Lead Design and Sound, Code When: 2020 – 2021 Software: Unreal, FMOD, Ableton, SunVox
Listen to the audio!
Live/Wire is a multiplayer competitive FPS centered around player mobility and unique ammo management mechanics. Each player is equipped with a power cable which is used grappling around the stage and charging their battery-powered weapon. 2 teams of 4 duke it out in a large city square, competing to get the most kills.
In earlier stages of development, we planned to have more diverse, sports-like game modes where players would have to work as a team to score points and deal with obstacles that required more than one player to overcome. These concepts were removed due to time constraints on the project.
The forefront of the teams level design process was to figure out how players would want to grapple around while playing a competitive shooter.
When prototyping, I experimented with all sorts of different uses for grappling; hanging from a set point, exclusively zip to point, as well as just setting a point and swinging around. After lots of playtesting we determined that having a fusion of zip to point and swinging was the most fun and versatile method of movement. We knew that competitive shooters involved a lot of evasive maneuvers, so that inspired us to lean towards more fast paced and dynamic movement for the grappling.
It took a bunch of testing to figure out how levels should be built, and what was fun for players to navigate. We knew that the concept of lanes in an FPS map wouldn’t work for Live/Wire, given that there are very few restrictions on where the player can grapple to. Because of this, we focused on power source placements and sightlines. Players will need to charge their weapons, so they will naturally go towards and stay near power sources. To incentivise movement between sources, each source gives off a different amount of power, relative to it’s object; Street lamps will not charge your weapon as fast as an AC unit.
We also focused on making the city more like a jungle gym, with crossbeams and holes for the player to gain verticality and have surfaces above to swing from. While testing, we found that players wanted to use the grapple to just scale a building without swinging around, so we tried to shape buildings in a slight conic shape to allow them to do this.
One of the biggest difficulties we face with grappling was on the code side, and making it consistent for all users in a networked game. A lot of the values that were controlled for the hook were based on both server and local tick, which meant that depending on your connection to the server and how well your computer was running, the grappling speeds and air control would be drastically different. I did a ton of tweaking for values and trying to get tick speeds more server reliant to have a consistent experience for everyone playing, and we’ve had some moderate success on that front.
When constructing our levels and testing them, we found that players in QA were constantly flipping between moving too fast, and feeling like they weren’t moving fast enough. After tweaking play area sizes and grapple speeds, we discovered that having textures and fine details on buildings made a huge difference to how players perceived their speed in the environment. Without textures, (and having smoothed, cel shaded lighting) there is a large amount of depth that gets removed, making the scale of buildings feel very odd when moving between a running and grappling speed. We unfortunately couldn’t add textured buildings due to time constraints, but helped me think differently about designing spaces for the player controller and gameplay.
With the heavy focus on player mobility and speed in Live/Wire, I thought it best to focus on the players movement sounds to reflect it.
All of movement SFX is my own foley work recorded with a Zoom H4n, clipped and edited with Audacity, and added into their respective cues in FMOD. All of the impact sounds (running, landing, sliding) are recorded on a hard, tile floor base since the majority of the city appears to be made of concrete. I had plans to record for more materials like metal, gravel, and glass, but levels design ended up not requiring many types of materials.
I think the most impactful audio that I added to the game is the dynamic wind when the player is soaring through the air. It’s constructed in FMOD primarily using its parameter and dynamic blending abilities. Based on the players velocity, the wind volume will pick up and the samples will switch from lower winds to higher ones, creating the illusion that the air is passing you much faster.
The music is heavily inspired by the Unreal Tournament ’99 OST, specifically for it’s sectioning and instrumentation. I tried to keep an electric theme in the music by making the instruments as raw as possible; the main bassline in the title track is just a pure square wave voice that has some simple modulations on it, which I believe is similar to an electrical hum you would hear from any sort of power source in the real world.
Crypt Card Game
A prototype of a physical card game in digital form for a client. Players collect items and relics to confront boss monsters while competing against each other.
Roles: Code, UX/UI Design, Sound When: 2022 Software: Unity, Affinity Designer, Ableton, SunVox
Listen to the audio!
The Crypt Card Game prototype is a physical card game designed by Petie Mata, my client and my tutee.
The object of the game is to collect 3 Souls before the other players do. Players do this by selecting a hero archetype and entering an area of a dungeon filled with monsters. players collect items, relics, and pets to build their characters power and defeat the boss of that section, giving them a soul.
My roles in this project were to lead and facilitate the development and design of the digital version, while also teaching about the game development process and principles.
When the digital project started the game was already mostly complete, given some balancing adjustments made while playtesting. my focus was making the physical game into a controlled gamespace, while also feeling as much like a card game as possible.
My early mockups were designed to actively show the cards in a dock, not unlike hearthstone’s card representation. in the first, the art for the enemies would be represented as a real creature that the player could select and read about. When a player used an item or spell, there would be a physical representation acted out in 3D space to give the impact of the card used. In the second, it plays out more like the tabletop version. The benefits of this design are that is much easier to scale for mobile devices, (which was an early goal for the game.) and it’s lack of assets required in comparison to the first.
It took a few redesigns, but the current layout is essentially the same concept as the first mockup. Instead of showing cards, each action/item is represented as it’s art in this HUD setup. The player can hover an action to see what it does. The player can then click and drag it to the center of the screen to do the action. If the player wants to view an enemies information or attack them, they can click them and the camera will zoom to look at them.
Programming wise, this project was a major learning opportunity for me. The game has over 300 cards, all of which do unique things that are not simple to compress into universal actions. Not only that, but one of the goals was that the game would be accessible for balancing and adding/removing cards in the future, so it had to be approachable and efficient.
To me it seemed that the easiest approach was using CSV’s for everything, so that designers can edit values directly in the spreadsheet, reimport it and hit play. Each CSV is essentially its own deck, and a deck manager holds and reads the CSV and creates a dictionary to act as the reference deck. When information about a cell is requested, the deck manager recalls the CSV line number from the name of the card, and delivers the information of the requested cell.
To handle specific actions, we developed this simple language to try to manage the diverse actions of every card. The tag cell essentially is the function name the action needs, and the TagInfo cells are for specific information about that action. (this example will increase the enemies strike count by 1.) The conditional is a listener that prevents the action happening if the condition is not met. (In the above example, this action will only happen if the player has no relics equipped.) This system works well for maybe half of the cards, the rest have abilities that are either unique or too complicated to be boiled down like this. For those, a custom function is written to account for those abilities.
Heroes are handled uniquely compared to other cards, mostly because they have more actions than any other card type. Rather than a spreadsheet, each character is its own scriptable object. It holds all the hero-specific information in a neat manner while also allowing for variable amounts of abilities and attacks, which some heroes have.
The card game has a pixelated art style, so it made sense to reflect that throughout the rest of the digital game. We had gone with the 3D mockup because it felt a little more novel and cool to see the characters actually move around and fight in a space, so most of the set dressing is done with voxel art.
The artist is not a trained animator, so every hero and creature is just a static image. I thought that to give the creature and experience a bit more life, the characters needed some sort of animation, so I created a set of simple, squash and stretch animations for the player and enemies to give the game a little more life.
Prosper Springs
Prosper Springs is a narrative-based rail shooter where they player can use their hand to pick up and interact with objects.
Roles: Design, Code, Art, Sound When: 2019 Software: Unity, Illustrator
Listen to the audio!
Prosper Springs puts the player in the shoes of a bank robber; He’s hired a rag-tag crew with a false advertisement and has planned out his heist in order to steal from the man who killed his father. But is this act worth the lives of your innocent teammates?
This is a first person rail shooter experience where the players main interactions are with the main characters hand; players can pick up and use objects in their reach to use to deal with enemies, interact with Rube Goldberg machines, and save the lives of your fellow bank robbers. The player is presented in scenarios where they need to defend themselves, while also figuring out how to defend their teammates as they carry out phases of the heist; If a teammate dies, the route the player takes will change.
I developed this project by myself for the Game Tech II and Interactive Storytelling classes at Champlain College, it is currently unfinished.
At the beginning of this project, I wanted to experiment a split screen rail-shooter experience, with both players using a mouse to control each screen. The Idea was that the players were back to back, and they could pass objects between one-another by grabbing it and raising it over their head, where the other player could grab it and use it for their needs. The technical complications were pretty immediate; using 2 mice on one machine was rough, even with plugins that supported multi-mouse input.
Because of this, the project morphed more towards a traditional rail shooter experience, but kept focus on player interactivity with the environment. Instead of just having a gun like most rail shooters, the player instead takes control of the characters hand, and can pickup, throw, and interact with most objects within their immediate space. Players can pick up and drop objects by holding and releasing right click, and do specific actions with left click. (hold a gun with right click, pull the trigger with left.) This control scheme was added to mimic the actual actions required to hold things in real life; You need the coordination to hold a tool and use it in real life, with many objects you palm them and hold with your pinky/ring fingers, and do complicated tasks with the rest.
There were tons of interactions I had planned when working on this project; Pulling on ropes to pull another object, picking up TNT and throwing it back, wiping a dirty window to see a hidden resource, etc. These were out of my skill level at the time, but I did what I could to make the area feel as interactable as I could. I was inspired by many VR titles that make their spaces as interactive as possible, a driving force for making the mechanics of prosper springs was to see how close I could get to a VR experience on computer.
An obstacle I encountered when planning encounters was how the player was going to get resources. When a player “Uses” an item (throw a rock, fire a gun) power is constantly leaving the player. If they aren’t that accurate with their shots, they could be left defenseless and the game is over. It wasn’t my intention for the game to be punishing for the players lack of skill, so this was a problem I considered for a long time. At the time I didn’t have a solution for this problem, but I think having enemies occasionally throw objects back at the player might be a good approach.
This game makes heavy use of Unity’s timeline feature, and a plugin Called CineMachine.
The Timeline handled all of the games sequencing; I would set specified points on the timeline where the player would stop and do some combat or handle an event, and once a timer runs out or the last enemy is killed then they would automatically move to the next point. On each of these points, the timeline would send a notice to a master game manager, which would handle the timed spawning and triggering of other events.
CineMachine handled the dolly cart effect on the player’s camera, as well as some of the more complicated camera looks and movements. If the player moves their hand to any side of the screen, the camera would look a little bit in that direction, revealing other resources or potentially other enemies.
The toughest part to add was the pathing for all of the crew members. I had planned out everyone’s paths, and they were all easy enough to implement, however when characters died they had to discontinue their path and change the course of the game. Some of the crew members had interwoven dialogue that wouldn’t make sense if one of them wasn’t there. Instead of making the dialogue branch, I made a compromise and made most of the dialogue directed at the player, so that If a character died their conversation wouldn’t happen.
A major inspiration for this game was those western-themed shooting galleries that you would see at a fairground or carnival. Since the player would be looking around and experiencing an environment, it was important to me that the environment to be enjoyable to look at, as well as being convincing as a town.
Much of the art was done with the ProBuilder plugin for unity, with textures and characters made in Adobe Illustrator. I’m not a strong character designer, so all of the characters are flat and simple; this made it easier to create variations, as well as fit the shooting gallery idea a bit more. (their death animations really reflect this idea.) I used unity’s post processing effects to add some ambient occlusion and pop to the colors, and a duplicate model with flipped normals for the interactable object highlight.
In order to make an entire town, I needed to make some simple building pieces that could be modularly put together to create the illusion of a bunch of unique buildings. I create a bunch of base blocks, and made them each so that they could be rotate and add decks and other small exterior features like basement doors and such. I made some simple textures in Illustrator and adjusted the tiling size so that It looked true to life in the game, then went to town making a town.
Hyperlace
Roles: Design, Art, Sound, Code When: 2018 Software: GameMaker, SunVox, Illustrator
Listen to the audio!
The main challenges I faced when designing this game was the level progression and the initial tutorial sections.
A personal goal that I set for myself was to create a tutorial with as little language as possible, to both make the game accessible to people of differing languages or reading abilities, as well as getting the player actually performing the actions necessary to the game. I decided on creating a bunch of short introductory levels to ease the player into the movement, then gradually adding on mechanics and challenges that reinforce their decisions to move around. This meant that the levels really had to start from the bare bones, as well as create situations for players to make mistakes.
I approached this by listing out the order of thing players would need to learn to understand the constraints of the mechanics; Moving on the grid, looking for goals, line collisions, and the properties of changing colors were the main lessons needed to experiment with their relationships. I ran through many iterations on the first 7 levels of the game, while having other students test to make sure that the intro was clear to new players.
At this point in my audio career, my most comfortable range was in making effective and fun 8-Bit and chiptune sound effects and music. I thought that this space also fit the style of the game, since the visuals and gameplay are fairly simplistic, like games that would be played on consoles with those kinds of audio limitations.
One of the main ideas I wanted to accentuate with the gameplay music was the color changing mechanic of the game. When the player changes colors, they have different options and moved into a different phase of the puzzles solution, and I thought that having the music change to reflect that would help the player feel that change. I approached this challenge by writing one main loop, and then making 3 different versions of that song with different voicing and general motion. The tracks switch seamlessly when the player changes color, which gives the illusion that the instruments switch instantly.
When working on the art assets for Hyperlace, I knew that I wanted the visuals to be very clear and readable, while also having the gameplay look aesthetically pleasing.
Each object has its own shape and use of the colors to help them stand out to the player, since all of these objects will have varying colors throughout the game. The gameplay has the player switching between 3 different colors, so having the color be visually distinct from each other was incredibly important. I decided to stick with and RGB theming since they work well together, and using yellow for goal-related objects.
Aside from projects made with visual and block coding, this is my first voyage into written code. Hyperlace was created in GameMaker 1.4, which has both visual coding and it’s own language, GML. GML was a great language to start with when making a game, it was very readable and working with it taught me a lot about structure of code, and how to approach a problem.
One of those problems was getting the line graphics to rotate in the correct direction, based on the previous direction. There were effectively 2 line images: a straight line, and a corner piece. Getting the straight lines to rotate was pretty easy, but for the corners I had to determine how to properly track the players previous rotation and decide how to properly rotate the corner piece. Doing this alongside setting the proper color and collision properties was quite a challenge to overcome, but I learned a lot about structuring code and problem solving when working on this feature.
I’m Simon, a creator who’s interested in making digital art and experiences.
For as long as I can remember I’ve been messing around and making things on the computer; Starting out with making some simple songs with a MIDI writing program, to tinkering with games and code, and eventually mixing the two. Exploring digital arts and creating compelling experiences is what I’m all about, I love to learn about new technologies and apply them in all sorts of ways.
If you wanna get a hold of me, you could shoot me an email at SimonWaggDigitalArts@gmail.com!
Thanks for visiting!
