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 - XLambda

Pages: [1]
Programming / Problems and Pitfalls of Deterministic Combat
« on: May 31, 2013, 04:47:45 PM »
I've recently spent some time thinking about how a good deterministic combat system should be set up. (Note that my definition of 'combat' also includes interactions that aren't necessarily combat, such as picking locks etc.) I'd like to share my thoughts, and discuss some particularly problematic points that I've come across. Most of this is related to an actual WIP implementation.

1) Keeping the system understandable
For a combat system, I'd say that there is a certain degree of complexity you can go into. The goal should be to keep it simple enough so that the player can actually predict the result of one turn of combat, but complex enough to not make it trivial. 1HP games are a particular offender in this area, as they don't actually have a combat system, so anything relating to combat (like skills, talents and equipment choices) that you would expect to be interesting is going to be extremely reduced and abstract. The other extreme would probably be ToME4, where the entire game is basically one big awesome (semi-deterministic) combat system.

2) Providing a chance to react
This is directly related to the previous point. I've never been a fan of complicated time systems. Things like +10% movement speed in ToME4 are very hard to actually make intelligent use of, and even the better time systems, like the one in Sil, still require a certain amount of calculation just to find out who can move how many times next turn. One area where this is very apparent is the ghoul race in ToME4. The ghouls have a speed penalty of 20%, so every few turns the enemies get two turns. Since this is not only annoying (essentially turning a 2HKO into a 1HKO) but also hard to keep track of, the ghoul race is rarely used by normal players.
I feel that the most elegant time system is the chess-like - you always know how many squares the enemies can move and how many attacks they get, and barring OHKO situations you will always have a chance to react to your enemies' actions.

3) Approximating the intention of the non-deterministic interaction
I can't think of a big deterministic CRPG/roguelike right now. So basically every mechanic we import from a non-deterministic system needs to be converted into a deterministic mechanic. One particular example I'd like to present here is the lock-picking problem.
In most games featuring this mechanic, your chance to pick a lock is based on your stats (say, dexterity and the lock-picking skill). So if you have a lower chance to pick a lock, it will take longer for you to open that door. Anyway, if you have the skill and thus the possibility to pick locks, even if your chance is only 1%, you will be able to do it with a finite number of attempts. However, in some situations (say, the player is poisoned or about to be attacked by enemies) this is not feasible and the player is forced to find another solution (or hope that fate smiles upon him, heh).
A naive port of this mechanic to a deterministic system would result in you being able to always pick locks below a certain difficulty level, and being completely unable to pick locks above that level. This results in completely different behavior than in a non-deterministic system.
One method for solving the lock-picking problem in a deterministic system would be to assign the lock a pseudo-HP bar. Every attempt reduces the pseudo-HP by a certain amount, allowing the player to predict when the door will be open but still consuming the time that the task would take in a non-deterministic system. Of course one can discuss whether this is an elegant solution or not. But it approximates the actual behavior of the lock-picking mechanic in non-deterministic systems much closer than the naive port outlined above.
This is just one problem, but it shows that one sometimes has to change a mechanic quite a bit to achieve a close approximation of behavior.

4) Granularity and the problem of the killer rat
This is something I've run into personally just a few days ago. In almost every roguelike you have your basic beginner monster that is only a threat on level 1 or 2. Later on, they will have a hard time hitting you through your +5 chain mail, but there's still a realistic - albeit low - chance for them to hit and do some damage.
Imagine a deterministic combat system in which armor can reduce damage down to zero. Since the system is deterministic, and the damage enemies do more or less fixed, this completely trivializes all enemy types where damage <= armor reduction. In other words, those rats I throw at you on DLvl5 will be completely uninteresting because they don't even have a chance to pierce your armor.
Now imagine a deterministic combat system in which damage cannot be completely reduced to zero, but to some lowest possible amount which is x. In this case, even completely trivial enemies, like the rats above, can become incredibly dangerous if encountered in large numbers. A situation in which the player is surrounded by, say, 8 rats leads to a loss of 8*x HP every turn (not considering the effect of killing some of them), which may or may not be a lot of damage. The only way to make a couple of rats not hit harder than your average troll is to scale up damage considerably. But this in turn leads to situations like in ToME4. where the player can end up having several thousand HP, with enemies possibly having tens of thousands of HP. Which of course makes the system harder to understand and handle for a human player.
I haven't really found a good solution for this problem yet, and would appreciate ideas.

5) The missing distribution
One of my favorite decisions in non-deterministic combat systems is choosing whether to equip the longsword(3d4) or the glaive(1d12). (I just made those up, they are not from any game). The longsword, in this example, does more damage in average, but the glaive has a much higher chance of doing its maximum damage, possibly finishing off a low-HP enemy in one attack.
This differentiation is completely lost if you switch to a deterministic system. Barring damage types, there can be only one best weapon, and that is the one that does the most damage. So unless you assume a bash/slash/pierce damage system (which of course leads to the golf bag problem), it's hard to differentiate, say, an axe from a sword. For a game that aims to have a high variety of items, that's bad news. And I still haven't really found a way around this.

6) Not making it too puzzly
I kind of like Rogue. It's just the right mix of normal enemies (that require just physical strength and good equipment to beat) and puzzle enemies (that require some specific setup of items and/or tactics to defeat). What I can't stand are games that are too puzzly. We are still roguelike players, not puzzle-game players. Of course there is some interest in puzzles to present a tactical challenge to the player, but this should not be the entire point of the game.
In deterministic roguelikes there is often this tendency to go overboard with the tactical challenges, turning the whole level into 'something that needs to be solved'. This moves focus away from things a dev can spend a very long time working on and putting a lot of love into - clever and beautiful procedural content generation, interesting theme and immersive setting, emergent narrative...
I guess I just don't want deterministic roguelikes to end up being variants of Aaron Steed's Ending where the block things are orcs and trolls. (Not that Ending is a bad game, btw.)

Other Announcements / Reviving the Roguelike Magazine
« on: May 16, 2013, 04:37:19 PM »
This was once a thing, and it's a shame it isn't anymore. So, I've been thinking about reviving the mag of old.

In this golden age of RL development, many folks want to stay up-to-date wrt the state of the dev scene, and I think the form of the magazine offers something our current media don't. It is more compact than the Roguelike Radio podcast (which is excellent, and you should not miss) both in size and organizational overhead. Especially developers of smaller projects probably feel more comfortable with answering some questions over email or irc than jumping on the radio for a one-hour discussion. And it is probably more pleasant than looking through roguebase, for people who don't like reading devblogs. All in all I think it would be neat both as a way to keep informed and discuss specific games and topics that devs and players (should) care about.

Of course this wouldn't be weekly or monthly - I think a period of two or even three months would be optimal. There isn't just enough going on in the scene to allow for more frequent 'releases', and I (as well as possible interviewees) happen to have a life as well. It would also be enough time to allow for content contributions from the crowd.

I guess my question to the roguetemplars is, would you read a Roguelike Magazine?

Traditional Roguelikes (Turn Based) / 7DRL Success: H.P. Roguelike
« on: March 18, 2013, 03:55:00 PM »
So, it seems that my 7DRL was successful. It's certainly not perfect, but it is playable and hopefully somewhat enjoyable.

I've always been fascinated by the monster memory of Angband and its family. It seemed like something that on its own could motivate venturing into a dungeon. The central idea behind my project for this year's challenge was to put it in the center of game-play. And because I'm a hopeless fanboy of everything Lovecraftian, I decided to throw some gibbering horrors from beyond all space and time into it as well. Because Tentacles. And so, Tales of the Tenebrous Pit was born. Or, as someone on #rgrd put it, Pokéthulhu.

Behind every author is a story. The story behind my favorite author, HP Lovecraft, involves two insane parents and way too much racism. My 7DRL tells another story - the story of a failed expedition, an ancient place full of horrors and a hopeful author who prefers to explore it instead of running in fear. A man armed only with a gun and a notebook.

Of course, you run into various problems when tackling such a project. Even though large parts of Grandpa Howie's work are supposedly in the public domain, their legal status isn't quite clear. On top of that, the beasties of the Mythos are quite well-known to many folks nowadays, and there is no real motivation for completing the notebook if its content is already known before you start. Thus, I turned to the roguedev's oldest and best friend, and prayed to the mighty god RNG for guidance. The result was a generator that pumped out not just random monsters, but also their brain-blasting descriptions. The horrors dwelling in the Tenebrous Pit are as numerous and varied as the spawn of Shub-Niggurath!

Game is available here. I'll probably do a little patch today or tomorrow, the interface could use a little more love that I forgot about.

EDIT: Have some screenshots. Linked due to cyclopean size.

An ordinary dungeon level
Argh, the horror! :P
A half-completed notebook
A notebook entry.

Other Announcements / 7DRLC2013 (Lack of) Ideas Thread
« on: February 02, 2013, 05:05:10 PM »
Still haven't got an idea for this year's 7DRL? Look here! Let us lament our lack of ideas together!

Sources for ideas:
Last year's idea thread
2009's idea thread post with ideas

I had an idea for the last six months or so, but feel increasingly uncomfortable with it. I guess it's because I realized that the only unique thing about it would be the theme. That, and I suck at ideas anyway.

Traditional Roguelikes (Turn Based) / Magmahack (now at beta 3)
« on: September 17, 2012, 12:26:39 AM »
Hey everyone, here's another late contribution to ARRP.

I'd like to introduce MagmaHack: Wrath of the Adamantine Sock: Tales of Terror and Treasure!

MH is partly inspired by DF, the utter insanity of Bay12 and my love for underground fantasy settings. It's a very young game - I started dev'ment in June - but it's already playable, winnable and hopefully enjoyable.

Source will go online tomorrow, I think - some sleep is needed now. ;D

Release post on my site

Programming / libjcsi patch
« on: June 16, 2012, 01:02:42 PM »
I recently went through the libjcsi code and fixed a few bugs.

- background colors will now be buffered correctly when using the Swing interface
- Symbols are now directly adjacent to each other vertically, which allows the use of box-drawing characters.
- the window height is now correctly derived from the console and font dimensions.

I post the patch here so Slash can add it to the repo. :)

EDIT: Apparently the forum does not allow me to attach the patchfile, so here it goes. Patch.

Programming / Do you prefer square or non-square fonts?
« on: June 10, 2012, 09:57:56 PM »
This one came up while I was playing through my RL collection. Some games, especially libtcod ones, favor square fonts. Many others seem to go for non-square ones. Both have clear advantages and disadvantages.

I guess with so many graphics solutions offering both, it's a matter of preference. So I'd like to know what the people around here prefer.

Myself, I prefer a non-square one with a high x-height. Preferably along the lines of DF's 12x16. It doesn't distort the dungeon dimensions too much and is more legible than square fonts.

Traditional Roguelikes (Turn Based) / 7DRL Success: The Challenge!
« on: March 17, 2012, 07:04:28 PM »
Since my 7DRL started as an idea on roguetemple, I thought I might announce its successful completion here.

Play a young and hopeful programmer trying to write a 7DRL as he faces certain doom in the Dungeons of Development! Get through the dungeon before the Seven Days of Magic are over! Wield powerful weapons such as vi and emacs! Run from bugs and segfaults! Drink massive amounts of coffee to increase your laziness! And other stuff.

Download (including source):

I personally liek it a lot, it's my very first 7DRL. I certainly lost some time to not having lots of code left over from previous projects, but it still turned out nice, I think. I hope at least some people will have fun with it. :)

Programming / Java RL tutorial!
« on: March 06, 2012, 12:49:23 PM »
Since quite a few people seem to be interested in RL development with Java, and since there is no fitting tutorial that I know of, I've started to just go ahead and write one.

If everything goes right, it should:

-> be generic and not based on a single specific library. I'll use Slash's libjcsi, which is basically a swing implementation of curses, so the basic methods should all be provided by whichever library you prefer. (I'll encapsulate it anyways, so no worries.)

-> provide basic algorithms that, while not up to most people's standards, do the job and are easy to understand.

-> not do any l33t r0gu3l1k3 h4x. Yes, there are some crazy programming things you can do to make your life easier. Do they make things easier to understand? No.

-> result in a horribly soulless, unbalanced, flavourless, boring, playable little game. The emphasis is on playable, lol.

Once I have the basic data structures laid out, others are very welcome to contribute. I might put it up at roguebasin if people like it.

I do need some help, though - I'm searching for a simple and easy to understand FOV algorithm. I usually use something like MRPAS, but that's just waaay too complicated for a tutorial.

Programming / Modeling Armor in Roguelikes
« on: February 19, 2012, 11:31:00 PM »
While I was working on the (admittedly simple) combat system for my project, I came across the problem of modeling armor. I've taken a look at some games and came up with a few variations.

1) Armor as a second health bar
The armor absorbs a fixed amount of damage and is destroyed after that. The DoomRL model, doesn't really work because armor is not really expendable in most fantasy settings.

2) Armor blocks with a fixed probability
With a certain probability the armor will absorb all damage, otherwise the entire damage is done to the attacked creature.

3) Armor blocks a fixed percentage of damage
All damage dealt to the attacked creature is reduced by a fixed percentage. Since most games use only integer values, this could be bad.

4) Armor blocks a fixed amount of damage
All damage dealt to the attacked creature is reduced by a fixed value.

5) Armor block every attack dealing less than a fixed amount of damage.
The same as above, but when the dealt damage is larger than the armor value, there is no reduction.

Of course, most of these can be combined in some way, but I think these are the most common basic approaches.

My question is, which ones do you find viable? I have a hard time deciding which one would make more sense. I don't really care for realism if an unrealistic solution promises better gameplay. I don't have much experience with combat models, so I'd appreciate it if some of the more seasoned developers could give me a few hints. :(

Other Announcements / Best place to put a RL dev site?
« on: August 08, 2011, 06:53:06 PM »
Hi, everyone!

I was wondering what the best place for a dev site is. Basically, I've been doing some work on my pet project - although it's still far from a releasable state right now - and thought about putting a little dev site up at a later date. Is it better to put the development details on a blog or WP site and the actual files on a file hoster? Or would it be better to get some webspace and put everything into that one?  :-\ What do you recommend?

(note: wasn't sure where to post this. if misplaced, please relocate.)

Pages: [1]