Made for: ARU 3rd Year
Duration: 7 Months
Engine: Unreal Engine 4.25
Language: C++/Blueprint
Position: Pair
Brief (Excerpts) – From Jagex:
“Your challenge is to design, implement and launch a version of a classic video game from the late 70’s to mid 90’s.”
“Care should be taken to not duplicate key visuals or names from this title, avoiding legal disputes around ownership and copyright. However, gameplay and “feels” should be immediately recognizable. As a stretch goal, we are interested in seeing what modern twists can be added to the gameplay, enriching the users experience but fundamentally preserving the original.The final product should be launched on itch.io, and should include a way that players can offer feedback.”
Claim Showdown! is a modern re-imagining of the retro arcade game Claim Jumper (1982) for the Atari system. Currently in development, It’s a 1v1 top-down competitive shooter with both local and online play. While it wasn’t polished enough for a public release, it is still available to download on itch.io.
Download Link
At the start of the project we had to find a retro game to remaster. We eventually settled on “Claim Jumper” from 1982 in which players navigate an American frontier inspired western environment collecting gold and avoiding obstacles. The simple 1v1 party-game style seemed easy to capture and pitch in a newer iteration.
We decided to keep the top-down perspective but transition to 3D with controls adapted to meet a more modern standard. The players can move and aim independently and have a wider range of interactions available. Items can be manually picked up, dropped, and thrown. A shovel would be used to dig for gold at indicated sites instead of gold nuggets spawning randomly. The revolver remains largely unchanged with bullets traveling through the air. Finally, instead of being placed in a hospital, players get stunned for a brief period if damaged during this phase of the game.
Our big twist on the formula was splitting a round into two main phases – exploration and showdown. The exploration phase is largely inspired by the original game in that it pits the players in an open area with the objective of gathering gold and converting it to money in a set time. Once the timer runs out, players are transported to the shop where they can buy items with the money they had collected. These items upgrade stats like movement speed, fire rate and health.
After purchasing their items, the players are taken to a small arena where they fight one on one. In this showdown the last one standing wins the round and comes closer to victory.
What I did
Programming
Most of my programming work focused on gameplay and features. In a pair we were able to work on many parts of the project together without really stepping on each other’s toes. However, I let Ves handle the backend matchmaking and core gameplay architecture on his own, giving me a chance to focus on the details of implementation. Most code stayed in C++ with extensions into blueprint when I was more likely to reference and utilise the meshes, effects and audio that I created.
Importantly, this was our first networked university project as the game could be played in both split screen and online. Since working at BULKHEAD we had gained an extensive understanding of replication in UE4, integral for testing since we were working remotely.
Game Design
I handled the balancing and made changes to the gamemode when things didn’t click during our playtests. We focused our efforts on making things functional first then pushed to make it playable from start to finish. Any features that weren’t integral were pushed to later sprints.
In the first design there was only one round which felt frustrating for the loosing player and made purchasing items usable only in the showdown. Our biggest change was adding the best of 3 rounds which allowed items and gold to be carried over and give the looser another chance.
Health and armor was also only show in the showdown. Adding additional rounds made it obvious that we should add these systems to the exploration phase too. This made purchasing items and collecting gold more impactful on how players chose to play the game.
Level Design
The layout of the arena was kept similar to the original with the assay at the top and banks in the bottom corners. As we tested I kept reducing the size of the level as downtime caused frustration. This caused players to gain more gold over the course of a round and interact with each other more often, creating more opportunities for combat in the exploration phase.
I tried to keep a balance of open routes and cover so that players could escape from each other but still have a good chance of stunning and stealing items where it mattered most.
Originally I had dig spots all around the level but I eventually pushed them into more specific areas at the sides with additional spots between the banks. This caused players to split up when digging then come together again at the assay. I also tightened a choke point at the train tracks and moved the banks futher apart, heighening the chance of players stealing money as they move it south.
Modelling
As I had more experience in Blender, I decided to push myself and put more effort into creating assets. We relied on two western style low-poly asset packs as a base but many objects we needed were either not present or not fleshed out enough.
Objects like the snake, gold, money bag etc. were original assets that I made to made to match the style of the pack. Other things like the buildings (bank, assay, shop) required heavy modifications or amalgamations of asset sections to fit our layout and camera perspective. Base textures sufficed since they had a large pallete of flat colours to choose from. I only had to make unique ones for the decals on the assay and bank. The only assets I didn’t touch were static environment pieces like the rocks, ground, cacti etc.
As things progressed I made a separate variations for each character based loosely on cover art from the original game.
I was able to smoothly integrate clothing items by lining up the vertices and matching weights with those on the character mesh to prevent clipping.
Weapons were also a mix of asset pack, completely new meshes and modifications of the asset meshes.
I also had the job of populating the game with these assets. The game level needed to keep certain areas clear with random cover from destructable objects that respawned per-round.
Inside the shop I crammed the scene with objects and added subtle lighting to create a darker feel and put focus on the menu that the players would be using. Items would also be placed on the shelves and counter as they became available.
The menu scene also needed fleshing out, sticking to the style of the main level, reusing elements like the train in the background.
Animation
For the player characters a lot more effort was needed to get a workable skeleton. I had to create a custom rig to better match the unreal base and make importing easier. This required a full reskin to make rotational extremes look nicer and utilise some extra bones.
The number of animations required for the player became quite a lot to manage in the end. I started with a basic 4-directional cycle for walk and run with upper body poses for gun, item and shovel when they are held. Melee, throw, shoot, dig and aiming poses for the three types were required too.
Impact and stun loops were also added which I hoped could be additive but simply didn’t look right across all three possible states so I created variations for each. The 4-directions then started to cause leg collision so I made 6-directional walk and runs + upper body 4-directional walk and runs for the three states to make them look less static. movement anims were also synced with markers to ensure they blended seamlessly.
I also added a slight swing from the shovel as it sat holstered on the character’s back and made the characters look at certain objects when close. Another small touch was blinking, easy to implement since the eyes were just cubes.
The snake was also hard problem to solve. Getting the movement right with keyframes seemed impossible so I gave up on trying in Blender and made a custom animation node in C++ instead. Evaluating sine over the bone chain to offset the positions gave a much better result.
I rigged and animated the train, IKing the piston so that it pointed from the wheel back to the chassis as it moved and matching rotations with move speed. The tumbleweed was fairly simple too, spining and scaling as it bounced along the ground with a random bounch height and duration for variation.
VFX
VFX requirements were fairly light with explosions and bullets taking priority. I tried to add effects to many objects like bouncing tumbleweed, train smoke and dig spot dirt.
I needed to split crates and barrels into individual pieces with interior faces in order to create damage states and destructable chunks.
Gold objects and moneybags shine brightly, dropping small particles as the player moved so that other players could follow them.
Audio
We were able to work with two other university students on a different course for sound effects and music respectively. We both gave feedback on menu, showdown and exploration tracks as well as stings for each cutscene. Ves implemented the music while I focused on the effects.
The sound effects student was quite busy this semester so I filled in the gaps where I thought we would need the most attention. I’d often use the audio he provided me as samples to layer with my own that I’d sourced. I also now had access to proffesional royalty-free libraries which I relied on to get more samples for mixing before importing into engine. I then imported seperate tracks for most effects, modulating them to reduce repetitive playback.
The gun sounds required the most work, layering many samples into core elements then modulating those based on distance to the listener. Said listener also needed to be shifted slightly forward to match the perspective of the player, otherwise sounds to the south would be louder due to the camera angle.
Cutscenes
To transition between phases I created cutscenes in sequencer featuring camera and character animation. This required a bit of setup to work alongside networking. I figured that I could bind actors to sequencer references so I wouldn’t need two characters in the scene. I use temporary character BPs to keyframe the animations that are destroyed on play. When cutscenes start, characters are set not to replicate then are bound to the temp character channels based on playerID. Replication is enabled when the cutscene ends. This allows a smooth transition from cutscene to gameplay without actor swapping which also keeps clothing, weapons etc.
In all, I feel this project was pretty successful. We got full marks across the board for most sprints and our submission as well as positive feedback from Jagex. I was also able to finally put my experience with modelling, animation and sound to use in a group project. However, there is certainly a lot of room for polish and more things to add from our list of ideas that could spice things up. We agreed that it wasn’t up to snuff for an actual release but we were glad that those who played it saw that potential.