Work Post

11:23pm - So last time on Relee's Coding Blog I figured out the time management system.

Today I'm going to try to go down that list of things you should have figured out before you start coding, and see if I have solutions for all of it.

The first four problems are all time problems, and should be handled by the time management system I went over yesterday. It'll handle determining whose turn it is, keeping track of future events and making them happen on schedule, handling effects with intervals denoted in absolute time, player turns, or monster turns, and making sure things still work right when players or monsters can have their speed change or be frozen/reanimated in time.

The next problems are space problems, and I'll try to figure them out now.

Part 1 is the representation of the map. I'll be using a 2D grid of nodes with various properties. Specifically, besides the basic properties of a node, they'll have a sprite, and a resource property with type and passage cost for A* and a 'hidden/revealed' flag for the player's perspective. I've seen some implementations that just use the sprite and have the others determined by what the sprite is, but hopefully a couple of integers will be easier to check. Mostly I'm doing this so I can reuse sprites.

Part 2 is saving and restoration of the map. I plan to save the map in json format. The sprites will be stored as a reference number, and the others are just numbers.

Part 3 is ranged effects, aiming, and obstructions. That's an interesting problem I hadn't really thought much about before. I suppose I'll use a line-casting function to see which tiles the potential attack would go through, and if any of them are blocking then it doesn't go through. Everything else will be percentages.

Part 4 is area effects and how they interact with restricted areas. When an effect would target a restricted area, like a non-open space, it might open it, or it might do nothing, depending on the nature of the area effect.

Part 5 is Player and/or monster gametime alterations of the map. That's going to be possible in this, since digging out the dungeon is what you do. It'll be done using the same action system that handles magic effects.

Part 6 is Planning and Pathfinding. Planning will be done by GOAP and Utility AI and Pathfinding will be A*.

Part 7 is illumination/field of view/line of sight. There's standard ways to do this in roguelikes already, I might just port the libtcod to GDScript and use that's methods.

Part 8 is Dungeon Generation. I don't have that figured out yet, and figured I wouldn't have to deal with for a while. There'll be a specific 'Generate Dungeon' function that sets up a new dungeon. It probably won't even be random for the prototype.


Those are the Space problems. Next comes Items problems.

Part 1 is picking up items. This is important because when you pick up an item it usually goes from being a world object to being a member of a list in your inventory. At the very least, even if you keep the internal representation of items the same, you have to remove it from 'the world'. I think the most straightforward way of dealing with this issue is to give item entities an 'onMap' switch and when it's false it doesn't worry about having anything displayed on the map. Then I can have the item switch from the on-map entity list to an inventory entity list for the mobs. There'll be all sorts of mobs carrying all sorts of items.

Part 2 is putting down items. The opposite of the previous.

Part 3 is wearing and wielding. I suppose there does need to be some way for an item to say 'use this sprite on your paperdoll' when it's been equipped. So I'll include that on item entities.

Part 4 is using as a weapon and/or ammo. I think it means using non-weapon items as a weapon? I don't think I'll make that possible. You can only equip items to their appropriate slots.

Part 5 is Eatig and Drinking. When you eat an item, it gets consumed and the entity deleted and released.

Part 6 is putting it in a container. That works the same as putting it in your inventory, so the same as picking it up, only it's the container picking it up from your inventory.

Part 7 is using it as a container. Containers will be flagged as such in their item data.

Part 8 is Attempting to break the item. If you succeed then the item runs a break operation.

Part 9 is transforming one thing into another. There won't be any transformations where properties are maintained between two entities so it'll be a straight 'delete this, create this' operation.



The last items in the checklist are things I'll have to take care of when I get to coding the basic architecture of the systems. Making sure that the AI is exetensible, making sure the stats are functional...

Oh here's an interesting one. Determining hou items and monsters will be represented in live game data without tangling up your references so pointers to an item or a monster exist at more than one place and can be left dangling when it is killed/destroyed.

I hadn't thought of that problem when I was thinking about how to handle my entities. I had planned on having multiple lists of references to different things, but that means I have to clean up in many places and things might get missed in the shuffle of deletion order.

So, let's see... One big entity list for all the things doesn't seem like a good idea either.

Maybe they can only exist in one list at a time? The world entity list, and the inventories of entities in the world. I'm thinking there'll have to be a flag that determines if something can be picked up, and another to determine if it can be placed into a container. Besides not wanting containers of containers of containers, I want to make sure huge things don't go in tiny things.

2:09am - Alright I think that's enough for now. I need to take a break and maybe get some sleep.