Today was an incredible day. Over the last several weeks, I have been in touch with with a gentleman who owns a company that rents, sells, services, and deals with arcade machines, slot machines, ATMs, coin pushers, pinball machines and more. It’s a very cool business and his company provided and maintained the arcade machines that are on the Van Dyke campus of Grace Family Church. He recently caught wind of our arcade-centric project “Light Quest” and almost instantly offered to help with the project.

After I had reached out to him and explained a little bit about what I was trying to achieve, he didn’t even hesitate to generously donate an arcade cabinet to help get us started with the project. Once we’d set a date, I drove down to his warehouse and got the grand tour of the entire property. It was filled with all kinds of arcade games, pool tables, slot machines, pinball machines, ATMs, all in various stages of completion. It was amazing to see all the hard work and dedication put into these fascinating machines and got me all the more excited for our very own arcade cabinet build!

Once I’d picked my jaw up off the floor, it was time to actually load up the cabinet I’d come by to pick up. I was unsure of what to expect, as the original offer was a “blank cabinet”, so I’d prepared by bringing along some furnature blankets and some ratchet straps, just in case I’d need them. I also wasn’t sure if the cabinet would be built to a point where it’d be sturdy enough to transport, or if it’d be a brand new Ikea-style in a flat box I’d have to assemble back at the office. After I had speculated all possibilities of what a blank cabinet might look like, the word was given, “Oh, hey- just give him that Galaga machine over there!”

By the way, before I go any further into the story, I just want to take a minute and point out these awesome workbenches. It was so cool seeing all of the parts from original arcade games all laying out on a table with manuals and instructions on how to put everything together! All the soldering irons, tiny screwdrivers, and specialty tools were absolutely awesome to see.

Enter: The Project

Obviously, this one had seen better days, but this was one heck of a head start (and an EPIC cheat sheet) on our very own custom arcade cabinet. Coming up next, we start tearing this cabinet apart and start rebuilding it from the inside out.

Last weekend, I realized I was spending a lot of time focusing on the artwork and visual design of the game. It had been a while (months) since I’d coded anything and even longer since I’d coded a game in Godot. So in an effort to knock the dust off, I decided to enter a 72 hour game jam.

Anyone will tell you that’s virtually zero time to do any sort of game, and that’s true. You’d have to scrap all things fancy and focus on just the bare necessities. A simple character design, a simple enemy, maybe some projectiles, and that’s it. Anything beyond that in 72 hours is icing. Oh, and the other thing- this game jam had a limitation that would be announced at the beginning of the jam. It could be anything from “must be beatable in 10 seconds” to “cannot use gravity”.

I was already nervous about the jam itself, because the jam is already difficult, and I’m coming out of a long coding hiateus. So the closer the weekend got, the busier it got. I already had a dentist appointment scheduled, so I knew that would take a chunk out of my time, and then I ended up having a few video shoots land on that weekend as well. By the end of it, I really only spent about 5 or so hours on the game.

Hour 1

The jam began around midnight local time and the limitation revealed was “cannot take place on Earth”. So my mind immediately went to the classic arcade game “Space Invaders”. I went to work creating the player spaceship. I ended up spending 10-15 minutes on this design.

Next up, I went for the easiest one. I needed some sort of bullet for the player to shoot, so I went with a simple white rectangle. That took about 10 seconds. Next, our player needed some bad guys or aliens to shoot. I took about 20 minutes on the alien ship design, and actually ended up liking the enemy ship design more than the player ship… Maybe I should have switched their roles and used the enemy ship as the player ship. Maybe next time.

Next, I wanted to get these sprites into the game enginee and give them some basic movement. To do this, I imported the sprite into Godot and promptly burned 30 minutes looking for how to turn off the image filter. The filter is enabled by default, which makes small sprites come out blurry in the game engine. Definitely needed a refresher on this one! Once I found the hidden check box, I was ready to dive into the code. I just used the default direction keys that are predefined in Godot. I lifted a little script from the Godot docs to acheive basic left, right, up, down, and diagonal movement.

Once I had basic player controls up and running, I needed to get him shooting something. Next, I imported the bullet sprite, and attached a script to it that told it to travel up on the y axis at a fixed speed. Once that was done, I saved the bullet as a scene so it could be instantiated in the game as many times as I needed. The only problem that remained was getting rid of it. If I fired 20 million bullets over the course of my gameplay, the game would run great at first, but eventually, the engine and/or device would hit a limit and wouldn’t be able to process 20 million bullets continually moving through the game on every frame refresh (on screen or not). So to fix this, I gave the bullet a 3 second timer, connected it to the script, and when the timer expired, the bullet would execute queue_free() or remove itself from the game.

Hour 3

Now it was time to set up some basic rules in the game world. I wanted to fire a bullet when I hit spacebar, it flies up the screen, and if it overlaps with the collider that’s attached to an enemy spaceship, then delete both the enemy space ship and the bullet that hit the spaceship. That code was injected into the bullet object, so each bullet is looking for an overlap. So each time it overlaps with something, it checks if the name of that object is “Enemy”. If it is, then it will set itself to be invisible, stop moving upward, make an explosion animation visible, play an explosion sound effect, and play the explosion animation… then after 3 seconds the whole thing gets deleted regardless if it hit an enemy ship or not.

Hour 5

After lots of trials and errors, I finally ended up with a somewhat playable… something. It’s not really a game because there’s not way to keep score and no way to actually win or lose the game. If the enemy ships contact the player, nothing happens. If the player shoots an enemy ship, it blows up, but there’s no score or anything. So it’s pretty much an infinate shooter with no score.

Also, before I forget! When I was creating the script for the word, I didn’t want any enemies or bullets to already exist in the world. I wanted the enemies to just show up randomly (from the top of the screen, flying down toward the player) and bullets to appear when the player hit the space bar. So to do this, I saved the enemy ship as a seperate scene so I could instantiate it whenever I needed it. I attached a timer to the world scene to expire every 1 or 2 seconds ( I forgot how long, but it was defnintely expiring every 3 seconds or slightly more frequently). Every time the timer would expire, the world would instantiate a new enemy ship somehwere at random just above the screen, so they would start flying down into view.

TIME’S UP, PENCILS DOWN

Here’s what I ended up walking away with. And more importantly, along the way, I learned how to export a Godot project as a Linux executable for the first time. Previously, it had only been HTML exports. So yay! Speaking of which, here’s the HTML version:

CONTROLS:

Arrows keys move up, down, left, right, diagonal

Space bar to shoot.

Make sure you click the game before you play it, so it will know to recognize your inputs are for the game, not for typing 😀

Blocking Out The Initial Run/Skate Cycle

I have to admit, starting the animation cycle was pretty intimidating. Especially when I’m staring at a nearly finalized version of the main character. Luckily, I came across a tutorial that got me an EXCELLENT head start on creating the run/skate cycle. I ended up just creating a new project file to begin the animation cycles.

The tutorial I followed was actually doing a common run cycle, but for my use case, I needed to convert it to a “skate” cycle, since WIllow will be skating through all the levels of the game. After doing some initial research on roller skating in an effort to find a profile video of someone skating past the frame. Unfortunately, I was unable to find a video of that specific skate cycle reference, so I just neded up modifying the run cycle from the tutorial to a skate cycle.

First I started out by importing a copy of the character sprite into a smaller canvas for scale reference. Then I created a new layer for the head and 8 new frames. I started bobbing the head up and down in a “running” motion. Next, I created a rough forearm shape and swung it back and forth. Next the lower legs, upper legs, upper arms, and torso. Once all the body parts were connected and felt like they were making the appropriate running motion, I started to modify it. I ended up sliding the legs more rearward to give the impression that the weight was resting on the front foot for slightly longer as the body was sliding forward. The resulting animation is still pretty rough and will likely change, but I think it’s an okay start. I’m going to try to enter a 72 hour game jam this weekend, but I’m not sure how I’ll do because my weekend just piled up with outside work. We’ll see how it goes!

Running into the weekend like..

Learning a New Pixel Art Form

One of the most helpful sources for learning this new pixel art thing has been Brandon James Greer. His videos have been insanely useful for learning the basics of pixel art and changing the way you approach creating new art. Please give that guy a subscribe!

Select the Smallest Detail That You Want Visible

Select Your Canvas Size

Depending on what your ultimate goal is, this one might actually be your first choice. Knowing which resolution to design in will ultimately impact the amount of detail you can realistically include. In my situation, I’ll be using my pixel art to animate walk/run/jump/idle cycles, and create spritesheets and tilesets for a retro inspired arcade game. With that in mind, I’m using the original resolutions of classic console hardware as a starting point for my designs. The NES console’s resultion is 256×240. With that information, I can start designing my character within the context of the entire screen so I’ll know just how that character will look and feel within the space of the entire screen.

Reference For Getting Started