Al.One – A GameJam Game


17 days ago Adrian Rodriguez prodded the team a bit to consider a GameJam. The topic was “spin” and Adrian already had a great idea for a concept. We had used Unity on a previous project or two which got pushed aside, Adrian had released Squishy Finger Frenzy, but as a team we had never released a game.

The Title Screen of Al.One

Taking Dave Zokvic’s advice we went with a low-fidelity prototype to start testing things. It was perhaps the most visibly anti-climactic game, but it gave us the ability to get things working without tripping over complicated physics or aesthetic choices. That probably smacks a lot of us in the face, because we want games to be visually pleasing. But I promise, we would have tweaked 3D models for hours if we hadn’t done this.

The only exception here is that we had a good idea of what we thought the ship would look like, and it was basic. So instead of creating a low-fidelity model of a basic ship, we just built the ship. The crystal formations took all of 10 minutes each and gave us some items to test the weaponry against. They’re based on cubes.

Early game visuals

The scenery was an easy expansion, too. Since we had a basic set of crystals, we just scaled and rotated them randomly and spread them out over the visible space. That makes things interesting, too, since it won’t always be the same. This played into things later when we started working with enemies.

So from there, we started on the weaponry. Originally we used capsules, which would spin and throw-off the physics. It looked a bit like floating Tic-Tacs.

Bullets flipping into space

When we changed to orbs, things started to stay more consistent.

Using orbs as projectiles

With that we needed moving targets and threat of death. So the quickest thing to do was to add the enemies as white cubes. We dropped in four spawn points and let them spin up enemies every so often. Those enemies had a simple directive to walk to the place where the player was sitting.

A square box used for enemy testing

Enemies seeking the center

In the earlier iterations the enemies slowed down as they approached the player. That resulted in some really strange occurrences. Like this imaginary-wall scenario where the enemies just would not cross some unknown space.

Enemies stopped along an imaginary wall

During testing, we noticed that by shooting one of the crystal formations the enemies would progress again toward the player. That often meant you’d get swarmed by droves of enemies.

Enemies swarming the player

That just meant we needed to tune the colliders so that the enemies wouldn’t hang up on tiny crystals the player couldn’t even see.

But with consistent enemies, we swapped out the cubes for 3D modeled spiders and centipedes. To date, the spiders don’t really have names. But we call the centipedes “replicators” or “splitters”. Here we put the cart ahead of the horse in early development phase. We knew we wanted the color of the orbs to matter, so in early calculations Dave recommended that shooting the replicators with the wrong orb meant they’d split. The problem was, when we wrote the code we hadn’t yet allowed orbs to assign color-based damage. So it was “game over” every time a replicator showed up. The more you shot it, the more it split and then caused damage.

Replicators splitting at the player

After getting color damage figured out, we moved on to bonuses. To collect those from across the screen, Jeff recommended a tractor beam dynamic. At first the bonus types were hidden, so you didn’t know which of the 6 bonus types you had just earned. To make it a little more comical, at first the tractor beam was invisible. So you had to hold down shift to pull the bonuses, which you didn’t know you could do, and then when the bonus landed on the player, you had to perform an action to use it that you didn’t know existed either. We fixed that with a yellow particle system on the tractor beam.

The tractor beam

The added effect there was that the yellow color gave us a neutral color to use elsewhere. Health bonuses, for example, aren’t assigned to red, green, and blue colorations. Yellow was perfect here.

After that we needed a way to show when a bonus had been collected. Some of them were associated to color, others weren’t. In the end, we only used two out of six bonuses so that we could release something of quality and test bugs.

There’s also a hidden weapon that isn’t always usable. Your ship charges over time and then, when it’s available, it quietly sits there until you hit enter. When you press enter, it discharges and then recharges again. In a later iteration we’ll probably show the charge visually. It also deals out color-based damage based on whatever color you have selected at the time. That’s great if you have a blue replicator on the screen, for example, but bad if you have two replicators of different colors.

For the sound effects and music side, we wanted to create things that blended well, and then also didn’t get annoying with the thousands of blaster shots you fire per game. The goal of the sounds was to present them as if you were in the ship. So you don’t ever hear enemies dying outside by design. The sound we made for the orb is a highly effected piano tone, playing a C. The tractor beam sound is a serious blend of pads that we reverbed to death. For the shock damage we used the same idea as the tractor beam but distorted it quite a bit.

The music was written entirely for this project by Light the Deep and Franco Lezameta.

We hope you enjoy Al.One. It was a lot of fun and we learned so much in a short amount of time.

Want to know when we release games or need testers?

Sign up here. No spam or sales-pitches, ever.

* indicates required

About Northward Compass

Founded by David Brooks in 2010, Northward Compass is a small, distributed design shop that claims Orlando, Florida as home. We specialize in dynamic, interactive, and modern web sites, applications, and games.

© Copyright 2010 - 2019 Northward Compass. All rights reserved.