A month ago I didn't know this was going to happen, but I made High Tide.

Here's what I did over the two weeks of My First Game Jam: Summer 2021.

Game Engine

I don't know how to code. I've retained some knowledge of HTML from the early Myspace days, but that's about it. The first step to deciding which game builder to use was predicated on the fact that I needed a super basic, visual scripting kind of program. I tinkered with RPG Maker MV some years ago but was quickly overwhelmed by how complex it could get. As a beginner in anything, embracing limitations is the best way to flex creativity.

GB Studio got on my radar and it was love at first sight. Chris Maltby created a delightfully simple game builder and even packaged a small demo project you are free to try out, manipulate, or disregard completely. The community that's sprouted around it is pretty robust and helpful, too. GB Studio is FULL of limitations and that's precisely what I needed; Starting out somewhere simple and familiar was the best way to build confidence in trying and failing at something over and over again.

Take a look at GB Studio here, or here.

I'd also recommend checking out GB Studio Central for some good tutorials and excellent resources.

When deciding on what kind of game you want to make, really look at what you're comfortable failing at. The secret really is the comfortable part in that statement. There will inevitably be problems you run into and if it isn't fun or at least interesting, you're gonna get fed up with it real quick and move on to something else. Showing up again and again, I found, is what gets a game built.

Concept

My imagination has gotten me into trouble in the past. It's colorful, complex, and frequently looks a lot like something attainable that's actually not. I have so many ideas in my head that it can feel impossible to even write one down on a sticky note. For High Tide, the concept for the game began with what I was capable of building. In this case, I was able to quickly throw together a "shoot-em-up" style level in GB Studio and work from there. I knew I wasn't going to be able to create new and inventive mechanics for my first game, so best to stick with tried-and-true gameplay and find creativity in the art. 

I liked the idea of taking the concepts of space shoot-em-ups like Gradius or Darius Twin and putting them underwater instead of in space. That idea set the entire foundation for High Tide. This was where my imagination started running, building a story arc, characters, lore, politics, and so on.

I'm very familiar with the sensation of an out of control concept, which is what I was feeling after about 45 minutes of brainstorming.

I stopped, had a beer, and watched Empire Strikes Back.

There's this part in Clerks (stay with me a sec) where the character Dante is arguing with his coworker, Randal, about how Empire Strikes Back is superior to Return of the Jedi. It's classic. Go watch it, if you don't know what I'm talking about. Anyway, Dante bases his claim on the fact that the movie is a series of down-notes, a reflection to what life, in his opinion, is. Now, I agree that Empire is superior, nay the best Star War, but not just because of the "down-notes." The tension in that film never lets up. Every time there's a problem, it only gets worse! The tension keeps building to an epic crescendo and releases only for a few, scattered moments so we can catch out breath. 

That's the thing!

I then made this list of story beats I could use as level concepts.

Some of this didn't make it in the game in its original form, but here's the breakdown:

• Level 1 - Set tension
• Level 2 - Raise tension
• Level 3 - Raise tension, again
• Level 4 - Boss fight climax!
• Level 5 - Maintain a little tension till the end

With that, I had the roadmap I wanted. Then it was time to get my proverbial hands dirty.

Scrum

You can read more about this unfortunately-named concept elsewhere, but since you're here, I'll tell you that it's a method of development that focuses on empirical evidence and understands that the problem(s) you will face cannot be fully understood or defined up front. Therefore, the project is rapidly created over several, quick iterations, each building on the strengths of the last one and doing away with the weaker aspects. This is the widely adopted method of game development we see used today.

As a one-person team, I adapted to this concept by making my game, start to finish, as best I could, in a day. Each day I would repeat this process and add more layers to the game. Early stages had no artwork, challenging me to make cohesive gameplay without the aid of sound or visuals. It's there where a lot of things got left out or scrapped entirely.

I had intended for the game to be one part shoot-em-up, one part platformer. The platformer aspect was scrapped when I found it didn't match the feeling I wanted of being in a small, cramped submarine. Changing it to top-down allowed me to flesh out the world more by adding interactive items to help fill in details. This mode also created the change of pace I desired to give the player a moment to catch their breath and do a little exploring.

As I learned more about how to build levels and create interactive elements, I was able to quickly and continually make changes with each iteration. A nice side effect was that I accepted the project was never going to be perfect, but it'd be better than the previous build. The small, incremental steps of continual improvement is something I usually struggle to recognize. I know the phrase "Rome wasn't built in a day," and understand the reality that things take time, but actually experiencing that feeling is different from knowing about it.

As quickly as possible, I wanted to make sure I could make a functionally playable game, start to finish. Having something that worked well enough meant I could spend the remaining majority of time on art, text, and music.

Continued in part 2...