![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee8: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.
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.
