Games

(click for development details, design considerations, and more links)

Lunch Break

is a team project developed for Drexel's junior game design class For the project, I:

Developed a fast-paced first-person shooter with 6 other programmers
Ensured consistency & maintainability in a 40+ script code base
Created 10+ reusable components to keep the codebase D.R.Y.
Programmed the player controller

Roles:

Programming
Design

Skills:

C#
Game Design
Version Control (Perforce)

Tools:

Unity
Visual Studio Code

Play Code

Variant Gunner Deluxe

Play Code

Variant Gunner Deluxe is an updated version of my solo project developed for Drexel's GMAP 231 - Scripting for Game Design. We were given free reign over the design of the project, so I decided to make a short shoot 'em up inspired by Treasure's Radiant Silvergun. The Deluxe update boasts a refactored code base and bug fixes.

(scroll down for postmortem)

As a programmer, I:

Developed the design, graphics, and code in < 3 weeks
Created the player controller
Constructed 4 unique weapons
Scripted a dynamic camera

As a designer, I:

Designed 4 unique weapons that solve different problems
Made a tight character controller tooled for precise bullet dodging

Skills:

C#
Game Design
3D Workflow

Modeling
Texturing
Rigging
Animation

Vector Illustration

Tools:

Unity
Blender
Visual Studio Code

Postmortem (Original, Sep '24)

Even now, Variant Gunner stands as one of my proudest projects, showcasing my skills as a programmer and tastes as an action game designer.

Variant Gunner has 2 main inspirations, the greater of which being Radiant Silvergun, a shoot 'em up that I had beaten prior to development, and Alien Soldier, a run 'n gun with a heavy emphasis on boss fights. With the time allotted, I wished to make a similar, though truncated, experience to Radiant Silvergun, but with a greater boss fight focus. I like the push-and-pull that boss fights provide, as well as the prospect of exploring boss fight design in my own game!

What Went Right

Variant Gunner gets the fundamentals right. The controls are tight and responsive, and the player has a reduced hurtbox size, both contributing to a fun bullet-dodging experience.

What Went Wrong

Three weeks seems like a lot of time to make a game, but for my experience level at the time, coupled with my obligations for other classes, the time allocated felt like a commodity.

The primary issue with Variant Gunner is the game's lack of polish. Unexpected enemy behavior can occur if the player dies on Level 2, and the boss hurtboxes are still active during death. Shooting the bosses during death leads to a massive score increase.

From a design standpoint, I would've liked to include one more enemy type. I think my original rational was to lend more of my focus towards the boss fights, but it would've made the levels feel more varied.

What I'd Do Differently

The main thing I'd do differently is attempt to polish the game more. I was limited on time, however some features should've been scaled back in order to support the structural integrity of the game.

Mini-Postmortem (Deluxe, Nov '24)

It was nice going back to the project and refactoring the code with newer sensibilities. Variant Gunner was the first project where I used composition in order to facilitate code reuse, and while this made the code base much cleaner, the entities still did a lot of heavy lifting when it came to utilizing those components. Now, with the refactor, the entity code is much more lightweight, acting as the glue for all its components.

There were many small things that I tried to figure out while developing the original but couldn't, such as homing bullets facing towards their targets. Because of this, they always faced up. In the Deluxe version, this was fixed, and many other bugs, such as missing enemy spawns, and boss damage after death have been fixed.

Variant Gunner stands as one of my proudest solo projects, and the Deluxe update is one of my proudest code bases.

Power Forsaker

Play Code

Power Forsaker is a team project developed for GMTK Game Jam 2023. The theme was "Roles Reversed", and we came up with the concept of a player that loses abilities as you progress, rather than gaining new ones.

(scroll down for postmortem)

As a programmer, I:

Created the player controller and abilities, including

jump
double jump
wall jump
ground pound
dash
glide

Developed the Ability Forsaker UI

As a designer, I:

Composed a team of 5 Drexel students
Drafted the "ability loss" concept
Crafted the player's initial moveset
Mapped out the level the game takes place in

Skills:

C#
Game Design
Version Control
Communication
Teamwork

Tools:

Unity
GitHub

Postmortem (Sep '24)

Power Forsaker is the first 2-hour game jam that I and many members of the team have participated in. On top of that, most of the team had obligations to juggle alongside the jam. With all considered, I think we've made something to be proud of.

What Went Right

The biggest strength of Power Forsaker is its ideas. When given the theme "Roles Reversed", we divised the idea of a reverse metroidvania, where you lose abilities rather than gain them. Even abilities like the basic jump were fair game, and this concept of ability loss still has potential for a full puzzle-style game designed around forsaking the right abilities to best conquer certain obstacles.

What Went Wrong

Power Forsaker's biggest weakness is execution, and there's no one more at blame than myself. There are glaring flaws with the game that I could've (and should've) addressed before jam submission.

The character and abilities don't feel as good as he could to control. Ideally, the player should feel empowered, which would make the process of removing abilities much tougher.

From a level design standpoint, I should've made a longer intro for the player to really take advantage of and get used to the abilities present, so that the full weight of forsaking a double jump for instance, would be present.

Moreover, the game is too hard, with precise jumps and other obstacles tough to navigate if you aren't the developer of the video game. To clarify, my disagreement with the difficulty isn't the high difficulty itself, it's where specifically the difficulty arises, and obtuse solutions to obstacles that border on control exploits aren't good sources of difficulties.

What I'd Do Differently

I can't speak for the other members of the team, but for my part, if I could do 3 things differently, I'd,

give greater focus to the feel of the game,
make the game easier to complete, and
dedicate more time to polish.

Castle Conquerors

Play Code

Castle Conquerors is a solo project developed for Mini Jam 134 Islands². With the theme of "islands" and the restriction of "on a grid", I create a game where the must collect coins to spend on units to defeat an opponent with the same goal.

(scroll down for postmortem)

As a programmer, I:

Created the player controller
Developed the opponent and unit AI using ovstacle navigation
Programmed the UI

As a designer, I:

Designed a game where coins must be collected and spent to conquere a castle
Melded action with strategy

Skills:

GDScript
Game Design
3D Workflow

Modeling
Texturing
Rigging
Animation

Vector Illustration

Tools:

Godot
Blender
Inkscape

Postmortem (Oct '24)

Castle Conquerors was made for the 134th Mini Jam. I has 72 hours to ideate and execute. The game marks my foray into strategy blended with real-time action. I cannot pretend this was the plan going in; in typical jam fashion, the ideation process was very loose. Even so, I am quite proud of the result, and hope to incorporate more strategic elements in my future action endeavors.

What Went Right

This long after its original making, my memories on the ideation stage of Castle Conquerors are hazy. One of my major inspirations was Clash Royale, which can be seen in the map design and the win condition of destroying your opponents tower. I'm not quite sure where the coin collecting and spending on statues came from though.

I think the idea I came up with was creative and I executed it in a clean, organized fashion. There was no final hour scramble.

What Went Wrong

The biggest flaw with Castle Conquerors is the difficulty. I didn't want to make a game that players would beat on their first try, so I tuned the game so that it would be a sufficient challenge for me. This resulted in a game that many of the jam participants were unable to beat.

The heart of the difficulty lies in the artificially intelligent opponent. My original rational was to make an opponent that had better stats than the player character (speed and aversion to mistakes), so that, in order to win, the player would need to make better decisions. The issue is that the AI wasn't dumb enough. The AI's decision making caliber is very similar to that of the average player. The result is a better opponent. The game itself doesn't present many options for counterplay besides trial and error, leading to a frustrating experience.

What I'd Do Differently

As aforementioned, I had less than 72 hours to think of the idea, and create the graphics and code necessary to fully express it. There are a few small things I'd spruce up with more time, but from a design standpoint, the main issue stems from the difficulty of defeating the AI opponent.

If I ever make a "Deluxe" edition of Castle Conquerors (as I have done for Variant Gunner), I would change the AI so that its stats are closer to the player character's. I'm still not sure if I want them to be equal, but a speed nerf would most certainly be employed. In addition, I'd like to decrease the AI's intelligence. For example, just like the player can fall into the water, I'd like the AI to occasionally do the same, in order to mimic human error, and give players more of a fighting chance.

Rodeo Armada

Play Code

Rodeo Armada is a team project developed for Drexel's GMAP 260 - Overview of Computer Gaming. As a team of 7, we created an infinite runner + run 'n gun hybrid, with an alien attempting to escape futuristic cowboys.

(scroll down for postmortem)

As a programmer, I:

Created the player controller and UI

As a designer, I:

Planted the "infinite run 'n gun" seed
Chose the 3 collectible weapons and default starting weapon
Came up with the name

Skills:

C#
Game Design
Version Control
Communication
Teamwork

Tools:

Unity
GitHub
Visual Studio Code

Postmortem (Sep '24)

Rodeo Armada was the first group project I worked on at Drexel. To this day, it's the second largest game development team I've worked in. It was a learning process, at least for me, but I think the end result was a good game, and a great school project. We were given ~5 weeks, the latter half of the 10 week term, to make the game.

What Went Right

I'm not quite sure how the idea came about--I believe we were discussing making an infinite runner--but I somehow came up with an infinite runner mixed with a run 'n gun. Even now, I wish I had better methods of formulating creative sparks.

What Went Wrong

We had issues with weapon balance during playtesting, but even with the changes we made afterwards, the weapons don't do enough to aid the player over the default pistol. The pistol gives you maximum contol over height and direction, with no downsides besides having to mash to rapidly shoot. The other weapons come with their own quirks that make enemy dispatching less efficient than the default weapon. I think a good solution would've been for the alternate weapons to have no downsides besides limited ammo. After a certain amount of shots, the weapon would return to default. This could add more value to the weapons and make them more desirable for players.

What I'd Do Differently

I think for my part, I helped devise a novel enough game idea, and the character is tight and responsive. However, I think I could've discussed some aspects of the game's design with the team a bit more.

Hello! I'm Joshua Walcott,

Games

More games

Experience

Full resume here

Skills

Contact

polygonalcube@protonmail.com