Freshly Squeezed Progress Report: Laying Down the Groundwork

Last week, I reported that I was trying to fix some long-living and annoying infrastructure code and continuing to find reference art for the look and feel I wanted for this second Freshly Squeezed Entertainment project.

I did not accomplish what I set out to do, but I did get started, and I continued this past week.

Sprint 4: Pre-production and initialization

Planned and incomplete:

• Finish initial design document
• Create save file
• Create player character
• Create [redacted] environment layout

Last week, I started making changes to my menu code because the existing code required a lot of seemingly extra work to create a menu, and I knew I could simplify it. I ended up reverting those changes, but then tried a different approach, and I’m pretty happy with the results.

I replaced all of my game’s existing menu code with the new version, which wasn’t too much effort, and it felt so much easier to spin up a menu. And since my game will need more menus, and my future games will also have menus, and I’ve been dealing with the existing code for too many years, I think this was a good use of a few hours.

Of course, I’m not trying to make just menus. I’m trying to make a game. And so the next order of business was to get from the menu to starting a new game.

I decided to start by creating a save file. I have used yaml-cpp in the past, and it works well enough. But I’ve been using an older version, v0.5.3, for a long time, and the compiler has been warning me about deprecated functionality, so I decided to upgrade to v0.7.0.

And besides no longer needing to depend on the boost library anymore, this new version seemed to be a good drop-in replacement. I had no changes to make in my existing code.

But I was still getting warnings, this time from Google Mock. As someone who test-drives his code and otherwise enjoys having automated tests as part of every build, I have been using the same version of Google Test/Mock for many projects, but it looked like it was time to update to a new version. Instead of using the latest, though, I wanted to use a version that still allowed me to create a build using a Docker container with Debian Jessie, mainly so that my game should be compatible with as many Linux-based systems as possible. So I upgraded to Google Test v1.11.0, because apparently anything newer relies on a version of CMake that Debian Jessie doesn’t have yet.

And all of my existing tests continued to build and pass, and now I have no warnings when I compile.

So now that my project’s infrastructure is updated, I could get back to the task of creating that save file.

I believe that Toytles: Leaf Raking was my first game with persistence, and the way it worked was that you could always pick up where you left off or you could reset and start a new game, but there was no way to have multiple saves at the same time.

I didn’t include persistence in my first Freshly Squeezed Entertainment game Toy Factory Fixer, but I did have a contract game that I worked a few years ago that did have multiple named saves.

And so I know what I need to do to allow the player to create, delete, and otherwise manage multiple save files at once, but I found myself getting stuck right away. Frankly, I didn’t want to work on this seemingly simple thing with a lot of moving parts. At least, not yet, especially because there is no game play to worry about wanting to save progress for in the first place.

I realized that this was an opportunity to narrow my scope a bit. Instead of spending time on allowing the player to input a name for a save file and to load a named save file, what if I hardcode it for now? So you get one save, and your option is to either start a new game or load an existing game. I could always add multiple saves as a future change.

Then I felt stuck again. From experience, I knew I wanted to give my save data a version number, which will allow me to make development updates and load older files.

But what else can I save at this time?

Putting on my game producer’s hat, and my hindsight is 20/20 glasses, I think I had the order of operations wrong in terms of what to work on next. I probably should have worked on the main player’s character first.

The main player character is ultimately going to be customizable. Not only can you give the character a unique name, but you can give them a nickname, assign pronouns, and choose a portrait.

So at the start of a new game, you could name your character, pick a look, and change a few other options.

And once I had that functionality in, THEN I would have had something to save.

So there’s a note to my future Self and to any aspiring game producers: wait until you have something to persist before you work on persistence.

As it stands, I have a menu that can get me into the start of a new game, but nothing interesting to do once you’re there.

Outside of the planned work, I also continued to create doodles and even experimented with drawing the 1st-person view. Perspective can be tricky, and since I am trying to mimic the look of early 2D, 1st person games, I was trying to figure out how to draw each “tile”.

Basically, how big on the screen should each tile be? How many tiles can I see ahead and to the sides? Where do I draw the edges of each tile?

One thing I tried was to create a 9×9 grid of squares, then on a screen with some lines to indicate the single vanishing point, I tried to use a perspective tool to see how the grids would look on the floor of this simulated view.

The results were OK. I couldn’t use the actual vanishing point with the Uniform Transform Tool, and if I tried to get close, it looked completely wrong. But if I only used the horizon defined by that vanishing point, then I got something that looked reasonable.

I’m not sure I’m too happy with it, but it is a start, and I can already picture using something like this to help me draw a world that looks like it fits together. It was a neat experiment, but it isn’t something I need to worry about working on yet anyway.

Side note: I titled this post to refer to all of the infrastructure updates I did above, but now it looks like I had planned it to be a pun about this floor tile experiment, but it was a complete accident that happens to work well.

For now, I need to focus on implementing the player character and getting the player to do something with that character.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking, Toy Factory Fixer, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!