Author: Gianfranco Berardi

In my previous sprint report, I created an introduction script for The Dungeon Under My House, my second Freshly Squeezed Entertainment project, but I decided I wasn’t happy with it.

I also discovered a mysterious crash issue when I ported it to Android to test it, and I was definitely going to need to fix that issue.

Sprints 28: Pre-production and initialization

Planned and complete:

• Defect: Android crash when drawing ceilings in dungeon

Unplanned and incomplete:

• Revise character customization

After I finished working on the dungeon doors and basically having a working dungeon mode, I switched to focusing on the house and the intro script. At the time, I was able to create an Android build and verify that while the dungeon view needs optimization, it was functional.

So imagine my surprise after getting the intro script done and wanting to share it with others that the Android build crashes when entering the dungeon while my desktop build does not. Something was going wrong, and there were no changes to the dungeon rendering code between my previous Android build and my current Android build.

I found it frustrating to debug on Android, but after a few days of poking at code and adding logs, and yak-shaving to try and fail to get debug symbols so that LLDB could tell me what I was looking at, I could narrow the apparent issue to a crash when rendering the ceilings or the floors.

If I removed the ceiling and floor rendering code, the game seemed to work just fine. So what gives? Well, when I render the ceiling and the floor, I create a buffer of pixel data, then update a sprite’s contents with that data.

In other words, I did something like the following:

void drawCeilings()
{
    const int pixelSize = targetDimensions.width() * targetDimensions.height()/2;
    Uint32 pixels[pixelSize];
    // Figure out what to put into pixels.
    updateSprite("DungeonCeilingSprite", pixels);
    ...

The drawFloors() code is almost the same.

This code works. Or at least, I thought it did.

Maybe I had some memory getting trampling due to new code? I tried removing all that new scripting and triggers code, and I still saw the same problem.

Ultimately, and I wish I had a better way to confirm it is true, I think my game is getting a bit big memory-wise.

I came across something about being able to set the maximum stack size of a thread, and it made me wonder: what if instead of setting up the pixels on a stack, I create them on the heap?

So I made the following change:

void drawCeilings()
{
    const int pixelSize = targetDimensions.width() * targetDimensions.height()/2;
    Uint32 * pixels = new Uint32[pixelSize];
    // Figure out what to put into pixels.
    updateSprite("DungeonCeilingSprite", pixels);
    delete[] pixels;
    ...

And the crashes disappeared.

This experience did get me to fix a few minor memory issues that valgrind identified that had nothing to do with this issue, but it also made me wonder if I needed to shrink the PNGs I was loading into memory at the start of the game. I worry I’ll be running into a similar issue soon.

But let this be a reminder of what Brian Hook said in Write Portable Code: you can’t say your project is cross-platform unless you actually build and run it cross-platform.

Anyway, after I did a bit more testing to try to make sure the crashes were actually resolved, I moved on to do something I’ve been looking forward to for some time: making the characters look better.

All of the graphics in the game have been placeholders until I figure out the look and feel I am going for, but until then, it makes for some ugly screenshots.

Weeks ago I got tired of seeing nothing but floating heads, and I decided to give the characters bodies, but throwing a skin-colored rectangle under the face sprite was probably not my best idea.

This is supposed to be a family-friendly game, but quite frankly, this was a little too phallic-looking.

Sorry. B-(

So now that I’m addressing the characters, I decided to give them better placeholder bodies.

My old attempt at a placeholder body was simple but problematic (in a different way). I was drawing the head, and then attaching the body to it, but then I needed to guess or do extra math to figure out where to place the character vertically so that the feet end up where I want. Some characters are taller or shorter than others, after all.

Now I start from the feet and go up. When I say where I want the character to be, their feet will be in that location. No guesswork.

Humorously, I did see what happens when I don’t correct the character location values.

But how does this new placeholder rendering, which is only slightly better than before, help with player customization?

Well, I have new menus in mind for character customization. One menu will be allowing the player to customize the body in terms of skin color, height, and size. Another will allow customization of facial features. Another will customize clothing.

So for now, my rendering code takes into account skin color, face type, height, and size, properties that are available in the character code. When I add the menus to modify those properties, I can see when they take effect immediately.

Unfortunately, chasing down that crash bug meant less time to dedicate to creating those menus, but I hope to make significant progress, including updating the face art so that it is a lot less placeholder-y.

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 on the intro script for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I have since continued the work.

Sprints 27: Pre-production and initialization

Planned and complete:

• Create introduction script

I had envisioned a multipart introduction that allows the player to learn about the characters of the game and navigate their way around the home before finding themselves in the dungeon.

With the first scripted part finished and kicked off as part of the game’s initialization, I created triggers that would start the second and third parts.

The first script features dialogue with your Explorer’s Club friends, and ends with you on a quest to get snacks.

I created triggers that have arbitrary criteria, and one criterion I created was to determine if you had entered a specific room.

So when you enter the kitchen, it would start the second part of the intro script, which eventually sends you to the basement.

Entering the basement kicks off a third intro script, which ends with you discovering a part of the basement you didn’t know existed before.

This second basement isn’t visible in the house view until that point, but it features a ladder, and when you climb down and enter the dungeon for the first time, it kicks off the final intro script.

To make all of the above work, I needed to modify the triggers, commands, scripts, and menus to support a bit more flexibility and capability. Up until now, a menu option was always tied to a single command, but now triggers, scripts, and menu buttons can all kick off a series of commands. In practice, it means I can have a trigger disable itself after the first time it is triggered, while also starting a dialogue script, while also setting an arbitrary flag to a particular value.

Many years ago, I made a game called Stop That Hero!, and in it I created a data structure that could be any arbitrary data type that I would like. It turned out afterwards that I discovered boost::any was a thing, but my own code worked well enough, and I found it useful this time around, too.

Well, anyway, now that I have the intro scripts, I found that I didn’t like what I had made. It’s functional and it does what I set out to do, but in my head I have this colleague who once said that he hates long sequences of introduction that prevent him from playing the game right away. He hates it so much that he stops playing the game entirely.

And I realized that I had made just such an intro.

So I started thinking about ways to change the intro so that the player is more actively involved and driving things instead of passively hitting the “Continue” button until the blocks of text go away.

I’ve mentioned before how I want dialogue to be more than merely static text with branching, and I think this intro would be a good opportunity to figure out what the player should be able to do and how to make it work.

Unfortunately, before I could work on it, or on making the art for the characters much better, I discovered that while the game seems to work just fine on my development machine, it crashes when I run it on Android, specifically when entering the dungeon.

It is strange, because I have an Android build from a few weeks ago that runs perfectly fine, and I haven’t touched the dungeon code since that build.

The crash seems to point to a memory trampling issue, and I spent the last few days of the week investigating and debugging. Unfortunately, while I narrowed down where the crash seems to be occurring, it isn’t clear to me why it is occurring.

Creating an array of Uint32 shouldn’t cause an issue, but clearly something is wrong:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x74db82e79e88
Cause: stack pointer is in a non-existent map; likely due to stack overflow.

And I wonder if it doesn’t have something to do with the triggers and scripts, which need to live separately from the main GameData data structure, which may or may not be handled properly when I am periodically saving it.

So this coming week I hope to figure out why the Android build crashes. So far I have fixed a number of minor memory issues that valgrind found, but none of them seemed to be related to this issue.

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 made it easier for me to playtest and improved the interface when in the house screen of The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I since set the work on creating a scripting system to get the intro going.

Sprints 26: Pre-production and initialization

Planned and incomplete:

• Create introduction script

I envisioned the introduction roughly as follows:

1. Dialogue involving the player’s main character and their friends in the Explorer’s Club.
2. Player puts together a party for 1st quest: go get snacks.
3. Go to kitchen, have dialogue involving parents, who send party to basement.
4. While in basement, discover secret room with a secret ladder that leads to the dungeon.

To start, I needed to change from hardcoded scripts to something a bit more general purpose.

I created a few data structures to hold the text, the id of the speaker so I knew which character to render along with the dialogue box, and a collection of menu options. Those menu options would have commands that would run when selected, with “Continue” setting the next script ID as the current script.

That part was easy.

The trickier part was allowing the scripts to handle variables. Since I want the player to be able to customize the names and looks of the Explorer’s Club members, I couldn’t hardcode their names.

So instead of “My name is Francis”, for example, the script text is “My name is {{friend[0].name}}.”

I don’t normally do a lot of text parsing, so I wasn’t familiar with what text parsing utilities I could leverage. My plan was to keep it simple, using std::string and find() and substr().

If I wanted to separate the script into words separated by spaces, those functions would be great, but it seemed my code was going to be more complicated when using the curly braces and brackets. Was there something else I could do?

So of course as soon as I asked in a C++ IRC channel for advice, I thought of regular expressions, and by the time someone responded, they just confirmed I was on the right track with that line of thought.

What was really annoyingly helpful was that someone fed a similar question into a generative AI, and it popped out some code that was more or less what I was trying to write. In the past I’ve seen people share links to FAQs or forum posts, but this was the first time someone asked an AI and gave me the generated response. My initial reaction was to hate this new development in IRC question-answering, but I was very impressed with the results. The regex string the AI generated to match with the curly braces gave me a quick shortcut, so at least I didn’t spend too much time trying to create that regex myself.

In case you are wondering, the regex is “\\{\\{([^}]+)\\}\\}” and you can read it as “get me everything between the {{ and }}”. My initial attempts were nowhere near that string, by the way.

I wrote code to parse out the variable name, the array index, and the property name.

Once I had all of those, I could then throw it at a growing if-else statement for various variables I want to support. So in this case, I would see “friend” and check which array index and which property, and then the code would use std::regex_replace() to substitute the appropriate text.

So “{{friend[0].name}}” would get replaced with the result of gameData.getFriend(0).name, which is “Francis” by default, and “{{friend[0].nickname}}” would use a different code branch to use gameData.getFriend(0).nickname instead.

Besides “{{friend[]}}” variables, I also added support for “{{currentLocationName}}”.

So now I have the ability to create the first part of the dialogue, with the main characters having an Explorer’s Club meeting. They are inducting a new member, and then someone suggests getting snacks.

Oh, and now that I can show different people talking, I found it frustrating with this placeholder art to know WHO was talking, so I added a label that shows the character’s name.

Eventually I would like to create a “quest” system, so upon finishing this first part of the intro, you get a new quest, with an initial objective to go to the kitchen to ask your parents for snacks, and new objectives getting added to go to the basement.

But for now, I needed a way to start the second part of the intro. Going into the kitchen should start a dialogue with the parents.

So I started working on a trigger system. A trigger has criteria, such as the player being in a particular location. If the criteria is met, then the trigger’s commands should get processed.

I decided that triggers should be either active or inactive. This way, the game isn’t constantly checking all potential triggers in the game, and it will be easier to manage if I only have to worry about accidentally meeting criteria or debugging wrongly successful criteria on fewer triggers.

For now, I have the one criteria, which I can use to detect if the player has made their way to the kitchen. I still need to have a way to enable or disable triggers, process active triggers, and process a triggered trigger’s commands.

But that’s work for the coming week.

In the meantime, I have also been trying to create a prototype for the meaningful dialogue system I want to create. Instead of merely branching dialogue with “correct” or “incorrect” choices, I am toying with the idea of conversation threads based on topics. Threads can progress (instead of being static), can relate to other topics, and can be “loose” or “tied off.”

What if each time you talked to an entity in the dungeon, you could pick up where you left off in your conversation, rather than get a stock response each time? What if that entity is actually interested in you, and so it isn’t enough to simply read some text and dismiss it. You have to answer, and your answer matters. Being dismissive might be an option, but the consequence is that you are seen as dismissive. On the other hand, if you are enthusiastic or deceptive or get caught in a lie, there would be other appropriate consequences.

That’s what I’m going for, anyway. I know I’ll need to prototype this part and try to create something enjoyable and feasible. I anticipate needing a LOT of writing to make this work well, but I want the focus to be on the game play rather than the text.

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 previous report, I created an Android port with the intention of making it easier to hand someone a demo, then placed residents in the titular house of The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I continued by making the ability for me and others to playtest a bit easier.

Sprints 25: Pre-production and initialization

Planned and complete:

• Quit to main menu

Unplanned and complete:

• Make house rooms into buttons

Unplanned and incomplete:

• Create introduction script

One of the ways it would be easier to playtest the game is if I didn’t need to close it and restart it to try it from the beginning each time.

I added a way to quit to the main menu, which sounds simple, and mostly was, but part of the work involved thinking through the user interface a bit more. Up until now, the house view was basically a view of the room or house layout and some buttons on the side.

It’s still mostly the same, but I’m trying to anticipate what else I might want on the screen. For instance, the player’s party should be visible in some way. I also need room for buttons that might always be on the screen, and others that are contextual.

Which of course begs the question of what buttons I expect to need. I know I eventually want a button that lets the player see the map, and even though it hasn’t been implemented yet, I think the needs there are obvious. I also haven’t implemented dialogue/conversations yet, but in this case I don’t yet know what I want to provide the player.

So for now, I gave the background a color other than black, created a gear icon to represent “settings” and gave the settings modal the button to return to the main menu.

Next, I was tired of having the right side of the screen full of buttons representing each room in the house, so I created a button out of each room itself. It was fairly quick work.

Finally, I decided it was time to start talking.

That is, I’ve been thinking about how to design and implement the dialogue/conversation systems for a long time, but I need to start making something real. The current intro script has been nothing more than hardcoded menus, and I need to make it more general purpose so that more scripts can be more easily written.

As I’ve said before, my intention is not to merely create a simple dialogue tree like most games. If all I wanted was an NPC who repeats the same sentences until you choose the correct response option, it would be relatively simple and easy to implement. After all, my game Toytles: Leaf Raking (which, by the way, is on reverse sale this week, so feel free to check it out) features such dialogue, so I can always build on what I’ve already made.

Since The Dungeon Under My House will be a non-violent game, I wanted to have dialogue and interactions become more engaging and interesting to replace the otherwise compelling mechanics of hack and slash that is typically in a 1st person dungeon crawl. I don’t want to merely disguise hack and slash mechanics. I want conversations to be a completely different kind of game play.

Unfortunately, while I have a number of different ideas and directions to go in, there’s a lot of unknowns still.

For instance, should there be random encounters? It’s typical for this kind of game, and while it might be challenging to ensure these encounters are interesting and varied, it might make the dungeon feel more populated.

Alternatively, what if the encounters are with entities that you can see beforehand, that take up space in the dungeon? Then the player can choose when and where to engage with an entity, and my own work to write dialogue is limited to the characters I purposefully created.

I’m leaning heavily towards the latter, partly because I want conversations to be meaningful and impactful. If you talk to an entity who sticks around, you can build a relationship, whereas having random encounters results in a lot of interactions with strangers you never see again and won’t impact your life much.

I’m envisioning giving the player options to speak with a particular type of tone, to have different intents with messaging such as amusing or scaring or inspiring, to brush off, to merely listen intently, and to do any number of the kinds of things people actually do when they interact with others. I want NPCs to have memories of how they were treated, to have goals that dictate how they treat the player’s party members and others, and ways to influence and be influenced.

For now, though, an intro script will likely look much more like a typical dialogue tree, introducing the player to the game world and getting them to their first goal as quickly as possible.

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 finished working on doors (for now) and got ladders into The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

My intention for the next week was to make sure someone else can play the game, as it was a goal of mine for the quarter.

Sprints 24: Pre-production and initialization

Planned and complete:

• Create Android version

Unplanned and complete:

• Place family and friends in house

Unplanned and incomplete:

• Quit to main menu

Creating the Android version was a lot more straightforward than I anticipated, mainly because I have the build scripts and everything I need.

All I had to do was create an app icon.

It’s a temporary app icon, as eventually I want to get better, more permanent art into the game anyway, but I am wondering if there is a great icon for this game that isn’t a hallway or a door or the ladder.

Running the game on my Android phone, I found that the performance in the dungeon was not great. On the one hand, it worked. I could actually move about in the dungeon and my phone didn’t explode or burn up. But movement was a lot less smooth compared to my desktop.

I know my code wasn’t optimized, but I wonder if the issue is with the speed of the code or with the entire premise of raycasting as many columns as I have.

The final game might have a smaller viewport for the dungeon, which might make the game look a lot more blocky and pixellated than I want.

I didn’t end up sharing this version with anyone, but now I know that my game functions well enough on Android and can be easily built and shared going forward.

Next, I revisited the house. I wanted to get the Explorer’s Club and the parents into the game. While the dungeon is a 1st person view, the house is like a dollhouse seen from the side.

Eventually I want to replace this art, too, but I decided I needed to get the characters represented before I worry too much about how they look. So they have different faces over rectangle bodies, and they have different heights.

The Explorer’s Club is a group of kids who hunger for adventure in their sleepy suburban town, and I’m looking forward to exploring their world with them. I’ve written a bit of an intro to them, given them names and nicknames, and came up with the idea for their first quest: find some snacks.

By the end of the week, I found that I kept having to close the game and reopen it to start a new session so I can see my changes, and I decided that I needed to add a way to quit to the main menu from within the game, which required working on the in-game HUD a bit. Unfortunately, I ran out of time before I could do much, but after that task I’m looking forward to making it possible to interact with the Explorer’s Club in the 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!

I have been on a family trip for the last couple of weeks, but in my last sprint report I finally got the door to render properly and turned it into an obstacle that blocks your path in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I fleshed out the rest of the door implementations and then some in the time before and after my trip.

Sprints 22 & 23: Pre-production and initialization

Planned and complete:

• Doors can be opened/closed

Unplanned and complete:

• Put ladder back into dungeon

I realized that many similar games implement doors in a much simpler way. Instead of swinging open, they slide sideways into the wall, much like the doors in Star Trek.

Oh, well. I have doors that swing open and close, and now doors actually prevent movement through them.

The code to handle doors as obstacles was a little messy. If you are facing a doorway, and the door is closed, it’s simple. You just can’t go through the doorway in either direction, either to leave the cell that the door is in or to enter it. If the door is open, then you can traverse between the two cells that were previously blocked from each other.

But if the door is open, the blocking behavior essentially gets turned to its side. A door on the north end of a cell that is opened is now blocking the west cell, and from the west cell you can’t enter the cell with the door in it. However, you should be able to enter the door’s cell from the east side.

But what happens if you are IN the cell that has a door, opened the door, and turned to the right? Should the door block you?

It was visible on the screen, and so it seemed intuitive that it would block you, but logically it made no sense.

I decided to not draw the door if it was too close to the camera, and it works out fine.

So now basic doors are more or less finished, and the game now has the ability to block or free access in a hallway by opening or closing a door.

At one point I had hardcoded a ladder to get back out of the dungeon and into the basement of the house, but that ladder disappeared as I worked on dungeon rendering.

So I decided to make it a full-fledged object in the game. I implemented it as a generic “portal”, with the idea that while doors allow you to move from one cell to another while providing a moving obstacle, portals teleport you to another location entirely.

So the ladder teleports you back to the house, but a different ladder or a stairway can take you to the next level of the dungeon.

I’m pleased with how the ladder looks from different angles, but clearly I need a new ceiling tile for locations with ladders to make it look like the ladder goes through somewhere.

For now, though, you can once again enter and exit the dungeon from the house.

I mentioned I was on a trip for a couple of weeks. I did not take my laptop, but I did want to spend some downtime thinking about and planning conversation systems. Since the game is meant to be non-violent, I need something to replace the typical hack & slash mechanics you would find in a 1st person dungeon crawler.

And I intend for that replacement to be as compelling and intricate. It won’t be enough to merely have a branching dialogue that let’s the player repeat conversations and try different options until they hit on the “correct” response.

That is, I want conversations to be meaningful and consequential.

But I am woefully ignorant of the state of the art in game dialogue and conversation design, and so I spent some time not only reading about the nature of dialogue and conversation but also trying to find examples of games that handle conversation differently.

I haven’t been terribly thorough, but so far it seems the state of the art is still just branching dialogue? With maybe some persistence of state to handle relationships or other consequences?

At least tabletop games have people performing improv.

My trip was good, but I hope I can dedicate a lot more time into figuring out how conversations should work.

But one of my goals for this quarter was to get a playable demo of my game into someone else’s hands, and to that end, making a mobile port is what I’ll focus on next.

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 challenges I was facing with correctly rendering doors in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I finally made some breakthroughs this week.

Sprint 21: Pre-production and initialization

Planned and incomplete:

• Doors can be opened/closed

After fighting with the math and code for so long, I am happy to say that the doors are visually correct now.

The fisheye effect I was seeing got eliminated as soon as I realized that the way I was trying to get the perpendicular distance was wrong. The current algorithm for rendering “things” such as a door (which can be effectively treated as 2D line segments) is to:

1. Sort all things by distance from camera, so I can render them back to front.
2. For each thing:
   1. Figure out the leftmost and right most columns to draw.
   2. For each column:
      1. Send out a ray from the camera to thing and figure out its intersection point, and use the relative distance along the line segment to determine which part of the source images to use when rendering.
      2. Then determine the distance from that point back to the camera plane (the perpendicular distance), which determines what height the thing should be drawn as and where vertically. Move onto the next column if this distance is greater than the distance to the nearest wall.
      3. Make various calculations to take into account the true height of the line based on whether part of it is cut off from being at the edges of the screen.
      4. Draw the column.

Part 2.ii was wrongly getting the perpendicular distance by trying to use the column to determine which position on the camera plane to shoot a ray out to the intersection point in Part 2.i. That ray was not perpendicular, unfortunately. Instead, I needed to project from the intersection point back to the camera plane. The position on the camera plane won’t have anything to do with the column I am currently drawing, which feels a bit counterintuitive to me, but after really digging deep and analyzing what was happening, it all made sense.

So the fisheye was removed, but there was still the phenomenon of the doors seemingly approaching the camera whenever the camera rotated between cardinal positions.

That is, if I was facing north, the doors all looked fine. And if I was facing east, the doors looked fine. But in between, the doors looked like they were separating from the walls/floors/ceilings and getting closer and then receding back.

After some more debugging and analyzing, I realized something: the way I was interpolating between the orientation vectors was linear.

My orientation vector was (0, -1) if I was facing north, and it was (1, 0) if I was facing east, but when I was facing north-east, it was (0.5, 0.5). The first two vectors are unit vectors, but the ones between them are shorter.

Shorter unit vectors for the orientation vector means that doors appear to get closer to the camera.

Once I changed from linearly interpolating between vectors to linearly interpolating between angles and deriving the orientation vector from that angle, suddenly not only did the doors seem to move in sync with the rest of the dungeon elements but the dungeon in general seems to render more correctly.

I will admit that I kind of liked how the walls and such looked when turning before I made this fix. It was a little off, but not so much that you might think there was something obviously wrong.

But it is amazing how there is one algorithm for the ceilings and floors, another for the walls, and a third of “things”, and they all use the orientation vector, but only one looked wrong if the orientation vector wasn’t a unit vector.

But now that doors render correctly, the next step was to make them solid. Up until now I could walk through them, which made it easy to debug the rendering code so I can see what they looked like on their reverse without having to go out of my way to walk around doors.

But now they block your way. I made a custom message for what you try to walk through a door.

Next was to ensure the menu changed to let you try to open a closed door.

And then I ran out of time for the week.

The remaining work on doors is to animate them opening when you click open, to allow you to close a door again, and to also let an open door block your path. That is, if you are facing north, and the hinge is on the left, a closed door blocks your path north, but an opened door blocks your path west.

Since doors can be part of a grid cell but can block movement both out of the grid cell and into it, my obstacle detection code feels a bit long. I need to check if you are trying to leave a grid cell through a door or if you are entering a grid cell through a door, and now I need to check if those doors are similarly blocking adjacent directions if they are opened.

But I am fairly pleased to finally be working on something more interesting than merely drawing the door.

At least, I hope I’m done with that effort.

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 how door rendering was trickier than anticipated for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

The tricks just kept coming.

Sprints 19 & 20: Pre-production and initialization

Planned and incomplete:

• Doors can be opened/closed

I’ll admit that I’m a bit frustrated. I’ve been working on rendering doors for way too long. Granted, in terms of actual hours, it is less than a week’s worth of full-time effort, but since I’m working on this project part-time, it has taken almost a month of effort according to the calendar on the wall.

Basically, I have doors rendering in the correct horizontal position, but vertically they seem to appear to be too close to the camera or too far, and while I am sure it has to do with a math error somewhere, I’m struggling to find that error.

When it came to drawing walls, I remember having a strange issue with how the walls were appearing until I figured out that I needed to truncate a value to an integer. Then suddenly a lot of things looked perfect.

And I suspect that there is something similar going on here.

I tinted the door and the entryway with a red color so it is easier to see how it doesn’t line up with the walls/floors, especially when seen at the edges of the view.

Even weirder is that if you turn to face a different direction, the doors seem to slide much closer to the camera before receding back to their only slightly wrong position.

Why can’t I just use the wall rendering code? That code is taking shortcuts, with the assumption that walls are aligned with grid edges. Calculating the distance a ray travels to a wall involves incrementally adding to a value until you know how far along the grid that ray has traveled.

In this case, a “thing” can be a line segment that does not align cleanly with the edges of a grid cell, and so calculating the distance is done more directly. If I calculate the distance to a door from the player’s position, I’ll get a fisheye effect. Weirdly, as my calculations take that into account by trying to find the perpendicular distance instead of the direct distance, I still get a fisheye effect, but it is less severe.

And it still doesn’t explain why the doors seem to move closer when turning, whether I am calculating the distance directly or not.

I’m sure I’ll figure it out, but it would be nice if I could do so more quickly.

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 started work on designing and implementing doors for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I got doors to render quite soon after publishing that report, but there were a few tricky things happening that I needed to address.

Sprints 18: Pre-production and initialization

Planned and incomplete:

• Doors can be opened/closed

The floors and ceilings render one way, the walls render another way, and then I have “things” like doors, which kinda need to act like walls, only they aren’t necessarily at grid edges the way walls are.

It took a little effort, but I was able to render doors in the arbitrary location I wanted them to be in.

Things need to render from back to front, and so they needed to pay attention to a depth buffer.

Then I needed to make sure that if the door was seen from an angle that it looked like it took space at an angle.

This involved interpolating a transform calculation between the hinge side of the door to the far side of the door.

I tried to make sure that the door was not taking up the entire height of the wall, since there is supposed to be a doorframe, and my math never quite worked out, but then I decided to just make the source image for the door itself with transparent pixels at the top to make it easier on me.

I had some weird glitches in which the door should be behind the player but still sometimes seemed to render in front of the player taking up the entire render area. I am sure there was some math I was not doing right, but at the moment my solution has been partially to hack in exceptions to when it should draw the door. I’m not happy with it, but sometimes it is easier to detect the problem than it is to figure out why the problem was happening.

One remaining challenge has been to fix the fisheye effect I was seeing when the door was drawn from an angle, an effect that was very obvious when the camera turned, since the walls don’t have the same effect.

I recognized that it was happening as a direct result of how I was interpolating the calculated distance between the hinge side and the far side of the door. I needed to use the perpendicular distance to the camera plane rather than the distance directly to the point source of the ray.

Drawing walls involves shooting rays from the leftmost column to the rightmost column, stepping through the grid cells until a wall is hit, then rendering that vertical slice of the wall.

When drawing doors, I can determine which column to start drawing from and which column to end drawing on, and then I interpolate both the source image vertical slices and the target vertical slice to draw it to, but I think I’ll need to modify how those rays are cast to similarly use the camera plane whereas at the moment I don’t.

Another thing I need to do is draw the door from the other side. The code technically could draw it in reverse, and in fact it did, but one of my hack/fixes prevents it now, so I will need to address it.

And of course, making the door functional will be key. There’s no point in having doors if they can’t be opened and closed. Ideally they should animate swinging open. And they should block movement through them in either orientation.

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!