Messages

1

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 03, 2013, 08:57:30 AM »

I made a higher dimensional prototype that uses a series of 1D representations to communicate the environment to the player.

https://dl.dropboxusercontent.com/s/cjkx4w3gwl07zk8/ndrl.swf

2

Programming / Re: Cooldown based timing system for complex RL timing.

« on: November 24, 2012, 04:40:54 PM »

Cheers for the suggestions Xan.

Omnomnom: I have considered that, and certainly if you designed your monsters to have a great variety of different speeds things could get very complicated very quickly.  A simple UI resolution is to display on each monsters its time till next action, and have a sidebar on your player telling you how much time each of your actions cost, thereby shifting the calculating onto the computer.  You could inspect monsters to see their range of possible actions, and how long they take.  Certainly player understanding is the most problematic element of complex timing, and some additional design effort would be required in this area.

Complex timing in general does add complexity to the game, and also a new area of strategy.  DoomRL uses complex time with a similar system to this and it is not too difficult for the player to grasp, despite there being little in the way of player aids about monster speed, and player actions being non-interruptible and highly variable in time (from ~0.1 seconds to 4.0 seconds).

For mid loading or rear loading actions... I don't like them much myself.  They are ok for long actions but I don't find them suitable for the short actions that comprise most of the things you do in RLs, attacking, moving, drinking potions, casting spells.  With regard to your monster example, that is purely down to specific implementation, it's up to the designer to avoid making such a undesirable monster.

3

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?

4

Early Dev / Re: NDRL: n-Dimensional Roguelike

« on: July 27, 2012, 05:35:55 AM »

I can win 45% - 75% of worlds by scanning each axis to find the position that minimises its distance to the portal. In a lot of them, I find myself 2 squares away from the horror before I get next to the portal. In those cases I go back the way I came, make some random moves on the other axes, and repeat (hoping that there are now asteroids between me and the horror).

As far as I'm concerned, it's random whether or not that procedure works. Sometimes the horror doesn't get stuck behind a rock, and stays 2 squares away. Since it's impossible to tell which two axes it's close on, eventually all of the axes are stuck against a wall, and I have to guess which axis won't get me killed if I move along it.

Edit: OK, I just got to level 13 or 14. My two feature requests would be:

1. If I walk along the same axis two turns in a row and the distances to the portal are n+1, n, n+1, then the point along that axis where the portal distance was n should be highlighted. It's information the player has, this just saves them from wasting paper writing down which coordinates the portal occupies.

2. Either include a rest command, or highlight the two axes that would lead to the horror. That way when I get killed, it will feel like I was killed because I was stupid enough to get cornered, not because I guessed wrong.

Edit: Oh, space is the rest command! That should be made clear in the game.

Also I've spawned on an asteroid a few times. Not a big deal, but a little weird.

Yep, #1 is something I've thought of too, and will implement if I develop this further with the same UI.  For the spawning, only the portal has checking for asteroids on it's spawn, because the collision is checked by the square you are moving to.  Space to rest is given in the instruction screen, although I should perhaps make it more prominent.

5

Early Dev / Re: NDRL: n-Dimensional Roguelike

« on: July 25, 2012, 02:19:45 PM »

I tried it, and it's not really a roguelike per say, but a unique puzzle game. It's a bit confusing. I'm not sure what I'm supposed to be looking at with the different axis views (is it in a third dimension?), but oh well. I thought that it was a bit of fun, but it got a bit repetitive. The levels are mostly the same except for the position of the portal, horror, and the space you have. I'm interested as to where this game goes in the future.

You are quite right, it really isn't a roguelike at present (and I'm really not sure if I will develop it in that direction - I get a very puzzle game feel from it), the reason the levels feel the same is they are all randomly generated at the moment, and mostly require the same tactics to defeat.  The game generates a map with a random side length (the vertical length of the columns) and a random (restricted to 3-5 until level 8 ) number of spatial dimensions, an axial view of each of which is represented by the vertical columns.  Each space is then randomly filled or empty (depending on the size of the environment) and the horror, portal and player are randomly placed.

6

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.


https://dl.dropbox.com/s/cjkx4w3gwl07zk8/ndrl.swf

7

Programming / Re: Roguelike timing systems.

« on: June 30, 2012, 06:01:41 PM »

I'm not worried about the computational side of it, the thing that I like about the RL interface is that it's very quick and simple to use.  If I move away from a grid to a continuous 2d plane I need to allow for a lot more variety of inputs, and without discrete locations player mental gymnastics are more complex.

Of course, the current in my prototype is by no means easy to use, but at least it's different.  If I switched to continuous position variable time doesn't really make any sense, and that's the interesting part about this idea to me.

8

Programming / Re: Roguelike timing systems.

« on: June 30, 2012, 12:46:49 PM »

If I did that I would need a more sophisticated control scheme, or it would just be odd.

9

Programming / Re: Roguelike timing systems.

« on: June 29, 2012, 05:44:13 AM »

It works.

I can't reasonably determine how fast I'm going.

Max velocities would be nice.

Yep, it doesn't have very useful UI aids yet.  But it's running on the time system I proposed, even if it's only keeping track of the player at the moment.  I'll implement a monster, attack and something to make it easier to see where you are going next.

10

Programming / Re: Roguelike timing systems.

« on: June 28, 2012, 08:06:00 PM »

http://www.mediafire.com/?h6nm8m88bafha6c

You'll need flash player to run it.  The rounding is dodgy at the moment, but don't mind that.

11

Programming / Re: Roguelike timing systems.

« on: June 28, 2012, 07:00:11 AM »

I understand the interface I'm planning is quite counter intuitive and will need quite a lot of UI aids for the player.  I'll post up my prototype when I've implemented a timing system in it.  I don't mind if the game will be a bit more ponderous than the usual RL because I'm aiming for a more tactical experience, under the roguelike control scheme.

Not all of the problems pointed out will apply though, as I am planning to have a 0s (or perhaps very small) attack time cost, and run attacks on a separate cooldown to movement.  This is to allow you to fight and move at the same time, creating a positioning game.  With regard to movement - it won't have an actual move cost, the time that passes each movement turn will be the amount of time it takes for you to traverse a single square.  Your movement input adds velocity to your current velocity, and then your avatar is moved one square according to that velocity.

12

Programming / Re: Roguelike timing systems.

« on: June 27, 2012, 08:20:46 AM »

AS is awesome- does a lot of work for you, but I'd recommend learning HaXe NME. It's the same syntax as AS only better in every way. They've wrapped the Flash API such that it can target multiple platforms. It's easy and accessible and more powerful- do it. www.haxenme.org.


Why the need for complex timing? How much of a role does it actually play relative to the end user as per your design?

Pretty central, I'm modelling momentum, while retaining single square movement. This requires variable time.  The player will be interacting directly with this system.


And Jo, that really does sound like a mess 

13

Programming / Re: Roguelike timing systems.

« on: June 27, 2012, 05:13:11 AM »

In my case, the design calls for more sophisticated timing rules than you usually see in a roguelike, with highly variable amounts of time passing per action (dependant on conditions) and multiple independent cooloffs per actor, to separate out the attack and movement steps (and possibly others, but starting small here!).  At the moment I am working on other projects in Actionscript 3, but I wouldn't be shy about learning a different language, although I am by now means an advanced programmer.

14

Programming / Re: Roguelike timing systems.

« on: June 26, 2012, 04:39:00 PM »

Could this become an issue if you are working in a slower language like python?

15

Programming / Re: Roguelike timing systems.

« on: June 26, 2012, 03:07:04 PM »

Great to know, thanks!