My first thoughts on turns and game timing were directed towards a priority queue of events. A creature takes a turn, then adds itself back on the queue for a later time. I thought about leveraging the queue for other things, like when hunger starts to take a toll, poisons that wear off over time, etc. But the more I go into coding it, I started to realize that efficiently managing that queue was going to be hard. So I decided to save myself the days and days of coding and testing and opted for a simpler solution. Like many others I'm using an energy system, where the game has an internal loop, each loop being a sort of 'game turn'. Any object that takes actual turns will have an amount of energy added to it, and when a certain amount of energy is reached, that object takes an actual turn and loses some energy. What's nice is you can adjust how fast a creature gets to take a turn by adjusting the amount of energy they gain each 'game turn'. Currently, objects get 30 energy multiplied or divided by a speed factor each game turn, and they get a turn once they have at least 600 energy. When the speed factor starts to adjust the amount of energy an object gets, I realize that the higher the required energy for a turn is, the more accurate the speed increase is. I'll work out the final numbers once I have a bunch of objects all gaining energy and taking turns so I can work out whether there's a performance issue. Anyway, the system uses a linear approach to speed. The speed factor is 1.0 if the object's speed is 0. For speeds greater than zero, the 30 is multiplied by 1.0 + 0.1 * speed. So +10 speed means you gain 2X the energy, +20 speed means you gain 3X the energy. For speeds less than zero, the factor is calculated the same, but the 30 is divided by it instead. So 10 speed means you gain 1/2 the energy and 20 means you gain 1/3 the energy. I also support actions that take longer than a normal turn, something like putting on heavy armor. I'll explain how I do this in my next post.

