Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Destroid

Pages: [1]
Programming / Cooldown based timing system for complex RL timing.
« on: November 24, 2012, 12:27:15 PM »
This system is a variant of the energy based systems presented on the roguebasin wiki.  I believe it is the most flexible way to implement an energy system in a roguelike that requires sophisticated timing rules.  It is very likely a game out there uses this exact implementation, but I've yet to see it documented.

I shall refer to anything in the game which requires time keeping as a 'timedEntity'.  Mostly this will be actors, but sometimes it will be other game objects, or more abstracts things such as tasks performed by actors.

Each timedObject in the game has a cooldown attribute, which begins at 0.  When a timedObject acts, its cooldown is increased by the relevant amount for the action, say 100 for moving or 50 for drinking a potion.  Each timedObject may have any value for its various cooldown costs and each action may be customised individually.  Each time a new action is demanded, the game loops through the timedObjects, and determines the timedObject with the lowest cooldown.  All cooldowns are then decremented by the amount of cooldown said timedObject has, and said timedObject takes its action.  The process is repeated as the game loops.

This system allows for essentially limitless variety in speed of actions and various ways of modifying speed - individual actions may be slowed by a multplier or fixed amount, or an entire timedObject may have its cooldown increased or decreased by an amount.  If you are willing to spend a little more time determining the next timedObject to act (via iterating instead of finding the lowest cooldown) multipliers can be applied to cooldown decrements per tick.  There is no ceiling on how lengthy an action may be, and no 'saving up' of actions (unless you allow negative cooldown values).

Other timing based effects, such as damage over time, dissipating gas clouds, traditional interuptible actions such as resting, changing armor, or anything else may be handled under the same system.  By creating additional timedObjects which interact with their host timedObject, preventing them from acting while they are in effect, damaging them, etc.  In this way sophisticated or lengthy interactions can be modelled, outside of the standard 'act now, pay later' paradigm.

I'm pretty confident this system can handle pretty much any timing situation a roguelike will demand, with a fairly simple system, using the same timing rules for anything that is based on time (players, monsters, status effects, spell cooloffs etc).  Does anyone see any flaws?  Areas that could be made simpler?  Is there a game you know of using this system?  A situation that cannot be timed by this system?

Early Dev / NDRL: n-Dimensional Roguelike
« on: July 25, 2012, 02:30:47 AM »
Hi, I've worked on this concept (heavily inspired by hyper-rogue) a bit lately and it currently displays most of the concepts I had in mind for it as a little side prototype.  It is named n-Dimensional as it's display and control system can handle as many as you like, however in game it will only display a maximum of nine at any one time.  Instructions are in the game, I'd love feedback on whether these are in fact adequate, or anywhere you were confused, understanding what is going on is probably the most tricky part of this game.  Currently it doesn't have many roguelike features (although I had them in mind when I conceived the game), it plays more like Pacman or a maze game.  The objective is simple, escape 20 levels to win the game, you die if you get caught.  If you don't die it probably would take around 15-25 minutes to complete the game, the difficulty takes a step up after level 7.

Programming / Roguelike timing systems.
« on: June 26, 2012, 01:17:10 PM »
Hi, I'm very new to designing roguelikes (and pretty new to gamedev in general) and was hashing out a few ideas, and one of them was the timing system.  In the end I thought a good system to do RL timing would be to have an array store all of your actors, and each engine tick step through the array to see if any actor is ready to act.  Readyness will be measured by a cooldown timer (or timers) that when they reach 0, the actor may take an action, filling it's cooldown back up again to an appropriate amount.

Then at one stage I looked over the time system section at roguebasin, and reading the systems there left me more confused than enlightened.  They talk about ordered queues and the like, but I really don't understand the benefits of having such a thing, versus (what I perceive to be) the simpler system outlined above.  Is there something I'm missing?  Is my system a variant on a standard but I'm just not getting it?  Or is there a good reason to re-order actors, or use a queue?

Pages: [1]