Category: Geek / Technical

In last week’s report, I started work on figuring out how to implement a simple raycasting engine for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I tried to continue the work this past week.

Sprint 11: Pre-production and initialization

Planned and incomplete:

• Move player in dungeon view

The short version is that I once again spent much less time on game development than I would have liked and so no, it isn’t finished yet.

The long version is that I was unable to dedicate time to game development partly because my family needed to spend time on figuring out how to protect our trans daughter from Iowa Republicans who recently passed bills and got them signed into law that prevents her from getting the care she needs in our state.

Besides those pains, I’ve also been dealing with literal pain in my back and my leg that has made it difficult to do much of anything, including sleep.

Meanwhile, any effort I was able to expend was spent on trying to understand the example implementations of raycasting that I’ve found so I can create my own implementation.

Most examples you find are either academic in nature, and so bizarrely all of them tend to have terribly short, non-descriptive variable names and other issues, or they are written by someone who is mainly focused on explaining the concept and so isn’t trying to setup the code’s design for anything more robust.

So while I could just copy the code and see if it works, and then adjust accordingly, I prefer to make sure that I understand what I’m trying to do. Sometimes I can replace a data structure with another. For instance, I have a Point class that is basically meant to be an position represented by X, Y, and Z values, so there’s no reason to have separate floating point values for X and Y like in many examples because I could always use a Point.

Or rather than make a very long function with a bunch of random variables everywhere, I can isolate some of the calculations into functions.

And rather than assume that I’ll be rendering from the point of view of the player’s party, I could instead make it render from the point of view of an arbitrary location, which leaves the possibility of scripting scenes or following a different character or object.

But frankly, the lion’s share was finding out that I was setting up some camera vectors incorrectly, and so while I expected the rays would always hit a wall, somehow it was escaping out of the defined dungeon grid cells and and so my code was entering an infinite loop as a given ray was not able to hit a wall at all.

I stopped the infinite loop by ensuring that a request for a grid cell that wasn’t defined returned something that indicated its walls were considered “out of bounds” instead of no walls, so the rays would hit something, even if I don’t intend to render “out of bounds” walls.

But I was still figuring out why some of my rays were hitting the “out of bounds” walls instead of my actual walls when I got to the end of the week. At least I can say that half of them seem to hit actual walls, although I haven’t looked to see if those walls seem sensible.

I really hope I can make the time to get this work finished enough to render the walls. I can’t wait to maneuver through my dungeon.

And I really hope that my daughter can grow up and live a long and happy life.

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last week, I reported that I was working slowly to build up the 2d-simulating-3d art and math to represent the dungeon for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

This past week I got a suggestion and decided to explore a different approach.

Meanwhile, there are mere hours left in my “reverse sale” for my leaf-raking business simulation strategy game Toytles: Leaf Raking. Soon it will revert to the regular price, so either get it now or get it later. Your choice, and thank you for your support either way. B-)

Sprint 10: Pre-production and initialization

Planned and incomplete:

• Move player in dungeon view

Much like the previous week, I did not get to spend as much time on development as I would have liked. Between the Iowa legislature making life tougher for the most vulnerable, some home improvement projects, and my back hurting me potentially due to those home improvement projects, it’s been tough to make time to sit down.

A few weeks ago, one colleague suggested that I simply use an existing 3d-engine instead of trying to create a 2D tileset. Thanks for the suggestion, Ken, and I apologize that I will ignore this otherwise very sensible advice.

As I said last week about why I insist on ignoring this advice:

Because I’m stubborn, maybe. I wanted to try it, and now I’m in the middle of it.

I know 3D would make a lot of this work easier, but switching to 3D would mean needing to switch to an existing game engine, something I’m not ready to do because then it means abandoning my many years of code that I’ve built up. Maybe I’ll think about it if I am still trying to figure this dungeon rendering effort weeks from now.

But it’s fun to figure things out, and that’s part of the reason why I like doing it the hard way.

Well, in response to last week’s report, another colleague suggested that I look into making a simple raycaster.

Thanks, Joel Davis, aka joeld42.

I had originally looked up how to mimic the look and feel of 2D 1st person RPGs from the 80s and 90s, and I found Reddit posts and forum posts in which people basically said, “You COULD do it this very difficult and time-consuming way, OR you could use a 3D engine and fake the old look.”

And people would also throw in raycasting, much like how Wolfenstein 3D and Doom’s engines worked, but I didn’t pay much attention because I didn’t want to make a real-time 1st person game.

But Joel said “Doing it in 3d in your own engine, whether a raycaster, a simple SW renderer, or regular 3d with opengl or something, doesn’t need to be that hard, you can keep it simple” and followed up with “You should try it, it’s fun and super simple. I’d say it’s less work than the approach you describe in the blog post.”

He also sent a link to this neat tutorial and web demo: A First Person Engine in 265 Lines by Hunter Loftis

So I downloaded it, toyed with it, and changed some parameters and values to get a sense of how the code and math worked, and I also played with the demo, which impressed me even when I disabled the lightning and rain effects. It was fast and looked pretty good.

There are quite a few raycasting tutorials out there, some of which I read a long time ago, and some of which are new and I read this past week.

I particularly enjoyed Lode’s Computer Graphics Tutorial: Raycasting and the follow-up on rendering the floor and ceiling, which helped me triangulate an understanding of what Loftis was describing in the other tutorial linked above.

And I also loved reading about this voxel space demo.

What I liked was the idea that instead of needing to generate multiple images to represent a single wall or floor tile, I could have one image and let the raycasting engine handle making it look like it is being seen at an angle for me.

And what I especially liked was that the math and technique seemed straightforward enough to implement.

As I said above, I did not spend much time on development this week, but what I did do was prove to myself that I could modify my code to render the walls in vertical strips the way a raycaster would.

So here’s how my in-game hardcoded hallway demo looks when I have separate tiles for the back wall and the side walls:

And here’s how it looked when I rendered the back wall and side walls using the same image but drawn with vertical slices:

Ignore the fact that I didn’t get the floor or ceilings in. I think you can hardly tell the difference between these two renderings. The second image isn’t raycasting. It’s hardcoded much like how the demo above is, in that I render the side walls until I hit the end of the hallway, then I draw a back wall.

Remember, though, that second screenshot shows me using only a single image for the wall, rather than separate images for the side walls which are a little clunky and awkward to create. I could easily throw in a different image and have a new wall tile that can be rendered in three ways without me needing to modify or create even more art.

Even if I don’t implement a raycaster, this technique of rendering vertical slices of an image looks good AND reduces my art-creation effort. It also means that my game download will be a lot smaller and take less time to load.

I could even get creative with both how it grabs portions of the source image and how it renders to the target location to perhaps create certain effects.

But I think I do want to implement the raycaster code. I want to be able to render walls seen from the sides, not just the direct hallway in front, and I want to be able to turn and have the code manage rotating in space with no extra effort.

And while I could use an existing engine and not need to implement any code to handle it at all, I don’t want to use an existing engine. I have my own code that I’ve been building up for years, and creating a raycaster using it seems like it will be quick, easy, and enjoyable enough. And being able to do things with my existing code is why I have existing code.

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In last week’s report, I talked about the math and art of drawing the dungeon areas for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

This past week I continued working on the dungeon representation.

Sprint 9: Pre-production and initialization

Planned and incomplete:

• Move player in dungeon view

I was out of town and visiting with family, so I did not put in as much time as I could have, which meant not getting as much done as I was hoping to by the end of the week.

To create a simple dungeon map, I needed to finish creating the data structures to represent the dungeon. This work was the easy part.

I had a grid-based dungeon, so naturally grid cells would be the basic building block.

If I wanted to keep things simple, I could have had each cell represent either an empty block of hallway or a solid block of wall. Zero or one, and I’d be done. Maybe use different numbers to represent different types of walls or hallways.

But I wanted more flexibility. Each grid cell is made up of four walls, a ceiling, and a floor.

So instead of drawing the outside of a grid cell in the simple version, I would need to draw the insides of the grid cell.

I anticipate needing a companion tool to create the dungeon layout as this game develops, perhaps using something like Tiled, but for now, I just need to give myself a simple dungeon, so I hardcoded one.

Old games used 2D trying to simulate 3D because 3D wasn’t viable on the older computing power they were using. Today, the advice to make similar games is to use a 3D engine and try to replicate the 2D feel.

And this past week, I started to really get as sense of why that contemporary advice exists. Just to have a single dirt tile for the floor, I determined that there is no way to get around needing to create that same tile from different perspectives.

In this screenshot of my art mock-up in GIMP, the yellow dotted square can represent the player’s viewport. To create the left side floor tile, I had to extend the dimensions of the canvas left and right. Then, just to see how far it goes back to the horizon, I kept shrinking the new side tile by about two-thirds. There is a back wall that I placed as a representative for the player’s maximum visibility.

Many 1st person games show a dark dungeon with visibility extending only a few tiles ahead, which gives a great atmosphere but also has the practical benefit of limiting how much art needs to be created to represent it.

For me, I think I determined that I can scale the art in code and get the same effect, so I only need to draw the tiles that are in the nearest row. No need to create separate tiles farther away, because scaling will handle it for me.

But because I want areas of my game that might be well-lit and provide greater visibility, I need to create a lot more tiles that are seen from the side than I would if I followed the tradition, mainly because those tiles could be seen in the distance. So instead of maybe one or two tiles to the sides, it looks like I’ll need to create quite a few more.

And that’s just one tile! To break up the monotony, I will also want to create variations on that tile.

And I would still need the ceilings and the side-views of walls. Perhaps I can simplify the art needs by creating modular aspects of the floor, ceilings, and walls, so I can have one generic piece of art that gets covered by brick outlines, chunks of rock, smears of dirt, etc in different locations to give the appearance of a variety of art.

But I will work incrementally, and so for now I just want to render floor tiles. One tricky thing I needed to figure out was to figure out exactly which cells are being rendered in the first place. The player can be in an arbitrary location in the dungeon, and so “forward” is relative to the player’s orientation.

Basically, I would need to figure out which cells to render and where on the screen. A cell to the left of the player would need to render tiles that are in the correct perspective, which means knowing what perspective that cell should be in. Turning around would show that same tile in a different perspective, or not at all.

Again, 3D engines have solved these problems so that they are a non-issue, so why am I doing it this more difficult way?

Because I’m stubborn, maybe. I wanted to try it, and now I’m in the middle of it.

I know 3D would make a lot of this work easier, but switching to 3D would mean needing to switch to an existing game engine, something I’m not ready to do because then it means abandoning my many years of code that I’ve built up. Maybe I’ll think about it if I am still trying to figure this dungeon rendering effort weeks from now.

But it’s fun to figure things out, and that’s part of the reason why I like doing it the hard way.

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last week, I reported that I was creating a house and basement, and I hinted at a location outside of the house in this Freshly Squeezed Entertainment project.

Since I officially announced that this project is called The Dungeon Under My House, I can now say that I’m building a dungeon. And yes, it will be under the house that I’ve created.

Sprint 8: Pre-production and initialization

Planned and complete:

• Create dungeon view with ladder back to basement

Unplanned and incomplete:

• Move player in dungeon view

The Dungeon Under My House is going to be a grid-based, 1st person role-playing game, and instead of working in 3D, I’m going to use 2D art simulating 3D much like games from the 80s and 90s.

Because I wanted to make things harder on myself apparently.

Unfortunately, I am not an artist by trade, and while my programmer art is decent enough for most of my purposes, I am already realizing that I have a lot more work than I initially thought.

In January, I made this sketch:

It was mainly to help me figure out what kind of art I would need to create.

Specifically, I wanted to have the ability to make each location in the grid look unique enough to be a mini-landmark. For instance, you might have a bunch of walls painted the same color in your home, but maybe the wall in your hallway has a pockmark, a nail hole, or even a drip of dried paint in a certain location that you would be able to recognize as belonging to that hallway’s wall.

Creating a single tile to be the floor wouldn’t get me there, and creating a handful of different tiles to add variety would only get me so far.

Instead, I want to create the floor out of a modular set of mini-tiles, so that I can mix and match. I could even render some of the mini-tiles at a slight angle to make them look like they are breaking up. Maybe it will work? I probably should do more mock-ups and tests.

But for now, I needed to render a single location: the spot right under your basement. It needs three walls, a floor, a ladder, and a ceiling. I’ll worry about mini-tiles in the future.

If you recall from a few weeks ago in Freshly Squeezed Progress Report: Laying Down the Groundwork, I was toying around with Gimp’s Uniform Transform Tool to see if I could get a good sense of how the art needs to be laid out to make it look like it is vanishing into the distance.

It looked…OK?

Well, now I needed to actually make something in game as opposed to mocked-up in an art program.

So I took a castle wall texture that I found on OpenGameArt, modified it slightly to give it a more sketched/cartoony look, and made a couple of skewed versions for the side walls. I made the ceiling a little shorter than the floor, mainly so that it wasn’t a boring perfectly centered horizon line.

And it looked fine except that things weren’t really lining up well when I coded something to render this art.

It was really obvious when I started trying to render a long hallway as an experiment, and I could see gaps between the walls as well as the fact that the walls didn’t line up at the top and bottom.

Basically, my math to figure out where to place the art wasn’t working, and it was breaking the illusion.

So I spent much of the last week figuring out the math for the placement of any particular wall segment based on the distance from the player’s viewpoint.

Skip ahead if you want to ignore the math.

The original wall art is 1024×1024. I created the side art at 256×1536. That is, the side wall is a quarter of the width and 1.5 times the height of the back wall.

With the back wall centered horizontally, that means that attaching the side walls on the left and right add another 50% of the width.

I want to be able to render the dungeon in an arbitrary viewport, something that could be potentially customized by the player. So I’m not hard-coding these dimensions, which is something I see in a lot of other games.

So, given an arbitrary viewport’s dimensions, I wanted the wall one tile away from you to be about 66% of the width and height of that viewport, and each time you see one more tile away it would be another 66% of the previous width and height.

The side walls would each take up about 16.67% of the viewport’s width, which totals up to about 33%. Intuitively, I had one-third for the side walls and two-thirds for the backwall, which should add up to three-thirds, or 100%, right?

And yet I was seeing vertical gaps where the tiles weren’t lining up horizontally. And it looked different depending on how the game’s window was shaped, since SDL2 was autoscaling much of what I was doing anyway. So sometimes there was a gap, and sometimes there wasn’t.

Was it rounding error? I’ve run into this kind of thing before in a previous project, when I discovered that the way I was rendering rectangular tiles for a game’s background meant that sometimes the rectangles had slightly different dimensions based on rounding errors. That is, a tile I expected to be 64×64 was sometimes 64×63. But I fixed that code years ago, and it wasn’t relevant here.

But the general concept seemed to be. 66% + 33% is actually only 99%, so maybe there was a 1% gap?

Eventually, I based the math on the actual relative dimensions of the art rather than the hypothetical numbers above. Plus, I used more precise numbers, like 0.666666667, which made things line up way better.

Plus, I found out that anti-aliasing introduced by the Uniform Transform Tool was producing slightly translucent pixels that meant my art itself had perceivable gaps, especially if I used a very bright color as a background.

So I remade some of the art and filled in all relevant translucent pixels, and it looked much better.

If you wanted to skip the math, you can continue reading here.

There are still gaps, especially at certain distances, but I have plans to address it, especially as I render more than a single hallway of tiles.

For the ceiling and floor, I used a picture I took in 2015 of the side of a glass I had a strawberry smoothie in. I turned it grayscale, skewed it, and it looks like a dirt/stone floor enough for now.

Next up, I wanted to make it possible to move the player within the dungeon, and so I spent time creating a way to represent the dungeon layout in code and a way to create those grid cells. I’m still working on it, but the dungeon is slowly coming to life. It may look a bit monotonous now, but it’s still a life.

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In last week’s report, I implemented a few character customization options and implemented basic saving and loading for my second Freshly Squeezed Entertainment project.

Since then I worked on a simple view of the player’s home.

Sprint 7: Pre-production and initialization

Planned and complete:

• Show house layout

Unplanned and complete:

• Create house view’s basement

Unplanned and incomplete:

• Create _____ view with ladder back to basement

When it comes to planning my week, I decided that instead of choosing a bunch of features/tasks to work on, I would only pick one. If I finish it early, I can pull in more work.

One key part of the game is the player’s home. I want the house to be a place where the player can regroup, collect supplies, and have various characters interact, among other things.

But I also recognized that much of what I have planned really only makes sense as a way to support game play that doesn’t exist yet. So I wanted to get through this part quickly. I have some reference art for what I wanted the various rooms to look like, but for now, a simple color-coded box with a label seems to work well enough.

Then I rendered the rooms relative to each other so you can switch between the House View and an individual Room View. For now, entering and leaving a room is all you can do. It’s not much, but it is a building block to more interesting work later, and the game saves which room you were in, so I know that part works.

The basement is going to be an important location, if only because it is where to find the entrance to the main non-house area of the game. I managed to get much of the work here done, but because it reveals a bit too much too soon, I won’t say more now.

HOWEVER! I will be letting my newsletter subscribers know those details as I formally announce this game this week, so if you want to know before anyone else, please subscribe to the GBGames Curiosities newsletter by following the link below! Otherwise, you’ll have to wait for my next update.

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!

Last week, I reported that I had started player customization for my second Freshly Squeezed Entertainment project by allowing the player to change their character’s name.

I continued the effort this week.

Sprint 6: Pre-production and initialization

Planned and complete:

• Create save file
• Create player character

Now that I can rename a character, I could save the game to persist that rename, which meant revisiting the save file work I had started. I changed the main menu to allow me to either start a new game with initialized default data or load an existing game so I can continue where I left off. More directly, it allowed me to test that saving and loading works while also giving me a way to reset and try again.

Next up was letting the player customize their character’s pronouns and their appearance.

Ultimately, I want the player to be able to put themselves into the game. I want more pronoun options, but for now and to get something quickly into the game, the player can choose between he/him/his, she/her/hers, and they/them/theirs. Scripts and dialogues will use those pronouns to know how to refer to you and your party members. I have to brush up on my grammar and language rules, specifically for possessive pronouns.

The most exciting part was getting to finally put some graphics into the game. I wanted the player character on the screen, especially when customizing, and so I experimented with one of my pencil and paper doodles, scanned it in, and created a digital form with highlights and shadows. Here’s a mock-up:

I like the hand-drawn look of it.

Creating a bunch of different face shapes and facial features for the player to choose from seemed a bit daunting, so I thought it might be easier if I made it very modular. I started with creating a handful of face shapes to choose from, as well as skin colors. Again, like with the pronouns, I want to provide more options, but this initial start lets me get a feel for how intuitive this selection process can be.

The simple facial features are just meant to make it clear that these are faces and not just weird shapes. I want to eventually put in eyes, ears, noses, mouths, hairstyles, and accessories, as well as bodies and clothing, so this customization feature will get revisited.

Even now, I have plans to replace these face shapes. I made them quickly to put together this menu to allow the player to choose between them, but I think I lost the hand-drawn look that I liked so much.

If you wanted to customize your character in a game, what would you want as an option?

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!

In last week’s report for my second Freshly Squeezed Entertainment project, I was updating my project’s infrastructure and figuring out the way I wanted to persist data from one play session to the next.

I found myself adding needed functionality since then.

Sprint 5: Pre-production and initialization

Planned and incomplete:

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

Last time, I realized that I couldn’t move forward with my save file work until I had something more substantial to save in the first place.

So I focused on creating the player character. I wanted the player to be able to customize their main character to their liking, so “Create player character” above has the following tasks:

• Main player character gets a default name, nickname, gender, pronouns, portrait
• Player can enter custom name and nickname
• Player can choose pronouns from He/Him/His, She/Her/Hers, They/Them/Theirs, and (perhaps a few other major ones?)
• Player can choose portrait from list
• Create portraits

Some of these tasks turned out to be quite large. I did not do anything regarding portraits because my time was spent focusing on creating the ability to modify the player’s name.

If I was using an existing engine, much of this work would likely be provided for free with some framework. I would throw up an input box and be done.

But I’m using my own code that I’ve been working on for many years, and I didn’t have a ready-to-use text input box, so I would need to implement it myself.

In a previous project, I had hardcoded a text input box to let a player name a save file. My implementation was a little hacky, but I only needed it in one place, and the code was fairly isolated.

For this project, I knew I was going to need such functionality in more than one place, so I needed to create a reusable widget. I test-drove the functionality in, which required a few changes to some lower-level code to support it, and by the end of the week, I had a text widget that I can throw into my existing menu code. With it, I had the ability to rename the player character.

It’s exciting because from now on my own code lets me throw a text input box into a menu for free going forward, and all because of the investment of a few hours.

I expect it will take me almost no effort to change the player’s nickname, but I did find myself thinking, “What’s the point of the nickname?” Originally, I anticipated the nickname being a fun bit of personalization you can give you and your party members that otherwise serves no purpose. If you can give yourself an arbitrary name, then the name already provides personalization. So is a nickname redundant? Do only certain characters in the game refer to each other by their nicknames, and is that compelling enough? Should nicknames not be player-chosen but show up later in the game based on how the characters develop, such as a character who learns how to swim really well being called “Fish” or “Froglegs” or something like that?

It seems like a small thing to worry about, but there are clearly some questions here that are relevant to the game’s design. I might hold off on nicknames until I answer some of them.

The neat thing to see this week is that a lot of hardcoded things are starting to become less so. For instance, I started with a hardcoded text box that introduced the player. Then the text box and associated menu is generated depending on which script is being shown. Now the game keeps track of which script to show, so that when the customization menu closes the game can pick back up from where it left off. In the coming week, I anticipate that I’ll be able to demonstrate saving and reloading a game at an arbitrary point so that a dialogue being shown can be reloaded.

This game is going to be a lot more content heavy than my previous games. The work I’ve done so far may sound overly technical and even unnecessary in a world with free game engines and tools, and I’m getting impatient to put some game play together, but I’ve been investing in making the development of this project easier and faster for myself, and it is already paying off.

For now, I am very interested in making sure that players of this game can see themselves and their friends in it, and so allowing the player to customize their characters to represent themselves is important enough to not gloss over. I just hope that with my limited capabilities and resources that I don’t do too little.

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!

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!

In last week’s report, I was still taking my high level ideas and concepts for my yet-revealed Freshly Squeezed Entertainment project and trying to make them more specific and implementable.

Since then I have enough to start actual work.

Sprint 3: Pre-production and initialization

Planned and incomplete:

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

Ok, to start with, obviously I didn’t get anything finished.

That said, I did spend much of the beginning of the week looking up references to help inform the art style for this project, both for the characters and the environments they spend their time in. It was also informative to read some background on some of these environments, and while I think it will ultimately help me create a better world, I also worry that there was still too much absorbing input and not enough creating output.

I spent time learning about the pitfalls of games that this project is likely to be compared to, especially when it comes to how those games and the companies that made them handled things like race and inclusion. More on that topic another day.

And I started to work on creating the initial save file, since persistence is going to be a very key part of the game from the beginning.

Unfortunately, I got slightly sidetracked. Since the code is my own, there is a bit of infrastructure related to how I handled menu-related things that is quite clunky. It is old code related to my understanding of the IMGUI concept, and it has been bothering me for a few projects now, and I finally decided to address it. EDIT: I realized that my attempt to address this clunkiness wasn’t well thought out and so I ended up reverting my changes. Ah, well.

Otherwise, I’ve been creating doodles of the environment and of potential characters, and I think I’ve got a good idea of what at least one of the characters in the game will look like.

So it has been a weirdly fruitful week while simultaneously feeling unproductive. I knew I had put too much on my plate when I started the week, at least if I expected to finish it all, and I’ve done this a lot.

On the one hand, when it comes to planning the week, I should plan what I can get done by the end of the week. I should have planned less.

On the other hand, I think what I captured in this list is a chunk of work that I want to get done together. It is less of a set of goals for the week as a set of goals for an initial playable milestone.

So, another clunky thing is that the way I handle project plans is a bit clunky, at least when it comes to how I actually try to manage the project. I should either plan less for a week, or I should find a better way to identify these collections of work for a given milestone.

Anyway, I apologize if this kind of background information is not interesting to you, but if you do like it, then you’re welcome!

For now, know that I have started coding for this project in earnest, and I am looking forward to being able to share more about this second Freshly Squeezed Entertainment game.

Remember, sign up for the GBGames Curiosities Newsletter below if you want to be the first to see what I’m working on.

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!