Category: Game Development

Last time, I reported that it was a lot easier to create the level layout for The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I spent the last two weeks integrating a scripted scene, then fixing a few graphical issues that had been bothering me.

Sprints 2024-16 and 2024-17: Level editor and Lighting & Art

Planned and complete:

• Create level editor
• Defect: Flashlight should light up adjacent cells

Unplanned and incomplete:

• Defect: Wall from cell behind player should not render on screen
• Create dungeon wall textures

It didn’t take me long to finish the work of adding tags to the level editor. Basically, I can have sections of the dungeon arbitrarily tagged with a string, and I can use the trigger I created last time to make something happen when the party enters that tagged area.

Which allows me to have this scripted sequence when the party enters the new large room:

And with that task done, the entirety of the work to support the intro sequence I had planned is functionally complete!

There are some areas that need more iteration, such as the part when you first discover the secret room in the basement, but the game now supports organic conversations, scripted conversations, scripts and flags, updating room art and objects based on player actions, items and inventory, interactive furniture in rooms, lighting and dynamic lighting thanks to a flashlight, a new heavy door with a minimum party size criteria to open it, and the ability to load levels from a file so that it is easier for me to create the titular dungeon.

So…now I just make the rest of the game, right?

Well, I wanted to fix a few issues that have been bothering me.

First, I wanted to make the flashlight feel better. My initial attempt had a single beam of light project out in front of the party, and it is functional, but in practice walking through an otherwise dark area felt like walking in a narrow hallway with black walls on either side.

It took a bit of math and then some debugging of my bad math, but eventually I got the flashlight beam to be joined on either side with a shorter, less bright set of beams.

It feels a lot less claustrophobic and helps the player to notice things off to the side when they are nearby but without revealing too much of the dungeon either.

With that part finished, another thing I needed to address was a problem with rendering the walls of the dungeon.

Normally, when you are walking around, you see part of the cell you are currently in, plus any walls it would have. But if you had a cell behind you that had a wall directly behind you, due to how the camera and raycasting was implemented to allow for part of your current cell to be seen, the wall behind you would get rendered, blocking the entire screen.

I didn’t address it when I first noticed this problem shortly after getting the raycasting code finished because I could always work around it: just don’t put two cells next to each other that are divided by walls.

But I decided that it was time to figure this out because I didn’t want to limit my level layouts due to a silly rendering bug.

After all, the reason why my game has arbitrary walls inside a cell is to allow for more flexibility than having a cell itself act as a wall as you might see in my raycasting tutorials. It seems silly to throw that flexibility out.

I could get into the math, but after spending days (or mere hours, if you remember that I don’t work full-time on this project) on trying to solve it with math and not getting too far without introducing other problems, I decided to fix it with a hack. I basically figure out which cell is behind the party, then when I check for walls to render, I ignore a wall if it was found in that cell.

It worked. I can now create levels that use up all of the cells instead of needing to remember to leave gaps in between.

Since I was spending so much time maneuvering through the dungeon and debugging what I was seeing, I decided to finally add new wall types. I now have not only stone walls but also dirt walls.

I’m not an artist (or maybe it goes without saying), and I’m not entirely happy with it, but these walls will fill the dirt tunnels of the dungeon.

I expect to replace the original stone walls soon. Those were placeholder art based off of some art found on OpenGameArt.org and modified, and while they worked fine, I think I need to focus on getting a cohesive look for this game.

But I found myself thinking about the nature of the rooms and hallways that the player will be entering, and I will be creating and changing the wall, floor, and ceiling images to support it.

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 my last report, I had mostly finished my work of creating the level loader code for The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

This past week I finished the work and did more.

Planned and complete:

• Create level editor

Unplanned and complete:

• Defect: Ladder renders in front of camera when facing away from it.

Unlanned and incomplete:

• Show script when entering open area in dungeon beyond first door

I had some small coding difficulty related to lighting color data that I was able to fix quite quickly, then I was able to swap out my hardcoded dungeon creation with my new dungeon loader code.

I had to address a few other issues related to persistence, though. Most of the dungeon is static, but there are some pieces of it that I can persist, namely the state of the doors. So I have to load the dungeon, which creates the door data as well, then if I am loading a game rather than starting a new one, I need to overwrite the dungeon door data.

This was a little trickier than it should have been, mainly due to the fact that my main game data object, which has all of the variable state of the game, is probably doing way more than merely holding state.

Anyway, once I was satisfied that I could load the dungeon without problem, I could move on.

Except I discovered that I must have introduced a problem. I found that if I was on the other side of the door that the lighting doesn’t show the wall arch properly because it belongs to the cell on the other side, so I solved it by creating a second one in the adjacent cell so that they appear lit from either side correctly.

As part of the solution, I had to offset the wall arch differently.

But apparently that offset got applied to the ladder as well, so when you face away from it, you see it in front of the camera. Whoops.

Luckily, by just changing the offset the ladder I could get it to appear where it should again.

Now what? Well, I knew the next part of the game I wanted to work on was related to what was beyond the door.

So I used Tiled to quickly create a large room with columns, added some red lights at a low intensity, and then within moments I was delighted that it was available to walk around in-game!

My plan was to make this large room a hub, with other areas of the dungeon splitting off from it. I want the party to enter the room and say something about it being so huge and expansive, though.

I ended the week by creating a new trigger criteria for entering a part of the dungeon that is tagged, then I started the work of adding a new layer to map so that a dungeon grid cell could have a tag associated with it.

The next step will be to create a new part of the dungeon loader to load that tag data in.

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 time, I reported that I was making good progress on importing levels from a map editor for The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I anticipated that I only had a few hours left to go before I could confidently use the new level loader code to load the dungeon, allowing me to easily create the dungeon layout.

Sprint 2024-14: Level editor

Planned and incomplete:

• Create level editor

I anticipated incorrectly.

Despite putting in a relatively significant amount of time into game development this week, I have not finished the level loader code.

But I am a lot more confident that I am almost finished with it. This time.

As you recall from the last couple of reports, I’ve been trying to leverage Tiled, the general-purpose level editor, to create the dungeon layout. Up until this effort, my small test dungeons have been created in code. Just trying to add a door and a single cell room beyond it already showed me how painful and error-prone it was going to be to continue without a level editor.

Of course, using a general-purpose tool like Tiled meant learning how Tiled works, then figuring out how best to use it for my own purposes. The Tiled Discord, specifically the very knowledgeable eishiya, has been a great help.

So to recap what I’ve accomplished so far, I have a DungeonGridCell which looks like:

struct DungeonGridCell
{   
    DungeonGridCell();
    ~DungeonGridCell() {}

    DungeonFloorType floorType;
    DungeonCeilingType ceilingType;
    DungeonWallTypes walls;
    OrientationToDungeonDoorIDs doors;
    DungeonPortals portals;
    DungeonLight lightSource;
    DungeonLight lightAmbience;
    bool valid;
};

The floor and the ceiling are defined by single values, but the walls, doors, and portals include not only the type but also the orientation. That is, you can have a cell with zero, one, two, three, or four walls.

So how would I represent a single grid cell in Tiled with all of that data?

I use layers.

So each cell is actually split out across multiple layers of data. I have a floor layer with tiles to represent the floor type, and I have something similar for the ceiling.

Doors and portals are represented as objects in their own object layers. Basically, I can place a door like a tile, even rotating it to get it into the correct orientation, and the only interesting thing I need to do when loading it later is calculate the cell it is in using its (x,y) position.

I tried to see if I can do the same with walls. See, the DungeonGridCell allows for the possibility of different types of walls in the same cell, but to represent that in Tiled would require a ton of different kinds of transition tiles depending on how many wall types I wanted to represent.

Maybe that’s not true. I think I know enough about Tiled to be able to create a tile layer, offset it so that the tiles show up in the corners of the regular floor tiles, and place the corners, then use the automap feature to generate the correct wall tiles, but it still sounds like a lot of work.

But if walls were objects, then I can place an arbitrary wall in an arbitrary location. Except the exported JSON would balloon in size. I calculated that if even half of the tiles in a 500×500 map had at least one wall, it would take at least ~130 MB just to represent walls in the JSON file. That’s way too large, even with compression, and I want to ensure the download size is small for this project.

So instead, I decided to limit cells to only have one type of wall possible, even if the code allows otherwise, mainly to make it easier to create Tiled maps.

Using the above two rows of tiles, I can represent every configuration of walls for a given wall type (dirt or stone). Eventually I will add more wall types, and maybe variations of walls to break up the tedium.

I can easily create this test dungeon which uses single walls, corners, hallways, and dead ends. I found I don’t need to create a tile that represents an enclosed cell, but maybe in the future I might have such a room with a ladder in it? So I’ll keep the tile in the tileset.

Now that I have a dungeon, I can save it as a JSON file.

But then I needed to import that JSON file and turn it into a dungeon level full of DungeonGridCell objects.

That’s what my DungeonLoader code is doing, and in the last week, I have been able to test-drive the code that can load the layers that represent everything except the dungeon light source and the light ambience.

Loading dungeon walls was slightly complicated due to needing to not only know which tile I was looking at but also what orientation the tile was in. The corner wall tile, for instance, represents west and north walls by default, but when rotated, Tiled represents that tile with some high-order bits flipped to represent horizontal, vertical, and diagonal rotations, which means I need to write code that looks at those bits and figure out which walls need to be represented.

I finished the week by almost getting the light source loading code in, which required converting from the hex representation of the light source’s color (a custom property I added to the tile in Tiled) to the Color object I have in my game. But my code isn’t working correctly, and I am starting this week by figuring out why.

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 was starting to figure out how to best configure a map editor so that I could have an easier time loading dungeon levels in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I started the week hoping to make up for the previous week’s lack of effort.

Sprint 2024-13: Level editor

Planned and incomplete:

• Create level editor

While I was more productive this week, I was still struggling to make time for game development due to other obligations, plus dealing with an unusual amount of ennui.

My main goal was to get my map in Tiled, which is exported in JSON, into the game as my dungeon level data.

I decided to use nlohmann’s single-header JSON library, partly because I figured it would be easiest to integrate into my project.

The documentation mentions ways to integrate it into a build using CMake or other build tools, but I think that might be for more complex situations.

What’s nice is that I can easily use the JSON library to create in-memory JSON to use in unit tests, allowing me to test drive my DungeonLoader code. Then, once I’m satisfied that the code works, I can easily use the same JSON library to load the level JSON file, pass in the JSON data, and expect it to work perfectly.

I imagine if I had a few more hours to dedicate to it last week that I could have finished the loader code. Maybe this coming week I’ll be able to be more focused and productive.

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 created a heavy, metal door that required the entire party to open it in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I had started work on learning Tiled so I could use it as a level creator/editor, and my goal was to get a simple level imported into the game.

Sprint 2024-12: Level editor

Planned and incomplete:

• Create level editor

Ok, so I’m doing less “creating a level editor” and more “bending Tiled to my needs” but ultimately the end result is that creating the dungeon layout will be faster and easier with its existence.

Unfortunately, this past week I struggled to get much time to work on game development. It was one of my least productive weeks in terms of hours, partly due to obligations outside of my business, but also partly because I spent some time on non-routine things. And I was feeling pretty tired and found myself wanting to nap more.

What progress I did make was mainly involved in creating a custom tileset for the floor and ceiling and figuring out how I can represent things in Tiled that need custom data.

For example, in the game, there is a ladder. A ladder can take you back to the house from the dungeon, but a different ladder might take you to a different level. So in the game’s code, it’s treated as a Portal. I envision not only ladders but also stairways being implemented as Portals, and a Portal has an ID that represents where it takes the player’s party if they use it.

Normal tiles in Tiled don’t have such custom information available. Tiled does have a concept of an Object which does, but an Object isn’t placed as a tile. It just floats in an arbitrary location.

So it seems like I can place Portals as objects in my Tiled map, then when I import the map data, I’ll need to figure out which dungeon grid cell the object is located in.

It’s not complicated, but as I’m still learning Tiled, I wasn’t sure if it was the best way to go.

Meanwhile, I am also figuring out not only how to make the map but also how to import it into my game. My game already uses YAML to persist and load data, but Tiled doesn’t export to YAML.

It does, however, export to JSON, and I can integrate a JSON library into my code, or I could use one of those JSON to YAML convertors that exist out there.

I’m anticipating a much more normal level of productivity this coming week, so I’m looking forward to making much more progress on Tiled so I can have a much easier time creating the dungeon levels.

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 my last report, the player can now use the flashlight to light their way through The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I had also started working on adding a special door that required the entire party to open.

Sprint 2024-11: Intro sequence game play

Planned and complete:

• Door with beam requires minimum number of party members (or strength) to open

Unplanned and incomplete:

• Create level editor

To recap, my original intro sequence felt too long and boring.

There were unskippable scripts that explained that there was a new member getting inducted into the Explorer’s Club followed by the ceremony itself and then discussion about going on a Snack Quest, and it took too long before you felt like you were playing the game.

For some time I’ve been working on making the introduction more interactive and playable, introducing the main mechanics the player will use throughout the game as soon as possible, and I’m finally almost done with this entire sequence:

1. The new member induction ceremony only starts once the player starts it, allowing the player to explore the bedroom and meet characters first if they so desire (Conversation mechanics, scripts, and flags)
2. The Snack Quest starts either after talking to Pat after their induction ceremony or when trying to leave the room after the ceremony. (Quests aren’t yet an actual “thing” in the game, but mechanically this is just scripts and flags)
3. The objective of getting the jar of pickles from the basement is added once the player enters the kitchen and talks to their parents. (Again, no quests, no objectives, just scripts and flags)
4. The dungeon entrance is revealed after the player searches for pickles in the dungeon. (Flags and new art)
5. The dungeon limits exploration without a flashlight. (Lighting, triggers, scripts)
6. The flashlight can be found and acquired in the bedroom under the bed. (Added furniture, inventory, and items to the game)
7. The flashlight allows the dungeon to be explored in the darkness. (Flags, scripts, and dynamic dungeon lighting)

The above has been more or less implemented, although I have some work to do to make the conversation mechanics more obvious and intuitive, plus I would like to make it more obvious how the secret door in the basement opens up. What was left to do for the intro sequence:

8. The party finds a heavy, metal door at one end of the dark hallway, which requires a full party to open (flags, new door type)
9. Once party opens door, they eventually find themselves in a wide open area with access to many parts of the dungeon.

My original idea for the door was that there would be a heavy beam acting as a drop bar that prevents the door from being opened. The only way to open it is to have a full party, as everyone will need to work together to move the drop bar.

It seems simple enough, but there were a lot of questions I had to answer:

• Can I animate the beam moving, or should it just instantaneously be in a new position?
• Where is the beam when it isn’t engaged? Lying on the floor? Leaning against an adjacent wall? Do I need to guarantee a wall is adjacent?
• Should the player be able to re-engage the beam?

It seemed like a lot of work, and so I decided to just…not do it.

Instead, I decided to make doors have different weights. Normal doors are easy to open, but really heavy doors require more people.

The reason why I wanted a door to require a full party to open, whether it was with a heavy drop bar or just a heavy door, was that I wanted the player to have a reason to go back to the bedroom and get a full party together in case they decided to explore the dungeon early.

Basically, this intro sequence now teaches the player how to play the game: they have shown that they can talk to characters using the conversation system, collect items by interacting with inventories, navigate the darkness by using a portable light source in the form of a flashlight, and now add characters to their party.

So, now what? After the player opens the big heavy door at the end of the hallway, what happens then?

That’s when the rest of the game really starts.

But I of course need to create the next part of the dungeon that they would see.

Up until this point, I’ve been using my game’s code to create the dungeon, and it worked fine when I had a simple test dungeon of a few rooms and some doors, but it’s not terribly intuitive to work this way.

I knew that I wanted a GUI editor eventually, and in the past I looked into the Tiled map editor, but I decided it was time to look more seriously into it. I could create my own from scratch, which I imagine would be fun and all, but it would probably take me way too long to do, and I want to get the game finished sometime in my lifetime.

Thanks to eishiya in the Tiled Discord, I got some very direct help figuring out how to use Tiled to create the dungeon layout in a way that I can then use in my existing code.

The above uses a tileset image that eishiya provided.

I still have some things to learn about how to use this tool, but I’m already figuring out some keyboard shortcuts and how to use layers. eishiya demonstrated how to use terrains to essentially paint the walls automatically, and I’m building up my own understanding of how to get there.

But besides figuring out how to use Tiled, my next main concern is to figure out how to import a simple map that I created, which should be straightforward although there is no Yaml export, and my existing code doesn’t have a JSON reader.

I am also interested in a custom exporter to make the map more directly related to how my code treats the dungeon levels.

Oh, and after a year of screenshots and videos, my wife alerted me to a typo that I have now fixed:

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 time, I reported that the player can now obtain items from furniture and that I was planning out how the flashlight will work in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I implemented a working flashlight and proceeded to work on the next in-game obstacle for the player.

Sprint 2024-10: Intro sequence game play

Planned and complete:

• Flashlight automatically lights up dark dungeon

Unplanned and incomplete:

• Door with beam requires minimum number of party members (or strength) to open

Now that the party can acquire a flashlight from under the bed, they can return to the dungeon to light their way through the darkness.

As I said in the previous report:

I think requiring the player to manually turn the flashlight on and off would be tedious.

Instead, I’d like the flashlight to turn on and off based on the current light conditions. So if the player is entering an area that is getting darker, then the portable light source turns on automatically, and once the player enters an area with getting brighter, the portable light source turns off automatically.

I figured a decent way to make it obvious that the flashlight’s status was changing was by popping up a piece of scripted dialogue.

I created two light thresholds, one for when it was getting too dark and you needed to use your portable light source, and one for when it is getting bright enough that the light wasn’t needed anymore. I figured that with two separate thresholds instead of a single boundary, the scripts wouldn’t pop up too frequently if the player decided to move back and forth between two grid cells.

The somewhat tricky part was the actual dynamic lighting of the dungeon. I was worried that the raycasted dungeon rendering code would be slowed down, but with only a handful of light levels being modified, it turned out that it wasn’t a big hit to performance.

Otherwise, it turned out to be straightforward to project out from the party’s current position and modify light levels on the fly, and as the party turns to the side, you can see that part of the dungeon gets lit up as they turn.

I’m not entirely happy with it, as it seems to lighting up more intuitively when turning one way but not as much the other, but on the other hand, it’s a quick turn and the player might not see much anyway.

Another issue is that I think the way the lighting works is functional enough, but I wish it looked more like a flashlight, with a rounded illumination. But maybe I’ll come back to it in the future.

But one thing I want to address sooner than later is that it feels weird. The light projects out in a straight line, so you can see the cells directly in front of you, but the cells to either side are left at their default light levels, which can be pitch black. But instead of looking like you are walking in a dark hallway with a flashlight, it looks like the walls on each side are just super dark.

Strangely and counterintuitively, to make it feel more correct, I might need to light up the cells to the sides a little.

But in the meantime, one more step in the intro’s game play is completed: the player can navigate a space that was originally too dark to proceed through.

I next started working on what the player would find at the end of the dark hallway. My plan was for it to be a door with a heavy beam across it. In order to open the door, the party would first need to remove the drop bar, and it would require a full party of three members working together to do so.

Currently, the only doors in the game can open and close, so adding a barrier and/or a lock was a future task, and the future is now.

It made me think about the need to persist the state of doors and how I might rearrange the data structures in a way that make it easier to save and load those states.

I’ve also been watching videos about level design, which got me thinking about this intro hallway. My original plan was to have one main way forward and one non-obvious and secret way into a different part of the dungeon. Now I am considering adding a third or even a fourth path, allowing a player who decided not to get the flashlight or not get a full party to proceed anyway. I’m considering how much freedom I want to allow the player to have this early and wondering if I should keep the intro sequence more direct and allow that freedom later.

But first, I need to work on the door, and that work should happen this coming week.

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!

Here’s the companion video for Monday’s Freshly Squeezed Progress Report: Grabbing the Flashlight from Under the Bed:

Enjoy! And let me know what you think by replying below!