I cut my Alpha down to a Beta
After my last blog post, it hit me: the year is half over, and I was still adding new features to my main project (still working on a new name for it). So, I re-examined my project against the goals I set for it:
Make something simple.
Make something quickly.
Make everything except the game engine and audio myself.
Make a complete game.
Release it before the end of the year 2020.
I've removed the goal of necessarily charging money for the game once it's finished. The platform I'm going to release on, Itch.io, has an optional payment option that I'll probably use instead. Still, I'm not expecting to make much (if any) money.
The reasoning behind this is straightforward: I want a 30 second timer in my game, and I don't believe I'll have time to add unlocks or other incentives for repeated play.
I've wanted a timer in my game ever since I decided on the endgoal: Get to the end before your lover dies. However, for most of development, I couldn't decide on what the timer length should be. 1 minute? 5?
Until recently, I planned for up to 5 bosses to be in my game. Additionally, I'm planning on there only ever being 5 levels total: a starting area, 3 randomly selected levels from a larger pool of pre-constructed options, and a 5th final area with a bossfight. Within this structure, a 1 minute timer that stopped when you reached the final boss seemed most appropriate.
It was the 5 planned bosses, with the potential complexity they would add, which caused me to want at least 1 minute for players to experiment. However, it's on these 5 bosses that most of my time was being spent. And, only 1 was finished. So, I decided to cut every boss except for the one that was finished.
My pool of monsters and traps to learn is small, and there is no barrier in levels to keep players from rushing through everything to get to the end. Given this, with the removal of all but 1 boss I decided I wanted to focus the player on speed over doing everything. This is a cheap way to try and force interesting choices, and it's usually not a good design decision when made from desperation or a need to cut content.
I still plan to stop the in-game timer when the player gets to the end. So, I need a timer that is long enough for the player to get through 4 levels, but just short enough to force the player to move quickly. If 1 minute was necessitated by random, complex (comparatively), and unskippable boss fights, it seems reasonable to me to find the new time by cutting 1 minute in half. 30 seconds it is.
With the timer decided and all but 1 boss cut, I realized I'd implemented essentially everything my game will require. So, I now consider the game to be out of Alpha and into early Beta. My next steps are 5:
Create new, 1 color, simplified sprites and animations for every object in the game.
Create multiple tilesets.
Find basic sound assets.
Compile art, sound, and game assets into a basic playable version to beg people to try.
Create a side project to learn how the Godot UI layer works.
Wait, wait, what was that last one?
It's an unfortunate truth that I know very little about implementing UI (menus) in Godot. This is a big problem, as I'd like to present the player with sound and input settings at the very least. So, I've started a new project called Shoplifting Godot.
This new project is not an original design, thankfully. I'll be attempting to recreate a game from 1979 called "Shoplifting Boy" in Godot, and I've selected this game for 2 reasons: It's one of the simplest games ever made (though it was advanced for the time, I'm sure), and I've never created a decent design for a stealth game. There's plenty you can learn just from seeing Shoplifting Boy in action, but I'm curious if there's more I can learn through the remaking process.
I learned about Shoplifting Boy completely by accident thanks to YouTube recommendations:
My next post (9/6) is on track to be part 1 of an overview of Shoplifting Godot, and should be the release date. Assuming nothing pops up to impede my progress, of course.