Temple of The Roguelike Forums

Development => Programming => Topic started by: requerent on March 01, 2012, 09:28:41 PM

Title: Designing Difficulty
Post by: requerent on March 01, 2012, 09:28:41 PM
Hola Roguelike likers!

I'm working on a thesis that has a little bit to do with procedural content generation and wanted to spark up some discussions to share some opinions and get some impressions. Most of the concepts I'm interested in have more to do with roguelikes than anything else, so I thought I'd start here. I'm not too sure how active this place is- but I hope that it serves as the general hub for RL development discussion that I'm assuming it does. If anyone has any suggestions as to where a better place may be, please comment!


Divorcing particular topics from the context of my entire project is a tad tedious, so hopefully I can do that without producing large blocks of text (not likely). To start, I'm interested in creating some vocabulary with which to establish a more appropriate paradigm for looking at particularly important concepts in the design of a game. I'd like to begin with defining what it is in a game that makes them difficult. By difficult I mean simply that the incremental challenge of the game is pleasurably stimulating and keeps those addictive juices flowing in the brain.


There are two basic concepts that I'm rolling around, complexity and solvability-

The first is solvability. How solvable is any given game? Upon entering a room, we can abstractly look at the 'problem' of the room in terms of an unoptimized minimax tree. The player is obviously the maximizer while the 'room' (and challenges therein) becomes the minimizer.

Within this tree of potential game states, how many terminal nodes result in a victory for the player? Or rather, How many are solutions? The more paths that result in a victory condition, the more solvable the room is (room is an arbitrary measure of scope- we can think of the entire game's solvability based upon the solvability of each region, of each level, of each room, of each monster, etc). In all games, the solvability of a game tends to decrease as the player progresses. This quality of a game, however, is only interesting if combat doesn't heavily rely on probability (Dying after a stun with 99% Stun resist in ToME is NOT fun OR interesting).

Solvability is typically addressed with an overly dependent relationship between designer and play-tester. If we can design procedurally generated content so that its solvability is within a desired margin of probability, it's possible to make difficulty less arbitrary and more procedural. This is interesting because the game world itself becomes an intelligent opponent providing us with a measurable degree of challenge. Solvability also includes stalemates (which are equivalent to NOT losing)- bypassing a room or running away.


The second concept is complexity. Complexity more or less describes the permutability and variety of actions- How many solvable game state paths already exist as an isotope? How many different actions are necessary? And how many total actions are necessary?

At the start of most games, the player has a number of total possible actions. As the game progresses, they acquire new actions. With these new actions comes the responsibility to incorporate them advantageously into normal play. In most games, they typically don't alter the outcome too much, but they reduce complexity (and thus the risk of ending up in an unsolvable path) when properly used in a situation that would normally have high complexity. Whatever the case for a particular game may be- as more actions are acquired, the difficulty of the game 'should' adjust to provide continuous challenge to ensure those new abilities are, at times, necessary components to victory or necessary for a perfect victory (one without losing a lot of HP- or something similar).

In a game where difficulty isn't increased arbitrarily, but built-in to the already randomly generated game world, we can think of this in terms of enablers. We cun run straight into Lava Lake and try to slay the Fire Dragon- but it's complexity will be greatly reduced (to the point of being possible) with that ring of Fire Immunity.




Solvability and Complexity are particularly important in Roguelikes because of their randomly generated nature. How do we know our randomly generated challenges are actually challenging the player? How can we ensure that the gameplay continues to be interesting? How can we not completely bone the player after all their hard work?


I'll talk briefly about ToME and Brogue, since they represent two ends of the Roguelike spectrum that are very successful-

The first is ToME, and the game that I feel falls the shortest in terms of being interesting in regards to Complexity and Solvability (as far as the random generation of challenges are concerned).

ToME is filled with critters and critters of enemies, but there is very very very little variety or complexity to combat. When we acquire a new ability, we will think briefly about how this ability fits into our standard mode of operation, but we don't really need to think very much about what we're doing.

Our character is either strong enough to solve a problem or isn't- the challenge has very little to do with HOW we play our character because the BEST move (and best way to build a character) is often very clear. In the case of ToME, we're playing against a random number generator- there's very little intelligence behind how the game produces challenges.

After level 10, for example, a whole new set of monsters are randomly generated. The only significant difference, in terms of difficulty, is probably the existence of stealthed enemies (which doesn't make much difference). These jumps in difficulty and complexity are arbitrary and typically uninteresting (just one more thing to think about). The game becomes much more interesting after we reach the Far East, but most contests leading up to a boss have more to do with resource management, equipment, and character design than with tactical decisions. This is in part due to the role of unrestricted resting- which is a necessity given the inherent imbalance of class abilities. The problems with class restrictions in ToME are more appropriately addressed elsewhere, but it's important to note how the structured approach to acquiring abilities and the variety of abilities that can be acquired influence complexity. There is so much variety that it's too difficult to make gameplay dependent upon it. As a result, the difficulty moves laterally about the shallow end of the pool. That isn't to say that ToME isn't hard. Just that it isn't complex (despite all the different options that a player has).

ToME seems to have a ton of depth in regards to how a player creates a character to solve the problem of the game world. However, the game world doesn't ask much from us- it's more about intelligent min/maxing and hoping that we don't get hit by a WTF dice-roll moment. For this reason, the infinite dungeon is a lot more interesting than the actual game- It, however, more readily exposes some of the problems with how difficulty changes. Don't mean to sound Harsh, in regards to ToME, it does a lot of things very successfully- but I think it's only remaining problems revolve around its difficulty.



Next up is Brogue. My longest run was contingent upon a heavily enhanced staff of discord. Brogue is interesting because we emerge with our own 'class' that we can play and build up based upon the tools we find.

Brogue starts out with very few actions possible and virtually no complexity. Because there is no complexity almost every path results in a solution for the first 4-5 levels. You can hold 'X' for the first several floors to save a lot of time.

By the fifth floor (or so), if we haven't acquired a certain set of tools (including potions), we're likely to be boned in the next few levels. The further we go along, the more we depend upon the RNG to increase our range of abilities in a way that actually allows us to deal with problems. In most cases, the order in which we use our abilities doesn't matter very much. Against a hard enemy I need to use all my charges and toss a few javelins- against easier challenges I do less. Sometimes order matters- but decision-making in Brogue is fairly straightforward.

The issue lies in the fact that Brogue's monster generation is always depth-based. If the RNG hasn't graced you with the right/enough junk, it's not likely to be a successful run. We can make decisions to reduce our consumption and increase our chances- but we can never be certain as to the solvability, given our progress, of a level. We may simply not be strong enough by the time we hit a certain depth.

Brogue also has a tendency of providing us with dead-ends or, despite a speed-running esque approach, starving us to death. Our solvability isn't assured. Starving to death when we haven't been making frivolous actions or even the slightest bit of backtracking and avoid resting at all costs is the most unrewarding death.



The overarching problem that Solvability and Complexity expose is assuring that we don't screw the player out of their hard work and ensuring that it's rewarding and meaningful (as opposed to frustrating)- or that we at least honor them with a glorious death. I haven't touched chess-rogue yet, but it's design (Being something more like a procedural DRoD than a Roguelike) seems to satisfy the objective of reducing solvability and increasing complexity. It just lacks some of the more interesting RPG-esque elements and emergent gameplay that makes Rogue interesting.

I personally think that a roguelike should give us challenges (mainly combat, but also other types) that are more puzzle-esque and strategic (and less RNG-based WTF moments). DRoD is an excellent example of this, but it's by the grace of level-designers that it explicitly satisfies complexity and solvability issues (at the expense of flexibility- it's probably less roguelike than chess-rogue). It's more interesting to have diverse solution paths that allow a player to develop their own playstyle, but to demand that that playstyle be refined over the course of a game. As a side note, fighting games do a great job of capturing a player's personality without necessarily confining them to a particular set of decisions.


Accomplishing desirable solvability and complexity procedurally is a pretty complicated problem- how can we generate a 'room' that with some certainty and in reasonable generation time, will give us solvability and complexity within a desirable range of difficulty? Some probabilistic heuristics would make it possible and there may already exist a few models to implement such an idea. In most cases, we wouldn't bother analyzing or shooting for such an objective, but just try and make sure that problems are reasonably difficult by a certain point in time by the virtue of what content is being generated (such as in Brogue or in ToME).  Unfortunately, the complexity of such a methodology is typically lacking and the solvability isn't necessarily certain- the burden of montonous work with a sudden dice-roll of death sucks. Although we aren't dissuaded from playing RLs for these reasons, I feel like RLs tend to lack completeness as a game because these two problems aren't addressed in a formal way. We don't even know if there is a solution because there may randomly be a dead-end or coincidentally unbeatable monster. They aren't necessarily solvable and they don't necessarily provide continuous challenge.


Anyhow- more to think about later. Please let me know what you think.
Title: Re: Designing Difficulty
Post by: Z on March 01, 2012, 11:09:25 PM
Welcome!

I'm working on a thesis that has a little bit to do with procedural content generation and wanted to spark up some discussions to share some opinions and get some impressions. Most of the concepts I'm interested in have more to do with roguelikes than anything else, so I thought I'd start here. I'm not too sure how active this place is- but I hope that it serves as the general hub for RL development discussion that I'm assuming it does. If anyone has any suggestions as to where a better place may be, please comment!

As for place, I think this is one of the two best places to discuss roguelikes in general. The other place is rgrd (http://groups.google.com/group/rec.games.roguelike.development/topics) (and also rgrm).

Quote
Brogue also has a tendency of providing us with dead-ends or, despite a speed-running esque approach, starving us to death. Our solvability isn't assured. Starving to death when we haven't been making frivolous actions or even the slightest bit of backtracking and avoid resting at all costs is the most unrewarding death.

I don't agree with this. Brogue has a "metering" system which makes sure that you get as much food as you need (and also other important resources like potions of strength and scrolls of enchantment). Starving is caused by a bad strategy, not by bad luck. I think this system works very well and I never starved, if you run out of food, this means that you should proceed to the next level and you are almost guaranteed to find more. I don't know what you mean by dead-ends, but it makes sure that you can reach everything (as every decent roguelike does).

Quote
The overarching problem that Solvability and Complexity expose is assuring that we don't screw the player out of their hard work and ensuring that it's rewarding and meaningful (as opposed to frustrating)- or that we at least honor them with a glorious death. I haven't touched chess-rogue yet, but it's design (Being something more like a procedural DRoD than a Roguelike) seems to satisfy the objective of reducing solvability and increasing complexity. It just lacks some of the more interesting RPG-esque elements and emergent gameplay that makes Rogue interesting.

ChessRogue is awesome, although it is maybe too easy to lose the game randomly (not due to randomness inherent in the game, but a typo). You should also like my Hydra Slayer, which is puzzle based, has more RPG-esque elements, no stupid maximizing (smaller weapons are often more useful than larger ones, and sometimes you have to make an enemy seemingly stronger in order to defeat it) and contains almost no ways to lose the game randomly (only an accident with a giant missile on a wrap-around level, or delaying drinking the Potion of Life one turn too long). Also try older games by Darren Grey (no hitpoints leads to better puzzles), and the popular semi-roguelike Desktop Dungeons.

Overall, I agree that effects which randomly either work or not, although so popular in roguelikes, tend to weaken the tactical quality of the game. Like the ubiquitous accuracy/dodge, or the also popular critical hit mechanics. I think Jeff Lait's You Only Live Once was the first roguelike with a deterministic combat system, and it was very good. You can try to win the game with the first character (the child), which is a very nice tactical challenge.

Quote
DRoD is an excellent example of this, but it's by the grace of level-designers that it explicitly satisfies complexity and solvability issues (at the expense of flexibility- it's probably less roguelike than chess-rogue).

DROD is a great game, but not generally considered a roguelike. I think this is partially due to it being created a long time ago, where roguelikes were more about role-playing and stats than about puzzle solving, and DROD was very different from this. Nowaday DROD feels closer to the puzzle part of the roguelike world. Still, the lack of randomness means that most people would probably call it a semi-roguelike.
Title: Re: Designing Difficulty
Post by: requerent on March 02, 2012, 12:03:53 AM
Quote
I don't agree with this. Brogue has a "metering" system which makes sure that you get as much food as you need (and also other important resources like potions of strength and scrolls of enchantment). Starving is caused by a bad strategy, not by bad luck. I think this system works very well and I never starved, if you run out of food, this means that you should proceed to the next level and you are almost guaranteed to find more. I don't know what you mean by dead-ends, but it makes sure that you can reach everything (as every decent roguelike does).

I've run into some situations where I've gotten into an area that is inescapable. Mainly with Pit Floats or a potion of Descent- I've fallen into rooms that have no accessibility to other areas of the level. I would also not be in possession of other ways to spontaneously change my location (teleportation) or depth (another potion of descent). The Food shortage issue actually happened to me on a run-through in which my entire focus was on making no extraneous moves (I don't think I was monkeyed or went swimming X_x). These are 'bug'-like situations that shouldn't happen, but they can. I similarly see inaccessible areas in ToME (where there are items/creatures) all the time on the forest-style maps (Trollmire and the Slave area- and far portals that use that algorithm). Bugs aren't really the subject of my concern though- just side-note examples on the sort of things that shouldn't happen or that effect solvability. Many of those types of problems/bugs (accessibility) have solutions.

The main point is the solvability- Have there actually been enough tools generated to proceed to greater depths? This oftentimes isn't the case. Even if it is, there is no assurance that these tools require more interesting gameplay via increasing the complexity. With Brogue, you aren't likely to make profound discoveries in how you play the game- you use what you can and sometimes it's enough, sometimes it isn't. The decisions have more to do with whether you increase your chance of surviving now or later- based upon what items you take from treasure rooms, where you use your enchantments and when you use healing potions.



There are plenty more rogue-likes that I need to be checking out. DRoD is definitely not a rogue-like, and many of the solutions to levels are extremely restrictive-- but it has a lot of wonderful components that belong in a successful roguelike. It also manages to implement puzzles within a 'style' that is appropriate for something rogue-like~ish.

I would actually like to see resources (such as HP) be used by heuristically generated challenges so that there are situations where a player will need to make sacrifices to succeed (Brogue does this in a way- with when to use items). Typically, we NEVER want to lose HP if at all possible. HP is a buffer to losing, but also can have a place in puzzles when utilized as a resource-component when generating how solvable/complex an area may be. If we're generating a game with a large world- HP is the buffer to running away from an area that is too difficult- an important feature...

Title: Re: Designing Difficulty
Post by: Pueo on March 02, 2012, 12:21:50 AM
I've run into some situations where I've gotten into an area that is inescapable. Mainly with Pit Floats or a potion of Descent- I've fallen into rooms that have no accessibility to other areas of the level.

I think you're missing the 's' button, for <s>earch.  No matter what, Brogue will always be completely connected.
Title: Re: Designing Difficulty
Post by: requerent on March 02, 2012, 02:45:03 AM
I've run into some situations where I've gotten into an area that is inescapable. Mainly with Pit Floats or a potion of Descent- I've fallen into rooms that have no accessibility to other areas of the level.

I think you're missing the 's' button, for <s>earch.  No matter what, Brogue will always be completely connected.

Ah- Search should be giving user feedback on failed attempts- "I failed to find anything." Or colorize a searched square.
Title: Re: Designing Difficulty
Post by: guest509 on March 02, 2012, 09:10:43 AM
  The dead ends in Brogue have nothing to do with solvability or complexity. Because there aren't any. I cannot be certain that Brogue is beatable (solvable) with perfect play every time. I've never had an unavoidable death so far. You'd have to find a group of very good players in order to do a good study. I do know that Nethack, a game with a TON of instant death situations and long as hell, is beatable with a very high % of success. One guy had a streak of several dozen wins. See the Nethack google group here.

http://groups.google.com/group/rec.games.roguelike.nethack/topics?lnk

  On the Brogue Forums we talk a bit about this. Maybe you already read it though. Here is the link.

http://sites.google.com/site/broguegame/home/forum    [go to the Winnibility Of Brogue thread]

  A few things you said above need clarifications. Solvibility of a game does not decrease as the game progresses. This might be true in some games but definitely not the majority. There is a game record of a Moria game showing that the higher levels were not dangerous hardly at all but the early mid game was deadly. Also games like Modern Warfare 3 are easy all the way through. With maybe a few upticks in danger to keep it interesting.

  I'm not even sure a steady difficulty curve is desirable. Many games have made millions, most modern games, by having a few hard parts broken up with large sections of grinding (easy, low risk areas). Smooth game playe and little minor rewards are what keep the player motivated. The feeling of triumph is saved for the bosses (or other difficult areas). Gears of War, God of War, MW3 and other major hits are built on this model.

  I guess a steady curve is a good idea in a Roguelike. But a good roguelike with periodic bosses where the difficulty spikes up would be neato. Arguably these instances happen in all roguelikes already. In an emergent fashion.

  Your comments that ToME lacks strategic depth outside of character creation and min maxing is going to be met with eye rolling. Also the feeling that you are just trying to avoid a WTF die roll in ToME seems a strange statement. I was under the impression that ToME has very few, if any, instant death types of moves.

  Both ToME and Brogue have their own Forums. You can ask more game specific questions there.
Title: Re: Designing Difficulty
Post by: Krice on March 02, 2012, 09:15:57 AM
The difficulty of roguelikes has roots in 8-bit games that were extending the gameplay time often with situations that were impossible to predict. You need to know what is going to happen so you can solve that the next time. I think it's just poor game design and that's it, but it's in odd way a part of what roguelikes are as games.
Title: Re: Designing Difficulty
Post by: requerent on March 02, 2012, 01:17:33 PM
@Krice,
Quote
A few things you said above need clarifications. Solvibility of a game does not decrease as the game progresses. This might be true in some games but definitely not the majority.

...

The dead ends in Brogue have nothing to do with solvability or complexity.

I'm NOT regarding solvability as whether or not a game is 'winnable.'

(from the original post):
Quote
Within this tree of potential game states, how many terminal nodes result in a victory for the player? Or rather, How many are solutions? The more paths that result in a victory condition, the more solvable the room is (room is an arbitrary measure of scope- we can think of the entire game's solvability based upon the solvability of each region, of each level, of each room, of each monster, etc).

But rather by how discriminating the decision tree is. Solvability asks how many terminal nodes in a decision tree yield favorable outcomes. The player may have become more powerful and thus more capable of solving difficult problems, to the point in which it seems easier than earlier problems, but mistakes are typically also less forgiving.

For example- On level 1 of some game, I can run circles around goblins with lots of 'extraneous' moves (those that would normally have very low heuristic value for an AI). I can't exhibit the same amount of extraneousness on level 10 vs a dragon and expect to be as successful. This obvious and at times arbitrary increase in difficult doesn't undergo much scrutinization- I propose solvability and complexity as ways of looking at how difficulty progresses in a game. Now- if I have to waste a bunch of healing potions on that goblin, then the future solvability/complexity with the Dragon encounter is going to change- making it even more difficult to generate challenges without a negative feedback cycle (other issue).

This quality of a game doesn't necessarily decrease throughout ALL games, but in games where it doesn't change there needs to be an attractive change in complexity or a really good story. In the case of roguelikes, solvability definitely changes and tends to become more difficult as the game progresses.

Quote
Because there aren't any. I cannot be certain that Brogue is beatable (solvable) with perfect play every time.

If Brogue's solvability, in terms of winning the entire game (Which I don't really talk about), depends upon a perfect playthrough, then it has virtually no solvability. Solvability, however, changes as we go deeper. If there are a few set of rote axioms that allow a player to play Brogue more 'perfectly,' then the player is making decisions based upon how he knows how the game generates challenges. There are other concepts important in making a game interesting- if the player knows how future challenges are generated and can prepare for them without having been given an explanation, then there is quite a bit of 'learn-die-reset' going on. This isn't 'bad,' but it's something worth addressing elsewhere. The obviousness of a 'right' decision makes solvability uninteresting and inadvertantly culls the depth of complexity.

"Dead ends" have EVERYTHING to do with solvability and complexity. Allowing a player to go down a path that will assuredly become unsolvable is wasting the player's time.


Quote
I'm not even sure a steady difficulty curve is desirable.

I don't think I meant to imply this. Just that solvability should decrease. Not necessarily gradually or as some measurable curve- or even as a 'this area is harder than this area.' Difficulty changes with solvability and complexity. If we have a ring of fire immunity, the complexity and solvability for the fire pit area suddenly change.

If we incorporate solvability and complexity into the generation of a 'room' (arbitrary measure of scope), we could do something zelda-like and obligate the player to find enablers that make areas possible. If all enablers were useful in all areas- this would create a positive feedback loop as each area is defeated, making the game get easier. However, if all enablers weren't useful in all areas then the game isn't very complex and the strategy could become fairly one dimensional (assuming enablers and 'possible actions' are related). This is a serious problem. Addressing Complexity and Solvability is part of the solution.

Quote
  I guess a steady curve is a good idea in a Roguelike. But a good roguelike with periodic bosses where the difficulty spikes up would be neato. Arguably these instances happen in all roguelikes already. In an emergent fashion.

In what way would that be emergent?

Quote
Your comments that ToME lacks strategic depth outside of character creation and min maxing is going to be met with eye rolling. Also the feeling that you are just trying to avoid a WTF die roll in ToME seems a strange statement. I was under the impression that ToME has very few, if any, instant death types of moves.

It lacks strategic depth because the BEST action that a player can make, given the information s/he has, is oftentimes very obvious. Very rarely do you have to shake-up your normal operations. The game is very repetitive. What qualities of a character that maximize our ability to survive/kill stuff become a priority. Say we're on an archmage run- We're not likely to dump stat points into strength unless it is for the purpose of acquiring the minimal amount of strength to equip something (Say we found some amazing randart armor and have a feathersteel amulet and somehow we have that stat points to dump). If we're building a hybrid mage for some god-awful reason, there is a necessity to use class and stat points as frugally as possible to ensure maximal survival. While it's true that a player can create their own challenges- I'm talking about possible game states. In games, we design difficulty around the assumption that a player wants to maximize his advantage.

Yea- WTF moments and ToME don't exactly go together (in that they necessarily result in 'death'), but heavy reliance on dice rolls will always give you lameness (and WTF moments). Because success in the game is probability driven, a lot of the challenge has to be reduced so that you can progress to the end (and enjoy the wonderful story). I pretty much design builds around stun immunity, considering how often stun resist doesn't really mean anything with my Karma... I would say that dice-rolling does a lot to kill interesting difficulty in ToME.

The most interesting strategic lessons I learned playing ToME are from running as an archmage on insane difficulty (which isn't even hard)- but these lessons tend to be more rote discoveries as opposed to genuine strategy. They are a question of "How am I going to be strong enough to do this area? What stats/abilities do I need for this area?" Completely dependent upon prior knowledge.


Quote
Both ToME and Brogue have their own Forums. You can ask more game specific questions there.

Even if I erroneously refer to qualities of ToME and Brogue that aren't really there or true, I'm using them as examples for something else. This is not meant to be a discussion on how "good" ToME and Brogue are. I'm not trolling or bashing them in any way, but trying to create an objective paradigm to improve games- in this case, on the very specific subjects of complexity and solvability. Brogue and ToME just happen to be more interesting to talk about for a number of reasons.


A designer can approach the problem of solvability and complexity however s/he wants, but at least knowing the vocabulary and looking at the problem of making a game with the right tools is empowering. If we design a game without these thoughts in mind, who knows whether or not the game will be a challenge or interesting-- from here we just tweak values hoping that it's fun.

Roguelikes rely on the RNG to create content- What if that RNG was implemented more heuristically? In the case of Brogue, we run into situations where we have dependency trees (IE treasure room puzzles), but the challenge of the game revolves around using randomly generated tools to fight off randomly generated monsters. We're, in effect, playing a genetic algorithm. This is very interesting- but it doesn't always provide interesting gameplay because it doesn't assure whether or not progress is still possible.

I believe that progress should always be possible- if progress needs to be dependent upon previous actions (by design- ie, potions and other expendable resources), then it shouldn't cull all possible victories in our decision tree unless there is another path that the game will let us take. If healing potions are 'mistake tokens' or 'extra turns' that we redeem to make up for our mistakes, then their usage shouldn't be required in difficult encounters. That is, there should always be some path within the possible set of decisions that will result in victory.
Title: Re: Designing Difficulty
Post by: guest509 on March 02, 2012, 06:40:16 PM
  These thoughts are hard to follow because you are attempting to create jargon using words already commonly used to describe things when speaking about game design.
  All, or most, of my misconceptions about what you are saying stem from vocabulary. I've done academic work that fell into that same trap. I'm not saying you are on the wrong track, but if you find you are confusing people who are interested and educated on the topic, you might want to take a second look at how you are approaching things.
  It seems like some interesting work, but discussion threatens to devolve into a somewhat frivolous exercise of miscommunication and corrections based on semantics.
Title: Re: Designing Difficulty
Post by: requerent on March 02, 2012, 09:27:45 PM
  These thoughts are hard to follow because you are attempting to create jargon using words already commonly used to describe things when speaking about game design.
  All, or most, of my misconceptions about what you are saying stem from vocabulary. I've done academic work that fell into that same trap. I'm not saying you are on the wrong track, but if you find you are confusing people who are interested and educated on the topic, you might want to take a second look at how you are approaching things.

When we ask the question- "Can this game be won?" We are asking whether or not it is solvable. If we ask the question "How many ways are there to beat this game?" We're asking "How solvable is this game?"

I think Jargon is against me because the literal meaning of solvability is to describe 'how solvable' something is. Applying solvability to a game, in terms of meaningful analysis, would involve a quantative description. Game states are the discrete progress of a game- the game state tree tells us how many paths are solvable and how many result in failed states. Solvability, then, describes the breadth of paths that result in solutions. If you think this use of the word is unreasonable and can think of a better one, I would definitely like to know!

Complexity then describes the depth of these solutions (which inherently includes properties like variety and symmetry for analysis).

Quote
  It seems like some interesting work, but discussion threatens to devolve into a somewhat frivolous exercise of miscommunication and corrections based on semantics.

That's still potentially useful. Semantic debates are important because they allow for more clear communication. In my case- I presented key terms explicitly. If they're interpreted any other way relative to how I presented them then semantic discussions are useful because I might discover more appropriate keywords to describe my ideas.
Title: Re: Designing Difficulty
Post by: Game Hunter on March 02, 2012, 10:51:22 PM
The terms might be a bit awkward but, given what they intend to represent, they're pretty good IMO. This is how I'm interpretting requerent's concepts of solvability and complexity:


I'd like to contribute to the discussion itself of making procedurally generated content that can get you both high solvability and high complexity (thus establishing a "truly difficult" puzzle), but that sounds like a really hard thing to create even by hand. Or maybe you're just looking into ways of creating PCG that can be tweaked according to these parameters in order to change the difficulty curve?

A lot of roguelikes, particularly older ones, like to use vast worlds and subtle gameplay structures in order to increase complexity for players who don't understand the game mechanics. This, in itself, does change the difficulty of the game to a point, but from the point of view of a player who can see everything in front of them, it's probably a lot simpler of a game. Honestly I'd say Krice nailed it, at least in terms of what we think of as a traditional roguelike. That said, designing something that really expects player creativity rather than prediction would make for an awesome game, roguelike or otherwise.
Title: Re: Designing Difficulty
Post by: Ancient on March 02, 2012, 11:17:53 PM
Quote from: Jo
  I guess a steady curve is a good idea in a Roguelike. But a good roguelike with periodic bosses where the difficulty spikes up would be neato. Arguably these instances happen in all roguelikes already. In an emergent fashion.
In what way would that be emergent?

1) An out of depth monster is generated. It is more difficult to beat than creatures native to the currently explored dungeon level. Typically this presents a low solvability problem and only slightly more experience and better equipment earlier as a reward.

2) An unique monster is generated. These are hand-designed and what values of solvability complexity to assign them varies very much. DCSS is arguably the most famous for this. Sigmund is a high threat for almost every character while Ijyb is barely noticeable foe unless he manages to lay his hands on a wand.

3) Artifact guardian is generated. ADOM does this. Usually solvability is not changed in comparison with other monsters because this is a standard creature with increased stats but complexity goes high since the guardian is buff and hits strongly. The artifact if good will severely diminish complexity of the whole game and may decrease satisfaction.

4) Something walks on polymorph trap or a shapeshifter takes upon a powerful form. Again, this usually has low solvability but often there is a high complexity solution of carefully avoiding it and waiting until timer forces the creature to turn back into its original form. See chameleons of POWDER.
Title: Re: Designing Difficulty
Post by: requerent on March 02, 2012, 11:54:53 PM
@Ancient

Emergent Gameplay, as far as I am familiar with the concept, has less to do with any given challenge and more to do with how many options a player has. A player can engage in emergent gameplay to solve more difficult problems, but they don't have to be more difficult. Emergent gameplay can be implemented 'for' fun- such as in Dwarf Fortress, where lava traps and other bizarre contraptions are entirely unnecessary but completely emergent.

Quote
1) An out of depth monster is generated. It is more difficult to beat than creatures native to the currently explored dungeon level. Typically this presents a low solvability problem and only slightly more experience and better equipment earlier as a reward.

2) An unique monster is generated. These are hand-designed and what values of solvability complexity to assign them varies very much. DCSS is arguably the most famous for this. Sigmund is a high threat for almost every character while Ijyb is barely noticeable foe unless he manages to lay his hands on a wand.

3) Artifact guardian is generated. ADOM does this. Usually solvability is not changed in comparison with other monsters because this is a standard creature with increased stats but complexity goes high since the guardian is buff and hits strongly. The artifact if good will severely diminish complexity of the whole game and may decrease satisfaction.

4) Something walks on polymorph trap or a shapeshifter takes upon a powerful form. Again, this usually has low solvability but often there is a high complexity solution of carefully avoiding it and waiting until timer forces the creature to turn back into its original form. See chameleons of POWDER.

I'm not sure if what you're describing is really emergent gameplay. These examples are challenges that may or may not require emergent gameplay, but they don't necessarily have anything to do with emergent gameplay. 4 is the closest, but that isn't increased complexity because evasion is a repetitive action. Complexity necessarily requires variance and assymetry. There is also nothing inherently emergent about evasion. For emergence to exist, there need to be a variety of properties from which gameplay can emerge. Emergence typically involves a monster only in how its weaknesses can be exploited (in that weaknesses of a monster are, in a way, part of the set of tools involved in solving the problem that is the monster).

Brogue has some excellent examples of emergence- A Bloat emits explosive gas upon death. If killed at range, an incendiary dart can trigger that gas, resulting in a certain amount of roasted goblin when used appropriately. In conjunction with flammable flora, problem solving possibilities can become very interesting.
Title: Re: Designing Difficulty
Post by: Z on March 02, 2012, 11:55:12 PM
I think Jargon is against me because the literal meaning of solvability is to describe 'how solvable' something is. Applying solvability to a game, in terms of meaningful analysis, would involve a quantative description. Game states are the discrete progress of a game- the game state tree tells us how many paths are solvable and how many result in failed states. Solvability, then, describes the breadth of paths that result in solutions. If you think this use of the word is unreasonable and can think of a better one, I would definitely like to know!

Do you intend to define solvability in an abstract and formal way, in terms of counting the paths in the game tree? I don't think this is possible (give me your definition more precisely and I'll try to show you why it is wrong). I would define solvability as the probability that the perfect player wins the game, but this seems to not be what you want (for example, in your example about having more freedom when fighting goblins than when fighting dragons, this freedom is irrelevant to perfect players).
Title: Re: Designing Difficulty
Post by: requerent on March 03, 2012, 01:48:40 AM
I think Jargon is against me because the literal meaning of solvability is to describe 'how solvable' something is. Applying solvability to a game, in terms of meaningful analysis, would involve a quantative description. Game states are the discrete progress of a game- the game state tree tells us how many paths are solvable and how many result in failed states. Solvability, then, describes the breadth of paths that result in solutions. If you think this use of the word is unreasonable and can think of a better one, I would definitely like to know!

Do you intend to define solvability in an abstract and formal way, in terms of counting the paths in the game tree? I don't think this is possible (give me your definition more precisely and I'll try to show you why it is wrong).


Hmm... I haven't worked out the details of a formal definition, but Game Hunter does a very good job of reducing my blatherings. I'd be better off drawing a picture... which is probably what I'll do in a bit. Either way, I'm hoping that a formal definition will emerge, at some point, but a formal definition isn't necessary for the concept to be useful.

Regardless,
Consider the tree of all possible game states of a relevant scope.

For any given state that is not terminal, the solvability of a state describes how many of that state's children contain a goal state in their respective sub-trees relative to those that do not.

EX. If a state has 8 child states and 3 of those have no solutions in their sub-trees, we might say the solvability of the given state is 5/8.

This isn't inherently useful unless we look at the relationship of solvability between parents and children through each possible solution path.

EX. A state may have a solvability of 8/8, but all of it's children may have a solvability that is 1/8. For a state to represent its solvability in a useful way, it needs to take into consideration all of its children's solvability.

When we hit a state that isn't solvable, it's likely (just an assertion) that we can prune it or treat it as a terminal node. From there, we can evaluate all terminal nodes of a given state to determine its solvability in a meaningful way.

EX. If state A appears to have 3/8 solvability and it's 3 solvable children have 1/8 solvability whose solutions are terminal- we can say that there are 3 solutions to 26 failed states/paths- or that state A has an evaluated solvability of 3/26.


Obviously, time-complexity makes this sort of solvability impossible to determine. But I'm suggesting its use as a parameter in random generation. If we can probabilistically generate challenges within desirable ranges of solvability, we can be relatively certain that the game will be challenging in the way that a designer wants it to be. In conjunction with complexity, we can probabilistically generate challenges that require a variety of actions. This approach may be a bit more intuitive than arbitrarily scaling levels up or tossing in monsters with more complicated properties.


Quote
I would define solvability as the probability that the perfect player wins the game, but this seems to not be what you want (for example, in your example about having more freedom when fighting goblins than when fighting dragons, this freedom is irrelevant to perfect players).

Hmm... Solvability shouldn't care about heuristics, so it doesn't care about perfect playing. The probability of a perfect player finding a solution is determined by how we design the game. Solvability, as an explicitly defined component (as a set of values to achieve certain qualities that we define as desirable) of generated content, will result in probabilistic solvability (of the whole game) for different heuristic skill levels (either novice or 'perfect' or what not').

So, yes to both. Solvability, as a generation parameter, could be implemented to generate game content so that a perfect player will win with some amount of frequency. But it could also be used to assure a certain degree of solvability so that perfect play will always result in a winner. We can then incorporate complexity to make this more difficult, but always solvable so we never let a player continue playing when they're already in a sub-tree with only terminal fail states (unless it's local- IE, a duel or a room). That's up to the designer though.

I personally think it's better design to always have some solvability unless it's a game where a psychological component plays a role in who wins (competitive card games, or decision games with a fog of war), but that's a player vs player problem- we don't want explicit solvability because if both players play perfectly then white will always defeat black (likely the case in chess if we had the computing power to evaluate all states- but it could always result in stalemate with two perfect players). Anyways- different topic of discussion.
Title: Re: Designing Difficulty
Post by: requerent on March 03, 2012, 02:09:08 AM
I'd like to contribute to the discussion itself of making procedurally generated content that can get you both high solvability and high complexity (thus establishing a "truly difficult" puzzle), but that sounds like a really hard thing to create even by hand. Or maybe you're just looking into ways of creating PCG that can be tweaked according to these parameters in order to change the difficulty curve?

Yep! If we can set parameters for solvability and complexity within certain probabilistic ranges, we can ensure a degree of challenge that we want. If a player in a RL scrapes by, with unlucky drops, to an arbitrary depth where Dragons may appear, but no Dragon appropriate gear has been generated, then we've boned the player in an uninteresting way. They've worked very hard to have to willingly throw themselves into the belly of a Dragon. This isn't tactically or strategically interesting. Simply avoiding it also isn't inherently interesting. Having to perform a set of varying actions to avoid it, however, is. If the level was generated with, say, a faulty column that could be struck to cause the Dragon to fall through a pit or to be crushed/weakened/stunned by falling rocks- that may be interesting and complicated if several things need to happen first.

Brogue creates these sort of dependency tree situations with it's key puzzles. A level with a key stuck behind lava will typically have a potion of fire immunity or levitation.

Quote
A lot of roguelikes, particularly older ones, like to use vast worlds and subtle gameplay structures in order to increase complexity for players who don't understand the game mechanics. This, in itself, does change the difficulty of the game to a point, but from the point of view of a player who can see everything in front of them, it's probably a lot simpler of a game. Honestly I'd say Krice nailed it, at least in terms of what we think of as a traditional roguelike. That said, designing something that really expects player creativity rather than prediction would make for an awesome game, roguelike or otherwise.

That's the idea. I find myself automatically defaulting to, "What do I need to do to prepare for this area that my character knows nothing about but that I, as a player, have experienced before?" ToME can get pretty bad about this.
Title: Re: Designing Difficulty
Post by: Z on March 03, 2012, 03:14:45 AM
This definition is very sensitive to meaningless decisions.

For example, if we add a question about the end of game "What do you use the Amulet of Yendor for? (a) eternal life, (b) infinite wealth, (c) love, (d) knowledge, (e) death" then solvability a:b suddenly becomes 4a:b+a (assuming that "death" is a losing option). With 20 questions it becomes, say, 1000000a:b. This example is silly, but in fact there are lots of meaningless decisions during the game. A typical 2x10 room can be traversed in 1024 ways. You can use a fire spell or an ice spell, but against most monsters it is irrelevant which one you use (while against some it is relevant). And if there are 40 monsters, we get 2^40 meaningless choices.

Also you always have these obviously bad decisions. You can always lose by pressing 'Q' to quit the game, or use another method of suicide (typical for the given game). When fighting monsters you can just wait until you are killed by them, instead of fighting back (the game will be probably still solvable while you are doing it, but it will be much harder). All of these seem to greatly reduce your solvability, but they have no relevance to actual gameplay.

But let's try it in an actual game, and see if we get a reasonable result.

Suppose we are playing Chess against an extremely bad player (we assume that this player is deterministic to avoid considering their decisions in our solvability formula). Still, this player knows the very basic (that it is good for him to capture our pieces, but maybe he does not know that it is important to defend his own, etc), so, when playing randomly, we are almost sure to lose. But still, we can probably win in most situations by playing well again, unless we really spoiled it. Winning the game of Chess requires a checkmate, while any reasonable person could checkmate the opponent's king using two rooks, it requires a quite specific sequence of moves, and when playing randomly, it is much more likely that the opponent captures our two rooks, or that one of the draw rules of Chess kicks in. All this means that your solvability would be extremely low in this game. But we were still playing against an extremely bad player. Only a basic understanding of the game is sufficient to win without effort. I suppose the same would happen for an easy roguelike.

On the other hand, the game "I take 20 red or black cards, and you have to guess their colors correctly" has a solvability of 1:20, which is much higher than Chess/Roguelike despite that intuitively it is obviously far from solvable. Note that this solvability would not change if I have shown you the cards.
Title: Re: Designing Difficulty
Post by: requerent on March 03, 2012, 11:47:15 AM
Quote
This definition is very sensitive to meaningless decisions.

That's kind of obvious.

The definition isn't complete or necessarily useful yet, but that doesn't have much bearing on the validity or value of the idea or potential. If I make a slight correction and say, "The tree of all salient game states." Then We already have a huge optimization.

Salient game states would simply be those that are... salient >_>. Completely solvable and unsolvable subtrees can be pruned. If all of a node's children are completely solvable, then this portion of the subtree is absolutely arbitrary. We can further evaluate salience relative to actions that the designer feels are more important- getting rid of obviously bad decisions. If we think of this in terms of heuristics, we may only be interested in the top N moves that are possible from a given state. Salience may be something we want to evaluate in a way that is similar but different from heuristics. For example- if an Ice spell or Fire spell have nearly equivalent outcomes (or similar heuristic costs), one could be pruned on grounds of equivalency.

This would actually make the game more complex, because we aren't considering highly equivalent actions as a contributing factor to variance when it comes to content generation. If we're in the land of 'Fire and Ice does the same thing,' we don't want to think of them as separate actions when generating complexity. This is just a side-benefit to applying salience.

Finally, we don't need the whole tree to have a useful model of solvability, we just need some samples of the hardest and easiest paths. If we're generating a room trying to satisfy a range of solvability, we might evaluate (adjust difficulty based on) the worst possible salient state (IE, player is surrounded) of a partially generated room.

Solvability also relies on Complexity for a game to be interesting. Complexity would regulate mundane repetitions and symmetrical paths during generation. Disregarding complexity for now- in a word, 'Salience' is a reasonable answer to the problem of meaninglessness.

Solvability will likely have a feature set of values (such as, at about what depth in the tree do terminal fail-states begin to appear?) that allow a designer to address difficulty in a way that isn't arbitrary.


Quote
On the other hand, the game "I take 20 red or black cards, and you have to guess their colors correctly" has a solvability of 1:20, which is much higher than Chess/Roguelike despite that intuitively it is obviously far from solvable. Note that this solvability would not change if I have shown you the cards.

Solvability isn't very useful when applied to coin tosses, but if we know what the cards are, then unoptimized solvability is sufficient to represent the entire tree. If we apply salience, solvability should become something like 1/2.

Solvability describes how solvable a game is relative to the range of decisions that can be made. Red-black is a much simpler game than Chess/Rogue, but it only has one solution. Chess is much more convoluted complex, but I think your chess example misses the mark. We don't care if players are making intelligent decisions,  player decisions throughout a challenge do NOT effect solvability! It is a measurable property of a decision tree or of a sub-tree (but we're only interested in the initial state- how solvable is a problem when the player encounters it? Or- how solvable is the problem when we generate it?). Calculate all possible board states and decision paths of chess, what is the ratio between Win and loss or draw? We obviously can't do that- but we're not trying to. We're trying to generate a challenge that probably satisfies solvability constraints.

Now- the outcome ratio of chess may not be better than red/black, but with salience it definitely would be.



BTW- Hydra Slayer is AWESOME. Is there a particular place for discussing it?
Title: Re: Designing Difficulty
Post by: Z on March 03, 2012, 01:30:23 PM
Quote
We don't care if players are making intelligent decisions,  player decisions throughout a challenge do NOT effect solvability!
Quote
Salient game states would simply be those that are... salient >_>.

I think these two are in fact related, since salient decisions would be those which can be taken (or maybe considered) by players making intelligent decisions. Otherwise any complex game would have a very low and irrelevant solvability (as my chess example shows).

Also, I think some way of probabilistic calculation makes more sense than simply counting the paths. Otherwise you would have to calculate paths which occur in very rare situations on the same level as paths which occur frequently. This also automatically prunes meaningless decisions (like my fire/ice example).

Combining the two, we get that solvabilty would be the probability that a player wins the game (except that now this is no longer a perfect player, simply an intelligent one).

In fact I think we could try to create an AI (or a bunch of AIs of different skill levels) and see how many of them pass the challenge. I think this would make sense as a way to automatically make sure that the game is solvable. But this would be also a lot of work for most good roguelikes.

This reminds me of a tiny roguelike called 'Get Out' (http://code.google.com/p/getout/).  In this game the number of possible states was so low that a skilled programmer could easily verify whether the game is solvable, and probably also somehow estimate how difficult the challenge is, using something similar to your ideas. Unfortunately it was done by an unexperienced programmer, so it just generated random levels without ensuring solvability. Could be a nice testing ground.

Quote
This would actually make the game more complex, because we aren't considering highly equivalent actions as a contributing factor to variance when it comes to content generation. If we're in the land of 'Fire and Ice does the same thing,' we don't want to think of them as separate actions when generating complexity. This is just a side-benefit to applying salience.

But we should also apply this to your previous example that there are many paths when killing goblins, but not so many when killing dragons.

Quote
Calculate all possible board states and decision paths of chess, what is the ratio between Win and loss or draw? We obviously can't do that- but we're not trying to.

It should be possible to calculate this in very simple situations (like king vs king + 2 rooks and some simplifications of the draw rules).

Quote
BTW- Hydra Slayer is AWESOME. Is there a particular place for discussing it?
Thanks! So far the most discussion happened in the announcement thread (http://roguetemple.com/forums/index.php?topic=1270.0) and I think this is the best place. (The discussion on the New Attnam forums also could be helpful, but I think you need to be registered to get there.)
Title: Re: Designing Difficulty
Post by: Ancient on March 03, 2012, 05:53:44 PM
@Ancient

Emergent Gameplay, as far as I am familiar with the concept, has less to do with any given challenge and more to do with how many options a player has. A player can engage in emergent gameplay to solve more difficult problems, but they don't have to be more difficult. Emergent gameplay can be implemented 'for' fun- such as in Dwarf Fortress, where lava traps and other bizarre contraptions are entirely unnecessary but completely emergent.

So emergence counts only on the player side? I thought it also applies when several rules interacting with each other creating something that was not explicitly designed fits in. There are no bosses for usual dungeon level. But that unique that happened to be generated with attack wand suddenly poses a challenge difficult enough to name that monster a boss despite it is not one in strict terms.

Quote
I'm not sure if what you're describing is really emergent gameplay. These examples are challenges that may or may not require emergent gameplay, but they don't necessarily have anything to do with emergent gameplay. 4 is the closest, but that isn't increased complexity because evasion is a repetitive action.

Okay, I definitely misunderstood something. When that centaur pops up in crawl at dungeon level three you have to constantly obscure its line of sight to you until it comes close enough you can try meleeing it. Why do you consider closing doors, reading scrolls of fog and casting stinking could to be repeatable actions? Doors can be closed only once (unless you open them but this exposes you to centaur's arrows), scrolls and mana points are finite. If you can simply walk away from a monster it is no threat worthy of discussion.

Quote
There is also nothing inherently emergent about evasion.

Note I did not claim that. I view unintended creation of such boss as emergent, not how you deal with it although there emergence may apply to that. Admittedly example 3 has absolutely nothing to do with emergence because it is a single explicit rule.
Title: Re: Designing Difficulty
Post by: requerent on March 03, 2012, 08:14:56 PM
Quote
So emergence counts only on the player side? I thought it also applies when several rules interacting with each other creating something that was not explicitly designed fits in. There are no bosses for usual dungeon level. But that unique that happened to be generated with attack wand suddenly poses a challenge difficult enough to name that monster a boss despite it is not one in strict terms.

I don't think that is emergent gameplay. We could call it an emergent challenge- but I think the meaning is different.

The PCGenerator operates under a specific set of rules. When it produces a random set of values that liberally applies these rules, we may get a monster that violates existing patterns. The generation rules allow for the emergence of challenges that the game is not designed for.

However, emergent gameplay describes how the player is allowed to solve problems. If we generate an emergent challenge but there is no emergent solution, how does this challenge effect gameplay? The player does the same old same old- s/he may have two different approaches for fighting "Critters" and "Elites," but a unique may or may not demand emergent gameplay. The game literally may not have to be played differently to solve the emergent challenge.

-----

Kind of like arbitrarily titling a piece of incromphensible modern art. Say we have some meaningless drivel of paint splatter- when people look at it that is what they see. However, if we are to arbitrarily name the piece "The plight of Sudan," or "The romance of Joann," or "Death of a Moniker," the audience will try and marry the current image to some meaning contained in the title.

Artist makes an abstract painting without a title or meaning in mind. After the fact, he gives it a title- possibly randomly generated. After a title is slapped on it, new meaning emerges. We suddenly see the flag of sudan trodden under by flashes of red, or curving lines that copulate into coalescing forms, or the visage of visagelessness falling into darkness. These observations into what the meaning of the piece may be are emergent.  However, if a person does not know anything about the Sudan, romance, or what a monker is, then a related interpretation isn't going to emerge! They may think of something else, but it may be irrelevant- or they may default to a "Paint is pretty" interpretation... or "modern art sucks."

The painting represents the monster. The emergent challenge.
The title represents a potentially emergent solution that is associated with that monster.
The interpretation is whether or not a player is ABLE to execute that solution.

An emergent challenge may or may not result in emergent gameplay. The two aren't necessarily dependent upon one another.
Title: Re: Designing Difficulty
Post by: Ancient on March 03, 2012, 09:18:52 PM
That settles the matter. I assumed your question to Jo dealt with emergence in general because you asked in what way that would be emergent.

By the way, my last modification to previous message did not register at posting time so I fixed it now.
Title: Re: Designing Difficulty
Post by: requerent on March 03, 2012, 10:10:17 PM
That settles the matter. I assumed your question to Jo dealt with emergence in general because you asked in what way that would be emergent.

By the way, my last modification to previous message did not register at posting time so I fixed it now.

Oops  :-[. I may have misread- I thought Jo was talking specifically about emergent gameplay. So, asking "in what way is that emergent?" I meant in regards to how I thought it was used originally.

I don't know how much emergent challenges make the game interesting if there isn't also emergent gameplay. The goal or spirit of 'emergence' has more to do with making the gameplay interesting. If emergent challenges don't accomplish that, then I don't know if the game itself satisfies the design goal of being emergent.

This is just me reading into things though.

---

Centaur example is totally emergent.

Evasion may or may not play a role in emergence- just an open statement.
Title: Re: Designing Difficulty
Post by: requerent on March 03, 2012, 10:27:32 PM
The formal representation of solvability may include only unique and salient game states. Salience, however, is subject to design, so the model is as useful as it can be implemented.

Quote
I think these two are in fact related, since salient decisions would be those which can be taken (or maybe considered) by players making intelligent decisions. Otherwise any complex game would have a very low and irrelevant solvability (as my chess example shows).

Hmm... It doesn't have to do with player intelligence because the solvability is generated into the challenge. The player's actual intelligence is not factored into generation (though I don't think this is what you're saying). We don't care what actions the player is making or will make, we just want to be certain that there exists a desirable amount of decision paths that the player can take to solve the challenge. Moves of a low heuristic (dumb moves) value are not salient because we assume they are failed paths. The player's decisions don't really have anything to do with quantifying how solvability effects the challenge. Solvability should try to include some unintelligent decisions after all.

Now, if we are using heuristic pruning of some kind to simplify the problem of solvability, then we need a measure of what moves are important and what moves are not. I'm not sure if this is the player's intelligence- the player doesn't have anything to do with how the challenge is generated.

Quote
Also, I think some way of probabilistic calculation makes more sense than simply counting the paths. Otherwise you would have to calculate paths which occur in very rare situations on the same level as paths which occur frequently. This also automatically prunes meaningless decisions (like my fire/ice example).

I think I've been wrong in thinking about solvability as a tree (which could work). It should be a directed graph.

If that were the case, we could generate solutions as salient actions from the goal state with some branching factors and desired depth until we decide to converge on the initial state. If this is the case, we can explicitly generate the paths with only salient events. Any divergence from these paths may or may not result in failure (which is a problem). The greater the branching factor from the goal state on, the more solvable it is. That is- solvability describes the breadth of solutions. Complexity, then, is how many required steps from the goal state to the initial state there are- or the depth and variety of actions. Excuse the redundancy, I'm still thinking this through.

Hmm-- Suppose a Hydra is generated that the player can't solve with current equipment. We could also generate a single weapon that makes the hydra solvable in some amount of steps... or a whole slew of weapons and items that all need to be used within a particular order to solve the Hydra. Even a two-headed hydra can be turned into an incredibly complex problem pending on what weapons and tools are available. Runes can be used to auto-solve these problems or jump between salient events, but if we were to exclude them when deciding which hydras and weapons to generate, we can generate challenges whose difficulty is very measurable.


Quote
Combining the two, we get that solvabilty would be the probability that a player wins the game (except that now this is no longer a perfect player, simply an intelligent one).

I'm reluctant to use probability to describe whether or not a player wins a game, but I think we can set the probability based upon how we address solvability. If we're analyzing a game's solvability... then yes, the digested information we get is the probability. It's probably more important to look at distinct challenges, though, instead of the entire game.




Quote
Quote
This would actually make the game more complex, because we aren't considering highly equivalent actions as a contributing factor to variance when it comes to content generation. If we're in the land of 'Fire and Ice does the same thing,' we don't want to think of them as separate actions when generating complexity. This is just a side-benefit to applying salience.



But we should also apply this to your previous example that there are many paths when killing goblins, but not so many when killing dragons.

I think it still works out- if salience only cares about the highest heuristic valued moves, goblins will be more solvable because more of those moves are likely to have solution paths than in the case with the Dragon- unless, of course, that's not how the game is designed.



Quote


Quote
Calculate all possible board states and decision paths of chess, what is the ratio between Win and loss or draw? We obviously can't do that- but we're not trying to.

It should be possible to calculate this in very simple situations (like king vs king + 2 rooks and some simplifications of the draw rules).

Yea- I just mean we can't generate the entire game state tree of chess. It's one of those end of the universe problems. Of course, solvability as a model might hypothetically care about all of that, we just have to implement it in a salient way for it to matter. For really good players, chess doesn't really begin until after the 20th move or so- both players have the same amount of knowledge of the game from the initial state, they can silently agree on how the game will progress (because the best first 20 moves or so has more or less been solved). I kind of hate chess for that. Knowledge becomes more important than a person's ability to solve problems.



I'm really just trying to rationalize the most complete and useful way to regulate difficulty in a game so that it remains meaningful and challenging. Solvability and complexity, and their sub-properties, in terms of some organization of actions seems to be close- but there are a lot of gaps that need to be worked out.
Title: Re: Designing Difficulty
Post by: Krice on March 05, 2012, 01:19:05 PM
I'm really just trying to rationalize the most complete and useful way to regulate difficulty in a game

Roguelikes are often complex and may surprise even the developer which is a good thing. Trying to create some kind of deterministic rules may lead to poor gameplay, because players can then determine everything before they get into trouble. Then again, it may be something intended, like the exact science of D&D system which makes some people work like a calculator.
Title: Re: Designing Difficulty
Post by: Darren Grey on March 05, 2012, 02:06:38 PM
I think even with deterministic rules the game can surprise the developer.  Players outsmart devs all the time  :)  Besides the cmoplaint is more against things like random battle mechanics, which lead to life and death in the game falling under the whim of the RNG.  Procedural content in terms of world creation and monster behaviour is still important.

A big issue with random battle mechanics is that you have to balance to balance the game around getting runs of bad rolls, as this is bound to happen in any game.  As such the game must be easier than it would be with a deterministic system, which can be boring if you keep getting good or average rolls.
Title: Re: Designing Difficulty
Post by: guest509 on March 05, 2012, 02:52:11 PM
  In games dominated by the RNG a deterministic combat system does not make the game deterministic overall. But it many circumstances it can give some much needed predictability.

-Jo
Title: Re: Designing Difficulty
Post by: Darren Grey on March 05, 2012, 06:06:35 PM
There has to be a balance between predictability and the unexpected.  Predictability means knowing that the goblin in front of you will die in one hit, but the orc takes two.  The unexpected means not knowing how the goblin will act, or what's behind the corner that could come traipsing round whilst you're tackling the orc, or what the unided potion in your inventory does if you choose to use it.  A mixture of the predictability and the unexpected means being able to plan ahead a few turns, with the caveat that things may not go as you expected.  Too much predictability and it becomes a set puzzle, which is boring since you solve it at the start and then just go through the steps.  Too much unexpected and it loses tactical depth since you can't plan appropriately.  If you can't plan properly then the game doesn't reward you for thinking, and so is boring.

Chess is always the best comparison in my mind.  You know the immediate result of your move, and you can guess how your opponent will react, and so you can plan ahead a few turns.  But it's not fully predictable and your tactics have to change and evolve as you play.  The game rewards thought, and because it keeps changing you have to think every turn.  It is never ever boring.
Title: Re: Designing Difficulty
Post by: guest509 on March 05, 2012, 08:31:19 PM
  Good points all. I had a system in mind where your heavy weapon is more random and risky whereas the more mundane normal attack is reliable. Think fireball spell and dagger attack.

  I think the example was of ToME being too random. I didn't catch that but I'm sure there are good examples out there.
Title: Re: Designing Difficulty
Post by: guest509 on March 05, 2012, 08:39:51 PM
I dunno if this adds anything.  Bobby Fischer created this chess variant that eliminates openings. Maybe you'll like it better.
http://en.wikipedia.org/wiki/Chess960
Title: Re: Designing Difficulty
Post by: requerent on March 05, 2012, 10:15:17 PM
Quote
Chess is always the best comparison in my mind.  You know the immediate result of your move, and you can guess how your opponent will react, and so you can plan ahead a few turns.  But it's not fully predictable and your tactics have to change and evolve as you play.  The game rewards thought, and because it keeps changing you have to think every turn.  It is never ever boring.


I'm in the camp that doesn't think of Chess as a 'game,' but more as a competitive puzzle.

The problem with chess is that it has no fog of war and the initial board state is always the same. It is not predictable what an opponent may or may not do, but both players can be aware of ALL possible outcomes of any given move.

Chess is then a battle between who has more of the game state tree of chess memorized. If that doesn't determine a winner, it is a battle of objectifiable (word choice? >_>) heuristics. If that doesn't determine the winner, then it's who is more familiar with whatever sub-tree of board states of chess we are in. IFF that doesn't determine the winner, we will finally have a game that is interesting.

Why do I dislike all of that? Because it has the potential to become-->

Quote
Too much predictability and it becomes a set puzzle, which is boring since you solve it at the start and then just go through the steps.

The other thing we're getting at here is accessibility. A player's skill rating is more dependent upon memorization than on one's ability to utilize the rules. Because Chess is a solvable game, it would eventually become a set puzzle. A low-ranked player has virtually no chance against a high-ranked player due to a difference in the number of early moves memorized. If those early moves didn't matter, then it would become a contest of who utilizes the rules of chess in the most interesting way.

A simple exercise to change things up is to allow players to place pieces on the board within the first two ranks in turns. If white places a piece first, then black has a slight advantage in initial board state, while white has an advantage in tempo. The change in starting conditions mean that memorization won't favor one player or the other. Intelligent building of the opening board state and clever utilization of the rules would play a larger role. After all the pieces are placed, the game is still completely calculable- we just cut out memorization as a factor in skill. Of course- there are obviously 'good' and 'bad' initial states and these may not matter much what the other player is doing, so memorization can still play a huge role if this style of chess is something that a player practices regularly.






An interesting game to look at, in terms of initial state and fog of war, is this little Italian card game called Scopone (Specifically the variation Scientific Scopone).


The gameplay is simple-
--40 card italian deck, each player is dealt 10 cards.
--Right of dealer plays first.
--Each turn a player MUST play a card (10 rounds per hand).
--If there exists a card or group of cards on the table that add up to the exact value of the card played, those cards and the one played are captured by the player's team. If multiple sets of cards exist, the fewest number of cards must be taken (player's choice on a tie).
--If a player plays a card and captures all the cards on the table, it's a 'scopa' (pronounce it loudly and proudly!) or 'sweep'- unless it is the last round of cards played.
--When there are no longer any cards in hand, the last person to capture is awarded all of the remaining cards on the table.


Points are calculated at the end of each hand. One point is awarded for each of the following:
--Most Cards (unless there is a tie)
--Most Golds (unless there is a tie- 'gold coins' is a suit)
--Highest Primes (generally who has most sevens)
--Gold Seven
--For each Scopa

The first team to reach 11 points wins. Points are only calculated at the end of a game and at the same time- therefore, it's possible to tie. If there is a tie, continue playing until the difference in score is 2.

Table talking is absolutely allowed- There are even specific italian words that players are encouraged to use to tell their partners what they want them to do. The only restriction is that a player is not allowed to announce a card in their hand.




What makes this game awesome? All of the cards are accounted for AND there are a variety of objectives for each hand. The rules are very simple and strategy gets very interesting.

If there is a 4 and a 5 on the board and I don't have a rider (9), I might play a 3 or a 2. My opponent, who has a 7, will want to win a prime, taking the 4+3 or 5+2 (pending on what I played) with his 7, leaving behind a 4 or a 5 for my partner which could result in a scopa for my team. The opponent knows that this is risky, but if he does something else there may still be a combination of 7 on the board passed to my partner- who might also have a 7. Say the board is 4,3,5- he might play a 2 instead of a seven. If my partner plays a 7, he leaves a 7 exposed to the other opponent who could take it as a scopa. Lots of things have to be considered.

Similarly- If one player of team A knows that the next player of team B has a 7, but that the other player of team A does, he can literally pass a 7 to his partner. The only way to prevent this from happening is for the other player of team B to ensure that an ace, two or three is on the board so that their partner can catch that 7 with a royal (face card)- that, however, could then expose a scopa with the remaining card. If card passing does succeed, it can oftentimes result in a scopa for the other team.

Say there is a 2 and 3 on the board and something else. You play an ace and your opponent has a 6. If two to three of these four cards are gold, a player will consider taking the risk of exposing a scopa to your partner. If they don't, however, they're going to pass a bunch of gold to your partner. Same sort of situation as the above two examples.

Being aware of how players pass on opportunities gives us hints as to what they have and don't have- but a player is just as likely to intentionally not play something to prevent the chance of a Scopa happening or to dupe you. With tabletalk as a component, both the rules and social component create a very fun and interesting game. You end up playing and thinking about the game in some really complex ways.

When a team is pressed into a position where they can't make a strategic action it's called a 'whirlwind' (because one team is taking cards when the other can't). A 'whirlwind' of scopas is the ideal progress of a game for one team (typically lots of taunting will result: "And it's become a whirlwiiiiiinnnd"- "is it breezy in here? Oh oh... look what just happened again"), but the game is very interesting because it's not difficult to come back from a losing position because there are so few points awarded. It's possible for the game to end in 2 hands, therefore dealer dis/advantage (though there isn't really any) is balanced by the way scoring is handled and by how many points you need to win. After all, each game both teams can get the same number of points in different ways. You have to play both to pursue objects and deny your opponents.


You can play it as a heads-up game also- just deal the second set of 20 cards after the first has been used up. The first hand is a lot of probing strategies, while the second one ends up dealing with card-counting and tricking your opponent.

The scientific variation causes the game to start as a whirlwind, which many players find frustrating (though IMO a better game)-- traditional rules have 9 cards to each player and 4 starting on the table.

If you have a friend or group of friends interested in alternative games, I highly highly recommend it-

http://en.wikipedia.org/wiki/Scopa (http://en.wikipedia.org/wiki/Scopa)
http://www.pagat.com/fishing/scopone.html (http://www.pagat.com/fishing/scopone.html)

Games are fast and a lot of fun. The regular version of two-player Scopa is in itself a great game. I find it to be much more strategic than Bridge or any other trick taking game.
Title: Re: Designing Difficulty
Post by: guest509 on March 17, 2012, 11:21:12 AM
  I'll have to check out that game next time I'm up for a card game night. Those happen very rarely nowadays. My group mostly gets together nowadays to play FPS frag fests.

  As for your project; I'm a huge fan of the methodology of Kinsey. His brute force information gathering so as to create rock solid statistics has influenced my academic pursuits in many ways.

  That said I think this year's 7DRL competition will probably produce a TON of games for you to study. I'm expecting there to be at least a dozen top games this year. All short and with easy to access source code (I for one would release my source to anyone who asks). It could take a lifetime to become an expert in more than 1 or 2 major roguelike games. With the smaller ones it is possible to really know the mechanics inside and out and use that knowledge to further your study of design and difficulty.

  Just a thought. 
Title: Re: Designing Difficulty
Post by: Vanguard on March 17, 2012, 09:38:59 PM
Because Chess is a solvable game, it would eventually become a set puzzle.

That's technically true, but in practice, no human player is ever going to be able to do that.
Title: Re: Designing Difficulty
Post by: guest509 on March 18, 2012, 08:37:58 AM
  On the contrary. Top Chess players have complained that the game has become a memorization exercise during the several opening moves. Meaning the more creative chess player will lose if he is not also the more 'memorized' chess player.

  You do not need to memorize the entire game for it to be solved. Just enough to beat everyone else.