I tried to do something a little different the other day – I decided to microblog my morning work on DFP in extreme detail on Mastodon, just in case it was of interest to people. It had a second purpose – to look at my own purpose and style, see what I could learn about my own way of operating (if anything useful at all).

For posterity, and in case it’s of interest people, I am putting the entire log, from about 9am to 12pm, here in this post.

Note: The italicised comments which look like this and begin with note are comments I have added while compiling these mastodon posts into this blog post. They are intended to add a bit more context, or correct something.

Wednesday Morning on Dungeons of Freeport

09:02

First up – fixing a bug I just found in the way ‘natural’ parts of the level work.

The game generates many small piles of rocks around certain objects stored in the game map. In Dungeons, these appear randomly in the corner of rooms. In the hub world / town map, they appear near boulders.

The reason is this: I want them to re-spawn every day without faffing around with ‘unique item IDs’ (which are used to put certain items in the hub world the player can take only once), and I want them a LITTLE random in where they are.

The reason I want small rocks en masse at ALL is – your first ranged weapon is a sling, and while the ammunition is rocks and so there for more or less ‘infinite’, you have to put the effort in to collect them. Either around dungeons, or at the quarry before you go into a dungeon each day.

I just realised when I changed the way items were loading, I broke the existence of those ‘natural’ proc gen items.

Fixed that.

Note: the way I have certain objects ‘spawn’ other objects around them when the level is loaded is a neat feature I think, but one that caused me some grief. The small stones they spawn are tiny and cause no issues, but spawing those impassible boulders dynamically for SOME reason kept blocking things. It took me a while to figure out which rooky proc gen mistake I made to place these objects covering passageways in the dungeons. Thing is, it did make me consider adding a way for players to move heavy/bulky objects. Pushing them. I didn’t do it, but it’s tempting. Might add a unique puzzle element to the dungeons if done well.

09:04

Aaand now a minor issue… it crashes when you walk over rocks.

D’oh.

Time to fix that. Wonder when that bug was introduced?

Ah. My own fuckup. Items can be ‘generic’ and have no class (ammunition, keys, etc) or be unique items that have an itemClass. I am an idiot and didn’t guard against whcih one they are before accessing it. Weird though, surprised I hadn’t seen that bug recently.

Note: this bug was introduced when moving the game from text mode to graphical. In text mode, the screen is rendered every time it’s dirty. That is, every time the player moves, does something, or a menu changes. A lot of the text rendering code is now in a dfp_text.cpp file, which constantly returns text for any visible TextElement, updating as required. The problem is that sometimes these bits of code were being run under different circumstances to when they were run in the original version, meaning original null pointer gating which happened higher in the calls tack were no longer happening. A reminder to me to err on the side of more aggressive null pointer checking.

09:09

Ah. That’s better. One problem: “Pick Up Rock” isn’t accurate… if you pick up ammunition like rocks, it’ll grab as many as you can hold in your inventory.

Better change that. (Yes I’m changing many small bugs as I find them now.)

Note: fixing small bugs as I find them is sometimes a good way to go, I feel, but other times it just slows you down. As I get closer to done I plan to add more items to my ‘bugs to fix’ list instead of constantly fixing them.

09:48

PHEW. That was annoying. Fixing it took me down a rabbit hole of “Oh I don’t have this helper method for Container() items. Oh wait, to add that helper function I have to add the following helper methods for Item() objects…” etc etc 

But it’s done.

09:55

Next up: having collected a big ‘ole pile of rocks, I’m going to venture into a dungeon.

Hmmm… there’s no message to indicate you selected a dungeon.

Will quickly fix that…

There we go.

DUNGEON TIME!

Note: The messages screen is a neat one, as it shows all non-‘simple’ messages. So, things like “you can’t go through the noise because there’s a tree there, duh” don’t stay in your message history, but people saying things or sounds being heard or actions you’ve taken? They stay. The message history also knows what ‘turn’ the events happened on, and while that’s currently not displayed… I might add that feature later.

09:56

And into the dungeon I go!

09:57

A WICKED CHUDLING!

You cannot escape. The fight is on.

10:00

Ahhh. First problem appears.

There’s no “you are in attack selection mode” UI for some reason.

Going to investigate that. I think I never implemented yet. Let’s see how long it takes me…

11:14

Getting there.

Window appears, just populating the details now.

Note: this process, as listed, took me a long time considering I had to add two UI elements, 2 UI commands and 1 text command. It actually didn’t, but I left something out of the below post – I also found and fixed a small but annoying bug which meant the window wasn’t correctly sitting in the right part of the screen. I allow ‘position’ for top level UI elements to have positions in the negative. So in this case, its position is -8, which translates to its right side being 8 pixels from the right side of the screen.

11:45

That’s the detail pane done I think? That’s enough detail.

Note: I am erring on the side of fuzzy logic for this game. While damage is shown in the dice format that’s actually used, the “vs” element above is only shown in debug mode. The thing is… I think I am going to show it permanently. I don’t think “-2 vs 0” is a bad thing to expose to players. Also, yeah… ‘IMPOSSIBLE’ is pretty pessimistic.

Further Note: the combat ‘dice’ logic works like this: the attacker and defender roll a D6, and add their respective pools. For example, the attacker, if using a sword, adds their strength pool. If the attacker rolls a 6 (and that number is still bigger than the defender’s result) a critical success happens. If the number is otherwise larger than the defender’s result, it’s a success. Equals means a draw. Less means a failure to hit, and less PLUS rolling a 1 means a critical fumble. What these do varies depending on what is being rolled for. All versus skill checks in the game are done like this.

12:00

Yep, okay. Two more minor bug fixes and good to go. That’ll do for this morning. Lunch time!

Final notes: this was a moderately productive morning for me. It’s a pretty decent breakdown of a standard good-but-not-great half-day of work. As always, sometimes I get a lot more done – and other times I run into a problem that causes me to stop what I’m doing and focus on that for entirely too much time.