PRESENTING  . . . VOID GALAXIA

Player Movement

The player ship’s movement is based on the Rotation code by Batu Orhanalp:
https://blog.batuorhanalp.com/how-get-rotation-data-from-siri-remote-on-apple- tv-73d2698dbb10. This code uses the gravity variable in the remote’s motion property and calculates the rotational difference between it’s current gravity and the previous gravity. The game uses this rotation calculation to determine how fast the ship moves, with the maximum speed being at a right angle (90 degrees) from center, with an 8 degree “dead zone” in the center of the range where the ship does not move at all.

Due to the difficulty of precision movement with the motion controls, I added in a brake button to freeze the ship in place, making it easier to make precise movements to evade in- between enemy bullets.

Enemy Movement

Enemies use a sequence of SKActions to determine how they move. These are built using an array of a custom class called a MovePoint, which contains:

• the point to move to,
• the time delay before each movement,
• either the time it takes to get to that point or the speed in which it moves,
• whether it speeds up or slows down, and
• moves directly or curves.

The setMovement() function contains 3 variables:

• a static movement (done once),
• a (possible) repeating movement, and,
• if there is no repeat, whether or not the enemy dies at the end (for enemies that leave the screen and don’t come back).

I had originally used “move here” points to decide how the enemies move, but switched to “move by this much” points, as it was easier to write certain movement patterns (a straight horizontal line always being x: ###, y:) instead of having to remember what they value of the enemy was at that point).

Player and Enemy Hit-Boxes

The player ship, enemy ships, and bullets all use the physics body code with matching category/collision bit masks. I used:

• 1 for the player ship and anything that can hit it
• 2 for the player bullets and enemy ships – to determine collisions.
• (all gravity/collision effects of the physics bodies were disabled since they were unneeded.)

While everything else has a physics body matching their sprite, the physics body of the player ship was made very small on purpose, to allow more difficult enemy patterns without making it impossible.

Player Targeting System

I want the player to be able to focus more on avoiding enemies instead of worrying about shooting back. So, I made a crosshair that can move with the trackpad on the Apple TV Remote, that “lock-on” to enemies and makes the player-ship shoot automatically. This was done through the use of SKPhysicsbody, as well. I gave the crosshair the same bitmask as enemies, and then – if it was not locked-on or moving – check if any enemies are overlapping with the physics body of the crosshair, and lock-on to an enemy if it was.

I also added a “priority” variable on enemies, where the crosshair would lock-on to enemies with the lower priority value first. This was to make it easy to target the first enemy in a line, and then move down the line as they all died.

Initially, the physics body of the crosshair ( the range in which it could find enemies) was about the same size as the crosshair itself. This was too small and made it hard to focus on some enemies, which defeated the purpose of the lock-on function in the first place. After experimenting some with a “laser targeting” system, where the ship would shoot-out a laser and find an enemy that hits that instead, I eventually decided to triple the size of the crosshair’s physic body, allowing it to catch enemies from much farther away.

Enemy Shooting System

As the main point of the game is to have enemies with ridiculously complex shot patterns, this went through an equally ridiculous number of revisions before I was happy with how it worked.

First the bullets themselves. I created a protocol called, “Shootable” which lays the groundwork functions and ensures that bullets have everything they need to work properly. Also, this protocol allows classes outside to work with a generic “shootable” class, that doesn’t need to worry about how the various types of bullets work.

One step up from the bullets is the Volley class. This contains a group of bullets and any information pertaining to how it is fired:

• how many times it is fired
• the delay before/after
• the time between shots
• differences in angle between each round

After that is the ShotSequence class. This is just a double array of Volleys, a sequence of groups. Each inner array is fired simultaneously, and after they’re done it moves onto the next array.

Then the Gun class. This determines how often the sequence is fired. Or, the sequence can be applied to a bullets nextStep variable, and will be fired from the bullet when its (optional) duration is up.

The current system was made in order to make the very last portion of the final boss possible.

Menus

The menus were made using Xcode’s Sprite Kit Scene Builder (.sks files.) The words were made using the VCR OSD Mono Font (online download), which is royalty-free. The menu controls were made with UIGestureRecognizers.

I added a screen when the game first starts up to hold the remote sideways since the first menu controls that way.

Sounds

I composed the music. The sounds in the game were created using either GarageBand with the magical-8-bit plugin and a USB Keyboard, or BFXR.net. They are played by SKAction playSoundFileNamed() in-game.

The music is played by a global AVAudio player. This was necessary to be persistent between scenes. During the transition between scenes (fade-ins, etc.) technically both scenes are present. In order to have the music stop at the beginning of the transition and play at the end, the music needed to be stopped, and the next song to play set, on the incoming scenes didMove(toView) and played on the outgoing scenes willMove(fromView).

Sprites/Images

I drew all sprites and images using the Aseprite sprite-drawing program.

Bugs, Glitches, and Performance

There were quite a few bugs and errors. One of the more annoying bugs was that the collision box for laser-type projectiles became very inaccurate. I had to fix this by re-drawing the collision box each frame instead of simply stretching it – it doesn’t seem to have affected performance noticeably.

On performance, I had to limit the update function – which gets called 60 times a second at its best – to look through the number of objects onscreen only once. This was done by creating the protocol, “Updateable.” Anything that needed to be altered each update had that protocol added to it, and the GameScene could request an update on each object “as? Updateable” using Swift’s optionals to ensure that only the objects that actually had the function would try to update.