Messages

1

Other Announcements / Re: I'm new here, and I've noticed this..

« on: October 02, 2009, 06:48:07 PM »

There are about 5 spambots trying to register weekly, but they can create lots of hassle... I dont have enough Action Points left to develop an alternate captcha or modification, I will leave it open for a week and see how it works

I really like recaptcha.  It's easy, it's simple, and it's FREE.  I'm pretty bad at PHP/Javascript and I figured how to use it, so that's saying something.  There are instructions on how to add it and use it, and they are pretty idiot proof instructions.  You just have to get the key.

http://recaptcha.net/

They look professional and you can play audio too if the thing is hard to make out.

2

Programming / Re: Balancing speed as a main attribute

« on: October 02, 2009, 06:36:23 PM »

I'm using speed as a basic stat, sort of.  Speed can be increased by gear, but only by relatively small increments.   Speed can also be increased by a particular skill, however only up to a 20% increase (A turn might take a character 2 arbitraty units of time prior and 1.6 units after), but that can only be done by taking a particular class path that forgoes combat prowess for escape tools.

I'm not a believer of double/tripple movement characters.  I think that would be too hard to balance unless you assume every character has access to rings of speed or whatever throughout the game.  But I like small increments leading up to a 1.5 speed character.  Maybe even a 1.8 if they really push it.  But since every player has access to speed increases, the skill that increases speed as a secondary effect is rather limited in comparative effect.

If I had to put a number on it, maybe 20% faster is worth doing 60% more damage?  I'm not sure it's a 1 to 3 ratio, I think speed gets better and better the higher it gets over doing more damage.  Moving twice as fast as a monster is worth doing 10x the damage, though that would make the game play tedious.

Best to limit speeds effect to something small like 20-60% over base speed for standard play.  If you want more out of a speed attribute, you could aways add additional damage combat modifiers to the stat.

3

Programming / Re: RougeLike Step by Step Tutorial?

« on: October 02, 2009, 06:19:27 PM »

There are two things you might want to do before a serious attempt.  Keep in mind there are a variety of approaches to software development.  This is just the way I would handle it.

1) Understanding all of the mechanics of what you are trying to do.

  a) User input, reading key strokes.
  b) Output (display), how you will display characters to a screen.  
  c)  Basic computer science principles.
  d) Saving and loading a file.

Here you need an understanding of what sort of libraries you need, what you can and cannot do with the language.   If you allow characters to save their game, you don't want 100 megabyte save files.  There isn't really any excuse for slow code with a roguelike either.  You might want to view some of the procedural content generation articles and some of the AI articles.

2) High level view of what your code will eventually look like

  a)  Data Structures
  b)  Classes
  c)  Methods

Here you might make a mock up of how your code might end up working from a high level view.  You might think about how you will handle spells/items/monsters/time/players/maps.  What sort of prorperties will each of these objects have and how will they relate to the game state.   You will probably have a main class, that contains instances of each of the objects.

Here is an example for a monster object.

Object:  Monster
Variables:  String name;
                  int px, py;
                  char c;
Methods:   Act(int time, player p, map char[][]){}


Granted your code will eventually grow, you want to have some idea on how everything will work.  Anyway, content is probably much harder to deal with than the actually programming.  So mess around, and start doing lots of designing.

Get out a sketch pad and start making diagrams, skill lists, level outlines, and interface display.  Think of what the plot will be and what the game play will be like.

4

Other Announcements / Re: Shockfrost

« on: September 25, 2009, 05:42:42 PM »

Man I have no idea how you would conceivably implement 1/10 of that stuff.

I don't think he had much experience in programming.  It's not as simple as just willing things into existence unfortunately.

5

Programming / Re: Movement and Circular FOV

« on: September 02, 2009, 05:53:38 PM »

Another idea is to have a roguelike with lots of mirrors (and maybe portals), which would affect field of vision, there could be also some special effects, for example:

Did you see the youtube video of ascii portal?  Now that is some sweet ascii 2d FOV.

6

Temple of the Roguelike / Re: Livening up Roguetemple

« on: September 02, 2009, 05:43:09 PM »

One of the problems for roguetemple is it's audience is focused on roguelike development and not playing.  Well that's not a problem per say, but that audience is smaller.

Most of the players are interested in the one specific game they play and most games have their own independent side area, something that is necessary.

I don't really have a solution in mind, but it's not a bad thing to attract developers.  Trying to get more of the developers from other games to post here would be a good start though, so I second the interviews.

Also, maybe directing some more topics on implementing features beyond the fov, map generation discussions, and basic AI that tends to dominate roguelike discussion despite the fact all of those are relatively easy to do and take a small fraction of the time necessary to develop a game.

Stuff like power curves, or player choices, skill system vs leveling, religion, and other stuff like that would make the development discussions more interesting.

Well, that's what I am interested in at least.

How about, The Roguelike Item Game Megathread!  Or, The Roguelike Religion Megathread!

Now that would be very cool stuff.  I'd love to hear what developers were thinking when they put in their identification games, or how religion is implemented in various roguelikes.  Status effects could be cool too, every major roguelike seems to implement confusion, fear, and poison nowadays.  Let's see a poll bands vs. hacks and discuss the differences and what that means for game play.

I'd love to talk to other developers about their ideas.  I find that stuff very interesting and picking their brains would help keep me motivated.

7

Programming / Re: Movement and Circular FOV

« on: August 26, 2009, 10:40:45 PM »

Has anyone made a far sighted roguelike with donut shaped FoV?

It would be extra challenging until you can find some bifocals.

8

Classic Roguelikes / Re: The greatness of Crawl

« on: August 24, 2009, 03:54:36 PM »

I think crawl is an amazing game as well.   I love it's conservative and front loaded nature.  There is a long and dangerous dungeon to delve, but most games are short, simple, and sweet.  The unobtainable gives the game its mystery and charm.  There is great depth and scale to the game, but it serves more as atmosphere and setting than as part of the game play experience.

How many of us have actually beaten crawl or experienced much of the side dungeons?  It doesn't mater though, just knowing so much is there adds to the fun and the sense you are traversing a truly terrible world.

To those of us who have made it to mid game, it tends to become more of a slow and drawn out slog.  But fortunately, the game kills you off before the suspense is ruined and the anticipation of what could be is met with the naked reality of what is.

I think I love the sense of a great beyond most about roguelikes, and crawl serves up the unknown and unexperienced in spades.  The player merely tiptoes around the maw of a vast abyss.  You may conquer the beast but victory is immaterial to it's enjoyment.

My favorite classes/races are sludge elf transmuters, vampire monks/necromancers, and demon spawn chaos knights of makhleb.  That and picking up namelex as a god is great fun.

I've never beaten the game.  I tend to get bored and/or die when I get fairly far and take a break from the game.  I've made it to Zot but the game gets tedious for me around level 12 where I tend to die.

:edit

I just picked it up again, and love mummies.  I haven't had much luck, but It's nice playing the game without a food clock and grinding.

9

Programming / Re: Representing agility

« on: August 24, 2009, 06:22:59 AM »

OO does not matter here. I think the problem is whether you have a player-centric (player is special) or world-centric (player is just a creature with special intelligence) view. The method I described is natural for the world-centric view, treating the player so differently than monsters in the speed system looks strange. As you noticed, you get some artifacts (although I don't see any situation where they would be noticeable for the player, except if the monsters fight each other). Unoptimized pseudocode follows:

gametime = 0;
foreach creature m in list if(m.t < gametime) gametime = m.t;
foreach creature m in list if(m.t == gametime) {
  m.act(); // which chooses an action (by UI for players and AI for monsters), performs it, and includes m.t += actionMod / speed
  }

    To be honest I could get rid of artifacts by doing something similar.  Just sorting by ap stored making a pass allowing them to act, then repeating until none can act again ending with a sorted list again and the player gaining control.  Ultimately it's seems more or less the same then with the difference being set game time, vs player giving ap.  So yeah, I suppose it depends on if the player is center to the game world and allows monsters to act. Though this doesn't mean the player can't also be a monster, and any implementation is going to end up with the player being some sort of special case.

     It just seems more intuitive to me the other way, it's neat seeing this implementation though.

  Also technically, having a monster object with a method act is object oriented design =p.

10

Programming / Re: Representing agility

« on: August 23, 2009, 05:13:25 PM »

I don't think it is that super easy, with all this AP conversion. Just remember a "time for next action" counter (T for short) for each creature (or another kind of event); the creature with the smallest T always acts first; the action increases T by a value dependant on the action type and the creature's speed. This is simpler IMO.

Well it's pretty simple really using an object oriented approach.

For the player making an action you'd just have something like this, where time is in inverse of speed and action mod is the modifier say for an attack could be .8 or something.

double time = (1.0/speed)*actionMod
foreach monster m in list
   m.act(time)

And in the monster class you'd just have a method act which handles the AI and a double ap which stores built up time;

ap += time;
while(ap > 1.0/speed){
 //decide what to do and set actionMod

  ap -= (1.0/speed) * actionMod
}

I dunno that seems super simple to me.  It would kind of cheat by putting ap into negative possibly if you had AI actions with an actionMod > 1.0 but that's no big deal.  I could see how it might not be preferable to have a monster take all it's turns in a row while not giving others a chance to act giving an edge to a priority queue when you have multiple monsters moving multiple times a turn.

I certainly use the knowledge about attack times when playing roguelikes. Crawl has a system with actions taking different amounts of time. ADOM also has a speed attribute which affects all actions (and a mode which shows how much time, or 'energy', did the last action take). ADOM's speed system implementation is needlessly complicated and has some strange artifacts (like, when I am running from a monster who has the same speed, it is not constantly in the same distance: sometimes it makes 2 moves for my 1 move, and sometimes it makes no move).

Time systems with actions taking different amounts of time, and different speed values for various monsters, are good, but simple systems, where each action takes the same amount of time and each creature has the same speed, except some exceptions which give numerically simple effects (e.g., doublespeed monsters, potion of doublespeed, weapon of doublespeed which allows attacking twice, and similarly half-speed stuff) are also good, because they allow easy tactical planning.

  Yeah, I never notice this in Crawl early on when it's like attacks take .9 of movement speed or something.  When it starts to get much faster it's noticeable.  But I still think attacking 5x in a row is more noticeable or getting in an extra headbutt or kick.

11

Programming / Re: Representing agility

« on: August 22, 2009, 07:14:35 PM »

I like that you are getting away from the crazy DND AC.  Also, removing randomness is a neat idea as well.  I've played some games that did this, and it can help make the game more tactical and predictable.

You can also have different actions take different amounts of time (this would be a more offensive take).  I suppose it depends on how you handle speed, but you could have agility reduce the time it takes to make a basic melee attack, quaf a potion etc.

Agility might not increase your speed per say, but it would increase your action speed to take a percent say 80% or something of your movement speed.

I have a really simple system of time right now.  Basically given a players speed, it calculates the time it takes to act given that speed.  It then gives that time to each monster on the level and they convert it to ap (action points).  They then spend that, if they have enough to act until they no longer have enough ap to spend.  I know there are a whole lot of implementations of time in roguelikes, but I think this way is super easy.

It would be pretty easy to make say an attack take 3/4's the time it takes to move or have a stat that reduces attack time while doing it in a more interesting way than angband variants, where you just attack multiple times in a row.

Granted, the player might not really *see* that attacks are taking 1/2 a turn or something that way.  It might be hard to notice that type of mechanic.  I guess it's debatable if that's a superior way.  Angbands implementation where you just make several attacks at a time is certainly more noticeable to the player, although you lose the natural progression you could have otherwise and have break points where at X agility you get 3 attacks per round and at X + Y agility you get 4 attacks and between that there is no real point.

I can list the ways dexterity effects the game I am working on if that helps.

Base amount of armor weight before penalties (multiplied by a modifier based on armor skill, with armor weight you can have begin to have penalties to stealth/spell caster, dodge, unarmed damage, and speed starting at a set percentage of your base armor weight)
To hit (based on primary weapon stat), not sure how you would handle this though but you could have armor piercing, where your tohit limits the mitigation armor provides an enemy.
Damage (based primary weapon stat, certain weapon types gain damage bonuses from agility.  A sword might get less dex bonus than a dagger and a mace might be pure strength)
Flat bonus to Dodge, you could do damage mitigation to ranged damage and certain spell types to avoid random factor.  You could have a base dodge rate based on agility and have that modified by dodge skill.
Flat bonus to stealth (gains an indirect bonus from dex's effect on armor weight penalties)
Flat bonus to recharging a magic item.

For a dragon ball Z type game, DEF might work against physical attacks.  And Dodge might provide mitigation vs certain types of ranged attacks.   Actually you could have both, say DEF applies 3/4s mitigation vs physical and dodge provides 1/4 and vice versa.

So say you had 60% mitigation from dodge and 20% from armor.  You might have 30% mitigation vs physical melee and 50% vs ranged attacks.

Also with speed, you really don't want to move 2x as fast as a monster, as you pointed out that's no challenge.  But you want some method where speed can be any variable.  So maybe you are moving at speed 25 and the monster is at 17.  Under a system like that you get an extra 4th turn to the monsters 3 about.  It gives a more natural progression.  Also if you make a physical attack take a fraction of movement for both you and monsters, you can separate things out a bit.  That would also lend to the type of mechanic where you might have a character with 2x speed, and 2x attack speed getting 4x attacks per round vs a slow tankish character that might do 4-5x damage.  That would be cool.

Another thing you could do is have movement resolve for the player after giving enemies a chance to act, while attacking takes first priority.  That would make it harder to abuse speed, as movement would resolve after the enemies use the time you give them.  So your attacks would resolve prior to monsters having a chance to act, and movement would resolve post monster action.  That would also resolve the movement abuse.  So say you move 2x as fast, you'd attack, then move away.  But the monster would have a chance to act before your movement resolves on your send turn.  You'd end up a space away but the monster would have attacked as opposed to you moving a space away, the monster then not attacking and moving one space closer to you.

Of course, you have to ask do you want to get rid of movement abuse?  If you have granular movement, some enemies might be half as fast as your character some might be 6/7ths as fast or 4/3rds as fast.  When you run into a slower mob, is it wrong to abuse movement?

That's all I have for ideas on agility, I hope some of those are useful.

12

Off-topic (Locked) / Re: What do you do for a living?

« on: August 13, 2009, 07:10:56 PM »

I work in IT and am working on a masters in computer science.

Oh and the most revolutionary game play was polybius not airship 2600.  But I'm prevented from speaking freely on that game after the incident.

13

Programming / Re: New Roguelike in development: Forge of the Elements

« on: August 11, 2009, 05:30:17 AM »

Every player castable spell is now in game.  I have a full write up on the spells.  I'm too tired to proof read tonight though.

I think I'm going to work on more of the casting AI, and then wands are next.

I didn't realize just how long it would take to enter all of those in.  I had them all planed out prior, but besides the damage spells there are a ton of unique effects, some with complex behavior.

The summoned pets I have in are pretty neat too, most of them even cast spells.  Take the blizzard elemental, for a debuff it has 'ambient drain' which is a short range cone that drains the mana of enemies.  I gave it another short range offensive spell as well, can't remember which though.  The pets mostly have limited amounts of mana though, and won't cast in melee.  But I figure this makes summoned companions more interesting.  I'll balance everything out later, in the mean time everything that seems cool goes in.

http://forgeoftheelements.blogspot.com/2009/08/game-mechanics-spell-casting.html

14

Other Announcements / Re: Difficulty

« on: August 10, 2009, 07:55:03 PM »

I suppose we play out of different reasons then. What I like about roguelikes is that they are skill-based in contrast to RPGs which are mainly 'grinding' based.
For me the only purpose of the randomness is to create replayability.

Clearability based on luck is just bad design. I understand that it makes sense in a game like poker, a game where a player plays against another player and is only short. But in a videogame where one round can take several hours an unclearable game is just wrong.

  I think it depends on your definition of skill and whether you want players to make high risk/reward decisions or to solve puzzles.  Nethack and Crawl seem like the two extremes on that.

15

Other Announcements / Re: Difficulty

« on: August 10, 2009, 03:31:10 PM »

With mastering I meant being able to perfectly play the game, not only understanding all of its mechanics.

There's really no point in playing a game that might be impossible to win to begin with because of bad luck. Whether bad luck creates too strong monsters or bad luck doesn't connect a floor at all doesn't really matter, it's impossible either way.

 I think maybe we are talking about two different things in discussing luck. I see risk as luck.  To me a roguelike intentionally hides information from the player through item identification and FoV, adds a dice roll to combat, and randomly generates gear/enemies to create risk.

Now if luck means there is a 50/50 chance the game will give you enough resources to win or that the levels will be connected or the enemies you are faced with are beatable, then yes this is poor design.  However, risk is created by providing situations where success cannot be determined given the knowledge provided to a player.

For example, say you enter combat with an enemy and another joins the fray from outside your FoV.  A smart player may weigh his odds and determine fleeing is the best option.  He might use a teleport scroll and randomly find himself in another area.  This isn't without risk however, as he might find himself in a worse situation and die.

If you always have perfect knowledge of the game and the outcome of each action, such as in chess, than yes a good player should always win.  However, I think withholding the game state leads to more interesting play, say as in poker.

You have no way of knowing if the next blow will hit, you only know the odds.  You don't know if retreating into the next room will leave you in a worse situation or not, only the odds.  You have no idea whether that un-id potion will benefit you or hurt you, only the odds.

As the game progresses and the player accumulates resources and develops their character, they should have more control over the game and find themselves less forced to play the odds.

But ideally there cannot be perfect play, as perfect play requires perfect knowledge of the game state.  To achieve perfect play you'd need to know the state of the RNG.  If you could achieve perfect play then winning should be 100% assured.   Perfect play would require counting the cards, barring that you are left playing the hand you are dealt.