Work Post

2:36am - Well, my Birthday is officially over, but I'm still up. I played one of my gifts for a while, and an Xmas gift from last Xmas also, and now I'm feeling like working. So, first I'm going to make a new section in OneNote for the project. There. Now I'm going to have to figure out what I need to do to make the prototype.

I'm thinking it'll be a top-down perspective game, but I'm not sure if I want to make it a single floor 'grid' of tiles or if I should make something more like Dwarf Fortress, with a 3D 'matrix' of tiles.

The latter is obviously much more difficult in every way, but it would make things much more interesting. On the other hand, I could make the prototype a grid and make the actual game a matrix after I know that the theory is fun. That's probably the best way to go about it.

So I'll make a grid of tiles. I'm not sure the best way to do that in Godot. I've done it one way before when I was working in Unity, following a tutorial, but it was kind of a weird way to do it then.

The most straight forward way, that is the first thing that comes to mind, would be to make a node for the grid and fill it procedurally with prefab nodes for the tiles, and have the grid node use a script to keep track of them all and reference them. I have a feeling this will run into performance issues but I need to try it to be sure.

Now what about mobiles... How should they interact with the environment? Should they be physics objects, bouncing around between colliders? Or perhaps they should be limited to grid-based movement?

I'm not sure on this one. I had been thinking that I'd just make them physics-based, but with a tile matrix that becomes much more complex, basically a 3D game, so I might as well make it 3D instead of 2D. But Godot isn't the best at 3D right now, and there's a lot more work to making 3D graphics look nice. I'd like to keep it to 2D.

So I think I should tie the mobiles down to the tiles. I can animate them moving between the tiles if I want to but they'll be stuck walking tile-to-tile.

It's beginning to look a lot like Dwarf Fortress. Which is a bit funny since I was thinking that later on I'd like to make it so that the player could start their dungeon by branching off from an abandonned dwarven settlement or ruin as a start option.

So, I don't want the tiles and creatures to be too interconnected. How do I keep them seperate but still touching?

My first thought was to have the tiles contain whatever occupies them, but it seems like that would tie them together too much. Moving creatures would mean reparenting them constantly.

I'd rather have the creatures be on their own 'layer' above the grid. Then in that case, maybe they keep a reference to which tile they're on?

But then, how would they check a tile to see if it's occupied? If the tile doesn't know what's in it, you couldn't ask the tile for that information. I'd have to have a second grid for the creatures and static objects, and reference the location based on lining them up. That seems like an even bigger mess than the other.

So the tiles should know what's in them after all, but perhaps the tiles aren't the parent of the objects and mobiles they contain. Instead, what if they merely contain a reference list of the mobiles or objects they contain? And the mobiles and objects likewise have a reference back to their container? Then they could figure out where they are, what's around them, and everything. This way they'd be seperate but together.

3:16am - This is going to have a lot in common with Roguelikes so I think I'll do some research on Roguelikes built in Godot and see how they went about it.

3:47am - Okay I'm spent. I've got more research to do on Roguelikes and how they handle their problems, but for now I'm good. Take care!

Work Post

8:58pm - Enjoying the games I got for my Birthday, but want to spend some time working.

So I did some research on Roguelikes again, it's not my first time reading some of these articles.

One problem with comparing the Roguelike Solution to what I'm doing is that Roguelikes often only have a division between empty space and walls, nothing more exotic than that. Certainly the simpler ones do it that way. They're also smaller, with less enemies. I saw one roguelike tutorial where they had a 2d grid of enum values for the map, and a list of entities that they would iterate through to find out if they were blocking. That seems kind of silly to me, going over a list of every object in the game every time you want to test for movement.

That said, I like the idea of registering references to the entities on lists. A list of mobiles and a list of items probably. Maybe a list of magic effects?

Maybe a list of turns, so that I can pop things off the turn order and push them back on the other end?

On the other hand, there's a lot of different ideas for scheduling in roguelike styled games, and I imagine that would carry over to turn-based games in general.

11:08pm - So I want to record this so that I don't forget it or lose it again.

I've finally decoded how this time management system works. http://www.roguebasin.com/index.php?title=An_elegant_time-management_system_for_roguelikes

The easy part to understand is that there's a doubly linked list with a traveling sentinel value in it. The hard part to understand is the Turbo Pascal code. The Python code at the end is very different and has even less explanation.

The way it works is that when an entity is added to the list, it gives an amount of time/energy until it can act, and three pointers. The first pointer is to the entity itself, the second is to a function that will return a 'rate' value that the time/energy is increased by, and the third is to a function that will run when the time/energy is 0 or more, returning the value that the time/energy is reduced by.

Then when you run the ProgressTime function, it first runs the rate function, using the entity as its parameter, and adds the return value to the time/energy value. Then, if the time/energy value is over 0, it runs the cost function, using the entity as its parameter, and subtracts the return value from the time/energy value. It does this for every entry in the list until it returns to the sentinel entry is found again.

The way you'd have a creature interact with this time system is that you have it added to the list, then when its turn comes along you use the rate function to return that creature's speed value, and the cost function to run that creature's AI function, decide on an action, process that action, and return the amount of energy that action cost.

Likewise for a player if you put one in there. You can keep running the ProgressTime function and when the player's turn is up, it'll wait for input from the UI instead of an AI program. Then it returns the energy the action cost and continues processing.



So that's basically the time management system I'll use. The game will seem to be in real time though, because the player doesn't have an avatar at this stage to worry about. How that'll work is that it'll be constantly running through the processing of actions, but it'll run through the loop at a set 'frame rate' so that the mobiles aren't dashing all over the place in a blink.


Another article from that site, http://www.roguebasin.com/index.php?title=Code_design_basics is somewhat a good reference for things to have settled before you begin, to avoid having to refactor. So I'll see what I've got so far.

I'm already feeling spent, though. I've been working for a couple hours so I think it's a good time to settle in with a nice Video Game.