The Last Raiders

An accessible, asymmetric take on the 2D fighting game genre.

Comment 4

Inspiration

We noticed that all of our brainstorming discussions seemed to concentrate around one single premise: how can we make something not only fun but also deeply meaningful?

Two of our teammates, Ilya and Leon, grew up playing a myriad of fighter games. They noticed a few common themes amongst their favourite titles that our game sought to improve upon.

Accessibility: mechanical and financial

Most fighter games are designed with an, avid fanbase audience in mind. This meant games were often shipped with obscure combo sequences, frame-perfect dodge mechanics and multi-button directional input modifiers. These mechanics allowed for thousands of hours of repeatable fun, but posed an extremely steep and inaccessible difficulty curve for casual players. On top of that, these games often posed a significant financial barrier to casual players: they are typically listed at $40-100 AUD per title, in addition to being specifically designed to run on expensive gaming hardware and consoles (costing anywhere from $500 to $2000).

We wanted to design our game with the casual player specifically in mind.

Asymmetry: experience and numbers

Another problem we noticed with typical fighter titles was their assumptions about player symmetry: they're traditionally designed to be played one-versus-one. The titles implicitly assume that the competing players are evenly matched in skill, so that the fun from the game comes from the back-and-forth between equal rivals.

In reality, however, we know this isn't always true. Firstly, in real-life gaming scenarios, there's often an asymmetry of experience. Some players have grown up playing fighter titles and have deeply memorised the most effective combo sequences and timings. Other players are completely new to the fighter genre and are only familiar with the basic controls. This often creates structurally unbalanced scenarios, where one player consistently wins against another - which significantly degrades the core mechanism of enjoyment in the genre.

Secondly, there could also be an asymmetry of player numbers. All is well when two players are enjoying the game - but what if the friend group is a trio? The traditional solution is to have two players active and the remaining player spectating; while some groups may also coordinate player rotations according to a specific protocol, such as "winning player stays on", "rotate turns after 10 minutes" or "randomly swap after 3 rounds". These are reasonable compromises, but they don't fix the core problem - that the 3rd player is essentially excluded.

We wanted our game to embrace this asymmetry within player groups and create genuine enjoyment alongside, rather than against it.

How we built it

We decided we would use a game engine to ease the overall development process, allowing us to write higher-level code without having to worry about low-level logic and processing. This led us to GameMaker, a a free-to-use (but proprietary) development environment made specifically for 2D games.

GameMaker gave us an integrated pipeline of sprite management and code editing. It offers both a visual, node-based way to write scripts, as well as using the domain-specific language GML (GameMaker Language) for faster iteration and modifications to code.

For hand-drawn visual assets, we drew them via Piskels, an online pixel art editor.

Challenges we ran into

Projectile handling and physics

With projectiles in-built into the design of the game, we needed a systematic way to simulate them. We encountered one of the core technical limitations of GameMaker: it was a fundamentally sprite-based engine, which only exposed low-level draw functions for rendering. That is, most of the code we needed to write involved "draw X at Y position on the screen". This meant that we had to hack together a rudimentary physics engine ourselves - and brushing up on our knowledge of VCE Physics and classical mechanics, we manually tracked velocity and acceleration variables for each projectile.

Sprite-work

Drawing and animating the sprites was a significantly time consuming part of the hackathon. The pixel art style of our game had the drawback of needed to express as much detail in as little pixels as possible: and so often we would need to extensively go back and revise sprite animations until they were aesthetically coherent.

Low-level UI Drawing

GameMaker offered no built-in UI framework - every element on screen had to be constructed manually through raw draw calls. This meant that something as simple as a health bar required us to explicitly calculate its pixel dimensions, position it relative to the correct player, and redraw it every frame in sync with the underlying game state. Any desync between the game logic and the draw layer would result in UI that visually lagged behind what was actually happening.

Since we wanted the game to run across different display configurations, hardcoding pixel positions was very risky; instead, we had to express UI coordinates relative to the viewport dimensions and ensure elements scaled and anchored correctly at runtime.

In GameMaker, fonts also had to be explicitly imported and configured as assets rather than referenced freely, which made dynamic text more difficult to implement than we initially anticipated. Getting consistent alignment and sizing across different text elements required a lot of trial and error.

Collision edge cases and bugs

Tunneling

At high projectile velocities, an object could move far enough in a single frame to skip entirely past a collision boundary. From the engine's perspective, the projectile was on one side of the wall at frame N and the other side at frame N+1, having never technically occupied the same space. We resolved this by implementing a step-based sub-tick interpolation pass for fast-moving objects, breaking their per-frame displacement into smaller increments and checking for intersections at each step.

Hitbox persistence

Our attack animations were tied to sprite frames, and we initially triggered hitboxes at the frame level. This created a window where a hitbox could "linger" for a frame longer than intended if the animation was interrupted - causing hits to register visually after the swing had already ended. We introduced explicit hitbox lifetime flags that were invalidated on animation cancellation, regardless of frame state.

Edge-of-platform interactions

Players standing at the very boundary of a platform would occasionally clip slightly below the surface before the ground collision corrected them upward, creating a single-frame visual stutter. Tuning the collision resolution order - checking floor collisions before lateral ones - largely eliminated this, though it required us to reason carefully about the sequence in which different collision types were evaluated each frame.

Accomplishments that we're proud of

  • By the ~44 hour mark, our game was fully functional with no major bugs in the engine.
  • The asymmetric multiplayer mechanic - the core design bet of the whole project - genuinely worked for us during playtesting. We were able to have hours on-end of fun - and sometimes, to take a break from development, we would play The Last Raiders together.
  • Our hand-rolled projectile physics held up throughout. Given that we had to implement velocity and acceleration tracking from scratch without any engine support, having it feel responsive and consistent during play was a real technical win.
  • We had time to significantly polish the UI, which given the low-level constraints we were working under, felt very meaningful.
  • We managed to get all the pixel art assets drawn and shipped in time for the hackathon's conclusion - a relief, given how time-intensive the sprite work turned out to be.

What we learned

  • We ended up rebuilding our definition of "fun" from the ground up - and trying to lean into the nature of player asymmetry rather than planning against it.
  • We learnt several quirks about GameMaker internals and game development design principles that prevent these quirks from turning into bugs.
  • We learnt to narrow down the scope of our project to the time limit. Initially we had a lot more assets planned and were even thinking about multiplayer functionality, but given the labour-intensive aspect of asset creation, we decided that the final version of our project was also the best balance between ambition and feasibility. ## What's next for The Last Raiders We will continue active development of the project, with aspirations for this game to hopefully become fully-fledged and releasable to a game marketplace in the future.

Built With

+ 23 more
Share this project:

Updates