Unfortunately, this project was put on the back-burner by management until the project was eventually scrapped. I absolutely would have loved to have seen this project through to completion, however, sadly, it just wasn’t meant to be.
However! There is a dim light on the horizon… There’s a possibility that I will pursue a personal gaming project in the future and will continue posting game dev updates under a new project name. Thanks for coming along with me on this journey.
Well, yeah. Trust me, I was fully anticipating an essentially non-stop flow of updates regarding Light Quest, but unfortunately, that project has slowed down a little bit. Just because we’re so far “ahead” with it, there’s no budget for it because we’re working on it outside the fiscal year. Anyway, keeping the spirit of gaming alive, I’ve decided to take on a new personal project in the meantime.
This concept, I’m very proud to say, came from my 5 year old son, who wrote this idea down several months ago, so there’s actually a very good chance he had the idea when he was 4. The idea was born when he drew out some lilly pads on a piece of notebok paper and explained how they rotate in different directions and the frog has to jump from one side of the pond to the other. I’m still desperately searching for the original drawing, and I’m posive I took a picture of it, but it’s not turning up anywhere.
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 furniture 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.
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.
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.
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.
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.
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 😀
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 ended 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..
Yesterday I began work on the first (of many) pixel art character designs that will be featured in the upcoming Light Quest arcade game. After some initial research, I found several pixel artists that recommended starting with a silhouette when designing a character. This achieves several things. First, it helps you create an iconic character that would be easily recognizable by its shape alone. It also helps create a clean design to help better feature the main attributes of the character. In the case of Light Quest, the main character named Willow, is a young girl around age 12 who is almost always seen wearing a pair of roller skates. So in the silhouette, I wanted to make certain that you were able to make out the fact that she was wearing roller skates.
In addition to beginning work on the initial character designs, I also began work on designing the various elements that will ultimately comprise the “Level Select” screen. This will be presented as a map of the town that Willow lives in. The icons that represent each level are a house, a pizza shop, a warehouse, a forest, and a lighthouse. The ground of the map (dirt paths, paved roads, sidewalks, and grass have yet to be developed, but will likely be designed separately. The idea is to have a top-down version of Willow’s sprite that will walk up, down, left, and right in order to ‘choose’ the level. Once Willow enters the level, it will switch to a side-scrolling platformer-style level design.
I feel like it took me a long while (maybe around 2 days, while not working on it all the time) to get close to the design as present. My biggest pitfall was actually just starting! Once I had a few blobs put down I was able to make several iterations before I got stuck. After that, I just did the entire process again. Just put a few different blobs down, got a different main shape, then made a few iterations before adding color. All in all, I thought it was really fun! I’m looking forward to creating more characters in this new (to me) style.
Yesterday I managed to compile Aseprite for my Linux laptop so I could officially get started with the game. I’m going to tackle pixel art graphics first because it will help define the look of the game, the style of the artwork, and color palette. Once all (or most) of the pixel art graphics are created, then I can begin work on the actual programming. This is still the extreme early stages, so there are still a lot of specifics yet to be discovered about how the game will eventually look and feel.
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!
When selecting a person, object, or character to create in your pixel art, one of the first steps is deciding how much detail you’re willing to lose, and where those losses of detail occur. If you’re creating a car, what’s the smallest detail you want to make out? Do you want to have a license plate visible? Readable? Once you’ve decided on that level of detail, create that smallest detail and work your way out from that detail. But also keep in mind that, depending on which detail you choose, that will impact your next most important decision when starting out.
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.
Again, Brandon has been a huge help in teaching me the basics of pixel art and how to get started with the sizing and scaling of the characters in the screen space. Just for everyone’s reference, I’ll leave you with this excellent video on the subject.
After watching several videos on the topic of pixel art, researching some of the artists in the top of my search results, I decided to make the leap and change up my graphics creation strategy. For me, personally, it took quite a bit of time to figure out how to compile the software from scratch (because I had to compile some of the dependencies as well), but without further ado, here we go.
I started off like normal, I guess, cloned the repo, and got to work inspecting the files, README, INSTALL, etc. I went through the process for several minutes only to find out that my version of CMake (installed like sudo apt install cmake was several versions behind the minimum requirement. I ran cmake --version only to find out that I was running version 3.10 when the minimum requirement is 3.14. So if you already have CMake 3.14 or above, you can skip this step. Otherwise, here’s how you update.
First off, you’ll want to get rid of any old versions of cmake by running sudo apt remove cmake. After that, head over to https://cmake.org/download/ to grab yourself an updated copy of cmake. I ended up downloading the source code and building from scratch, but that’s not completely necessary because there are several pre-built binaries available as well.
This one’s pretty straightforward. Just make sure you have git installed and run git clone --recursive https://github.com/aseprite/aseprite.git
The next step is getting all of the tools required to build Aseprite. This can be found in INSTALL.md
This is the very first step in INSTALL.md. There are step-by-step instructions inside that pertain to every operating system. Just be sure to read them carefully! This is the part where you install cmake, but just be extra sure to check your version by running cmake --version. If you don’t have version 3.14 or higher, refer to step 0.0.
Just to reiterate, the command to install all your dependencies in one go is sudo apt-get install -y g++ cmake ninja-build libx11-dev libxcursor-dev libxi-dev libgl1-mesa-dev libfontconfig1-dev again, just make sure to double check your version of cmake.
This one was a little tricky because this dependency wasn’t actually covered in the dependencies install command from step 0.2. It very well may be because Skia is actually a graphics library made available by Google, and thus, not available on traditional linux repositories. More information on the Skia project can be found at skia.org.
Inside the INSTALL.md file that you got when you cloned the aseprite repository, there are some notes regarding the moment you run cmake. You have to run it from inside the build/ directory (which you’ll need to create), and you will need to define where you have either compiled or decompressed your copy of Skia. The example directory (the default defined in the provided cmake command) is $HOME/deps/skia/ or something similar.
You can either compile skia yourself using the step-by-step guide provided by the team at Google, or, conveniently enough, the team behind Aseprite has a precompiled binary just for you! All you have to do is drop it in your $HOME/deps folder and continue with the steps to compile. Aseprite’s precompiled binary of skia can be found at https://github.com/aseprite/skia.
Once you’re done cloning the repository, you’ll want to go inside it with cd aseprite. Next you need to create a folder to build your files inside of, since builds inside the source aren’t allowed. mkdir build && cd build/.
The basic syntax of cmake is cmake [path/to/source/containing/CMakeLists.txt] [OPTIONS]. So from inside your build directory, you’ll need to define the source (one folder up). Then from there, you’ll need to tell cmake where your skia files are. More information on this can be found in the INSTALL.md file
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DLAF_BACKEND=skia \ -DSKIA_DIR=$HOME/deps/skia -DSKIA_LIBRARY_DIR=$HOME/deps/skia/out/Release-x64 -DSKIA_LIBRARY=$HOME/deps/skia/out/Release-x64/libskia.a -G Ninja ..Almost there! Once you’ve build all the files using cmake, and you didn’t encounter any errors, congrats! You’re almost there! If there are any more errors to come (in my experience) they’ll be on this very last step. The last command in INSTALL.md is ninja aseprite. That will actually start the build process and end up spitting out an executable binary that you can launch once everything is finished running.
./aseprite and enjoy your fresh copy of Aseprite!
So funny enough, I started writing this post well over a year ago. I’ve been wanting to learn Godot Engine for a while now, maybe 2-3 years. I ended up becoming intrigued with Godot when I was looking for a solid open-source game engine that was available for Linux. Godot was the first result that popped up, and there were a ton of really cool games that were created with it! Having the ability to deliver your final game to a fairly large variety of platforms was also a huge plus.
Being able to deliver to the Android platform was also very appealing to me. The only thing that deterred me from actually setting out to learn Godot Engine was the fact that it was built on a proprietary language called GDScript. Many developers praised the language for being easy to pick up and comprehend. Personally, nothing sounded easy about learning a new language. At this point, I had a background in basic web languages HTML, CSS, and JS. The trick was, GDScript is actually closer to Python than anything.
Speaking of Python, another language that had come up on my journey over the last several years. Blender is a powerful 3D animation platform built on Python, but I’d never taken the time to learn the Blender API to create plugins for myself. Regardless, on a whim, I took a free “Learn Python in 12 hours” course on YouTube. After I learned how Python is completely different language than JavaScript, I was able to take that knowledge (mostly about white space and formatting) and apply that to GDScript.
Flash forward about a year or two, I still had this post on draft, but I’d released two games already! Both written with Godot. I had a blast learning the absolute basics of game design and development, and I don’t regret a thing. Moving into the web design space has afforded me to learn a TON, and bringing fun stuff like Godot along for the ride makes tackling projects even better.
Check out Godot for yourself at godotengine.org, download the latest version, and make something awesome!