Arcfest was a side project I worked on in high school. It was a top-down fighting game where you fought against another person to knock them out of a shrinking safe zone. It was pretty fast-paced — a single round typically lasting less than thirty seconds, and a full match hovering around three to five minutes.

I thought the concept was an interesting spin on a fighting game, though it was more of a tech demo then anything else. I worked on it on-and-off — normally during the evenings. I probably could've spent more time on it longer, but I was working on another game at the time, so I felt like my brain would've fried if I kept up that workload.

I've always wanted to make a sequel to it — with a little more time and love poured into it... so I did!

The game is playable on the web, so if you haven't tried it out, you can check it out here:

https://johnrcd.itch.io/arcfest-2

Alternatively, you can download a Windows build. The performance is notably better, and there's some quirkiness with the WebGL build (some sounds don't play).

engine selection

The original intention for Arcfest II was to have it be developed on the Godot game engine. Around the start of the year, Unity got a ton of flak for creating a "pay-per-install" system, where developers would have to pay Unity for every install (a metric that had no reliable way of being determined). The change didn't affect me directly (and they did eventually rollback some of their plans), but there was a movement to phase out the Unity engine for game development and look into other alternatives — predominantly, Godot and Unreal.

I'm pretty attached to Unity (big fan of C#), but I figured given the type of games I like to make — relatively simple 2D action platformers, normally with a retro-like feel — could be made on just about any half-way decent engine.[1]

Long story short — that didn't work out.

Honestly, I hate doing tutorials, and unsurprisingly — attempting to work on a Godot game with my main source of knowledge being a partially-finished video tutorial was not going to cut it.

I think Godot is a fine engine, but learning it for the sake of avoiding Unity meant that I was constantly comparing both. The entire time I was doing stuff in Godot, a part of me was always thinking "I could probably do this faster/better in Unity," which was a terrible motivator.

Eventually, I just accepted that I wasn't going to get my vision of Arcfest II down if I kept trying to learn Godot, so I just went back to Unity. I'd like to say I'll learn Godot properly at some point, but at this point I'd sooner switch to a code-only framework than a full engine.

development

My main goal for development was to keep the same gameplay from the original, but with a layer of polish to make the experience better — upgraded art, sound, music, etc.

I also wanted the code to be a lot better, but there was a three year gap between the development of the first and second game — I'd be a lot more worried if my code wasn't already better by default.

pick your own ships!

In the game, you choose from a selection of four spaceships before the match begins. It was mostly done on a whim since I made four spaceship sprites instead of two, but it ended up being a benefit for me, since it gave me an oppertunity to work on a problem I hadn't encountered before:

Character customization!

Okay — It's not really character customization, more like character selection. The only thing you can do is choose a ship, but the point is that the I had to dynamically generate the spaceships based on what you chose in the match selection screen. The actual work wasn't too difficult, but there were definitely more problems to solve, and a decent amount of time making sure I wouldn't regret whatever system I ended up implementing.

There's no perfect solution, but I'm pretty happy with what I had:

  • There is a SpaceshipBase object that includes all the logic that every spaceship will have.

  • Stored in the game directory are SpaceshipData files that house the data for individual ships.

  • For every new ship, the data regarding the ship a player wants to use is provided (SpaceshipData). The Spaceship then processes the data, updating itself based on the new changes (adding ship sprite, updating movement stats).

  • Lastly, a ConfigurePlayer function is called with the player ID of the player who'll be using the spaceship, which will allow the player to control the spaceship.

There's probably a better solution out there, but I think it isn't bad, all things considered. At the very least, I have stuff spread out if I ever want to expand on anything.

(non-playable ships...?)

(probably not)

music

The original game effectively only had one music track — a fighting track that plays during the actual match.[2] It had a bit of a manic, goofy vibe — something you'd hear on a retro console like the NES, or something. For this game, I wanted to go for something a bit cooler, more intense — stressful, maybe.

Track 01: Technobabble (Main Menu)

Technically, Technobabble is the only song I made for the game. The other two tracks happened to be created beforehand. I just used them because they sounded good.

The main goal for this track was just to build hype and energy when a player first loaded the game. I had been a part of a game jam earlier[3] in the year, and while the game itself was relatively light-hearted (a game about a bee), I ended up making the music pop off, with overdriven guitars and a rock organ that blasted as soon as the game loaded.

It was kind of absurd, but I figured the same idea of immediately building hype would work better for Arcfest — just, less guitar and more synth.

Track 02: Infiltration (Gameplay)

This track was one I developed from a small project focused on creating cool 3D movement, similar to Mirrors Edge, but more gamified and less realistic.

The game never came to light (I am lazy), but the whole idea was to play as a guy put into suicide missions and somehow always make it out. This track specifically was about an infiltration gone wrong, and going up floor by floor in a skyscraper to escape.

Track 03: Resolution (Match Results)

I wanted to make a song that had a lot of fast notes, because it's ear candy.

That's about it.

i hate missles

I've dedicated a whole section to the missles because they caused me a lot of grief for completely avoidable reasons.

For around a full week, most of my effort was spent trying to fix the homing missles. There were a bunch of small things that I had to figure out or consider.

Just for fun, I'll organize it as a bunch of bullet points representing my (roughly chronological) thoughts:

part 1: standard coding stuff

  • Each spaceship has it's own light trail — it makes sense that the missles should have them too.

    • Arcfest I had different light trail colours for the missles, so we should make the colours separate.
  • Wait, where do we store these colours?

    • The spaceship metadata should probably include colours.

    • Wait, it's not just colours — it's whole Gradients.

  • why do the missles only fire upwards

    • I'm going to ignore this for now
  • How am I supposed to have the missle trail colours change?

    • (insert two hours of brainrot)

    • Okay so the Spaceship component at the root of the SpaceshipBase prefab should tell the MissleAttack component that it received Spaceship metadata and it can have it, which then sends a message to every new Missle that "hey you need to use this trail colour" which then needs to be passed directly to the trail component

part 2: descent into madness

  • ok I should fix the missle movement for real

    • (looks at Brackeys tutorial) what is a cross product

    • wait why are we using 3D math for a 2D moving missle??

    • screw this i'm using a different movement system for the missles

  • missles should be good

    • tl;dr: they were not

    • okay why are the missles doing complete 180 turns that's not how missles work

    • what if i just set their speed to a constant value

    • why are they moving AWAY FROM ME

      • authors note: i had the missles target the shooter directly because i hadn't implemented player spawning yet
  • (1 day of being terrible of math)

  • where is the original code for Arcfest

    • oh nice it's on github

    • it doesn't have the missle code because i switched to Unity Collab oh

    • unity collab is deprecated

    • screw it i'm going back to brackeys code

  • back to square 1 — missles always shoot straight up before doing the homing thing

    • i hate everything

part 3: salvation

  • I should probably watch the tutorial instead of copy pasting the code.

  • (figures it out)

Normally I like to code stuff myself because it's more fun and I have a better understanding of what I'm doing, but occasionally I don't do that and severely regret it.

testing

Arcfest is a casual game more than anything else, but since it's still a fighting game, it was important that the game felt fair and balanced. I also wanted to see what the game would look like in a competitive setting (or, as competitive it was going to get when I was asking two of my friends off-handedly).

nerf defense!!!

Spaceships in the game have four different stats:

  • SPEED: Top movement speed.
  • THRUST: Acceleration, basically.
  • HANDLING: How quickly can the ship turn.
  • DEFENSE: Knockback reduction.

I took a page from Brawlhalla, giving each ship a fixed amount of points that they can allocate into different stats. Because this was the only thing that could be changed between ships, it was important that each stat point was equal to another.

Immediately during testing, it was obvious that this was not the case.

Without contest, defense was so ridiculously broken that I'm surprised I didn't catch it sooner. Basically, defense gave percentage knockback reduction. Each point of defense added a flat amount onto your percentage, and the amount that an individual point gave was way too high. The difference between the lowest and high defense spaceships (3 and 8 points, respectively) was a whopping 25% in knockback reduction (15% to 40%).

NOTE: I'm editing this post in the future for version 2.0 of my blog, and I realized that this system means that each additional point of defense was stronger than the one before. For example, adding 1% of defense doesn't mean much when you have zero, but going from 98% to 99% means that your knockback is cut in half.

(Appearently League of Legends game design can be helpful.)

In a game like Arcfest, knockback reduction is always going to be one of the strongest stats because it means that it's harder for you to take damage. You use the same weapons as your opponent, with the same damage and knockback values, so the stat that gives you an edge in combat will always be useful.

I ended up going all in and cutting the effectiveness of defense in half. Even that didn't seem to be enough so I tuned it down a bit more later.

other stats

There's not too much to say about the other stats in terms of balance because compared to each other, they were fine. Part of that was because individual stat points felt unnoticable, so I did end up buffing them when I nerfed defense.

SPEED was not very important, because Arcfest is not a racing game. As long as you can outrun the missles — which you always could, even on the slowest ships — there wasn't much of a need to get faster.

HANDLING was probably the second most useful stat. Missles had a wide turning radius, and fast turning meant you could more easily juke them.

THRUST was interesting because it ended up functioning as a multiplier for HANDLING and DEFENSE. An increase in acceleration allowed you to better juke with your turns, but it also meant that you could recover faster from hits.

domain clash

One thing I like about competitive games is the jargon that the community develops overtime. The one that stands out to me is Overwatch (the main game I've been playing recently), where a lot of official terms are scrapped for more direct/implicitive word choice — Baby D.Va instead of Pilot D.Va, Sigma's Suck instead of his Kinetic Grasp, Lucio's Beat instead of his Sound Barrier, and so on.

Arcfest does not have a competitive community whatsoever (or any community lol), but when my friends were playtesting the game, they noticed that spaceships dashing into eachother cause significantly higher knockback for both parties than if only one person dashed. Since they're big fans of Jujutsu Kaisen, they called it a domain clash.

It's a small thing, but I thought it was cool.

I also ended up keeping it because it did look pretty sick. (Although, I had no idea what was causing it so I wouldn't have been able to fix it even if I wanted to.)

retrospective and future plans

I'll probably continue to work on Arcfest on-and-off inbetween projects and random life events.

The game was produced for Winnipeg Slow Jam 2024, but now that that has finished, I can expand my plans a bit more beyond simply improving the experience of the original game.

Some things I have in mind:

  • New playable spaceships!

  • Ability to choose a weapon before a match.

  • Different maps to play on.

  • Release the game soundtrack on Bandcamp + Spotify + (insert music streaming services here)

  • Three player combat?

  • Four player combat???

footnotes

  1. Unreal was the other popular engine on the table, but I didn't want to learn that for two reasons: I don't know C++ (and Blueprints seems kinda meh), and it's tailored for Triple A game development. I want to work on cute/fun 2D (probably pixel art) games, so it didn't look that promising for me. ↩︎

  2. Technically, Arcfest had two music tracks (not just one) — the results music, but you couldn't even hear all of it even if you wanted too. Also, if you only checked out the game through the gameplay trailer, you wouldn't even hear it, because I didn't have the song added into the game yet — I just slapped on the beginning of Glide by Stephen Walking. ↩︎

  3. The game is called Beelieve I Can Fly. You play as an ant that wants to fly, and attempts to do so by whacking bees into the ground to propel themselves upwards. ↩︎