Temple of The Roguelike Forums
Development => Programming => Topic started by: Xecutor on October 24, 2013, 03:40:30 AM
-
A lot of authors are trying to prevent players from farming. Sometimes this includes artificial limitations and not very logical/interesting mechanics.
But what if instead of preventing farming, you allow farming as integral part of the game.
For instance - you need 20 bat wings for quest or may be crafting recipe.
You go to the cave in appropriate equipment, with enough healing potions and food.
Than press 'f'arm key, enter end conditions and wait a little, while AI kills bats all around the cave.
The same with exp. You need a little till next level. You know that you can kill monsters
in this area relatively easily. Why not 'f'arm till level up then?
-
Theoretically, why not? However, my first impression is that if a player wants to skip playing and just let the AI fast-forward some tasks for him then there's something wrong with the gameplay.
In the bat wings example, why not change the quest or recipe to get just one wing that's harder to find? The amount (20) seems like just a cheap move to make the player spend more time with the game. And the exp example - this seems like the whole game is crap and only getting achievements or levels is fun.
In my opinion the core gameplay should be so interesting that you actually want to do it. Things like leveling up should be secondary - a byproduct of having fun with the game.
-
What purpose would this mechanic serve? How would it make the game fun?
What's to stop the player from telling the game that they want to autofarm 9 million rats and instantly hit the level cap?
Using bad mechanics to cover up other bad mechanics is never a good idea. In this case it would be better to remove the 20 bat wing quest entirely.
-
Farming can be fun, as long as it promotes clever play instead of repeating the same action dozens of times. Not giving the player enough food would solve the 9 million rats problem.
-
repeating the same action dozens of times.
That's what this thread is about.
-
So you want to put in a "play the game for me" button in your game?
Don't get me wrong, I'm OK with Crawl (and that little time-saver is probably the reason Crawl's the roguelike I've played the most), but think about what you're doing here. You're basically admitting that you're putting in a part of the game that isn't really fun to play, and just giving people a way to skip it. Why even put it in at all if you know nobody will want to play it?
-
What purpose would this mechanic serve? How would it make the game fun?
What's to stop the player from telling the game that they want to autofarm 9 million rats and instantly hit the level cap?
Using bad mechanics to cover up other bad mechanics is never a good idea. In this case it would be better to remove the 20 bat wing quest entirely.
I have thought about this kind of autoplay feature before, also. I'm not sure I would call this feature a "bad mechanic" per se, I'm just not sure it would really be needed in a game that gave the player alternatives to bat farming. A task is so trivial that a player can do it in a completely mindless way shouldn't still be giving them a useful reward.
But I don't want too quick to dismiss this idea. Xecutor, can you please tell us more about how you thought that it might be used? Are you thinking that it is impossible to completely remove situations like the one you described from the game, so there should be a way to make them more manageable?
Oh, and if there was a time limit, that might discourage players from abusing this feature to reach nine million xp by killing bats. Or, just if bats stopped giving xp after 500 had been killed, or whatever. I realize that just leads to more questions related to balance, though.
Incidentally, I think that I am now agreeing with zasvid regarding level grinding, at least as far as this discussion goes.
-
Don't we have this stuff in Angband already?
-
Roguelikes sometimes contain stuff which is fun the first time you do it, and boring afterwards. For example, answering the character background questions in ADOM, solving the Sokoban in NetHack, and so on. I think it is acceptable to automate these (provided that the player has already done the job).
-
Nethack should have had randomized Sokoban levels for a long time... [puts randomized Sokoban on to-do list for Zagadka ;D]
I liked how the farming techniques in Nethack require quite a lot of thought and preparation. I think there is value in that. The question is how to skip the long and boring repeating actions. Maybe a good designer could give an answer.
-
Even with randomized Sokoban levels, some people would not like the puzzle, but they still would feel compelled to solve them again and again, to reap the rewards. In this case, having intelligent auto-play as an alternative could help -- the disliked puzzle could be replaced by taking costs. (As mentioned in my comment on http://www.roguelikeradio.com/2013/10/episode-81-puzzles.html )
-
Even with randomized Sokoban levels, some people would not like the puzzle, but they still would feel compelled to solve them again and again, to reap the rewards. In this case, having intelligent auto-play as an alternative could help -- the disliked puzzle could be replaced by taking costs. (As mentioned in my comment on http://www.roguelikeradio.com/2013/10/episode-81-puzzles.html )
I feel like Z is right. There must be something that could be done with the idea. Xecutor was brave enough to put it forward, and I feel like we (including myself) did not give it enough of a chance. It is much easier to say that other people's ideas will not work than it is to help discover ways that they can work.
Realistically, don't most roguelikes have segments where players often think: "well, it sure would be nice to skip this section and move on to the next?" Sure you can say that an ideal game just wouldn't have parts like that, but that's not reality, is it? So, Xecutor seems like (s)he is just trying to address a very real problem here.
-
1) Show me these wonderful games with amazing mechanics with quests and advanced crafting which will NEVER force player to do repetitive/boring actions.
2) The point was in "in appropriate equipment, with enough healing potions and food.". i.e. you can't do this infinitely. And you have to carefully setup this. For example add the condition of when chracter must heal and what source of healing to use. If killing low level monsters won't cover expenses, you won't be able to continue autofarming for too long, no?
3) Crawl do not have neither quests nor crafting. And yet I wouldn't mind having 'autokill' option for enemies that no longer are a threat to the character. As traveling from D:15 to stash at D:5 might be somewhat annoying.
-
Yes, auto travel across the dungeon is something many RLs would benefit from, much more than other kinds of auto play.
Here is an idea. Turn farming into a puzzle that gets harder with time. For example, maintaining a special pattern of the puddings in Nethack, otherwise it all falls apart (I guess it would be similar to how herbs work in Adom). This would turn a repeated boring exercise into an increasing mental effort.
-
How about instead of automating tedious actions, you take them out the game.
-
And yet I wouldn't mind having 'autokill' option for enemies that no longer are a threat to the character. As traveling from D:15 to stash at D:5 might be somewhat annoying.
I think a better option would be for enemies that are no longer a threat to the character to run away from them.
But I'd be OK with something like that, too. It's a significantly different mechanic than the original post proposed though.
-
How about instead of automating tedious actions, you take them out the game.
Different people have different opinion of what is tedious and what is fun.
Some are totally okay with digging kilometers of tunnels in minecraft, but some are installing mods where bots/minions/golems are doing this for you.
If you start removing every potentially tedious things from the game, you might end up without the game at all :)
-
So, Vanguard mentioned that we should just remove mindless, repetitive parts of gameplay from the game. But I think Xecutor is right in asking whether that is really always possible. Sure those parts wouldn't be there in an ideal game, but can anyone name a game that has no parts like that whatsoever?
Also, I think one problem here is that we are overlooking what types of input the sessions of simulated play would require from the player. Anyone who thinks that these simulation aspects would just be an "easy mode" or play the game for you should think more about how they would actually be implemented. Presumably, the player is going to have to put some thought into editing algorithms which would determine the behavior of the PC during the period that behavior was automated, at least if they want the PC to survive.
Heck, if nothing else, the player has to specify what conditions will return direct control of the PC to them, right? Otherwise the simulation would go on forever. Those conditions could be that a certain amount of time had passed, or, more importantly, they could be that the PC had lost a certain amount of health.
But that's just the beginning. A lot of other algorithms would need to be adjusted too. How low does the PC's HP need to get before they rest, use a healing item, retreat from battle, etc. When should they use melee vs ranged combat vs magic? What monsters should they avoid entirely? I could go on, but all you have to do is try playing Final Fantasy XII to see that there is a lot of strategy involved in setting up and editing these types algorithms.
I don't buy the idea that playing a game using preset algorithms is somehow not really playing the game, either. This is the kind of argument that was used against Final Fantasy XII when it first came out, for instance. The algorithms really don't do anything for you that you couldn't do for yourself already, albeit more tediously.
You girls/guys also mentioned that you should take tedious elements out of the game rather than using Xecutor's ideas to make them more palatable. But, you know what parts of many roguelikes are trivial and repetitive? most of what you do in them. How much strategy is really involved in going up to a monster and pushing the arrow key to kill it? Not much, and that is what you do in combat, more often than not.
That's not to say that, overall, gameplay isn't cerebral and doesn't involve a lot of resourcefulness and skill. It definitely does. There are just also a lot of times where you do things that you don't really have to think about. I mean, there are times when my PC's die from what could be called my own boredom, because I was doing something I had done so many times before that I wasn't really paying attention.
You know I think that part of people's reaction to this kind of automation comes from some sort of deep feeling that a series of preset algorithms couldn't possibly capture the nuance of their play style. Sort of the "there's no way a computer could ever replace me" mindset.
But, I disagree with that. I think that by setting relatively few conditional statements, you could "play" a character better than a human using the hands on approach. I mean, you guys who are so into min-maxing seem like you would really be interested in exploring that line of thinking. Has anyone tried to come up with a "program" for ideal roguelike play?
-
Another way of looking at it is this: I think that the premise of Vanguard's and Xecutor's arguments are basically mirror images of each other. Vanguard's argument seems to basically be: "why simulate boring parts of the game when you can remove them entirely?" and Xecutor's argument seems to be: "why remove boring parts of the game entirely when you can just simulate them?".
And I think that ultimately both approaches have the same goal in mind (to eliminate boring parts of games) and both might ultimately both be useful, rather than either being "bad" or "wrong". They are ultimately complimentary.
EDIT: Minor wording changes.
-
But, I disagree with that. I think that by setting relatively few conditional statements, you could "play" a character better than a human using the hands on approach. I mean, you guys who are so into min-maxing seem like you would really be interested in exploring that line of thinking. Has anyone tried to come up with a "program" for ideal roguelike play?
Yes, for example, Rog-O-Matic plays Rogue on par with the best human players.
-
There are already some roguelike features which automatize parts of the game, but we are so used to them that we do not see them as that. For example:
- drawing the map automatically
- keeping track of the identified stuff
- "world map" like the one in ADOM
- having an "alternate weapon set" so that you can switch between a sword and a bow with a single keypress
- casting spells from a list, instead of requiring the player to memorize the spell (cf. Malachite Dreams)
- automatically taking care of the player character's physiology, organizing his pockets and packs into an "inventory", etc.
-
I`m not a great fan of the "automation" idea. At least not in cases where it regards the gameplay itself... so the example contained in OP sounds terrible to me. You simply no longer play the game, it plays itself.
The beauty of a good roguelike is the fact that you never know what might happen in the cave from the OP. What if a powerful monster wanders in or a trap is sprung?
But, I wouldn`t like it even in a non-RL - in these games if I consider some task a tedious chore, then there`s something wrong with the game itself - it`s not for me and I won`t indulge. Conversely, if the game is good (which encompasses combat/gfx/general ambience etc) - then I don`t have problem with killing 10 bats. I`m on a quest to clear a cave, and I`m gonna do it because I`m enjoying the game. I`ve broken approx several million pots/cut acres of grass in Zelda games but it was never a chore.
Having said that, one is of course free to experiment and if that was included in a game I`d have a look - it`s just I doubt I`d enjoy it. It might also raise a question of "fairness" - for example somebody invests lots of time and effort into building a castle in Minecraft, whereas another just automates it, is the end product "equal"?
(There`s also a dangerous recent trend in mainstream games, where paid DLC often contains some super items or treats that fast track the game avoiding gaining XP and such by the means of "normal" gameplay. It`s quite disgusting, really, and puts a question mark on how commercial games are planned these days.)
There are already some roguelike features which automatize parts of the game, but we are so used to them that we do not see them as that.
Sure, but your examples mostly regard the interface, not gameplay itself. Though one could argue that messing with the interface is a part of gameplay ;)
Recently playing Caves Of Qud I switched off the default automatic eat/drink mechanism, because I felt like something is missing. Paraphrasing Xecutor, if you start automating parts of gameplay you might end up with no gameplay at all ;)
-
Heck, if nothing else, the player has to specify what conditions will return direct control of the PC to them, right? Otherwise the simulation would go on forever. Those conditions could be that a certain amount of time had passed, or, more importantly, they could be that the PC had lost a certain amount of health.
But that's just the beginning. A lot of other algorithms would need to be adjusted too. How low does the PC's HP need to get before they rest, use a healing item, retreat from battle, etc. When should they use melee vs ranged combat vs magic? What monsters should they avoid entirely? I could go on, but all you have to do is try playing Final Fantasy XII to see that there is a lot of strategy involved in setting up and editing these types algorithms.
This sounds like a bad formula for a permadeath game. You'll eventually narrow down your formula to something more or less ideal, and end up having to input the same thing again for every character. At best the game will remember your settings and you'll just end up ignoring that part of the game.
I haven't played final fantasy 12, but from what final fantasy games I have played, I know that most of the series is ultra shallow. Roguelikes can and should do better than that.
You girls/guys also mentioned that you should take tedious elements out of the game rather than using Xecutor's ideas to make them more palatable. But, you know what parts of many roguelikes are trivial and repetitive? most of what you do in them. How much strategy is really involved in going up to a monster and pushing the arrow key to kill it? Not much, and that is what you do in combat, more often than not.
There's a lot of potential thinking involved in even that.
Is it safe to attack this enemy? Is it worth it? Which enemy should you attack? How badly do things have to go before you stop attacking? If things do go badly, do you run away? Use an item? Cast a spell? Did you plan out your escape in advance? Are you familiar with this enemy?
I mean, obviously there are games that screw it up, and even in good games you run into trivial situations, but the premise is solid.
I guess "autofight" systems where your dude just autoattacks until the fight is over are a harmless form of automation. I never use them though, and imo if fights last long enough or trivial fights are common enough that they're necessary, the game designer has done something wrong. Quick, brutal fights are inherently more interesting than long drawn out ones anyway.
-
Quick, brutal fights are inherently more interesting than long drawn out ones anyway.
Not necessarily. True for an average roguelike with a lot of opponents or lack of focus on fighting, but it's not a universal truth.
-
This sounds like a bad formula for a permadeath game. You'll eventually narrow down your formula to something more or less ideal, and end up having to input the same thing again for every character. At best the game will remember your settings and you'll just end up ignoring that part of the game.
I'll have to think more about what to say to this.
There's a lot of potential thinking involved in even that.
Is it safe to attack this enemy? Is it worth it? Which enemy should you attack? How badly do things have to go before you stop attacking? If things do go badly, do you run away? Use an item? Cast a spell? Did you plan out your escape in advance? Are you familiar with this enemy?
If you are familiar with the enemy (which you will be if you play the game regularly), and it is one that is substantially weaker than the PC, you don't have to think much about the things you just mentioned. If you want me to I can give you a LOT of examples of those kinds of situations from ADOM.
Maybe it doesn't happen as much in other roguelikes. I pretty much only play ADOM, so I can't comment on them. But in ADOM what I said is true.
Let me point out again that I understand there are situations where a lot of strategy is involved in playing roguelikes. But, I think most confrontations do not require a lot of strategy. Think about how many goblins/bats/rats you kill in a roguelike. Those battles very quickly become non-strategical, wouldn't you say?
And I really don't see how you can remove those types of trivial encounters from an open-world game like ADOM without resorting to some sort of scaling (which I am generally against). Maybe weaker enemies could avoid the PC? I think someone mentioned that already, but that tends to be annoying if you need to kill them for supplies.
These sorts of under-challenging conflicts usually happen when you are revisiting old territory, so maybe better transportation systems would help somewhat? I just don't see how they could be eliminated entirely, although maybe someone else can come up with better ideas.
-
This sounds like a bad formula for a permadeath game. You'll eventually narrow down your formula to something more or less ideal, and end up having to input the same thing again for every character. At best the game will remember your settings and you'll just end up ignoring that part of the game.
Yes, that's the point, that you would be able to ignore parts of the game that were so trivial you would essentially be mindlessly performing a task. I could turn that argument around and say this: In a roguelike with no option to automate gameplay, you will narrow your (manual) input down to something more or less ideal, and then end up having to (manually) input the same thing again for every character. At best you will remember your previous (manual) input and just end up mindlessly playing that part of the game.
Sure, but your examples mostly regard the interface, not gameplay itself. Though one could argue that messing with the interface is a part of gameplay ;)
Yes, that's exactly what I would argue. These are parts of the game used to require manual input, and are now automatically performed and integrated into the interface.
I would imagine that some of these features would once have been seen as a charming part of the gameplay experience before they were integrated. I bet there were people who used to love drawing maps of dungeons, and really thought something had been lost when automapping became standard. And maybe they were right, I'm not trying to put them down. But I, personally, am glad I have the option to automap.
Recently playing Caves Of Qud I switched off the default automatic eat/drink mechanism, because I felt like something is missing. Paraphrasing Xecutor, if you start automating parts of gameplay you might end up with no gameplay at all ;)
Yes, and that's another point, these would all be optional features. You wouldn't have to simulate anything. You could kill all those bats yourself if you wanted to.
Also, this whole argument could be resolved if someone would just put forth an idea that would make trivial encounters unnecessary. Assume an open world game like ADOM where some backtracking is necessary.
-
Yes, that's exactly what I would argue. These are parts of the game used to require manual input, and are now automatically performed and integrated into the interface.
Well, I wasn`t entirely serious, because once you go down that route, it becomes a minefield of silliness. As in, we could also say then that we`re really playing a pen & paper game because everything else - computers et al is just automation. Hell, even the paper is - otherwise you`d have to do calculations in your head.
Instead I prefer to separate concepts of interface & gameplay (which is probably why these have different names too). And interfaces evolved over time from basic ones - due to being first on the block & also hardware limited - to more advanced, with some features being an obvious norm nowadays.
Yes, I`m one of these people who still likes to draw a map, but that`s totally different and would never work in a roguelike, for obvious reasons like randomization and general pace. Though I was thinking recently that taking away the map entirely could be an interesting option for making games much harder, raising the tension and maybe implementing new mechanics (breadcrumbs?)
that's another point, these would all be optional features. You wouldn't have to simulate anything. You could kill all those bats yourself if you wanted to.
Optional is fine...though it could become a bit worrying then, sort of like the "optional" ability to save that removes the permadeath threat. Say there was a game that had options to automate heavy chunks of gameplay - it`d be seemingly the same and yet I would be perhaps a bit distrustful of how serious its core mechanics are.
Also, this whole argument could be resolved if someone would just put forth an idea that would make trivial encounters unnecessary. Assume an open world game like ADOM where some backtracking is necessary.
I think a better option would be for enemies that are no longer a threat to the character to run away from them.
I don`t really think it`s a problem - after all if an enemy is "trivial", you just steamroll it anyway - but this solution is very nice, I `ve seen it already implemented in one non-RL RPG and it worked rather well.
-
I could turn that argument around and say this: In a roguelike with no option to automate gameplay, you will narrow your (manual) input down to something more or less ideal, and then end up having to (manually) input the same thing again for every character.
This shouldn't happen in roguelikes. That's one of the genre's most important features - content needs to stay interesting through repeated playthroughs. If you can't do that you shouldn't make roguelikes.
Basic automation for simple tasks is fine. Autofight and autoexplore don't do any harm (though better design makes them less necessary). But if you're seriously contemplating automation for quests and other complex tasks, you need to reevaluate your design decisions.
-
These sorts of under-challenging conflicts usually happen when you are revisiting old territory, so maybe better transportation systems would help somewhat? I just don't see how they could be eliminated entirely, although maybe someone else can come up with better ideas.
How about monsters that continuously respawn? If the respawned species is chosen by what creatures currently live, then you can have natural selection make it so the most difficult creatures become more common. Or creatures come back undead? Another possibility is not have boring open spaces in your map to begin with. There's also challenges that aren't creatures such as traps, puzzles, or resource costs. I've tried most of these things in my roguelikes and they did keep things from becoming boring - at least in my opinion.
Under-challenging conflicts also have a lot to do with the overall power curve. If I start as a bumbling adventurer and end up as a god-like killing machine then it will be difficult to make something that's interesting in the beginning and end of the game. But if I start as a mediocre adventurer and, with the right loot and skills, end up as a fairly good adventurer, then some of the early challenges can still be interesting.
-
How about monsters that continuously respawn? If the respawned species is chosen by what creatures currently live, then you can have natural selection make it so the most difficult creatures become more common. Or creatures come back undead? Another possibility is not have boring open spaces in your map to begin with. There's also challenges that aren't creatures such as traps, puzzles, or resource costs. I've tried most of these things in my roguelikes and they did keep things from becoming boring - at least in my opinion.
Under-challenging conflicts also have a lot to do with the overall power curve. If I start as a bumbling adventurer and end up as a god-like killing machine then it will be difficult to make something that's interesting in the beginning and end of the game. But if I start as a mediocre adventurer and, with the right loot and skills, end up as a fairly good adventurer, then some of the early challenges can still be interesting.
Those do sound like good ideas. It's somewhat ironic that you mentioned increased respawning, though, because I was thinking another solution might be to actually decrease respawn rates. That way when you returned to an area you had already cleared, those trivial monsters would not be there. It would also prevent grinding. That seems like it might be a fairly easy to implement solution?
But, yeah, your idea does sound more interesting than mine. Dungeon ecology in general is an interesting thing to think about.
I do see what you are saying about the power curve also.
-
This shouldn't happen in roguelikes. That's one of the genre's most important features - content needs to stay interesting through repeated playthroughs. If you can't do that you shouldn't make roguelikes.
Wait, what shouldn't happen? Events in roguelikes shouldn't have patterns that are readily apparent? Isn't that a pretty common thing in any genre? I mean, don't you succeed at playing roguelikes and most other types of games by recognizing patterns as you encounter the same (or very similar) situations in multiple playthroughs?
Are you saying you think roguelikes should be based more on strategy and planning rather than memorization and pattern recognition? I can't say that's a bad idea if you are, but I think there are plenty of great and interesting roguelikes that have obvious repetitive elements. For instance, I think the content of ADOM is very interesting, but I do think it tends to be rather similar from playthrough to playthrough.
I don't get it, it sounds almost like you are saying good games don't have content that can be solved algorithmically. Don't you consider rogue to be a good game?
Basic automation for simple tasks is fine. Autofight and autoexplore don't do any harm (though better design makes them less necessary). But if you're seriously contemplating automation for quests and other complex tasks, you need to reevaluate your design decisions.
I guess I more or less agree with that. And, maybe the issues that we are trying to deal with using automation can be completely overcome through other means.
One thing I think is important to point out is that simulation frees the player to concentrate on other less small scale elements of the game. So, if you wanted to greatly increase the scope of what you allowed the player to do, it helps to let them simulate parts of the game that they don’t want to micromanage. Like in Dwarf Fortress, I think (I haven’t actually played it).
Another example where simulation makes sense is a game where you followed the PC over a long time period, and essentially raised them until they were old enough to complete the ultimate objective of the game. You might decide how they allocated their time growing up, what kind of apprenticeship they had, early adventures they went on that kind of thing. You really don’t have time to play through years of the PC’s life without simulation, I mean.
I guess for some reason I keep thinking that is what Xecutor had in mind, and that he was going to add more “macro” features to keep the player busy while they were simulating menial tasks.
-
Well, I wasn`t entirely serious, because once you go down that route, it becomes a minefield of silliness. As in, we could also say then that we`re really playing a pen & paper game because everything else - computers et al is just automation. Hell, even the paper is - otherwise you`d have to do calculations in your head.
That's exactly what I was thinking. Why is that silly?
Instead I prefer to separate concepts of interface & gameplay (which is probably why these have different names too). And interfaces evolved over time from basic ones - due to being first on the block & also hardware limited - to more advanced, with some features being an obvious norm nowadays.
They have different names and they are separate entities, but they are very closely related. As you know, it's hard to play a computer game without an interface. And some gameplay features have become integrated into the interface for so long we take for granted that they are different things. That's the point I was making about map drawing.
Yes, I`m one of these people who still likes to draw a map, but that`s totally different and would never work in a roguelike, for obvious reasons like randomization and general pace. Though I was thinking recently that taking away the map entirely could be an interesting option for making games much harder, raising the tension and maybe implementing new mechanics (breadcrumbs?)
So it sounds like you are saying that most roguelikes as we know them today exist because that feature was absorbed by the interface. And instead of making them "non-games" they freed the player to concentrate on other features that could later be added.
Optional is fine...though it could become a bit worrying then, sort of like the "optional" ability to save that removes the permadeath threat. Say there was a game that had options to automate heavy chunks of gameplay - it`d be seemingly the same and yet I would be perhaps a bit distrustful of how serious its core mechanics are.
The ability to reload saves in ADOM after death is there, isn't it? You used to be able to copy save files. I guess you still can? I never try, so I don't know.
I think a better option would be for enemies that are no longer a threat to the character to run away from them.
I don`t really think it`s a problem - after all if an enemy is "trivial", you just steamroll it anyway - but this solution is very nice, I `ve seen it already implemented in one non-RL RPG and it worked rather well.
Maybe that would work fine. I was opposed to the idea previously, but I can't think of any reason it wouldn't work, now.
-
Instead I prefer to separate concepts of interface & gameplay (which is probably why these have different names too). And interfaces evolved over time from basic ones - due to being first on the block & also hardware limited - to more advanced, with some features being an obvious norm nowadays.
They have different names and they are separate entities, but they are very closely related. As you know, it's hard to play a computer game without an interface. And some gameplay features have become integrated into the interface for so long we take for granted that they are different things.
Since this is exactly what I said already, it seems we`ve hit some semantic block here. Similar with this thing about mapping - I never meant that "most roguelikes as we know them today exist because that feature was absorbed by the interface." - only that doing it on paper, while suitable and fun in some RPGs could never work in RLs because what`s the point of making a map of a level that will randomize on the next playthrough? Madness. maybe that`s why early RL dungeons were single-screen, later on automap was added if necessary.
I can`t really explain any better why there`s nothing wrong with automating interfaces but plenty when you try to do it to gameplay. And these bats are part of gameplay, not interface. Sure, we can squabble over the fact that auto pickup is also part of gameplay and yet I like to have it ON - seemingly contradicting myself - and yet to me it`s just obvious why tiny things like that are okay while large chunks like quests are not. You simply have to draw a line somewhere.
That whole pursuit of removing or automating "trivial" and "boring" things just seems dangerous to me. So what are we gonna be left with, eventually, just boss battles? Also, wouldn`t these "exciting" tasks start to be boring after a while as well?
There has been the trend in mainstream gaming over last decade, trend that left a rather sorry-looking landscape since some genres previously known for their complexity/difficulty have been "streamlined' (ie "neutered") in the name of "accessibility". And the argument was exactly the same - we don`t want to do boring, outdated things, eww! - we just want to have fun.
Okay, I`m exaggerating since I know we`re talking two different cultures and design ideas, and yet, similarities are there. You mentioned FF 12 earlier. I`m pretty sure Gambit system was used to appease those who don`t like to pause and control NPCs manually - transition to a totally action system, which is what was used in FF 13.
Now, in an action RPG it`s fine - but FF used to be strictly turn based. Long story short, it could be also said it`s tedious to control every soldier in XCOM manually, what a design palaver that was, eh?
But there`s another angle here - trying to understand why some folk are so keen on this idea I thought about what I read in other threads and generally saw watching RL scene for a while now. Seems to me a big chunk of players treat RLs like puzzles - games to be tactically dissected and ultimately winning being priority, but more in a abstract, purist way. Meanwhile I`m still more on the roleplaying side of things - I love the good tactics and challenge on offer in RLs but still need my imagination fix and so the dungeon is still a dungeon and Kobold Paladin a living entity, not just a yellow letter K that has some important attributes attached to it.
Considering this, definitions of "boring" might differ - I understand somebody perceiving the game in purely tactical way might have trouble with these things. But to me weaker creatures or more mundane tasks are part of the gameworld. A well designed one, of course.
-
I don't get it, it sounds almost like you are saying good games don't have content that can be solved algorithmically. Don't you consider rogue to be a good game?
No, I don't. While I appreciate Rogue's contributions to game design, other games have improved on its formula to the point that it isn't worth playing anymore.
In an ideal roguelike, every choice would matter. Every turn would be spent on something significant. In most games that goal is unachievable, so the new goal is to come as close as you can. Automation is a sloppy and inelegant method. It's a crutch and it will weaken your games. The better and more difficult method is to refine your design until those trivial choices are replaced with better ones.
That's one area where the original Rogue excels. Through a combination of a strict food timer and offering little incentive to waste time, the game encourages you to make every turn count.
I guess my stance is that automation should be used in situations where there are no meaningful decisions to be made and no reasonable changes that could remedy that. Autopickup is a good example. You don't need to think about whether you want a potion of healing. Of course you want it. Automation just saves you a keypress.
-
How about a game that *thematically* calls for repetitive tasks? In a survival game you might want to stock a larder to survive the winter, or craft enough ammunition for a battle. The story you want to tell is that the player is surviving because of their own effort, is truly self-sufficient. Are you going to simply reduce the amount of food needed for winter until it requires a reasonable number of actions to prepare? Make ammunition appear in bundles? (no wait, isn't that automation too?) How about literal farming? Are these topics off-limits for a game because they're repetitive? I'd say a better approach is to build mechanics into the game that depict the passage of time, and impose a cost for its passage. Make time a resource of the game like any other. For wintering in DDA, I'm seriously considering adding a set of mechanics for subsistence living that can literally be left running for months with occasional interruptions, because in a survival scenario, just holing up in a cabin over Winter is a completely valid approach, and I don't want to make the player manually play through that tedium. The alternative of declaring by fiat that there's no such thing as Winter, or making the Winter scenario artificially more friendly to normal exploration-based play don't sit right with me. In fact we have a large-ish group of players specifically clamoring for Winters to be harsher, specifically because they want to pit themselves against the challenge.
Personally I'm not a fan of the trope that the way to make your character stronger is to achieve goals (reaching a level of the dungeon, killing enemies, accumulating "treasure"*). I prefer systems where skill and stat advancement comes from actually using the skills/stats in question. Many implementations of this lead to "grinding" the skill, often with various checks that a particular use of the skill is "significant". Instead of doing that, why not simply have the resource you're expending be the passage of time, and present ways for the player to expend that resource in a straightforward way?
In DDA, I'm planning on introducing a system where skill advancement is based directly on time spent practicing. That practice includes time spent using the skill "in anger", but a safer way to hone your skill is to spend time on practice actions in a safe environment, at least when you can afford to do so. Firearms are a major part of DDA gameplay, but access to them is sometimes difficult, so having the firearms and ammunition necessary to practice shooting is a goal in of itself. Melee is simpler, because you have no shortage of melee weapons you can practice with, but of course firearms are generally going to be more effective. Likewise, the hunger/thirst/fatigue clocks make spending time practicing things inherently costly.
*As opposed to intrinsically useful loot.
-
How about a game that *thematically* calls for repetitive tasks? In a survival game you might want to stock a larder to survive the winter, or craft enough ammunition for a battle. The story you want to tell is that the player is surviving because of their own effort, is truly self-sufficient. Are you going to simply reduce the amount of food needed for winter until it requires a reasonable number of actions to prepare?
You should design your game around whatever possibility allows for the greatest depth and the least tedium. Otherwise you're just weakening your game out of a misguided commitment to realism.
-
You should design your game around whatever possibility allows for the greatest depth and the least tedium. Otherwise you're just weakening your game out of a misguided commitment to realism.
Vanguard, it sure seems like you're awfully dogmatic about this topic, and I'm having a very hard time understanding your point of view because of that. I think that even if simulation aspects shouldn't be incorporated into most games, Kevin (and to a lesser extent, I) have described situations where adding them is perfectly valid.
Are you saying that a roguelike that takes place over the time periods that Kevin is talking about cannot ever be successful due to a "misguided commitment" to realism? Misguided how? Just because we disagree with you doesn't mean we are somehow misguided.
You seem like you are saying that certain topics for roguelikes are "off limits" because they require simulation, presumably because that simulation would make the game less fun or interesting. But I really don't see any way that you have convincingly demonstrated that this is true. Again, I certainly accept that there are some situations where simulation is not appropriate, but your complete rejection of it in any circumstances is a bit hard for me to understand.
I'm not sure if I believe any gameplay element is intrinsically bad. I think the success of an element depends on the type of roguelike that it is included in, which is to say, the other elements that it is combined with.
I've said this before, but when someone brings forth a new gameplay idea, I think that the community should be supportive, rather than dismissive, of that idea. It is very easy to find fault with such ideas, but I think what shows true creativity is to imagine ways that they would work rather than how they would fail.
-
Since this is exactly what I said already, it seems we`ve hit some semantic block here.
Okay, I see what you mean there. I agree that my post said almost the same thing yours did. I did read your post, somehow I just missed that.
I guess we are examining exactly the same information and coming to different conclusions. Which is fine.
Similar with this thing about mapping - I never meant that "most roguelikes as we know them today exist because that feature was absorbed by the interface." - only that doing it on paper, while suitable and fun in some RPGs could never work in RLs because what`s the point of making a map of a level that will randomize on the next playthrough? Madness. maybe that`s why early RL dungeons were single-screen, later on automap was added if necessary.
Okay, I do see what you are saying. That makes sense.
I can`t really explain any better why there`s nothing wrong with automating interfaces but plenty when you try to do it to gameplay. And these bats are part of gameplay, not interface. Sure, we can squabble over the fact that auto pickup is also part of gameplay and yet I like to have it ON - seemingly contradicting myself - and yet to me it`s just obvious why tiny things like that are okay while large chunks like quests are not. You simply have to draw a line somewhere.
Akeley, what do you think should be done in games that have a large scope, like dwarf fortress, for instance? Aren't you going to have to simulate some parts of that game given how much the player would have to micro-manage otherwise? Or do you not consider games of that scope to be a true roguelikes?
Also, I'd still like to hear what you think should be done in the case of an adventure that spanned a large portion of the PC's life, where time constraints would make it difficult not to simulate gameplay.
I really feel like there is more of what I would call simulation in just about all roguelikes than you are arguing. I mean, in ADOM, you don't choose individual types of melee attacks like you can in ToME. Isn't that a simulation feature? Doesn’t any game where you don’t micromanage every action the PC takes incorporate some simulation aspects?
That whole pursuit of removing or automating "trivial" and "boring" things just seems dangerous to me. So what are we gonna be left with, eventually, just boss battles? Also, wouldn`t these "exciting" tasks start to be boring after a while as well?
There has been the trend in mainstream gaming over last decade, trend that left a rather sorry-looking landscape since some genres previously known for their complexity/difficulty have been "streamlined' (ie "neutered") in the name of "accessibility". And the argument was exactly the same - we don`t want to do boring, outdated things, eww! - we just want to have fun.
I actually don't have a big problem with the bats. I kind of thought everyone else did, and I also wanted to give Xecutor's idea a chance. So, I understand where you are coming from.
But I wonder some about the implications of the kind of relativistic argument that you are making. It sounds like you are saying that we only find things in games fun because there are other, less fun, things are there as a contrast. Well, does that mean that we should intentionally add “bad” elements in order to make the player appreciate other parts of the game more?
In fairness, I suspect this isn’t what you had in mind, so I’d like to hear more about this idea.
Okay, I`m exaggerating since I know we`re talking two different cultures and design ideas, and yet, similarities are there. You mentioned FF 12 earlier. I`m pretty sure Gambit system was used to appease those who don`t like to pause and control NPCs manually - transition to a totally action system, which is what was used in FF 13.
I think that’s a reasonable conclusion.
Now, in an action RPG it`s fine - but FF used to be strictly turn based. Long story short, it could be also said it`s tedious to control every soldier in XCOM manually, what a design palaver that was, eh?
I see what you are saying here too.
But there`s another angle here - trying to understand why some folk are so keen on this idea I thought about what I read in other threads and generally saw watching RL scene for a while now. Seems to me a big chunk of players treat RLs like puzzles - games to be tactically dissected and ultimately winning being priority, but more in a abstract, purist way. Meanwhile I`m still more on the roleplaying side of things - I love the good tactics and challenge on offer in RLs but still need my imagination fix and so the dungeon is still a dungeon and Kobold Paladin a living entity, not just a yellow letter K that has some important attributes attached to it.
Okay, I think I really do understand your point of view pretty well now. You feel like you can’t experience being your character as vividly if there are simulational aspects, right? That actually makes complete sense to me. I actually hadn’t thought of that before you just mentioned it.
You want to really *live* the process of killing of those 10 bats, dismembering them, and stuffing the bat wings in your pack!
No, seriously, I do get what you are saying. That makes sense.
-
Are you saying that a roguelike that takes place over the time periods that Kevin is talking about cannot ever be successful due to a "misguided commitment" to realism? Misguided how? Just because we disagree with you doesn't mean we are somehow misguided.
It's misguided because decisions are being made to support realism, with little regard for whether they would make for compelling gameplay. Realism itself is misguided because DDA has already gone beyond the pale of implausibility.
Simulations aren't inherently bad. All video games could be seen as simulations. My point is that there is a difference between simulations designed to be mechanically compelling, simulations designed to support realism (your character must sit in a cave for 3 months because it's cold outside), and simulations designed to cover up bad design (kill 20 bat quests).
If you find a way to make your auto-hibernate or auto-grind systems mechanically interesting in their own right, go ahead and implement them.
-
It's misguided because decisions are being made to support realism, with little regard for whether they would make for compelling gameplay. Realism itself is misguided because DDA has already gone beyond the pale of implausibility.
Okay. I see what you are saying. I haven't played DDA, so it's hard for me to comment much about how well or poorly the design elements we are talking about would fit. All I can say is that what Kevin has said so far does make sense to me. Although, since I haven't actually played the game, it's hard to know if those ideas would work as well as it seems like they would.
So, are you saying that, in general, it's not reasonable to have a realistic system for character advancement even in a fantasy/sci fi game? I guess I've never thought about those ideas being contradictory, but I guess you could argue that they are. I'll have to think more about that.
Simulations aren't inherently bad. All video games could be seen as simulations. My point is that there is a difference between simulations designed to be mechanically compelling, simulations designed to support realism (your character must sit in a cave for 3 months because it's cold outside), and simulations designed to cover up bad design (kill 20 bat quests).
If you find a way to make your auto-hibernate or auto-grind systems mechanically interesting in their own right, go ahead and implement them.
All that sounds reasonable to me. I agree.
-
Akeley, what do you think should be done in games that have a large scope, like dwarf fortress, for instance? Aren't you going to have to simulate some parts of that game given how much the player would have to micro-manage otherwise? Or do you not consider games of that scope to be a true roguelikes?
Also, I'd still like to hear what you think should be done in the case of an adventure that spanned a large portion of the PC's life, where time constraints would make it difficult not to simulate gameplay.
I really feel like there is more of what I would call simulation in just about all roguelikes than you are arguing. I mean, in ADOM, you don't choose individual types of melee attacks like you can in ToME. Isn't that a simulation feature? Doesn’t any game where you don’t micromanage every action the PC takes incorporate some simulation aspects?
While still interesting, this discussion is getting difficult - reason being we start talking about really diverse games, even if it`s all kept within the RL genre. And so,
trying to define what DF is can be a risky territory - vide dedicated thread on this board. But its sim part is definitely a different beast than "normal" RL like Crawl, its sort of hard to compare. In general I`m not against automation in certain genres or particular games - but only when it makes sense and is sort of genre-specific, lets say in
4X strategy, while in squad based tactics I want to have total control.
As for that ADOM vs TOME example, I see it as a different design decision more than a step towards automation. Not every game has to feature detailed combat, some are more simplistic and still work very well. But I also feel we`re straying bit too much from the OP here, which is what I originally objected to - that cave example. Micromanaging and combat systems in games seem a different subject to me than that (perhaps wrongly, but that`s how I feel).
It sounds like you are saying that we only find things in games fun because there are other, less fun, things are there as a contrast. Well, does that mean that we should intentionally add “bad” elements in order to make the player appreciate other parts of the game more?
In fairness, I suspect this isn’t what you had in mind, so I’d like to hear more about this idea.
Nah, you`re right this isn`t of course what I meant, at least not so literally. Problem is - and it keeps cropping up in these discussion - my definitions of bad, trivial or boring might vary from other folks`n regarding this subject. As I said in other threads, if I like a game - and there`s many elements influencing that - then those fetch/kill quests (and we lived with this template since RPG beginnings, really) aren`t a problem.
Example (regarding long-spanning adventures too) - I was so immersed in the Fallout 3 gameworld (yeah, I can hear folk sniggering already ;) that I`ve never used the Fast Travel option (meaning literally hundreds of in-game hours). Meanwhile in other games, yes, very much.
Guess, again it boils down to the OP`s very example - I consider combat and questing to be essential part of any RPG. I can be very forgiving on other fronts, but if these elements suck - or are automated - I probably won`t enjoy such title.
But, this is makes more sense talking about normal RPGs - I struggle to actually employ this line of thought regarding roguelikes. I just can`t think of "boring" encounters in those I played. In Crawl tension`s so high it`s completely out of a question. If I see a "weak" monster, I think "food!" or "what is it followed by?", "any loot?" and so on. Also, once you`ve became strong enough or discovered particular monsta`s Achilles heel, the monster might be a lesser threat but that`s sort of a reward for playing and also a natural flow of things which validates the gameworld and exemplifies your character`s growth.
...or something ;) I like these discussion, but admittedly I`m not a game developer and so might lack a particular incisiveness and drive to completely dissect these issues. I`d sort of like to leave some questions unanswered too perhaps, in order to retain some of the kid-like magic videogaming still holds for me..
Okay, I think I really do understand your point of view pretty well now. You feel like you can’t experience being your character as vividly if there are simulational aspects, right? That actually makes complete sense to me. I actually hadn’t thought of that before you just mentioned it.
You want to really *live* the process of killing of those 10 bats, dismembering them, and stuffing the bat wings in your pack!
Hmph, well I don`t exactly light candles, keep a styrofoam shield at hand and dress in pyjamas druid robes while playing, but it seems you got that bit ;) My "roleplayin" is somewhere in-between "totally abstract" and "get LARP`d!" styles, probably closer to the former. Kinda vague feeling, especially in RLs. But yeah, if I started automating these vital (for me) parts of gameplay something probably would be lost.
Ultimately, it might be also that thing where not all games are for all people - and there`s nothing wrong with it. Maybe games with "boring quests" style should be avoided by folks who look for something different, and vice versa, instead of trying to enforce a change to the style. Don`t know, really...but I do like both and just sort of alternate between them, depending on mood.
-
You guys took example with bats too literally.
So, let's complicate it a little.
Let's say the character have a quest to bring 1 bat's wing, but in perfect condition.
Sharpshooter can hit the bat in the eye, and thus have unharmed wing.
Sorcerer must avoid elemental spells, but can simply put the bat to sleep and gather the wing.
Stealth character can steal up to the bat unnoticed and cut the wing, still unnoticed.
But brute barbarian with his huge club can only hope that sooner or later he will land a hit in the head and won't turn entire bat into a bloody lump.
-
You should design your game around whatever possibility allows for the greatest depth and the least tedium. Otherwise you're just weakening your game out of a misguided commitment to realism.
So thematics and verisimilitude aren't to be considered? Sure there are plenty of games where the theme is just a convenient hook for the gameplay to be built around, but that's a pretty narrow vision of what defines a game.
It's misguided because decisions are being made to support realism, with little regard for whether they would make for compelling gameplay.
I put a lot of thought into how changes to DDA will affect gameplay. Characterizing it as "with little regard" is uncalled for.
Realism itself is misguided because DDA has already gone beyond the pale of implausibility.
Non sequitur. Just because some elements are "implausible" doesn't mean all elements of the game should abandon any verisimilitude.
The essence of e.g. science fiction is to make certain "unrealistic" changes, and explore how that changes reality. I fully accept that DDA is off in "space opera" territory rather than anything resembling hard scifi*, but you don't just change the fundamentals of reality because they're inconvenient. Sure, there are games where you do, but you're stating it's a hard and fast rule for all games, which is overreaching to say the least.
Also I'd like a direct answer to the question of how to handle scenarios that are intrinsically time-intensive, is your answer really "just don't do that", or "make them shorter until they're fun"?
*Having said that, there's a sub-mode that's a straightforward "survive the zombie apocalypse" scenario rather than all the wacky scifi and alien themes.
-
You should design your game around whatever possibility allows for the greatest depth and the least tedium. Otherwise you're just weakening your game out of a misguided commitment to realism.
Not every game has to be a logical puzzle. There are many ways to amuse the player. Sure, one is to give them difficult decisions to make. But you can also tell them a story (GTA), let them be creative (Simcity) or let them make their own story (Dwarf Fortress, I guess, although I haven't played it).
-
Okay. I see what you are saying. I haven't played DDA, so it's hard for me to comment much about how well or poorly the design elements we are talking about would fit. All I can say is that what Kevin has said so far does make sense to me. Although, since I haven't actually played the game, it's hard to know if those ideas would work as well as it seems like they would.
So, are you saying that, in general, it's not reasonable to have a realistic system for character advancement even in a fantasy/sci fi game? I guess I've never thought about those ideas being contradictory, but I guess you could argue that they are. I'll have to think more about that.
Believability is a worthwhile goal in any kind of fiction. I really hate fantasy armor with those gigantic shoulder pads and chainmail bikinis and all that. It doesn't add anything to the mechanical part of the game, and it makes the other parts impossible to take seriously. Just because there are space ships and wizards doesn't mean people should stop behaving like human beings.
With that said, it's important to realize that other things may take priority over believability depending on what sort of game you are making. If your game is heavily mechanics-focused (as most roguelikes are) then realism ought to take a back seat to increasing its depth and cutting away at tedium. Now, if your game is intended to be a piece of interactive fiction or a lifelike simulation rather than a "gamist" game, it is probably worthwhile to allow a bit of tedium or shallowness to attain greater believability.
Cataclysm is not any good as a piece of interactive fiction or a remotely lifelike simulation. Cataclysm is a game where you can duct tape three cars together to make an invincible supercar and macgyver up some nuclear hand grenades out of stuff you find lying around. I'm not saying that as criticism. Those are good features. Cataclysm is a better game for having them but they are not realistic in the least. I'm not sure why the DDA development team feels that player characters ought to be just as susceptible to cold weather as real people when they are clearly superhuman in so many other ways.
So thematics and verisimilitude aren't to be considered? Sure there are plenty of games where the theme is just a convenient hook for the gameplay to be built around, but that's a pretty narrow vision of what defines a game.
I put a lot of thought into how changes to DDA will affect gameplay. Characterizing it as "with little regard" is uncalled for.
Also I'd like a direct answer to the question of how to handle scenarios that are intrinsically time-intensive, is your answer really "just don't do that", or "make them shorter until they're fun"?
The second one. Though not necessarily shortened, just improved in some way until it's fun (or deep or challenging or whatever). Nothing should ever be added to a mechanics-focused that makes it worse as a mechanics-focused game, even if it's an improvement in other ways. Making the queen weaker than a knight results in Chess becoming a more realistic but overall much worse game.
If you believe that your new rules for winter survival will make DDA deeper or more fun, then I have misunderstood you.
The reason why I said your change was being made with little regard for gameplay was because of your own words. You said that the game called for repetition due to thematic reasons and even described it as "tedium." I wouldn't expect you to couch the idea in those terms if your goal was a more mechanically solid game. It sounds like you're planning to add tedious and unfun parts to the game for realism's sake, and them letting the player skip those parts through automation.
Maybe you communicated poorly or maybe I misread, but it sounds like you want to want to add a bunch in a bunch of bloat knowing that it won't be fun.
-
I'm not sure why the DDA development team feels that player characters ought to be just as susceptible to cold weather as real people when they are clearly superhuman in so many other ways.
Based on the wiki for DDA, it looks like the PC has to eat and drink to survive. A person could survive a lot longer without food and water in mild weather than they could with food and water but unprotected from extremely cold weather. So why does cold weather susceptibility seem inconsistent to you?
As far as duct taping cars and nuclear hand grenades go, I'd have to know more about the context. Can you please explain that part, Kevin?
The second one. Though not necessarily shortened, just improved in some way until it's fun (or deep or challenging or whatever).
Vanguard, you are being pretty vague here. What would you do instead to improve them? I have a feeling you are saying the elements he is mentioning shouldn't be there at all in a roundabout sort of way.
Nothing should ever be added to a mechanics-focused that makes it worse as a mechanics-focused game, even if it's an improvement in other ways. Making the queen weaker than a knight results in Chess becoming a more realistic but overall much worse game.
I don't buy the idea that games can't be hybrids. I don't think that realistic elements and "gamist" elements are mutually exclusive. ADOM has both, for instance, and it does very well.
Maybe you could give us examples of roguelikes that you feel do a good job of following your guidelines? I mean, we know what you don't like, but we don't know what you do like.
If you believe that your new rules for winter survival will make DDA deeper or more fun, then I have misunderstood you.
Vanguard, it will make the game more fun to people who enjoy realism. We both know that. I know you wouldn't like these changes, but I don't see any reason the rest of the audience for DDA wouldn't.
And that's what's ironic. I could see all these ideas being well accepted by people who play the game, but if Kevin listened to you, he wouldn't add them because they are somehow thematically inappropriate. Isn't the bottom line that fun is more important than "purity" of gamist or realistic elements?
-
Believability is a worthwhile goal in any kind of fiction. I really hate fantasy armor with those gigantic shoulder pads and chainmail bikinis and all that. It doesn't add anything to the mechanical part of the game, and it makes the other parts impossible to take seriously. Just because there are space ships and wizards doesn't mean people should stop behaving like human beings.
I totally agree with what you're saying, it's just that to me, "kill a monster, gain a 'level'" is just as grating as "huge shoulder pads". Armor should act like armor actually works, gaining skill should work like gaining skill actually works. The question is how to accomplish that and keep it fun.
Cataclysm is not any good as a piece of interactive fiction or a remotely lifelike simulation.
This seems to be the crux of it. I don't consider DDA to be "mechanics based" at all. While it's status as a "lifelike" simulation is debatable (mostly because I'm not totally clear on what you mean, I'd certainly not call it "realistic" in general, but the definition of "lifelike" in my head matches up roughly), it is certainly an apocalypse simulator, if I had to come up with a two-word description of the game, that would be it.
Cataclysm is a game where you can duct tape three cars together to make an invincible supercar and macgyver up some nuclear hand grenades out of stuff you find lying around. I'm not saying that as criticism. Those are good features. Cataclysm is a better game for having them but they are not realistic in the least. I'm not sure why the DDA development team feels that player characters ought to be just as susceptible to cold weather as real people when they are clearly superhuman in so many other ways.
I'm very confused by this comment. There are specific avenues in the game to become literally superhuman, in fact you can render yourself nearly invulnerable to cold, but the baseline is very much human normal. Also the jump from "the vehicle construction system is unrealistic" to "the player shouldn't be susceptible to cold" is frankly bewildering. You seem to be implying that realism in a game is all-or-nothing, which is absurd.
Also I'd like a direct answer to the question of how to handle scenarios that are intrinsically time-intensive, is your answer really "just don't do that", or "make them shorter until they're fun"?
The second one. Though not necessarily shortened, just improved in some way until it's fun (or deep or challenging or whatever). Nothing should ever be added to a mechanics-focused that makes it worse as a mechanics-focused game, even if it's an improvement in other ways. Making the queen weaker than a knight results in Chess becoming a more realistic but overall much worse game.
Ok, given this I'm not sure there's a middle ground we can reach. My goal is to *depict* a scenario that spans a long duration of time without forcing the player to step through it, and your counter proposal is to change the scenario to not take a long time. Furthermore your position is that since you've categorized the game as "mechanics based", depicting those scenarios is "misguided".
How does your position apply to waiting and sleeping? I can mechanically see ways to eliminate them from most games, rather than running the game forward at an accelerated pace, but I can see it being desirable to go either way based on the game.
For example if the primary reason to wait or sleep is to trade hunger for MP or similar, give the player an ability to trade hunger for MP outside of combat.
If the only drawback of waiting is the chance of being interrupted by a monster, give the player an ability that recharges MP but has a chance of spawning monsters.
If there's no drawback to waiting, just have player MP reset once they're out of combat.
If your only consideration is mechanics, yes you should probably replace wait/sleep with one of these, but you're now thematically stating that the player is an inhuman automaton that needs neither rest nor sleep. This may or may not be what you want.
If you believe that your new rules for winter survival will make DDA deeper or more fun, then I have misunderstood you.
I'm giving the players options. Surviving Winter should be a challenge, and there are multiple ways to do that.
One is to acquire cold-weather gear sufficient to ward off the cold and play straight through Winter as normal, hunting and exploring etc...
One is to get a vehicle and head South to avoid the harsh weather. (far future feature).
One is to accumulate enough supplies that you don't have to hunt or explore to survive, and wait it out, possibly taking advantage of the time to work on skills, do crafting, etc.
Lots more I haven't thought of, but the players will.
My job is to implement features that let the player decide on a strategy and follow it with maximal fun and minimal tedium.
The reason why I said your change was being made with little regard for gameplay was because of your own words. You said that the game called for repetition due to thematic reasons and even described it as "tedium." I wouldn't expect you to couch the idea in those terms if your goal was a more mechanically solid game. It sounds like you're planning to add tedious and unfun parts to the game for realism's sake, and them letting the player skip those parts through automation.
Maybe you communicated poorly or maybe I misread, but it sounds like you want to want to add a bunch in a bunch of bloat knowing that it won't be fun.
Hmm, yes this in particular does look like a misunderstanding.
I've liked the concept of a "pure practice" system for a while, but until recently haven't come up with a set of mechanics that would make it fun. A naive approach where every action would have to play out manually would indeed be tedious in the extreme.
I didn't propose a naive approach though, I'm proposing a system where the time expenditure of the character is *managed* by the player in order to achieve the goal of increasing skills. For some reason you insist on focusing on the fact that virtual time is passing, like that in any way detracts from fun of the player.
If there's something un-fun in the game, and the game provides a better way to do it that's strictly better such that there's no reason for the player to do it the un-fun way, does it matter?
I'm not sure why the DDA development team feels that player characters ought to be just as susceptible to cold weather as real people when they are clearly superhuman in so many other ways.
Based on the wiki for DDA, it looks like the PC has to eat and drink to survive. A person could survive a lot longer without food and water in mild weather than they could with food and water but unprotected from extremely cold weather. So why does cold weather susceptibility seem inconsistent to you?
As far as duct taping cars and nuclear hand grenades go, I'd have to know more about the context. Can you please explain that part, Kevin?
There is a moderately elaborate procedural vehicle construction system that allows you to chop apart vehicles and reassemble them in more or less arbitrary configurations. The skill level, time and resource requirements to do so is ludicrously small, you can literally go from knowing nothing about the pertinent skills to building a basic car from scattered components in about a week. This is a conscious choice, since with the current framework provided by the game making it "realistic" would place vehicle building, and arguably some of its best content prohibitively far into the game.
I'm not so sure about the general crafting system, the time frames and resource requirements for that are for the most part reality-based, if not strictly realistic. The most unrealistic part of it is how quickly you can gain the skill necessary to do the crafting, but that's exactly what I'm addressing with my practice based skill advancement proposal.
-
Incidentally, Kevin, I really like DDA. I just started playing it tonight. The level of detail is really satisfying, and it makes me happy to know that there is an audience for games that are this in depth, because that is the kind of game I would like to make.
Thanks for making it.
-
Vanguard, you are being pretty vague here. What would you do instead to improve them? I have a feeling you are saying the elements he is mentioning shouldn't be there at all in a roundabout sort of way.
I actually think the premise is fine. The idea of things becoming more dangerous over time is a good one, and winter is as good a justification as any. If it were up to me, I'd make winter dangerous in ways that maximize risk/reward-based play rather than ways that support an arbitrary idea of realism.
Let's say that the main danger of winter was food and water scarcity rather than cold weather, but both can be easily found in fungaloid nests or something like that. Then winter time would be about pushing the player out of their comfort zone and into more challenging situations. The early game would be a race to get ready for winter, winter would be a big testing point, and after winter the player would be able to use the abilities and equipment they've gained to make progress towards whatever their final goal is, if one exists. Nothing about that hurts the believability of the game's scenario, but it leads to a greater emphasis on time and resource management than pushing the "simulate" button and letting the game run itself for a while.
The key is to think of situations that are mechanically interesting and then write story and setting to fit that rather than the other way around.
Maybe you could give us examples of roguelikes that you feel do a good job of following your guidelines? I mean, we know what you don't like, but we don't know what you do like.
Mage Guild is a good example of what I like. Most of your character's growth comes from finding orbs hidden in the dungeon. There's one orb on each floor. The game doesn't assign experience points for kills or quests or exploration or anything like that so there's never any benefit from grinding. It's a good system and the author even bothered to work it into the narrative. It's clear that he put top priority on the game's rules and then came up with a narrative that fits them. It's much easier to do it that way than to make good mechanics that fit your narrative.
Another cool thing is how Mage Guild handles item drops. Enemies have a chance to drop useful items when killed, but that only applies to monsters that were spawned when you first entered their floor. Nothing that spawns after that point will drop anything. So while you do have an incentive to explore the level and kill enemies, there's no reason to sit around and farm. There's no "realistic" explanation for why monsters that show up later wouldn't have potions, but the game is much better because of that decision.
Brogue carefully controls how many health and strength potions the player can obtain. Again, there's no "realistic" explanation for why those potions are consistently found at the same intervals, but it makes for a better game.
PrincessRL has a character advancement system where the player character spends long periods of time training, but the focus is on being mechanically interesting rather than realistic. The story was written to adhere to the game's rules, and the end result is both mechanically robust and reasonably believable.
-
I totally agree with what you're saying, it's just that to me, "kill a monster, gain a 'level'" is just as grating as "huge shoulder pads".
Killing monsters to gain levels could potentially be good for the game's mechanics. World of Warcraft shoulderpads are bad for believability, do nothing to improve the game's mechanical side, and look stupid. The first one is a trade-off. The second is bad taste.
How does your position apply to waiting and sleeping? I can mechanically see ways to eliminate them from most games, rather than running the game forward at an accelerated pace, but I can see it being desirable to go either way based on the game.
For example if the primary reason to wait or sleep is to trade hunger for MP or similar, give the player an ability to trade hunger for MP outside of combat.
If the only drawback of waiting is the chance of being interrupted by a monster, give the player an ability that recharges MP but has a chance of spawning monsters.
If there's no drawback to waiting, just have player MP reset once they're out of combat.
If your only consideration is mechanics, yes you should probably replace wait/sleep with one of these, but you're now thematically stating that the player is an inhuman automaton that needs neither rest nor sleep. This may or may not be what you want.
Any of these solutions are fine. There's nothing wrong with thematically explaining your ability to trade hunger for MP (or whatever) as sleep. If the passage of time isn't an important factor, go ahead and set the game's clock ahead by eight hours.
I don't buy that the lack of a sleeping mechanic makes your character an inhuman machine. Games don't make you shower and brush your teeth every day. That doesn't mean every game protagonist smells bad, it means that we assume those things are taken care of off screen because they don't really matter.
If there's something un-fun in the game, and the game provides a better way to do it that's strictly better such that there's no reason for the player to do it the un-fun way, does it matter?
That's a good question. You could make good argument either way. The most important thing is to communicate to the player that the bad method is not the best or the only option.
fwiw I'd probably choose to remove the un-fun thing from the game.
There is a moderately elaborate procedural vehicle construction system that allows you to chop apart vehicles and reassemble them in more or less arbitrary configurations. The skill level, time and resource requirements to do so is ludicrously small, you can literally go from knowing nothing about the pertinent skills to building a basic car from scattered components in about a week. This is a conscious choice, since with the current framework provided by the game making it "realistic" would place vehicle building, and arguably some of its best content prohibitively far into the game.
See, this suggests to me that you really do understand that it's ok to stretch reality if it leads to a better game. Why are unrealistically short learning times okay if unrealistically short winters are not? It's easy to come up with justifications for why the winter is short or mild. Maybe the apocalypse changed Earth's climate. Maybe the game takes place in an area with mild weather. Maybe light exposure to the game's mutagens has made humanity resistant to extreme temperatures. It's so easy to explain these things away. There are a hundred options you could choose from. That's why it's best to worry about your game's mechanical foundation first and things like realism and story second.
-
Incidentally, Kevin, I really like DDA. I just started playing it tonight. The level of detail is really satisfying, and it makes me happy to know that there is an audience for games that are this in depth, because that is the kind of game I would like to make.
Thanks for making it.
Credit where due, Whales' Cataclysm before we forked it was an incredible starting point, and within the context of DDA, I'm the lead, but my contributions are dwarfed by the contributions of the rest of the team. Speaking of, if it's the kind of game you want to write, feel free to join in: https://github.com/CleverRaven/Cataclysm-DDA
I actually think the premise is fine. The idea of things becoming more dangerous over time is a good one, and winter is as good a justification as any. If it were up to me, I'd make winter dangerous in ways that maximize risk/reward-based play rather than ways that support an arbitrary idea of realism.
The cognitive dissonance of "arbitrary idea of realism" is overpowering. I want things to work the way they work in reality, and you somehow see that as "arbitrary".
Let's say that the main danger of winter was food and water scarcity rather than cold weather, but both can be easily found in fungaloid nests or something like that. Then winter time would be about pushing the player out of their comfort zone and into more challenging situations. The early game would be a race to get ready for winter, winter would be a big testing point, and after winter the player would be able to use the abilities and equipment they've gained to make progress towards whatever their final goal is, if one exists. Nothing about that hurts the believability of the game's scenario, but it leads to a greater emphasis on time and resource management than pushing the "simulate" button and letting the game run itself for a while.
So you want to artificially REMOVE the option to hole up during Winter. I think this is a fundamental disagreement, you want to give the player a specific designed and constrained experience, I want to give the player a world to play in.
I totally agree with what you're saying, it's just that to me, "kill a monster, gain a 'level'" is just as grating as "huge shoulder pads".
Killing monsters to gain levels could potentially be good for the game's mechanics. World of Warcraft shoulderpads are bad for believability, do nothing to improve the game's mechanical side, and look stupid. The first one is a trade-off. The second is bad taste.
"no true Scottsman" You have an immersion-breaking issue, but according to some arbitrary criteria, my immersion-breaking issue isn't valid.
There is a moderately elaborate procedural vehicle construction system that allows you to chop apart vehicles and reassemble them in more or less arbitrary configurations. The skill level, time and resource requirements to do so is ludicrously small, you can literally go from knowing nothing about the pertinent skills to building a basic car from scattered components in about a week. This is a conscious choice, since with the current framework provided by the game making it "realistic" would place vehicle building, and arguably some of its best content prohibitively far into the game.
See, this suggests to me that you really do understand that it's ok to stretch reality if it leads to a better game. Why are unrealistically short learning times okay if unrealistically short winters are not? It's easy to come up with justifications for why the winter is short or mild. Maybe the apocalypse changed Earth's climate. Maybe the game takes place in an area with mild weather. Maybe light exposure to the game's mutagens has made humanity resistant to extreme temperatures. It's so easy to explain these things away. There are a hundred options you could choose from. That's why it's best to worry about your game's mechanical foundation first and things like realism and story second.
I've said all along that compromises are possible, but at every turn your response is that no compromise is possible, and that minimalistic mechanical design must always trump thematic issues.
We're getting nowhere with this. I simply don't agree that all game design decisions must flow from mechanical considerations, it's an absurd stance to take. If you want to make pac-man, make pac-man, I'll be over here making a zombie apocalypse simulator.
-
The cognitive dissonance of "arbitrary idea of realism" is overpowering. I want things to work the way they work in reality, and you somehow see that as "arbitrary".
It's arbitrary because you're holding realism as the highest virtue in some situations and completely ignoring it in others. There's no rhyme or reason to when you decide it matters.
"no true Scottsman" You have an immersion-breaking issue, but according to some arbitrary criteria, my immersion-breaking issue isn't valid.
Did you read my post? Do you know what "no true Scotsman" means?
One situation is trading away realism for a mechanical benefit. The other is trading away realism (and good taste) for no benefit. They are not equivalent.
-
"no true Scottsman" You have an immersion-breaking issue, but according to some arbitrary criteria, my immersion-breaking issue isn't valid.
Did you read my post? Do you know what "no true Scotsman" means?
One situation is trading away realism for a mechanical benefit. The other is trading away realism (and good taste) for no benefit. They are not equivalent.
I know exactly what "no true Scottsman" is, and it's what you're doing, which is saying that "Realism is important when it meets my criteria and doesn't interfere with what I care about, but it's unimportant when it doesn't meet my criteria and/or interferes with something I care about".
-
Kevin, I had some specific questions for you about DDA. For one thing, I am having a hard time understanding the way the pain mechanic affects the PC's ability to heal.
First, it does make sense to me that the PC is not able to function as well athletically when they are injured. It even makes sense to me that they would not be able to sleep if they were badly hurt. What I don't understand is why there is (as far as I can tell) no way to rest and recover HP without sleeping. It seems like this leads to a sort of positive feedback cycle where the worse the player is injured, and therefore the more pain they are in, the harder it is for them to start recovering from that injury by sleeping.
From a realism standpoint, I realize you wouldn't be able to completely heal a deep bite wound from just sitting down and “resting” for a few hours. However, I’m not sure it is realistic for any significant amount of healing to occur after a good night’s sleep, either. So I don't understand why you would have to be asleep to get *any* benefit. Shouldn’t the PC gradually recover HP at some low rate if they are stationary but not asleep?
I’m also curious about the way the inventory system is implemented. It’s interesting that the PC can wear layers of equipment on a given body part, but I do find it somewhat confusing that there aren’t inventory slots for particular parts. What I’m saying is, why not have a system where you have the equipped items are listed by the part they are equipped on. It just seems like this might be a clearer way of describing what the PC was wearing.
Also, why not have a shorthand system for showing the to-hit, protection, warmth modifiers, etc. for each piece of equipment on the main inventory screen itself (like ADOM) without having to select individual items and view detailed information about them?
EDIT: And, more on topic, both of you guys are making really persuasive arguments about what criteria should be used to determine what features are incorporated into a game. Honestly, I’m not sure most games aren’t better off using a combination of your ideas.
For instance, I think my personal favorite roguelike (ADOM) falls somewhere in between your two philosophies. I consider it to be pretty realistic overall, but it still has a conventional experience system and leveling up. And even though leveling up isn’t very realistic (well, it kind of is, that would be an interesting debate), it is a lot of fun. So I don't feel like it is bad that ADOM kept that kind of mechanic.
I actually have a lot more to say about this, but I’ll have to think about it for a while longer to decide how I want to put it.
-
It seems like this leads to a sort of positive feedback cycle where the worse the player is injured, and therefore the more pain they are in, the harder it is for them to start recovering from that injury by sleeping.
From a realism standpoint, I realize you wouldn't be able to completely heal a deep bite wound from just sitting down and “resting” for a few hours. However, I’m not sure it is realistic for any significant amount of healing to occur after a good night’s sleep, either. So I don't understand why you would have to be asleep to get *any* benefit. Shouldn’t the PC gradually recover HP at some low rate if they are stationary but not asleep?
I can vouch from personal experience that it actually does make sense. The benefits of the so called "good night`s sleep" compared to a bad one, or no sleep at all, are incomparable, and it`s not just old wives tale. Proper sleeping involves the "deep sleep" phase which is crucial to recovery. I`m no medic but it has to do with increased growth hormone production (plus other processes like increased toxin cleansing and obviously no stress from thinking about stuff). Being stationary is seemingly the same, and yet your body knows better and will withhold those magical reactions unless you`re asleep.
I`m locked in this kinda cycle at the moment - have a shoulder injury which is getting more painful at night, that in turn stops me from sleeping properly, recover a little bit during the few hours of shallow, rubbish sleep, next day at work strain it again and so it goes. Not fun.
I only messed around with DDA couple of times so can`t really comment on this mechanic`s implementation, but it sounds okay to me. Perhaps some, very slow, recovery should be allowed while just "resting" - but on the other hand I like the brutality of this idea, it says "do not get injured". I`ll be eventually okay - there`s no zombie apocalypse going on and I can just take a week off if it gets really bad - but any serious injury in extreme conditions usually equals death.
-
Kevin, I had some specific questions for you about DDA. For one thing, I am having a hard time understanding the way the pain mechanic affects the PC's ability to heal.
I'd normally say I should take the discussion elsewhere, but I think the thread is fairly well played out, feel free to chime in if you want us to take the DDA discussion elsewhere.
First, it does make sense to me that the PC is not able to function as well athletically when they are injured. It even makes sense to me that they would not be able to sleep if they were badly hurt. What I don't understand is why there is (as far as I can tell) no way to rest and recover HP without sleeping. It seems like this leads to a sort of positive feedback cycle where the worse the player is injured, and therefore the more pain they are in, the harder it is for them to start recovering from that injury by sleeping.
I don't have a current copy of the code at hand, but from what I recall, pain doesn't factor into ability to sleep. It's likely that you're just not tired. Fatigue acts as both a requirement and a resource, because when you get tired it *allows* you to sleep, which has beneficial side effects. The player definitely should be recovering from injuries all the time, and sleep would just accelerate it somewhat. See below for more detail
From a realism standpoint, I realize you wouldn't be able to completely heal a deep bite wound from just sitting down and “resting” for a few hours. However, I’m not sure it is realistic for any significant amount of healing to occur after a good night’s sleep, either. So I don't understand why you would have to be asleep to get *any* benefit. Shouldn’t the PC gradually recover HP at some low rate if they are stationary but not asleep?
This is explicitly a departure from realism left from when Whales was developing the game. He talked about it on Roguelike radio. The gist of it is he didn't want realistic healing rates to get in the way of game momentum, which is a valid concern.
I have a completely different solution in mind for this, which is to replace HP with discrete injuries ranging from "scrapes" and "bruises" to "cuts", "gashes", "contusions", "bites", "sprains", etc. The point of which is that you'd get out of most fights with negligible cuts and scrapes that correspond to the loss of a few HP. With a few HP missing you might be tempted to "top off" your health with an appropriate healing item* or rest, but there will be literally nothing to be done to resolve cuts and bruises immediately, so you press on until they accumulate to the point where it's impacting performance, or you happen to acquire a more significant injury, or ideally, until they heal, either by normal passage of time or because you stopped to rest. The intended end result is that injuries are a real thing you deal with rather than a totally abstract resource sink. When you come out of a fight with some injury, you treat it as you're able, then either press on or decide to take a rest, which might include something productive but with a lower level of danger. Untreated wounds, as in reality, would have a chance of worsening instead of healing, so you should bandage or bind cuts and scrapes, suture larger cuts, and apply liberal amounts of antibiotics to everything. All of this should present a streamlined interface to the player, requiring no more micromanagement than normal HP systems, but presenting everything in a realistic manner with more rational behavior, actions and material requirements.
I’m also curious about the way the inventory system is implemented. It’s interesting that the PC can wear layers of equipment on a given body part, but I do find it somewhat confusing that there aren’t inventory slots for particular parts. What I’m saying is, why not have a system where you have the equipped items are listed by the part they are equipped on. It just seems like this might be a clearer way of describing what the PC was wearing.
The problem with a slot-based system is that clothes don't actually work that way. In a more abstract game, you're free to restrict the clothes to ones that fit into the desired categories, but in reality clothing covers arbitrary combinations of different body parts. A shirt covers the torso only (for a reasonable definition of torso), pants cover legs but not feet, a trenchcoat covers arms, legs, and torso, etc.
What we have is head, eyes, torso, arms, hands, legs, and feet. You can break it up more than that (e.g. df), but that seems to provide reasonable differentiation.
Also, why not have a shorthand system for showing the to-hit, protection, warmth modifiers, etc. for each piece of equipment on the main inventory screen itself (like ADOM) without having to select individual items and view detailed information about them?
Take a look at the clothing layering menu, brought up with '+' by default. It doesn't provide everything you need yet, but it brings together most of the information you need for evaluating your clothing choices. Providing composite cut and bash protection values for clothing and for each hit location is a feature near the top of the pile for being implemented.
*We do have "health potion" items in the form of "first aid kits" and "bandages". As the injury system I outlined above is implemented, they will be relegated to treating wounds to prevent worsening, and all healing will be natural and time-based.
Ninja'ed by akeley: Ow, I have a chronic shoulder injury as well, good luck with that. Mine presents a particular problem in that it mostly recovers during the day, and my sleep posture is actually the thing that aggravates it the most. It's remarkably resistant to healing, I'd consider my relationship with it to be more, "managing" than "healing" :/
-
I can vouch from personal experience that it actually does make sense. The benefits of the so called "good night`s sleep" compared to a bad one, or no sleep at all, are incomparable, and it`s not just old wives tale. Proper sleeping involves the "deep sleep" phase which is crucial to recovery. I`m no medic but it has to do with increased growth hormone production (plus other processes like increased toxin cleansing and obviously no stress from thinking about stuff). Being stationary is seemingly the same, and yet your body knows better and will withhold those magical reactions unless you`re asleep.
Right, but I’m not arguing that sleep isn’t important, or even essential, to the process of recovering from injuries. I’m just saying that in a game where healing rates are already necessarily accelerated many, many, many fold beyond what they are in the real world, some recovery might reasonably occur during the time the PC was awake, also. Perhaps the PC should be in a state designated as “well rested” to heal properly, but I think resting while awake should have *some* benefit.
I only messed around with DDA couple of times so can`t really comment on this mechanic`s implementation, but it sounds okay to me. Perhaps some, very slow, recovery should be allowed while just "resting" - but on the other hand I like the brutality of this idea, it says "do not get injured". I`ll be eventually okay - there`s no zombie apocalypse going on and I can just take a week off if it gets really bad - but any serious injury in extreme conditions usually equals death.
Yes, that kind of slow recovery (provided you didn’t have infected or bleeding wounds) is all that I was talking about.
By the way, I’m sorry about your shoulder, Akeley.
I'd normally say I should take the discussion elsewhere, but I think the thread is fairly well played out, feel free to chime in if you want us to take the DDA discussion elsewhere.
Whatever you’re most comfortable with. I appreciate you being so approachable and open to talking about your game. It is very helpful to me.
I don't have a current copy of the code at hand, but from what I recall, pain doesn't factor into ability to sleep. It's likely that you're just not tired. Fatigue acts as both a requirement and a resource, because when you get tired it *allows* you to sleep, which has beneficial side effects. The player definitely should be recovering from injuries all the time, and sleep would just accelerate it somewhat. See below for more detail
Yeah, you’re right, I just didn’t understand what was going on. Sorry.
I do like the idea of hunger or thirst as being the resources consumed to regenerate health much more than fatigue, though. And there is also the more abstract resource of “safety” that is being consumed as you sleep and become more vulnerable to zombies sneaking up on you.
In general, I like the idea of being able to choose between gradually recovering HP while awake and vigilant, and rapidly recovering it while vulnerable to ambush. I also think it's neat how some games (like some D&D based PC games) have different levels of "resting safety" designated for different areas of a dungeon so that the player is encouraged to find a safe place to sleep rather than just randomly choosing any location.
I have a completely different solution in mind for this, which is to replace HP with discrete injuries ranging from "scrapes" and "bruises" to "cuts", "gashes", "contusions", "bites", "sprains", etc.
How will the player know how close they are to death, though? I mean, I know the whole concept of HP is an oversimplification, but how are you going to present multiple different types of injuries of multiple severities on multiple different body parts to the player?
I really like the idea, don’t get me wrong, I’m just worried that it would be too complicated.
Untreated wounds, as in reality, would have a chance of worsening instead of healing, so you should bandage or bind cuts and scrapes, suture larger cuts, and apply liberal amounts of antibiotics to everything.
All of this should present a streamlined interface to the player, requiring no more micromanagement than normal HP systems, but presenting everything in a realistic manner with more rational behavior, actions and material requirements.
But how would you pull that off? I’m optimistic about realism in roguelikes, but that seems like a very tall order. Wouldn’t treating individual wounds end up taking a lot of time and micromanagement?
By the way, I bet you have thought about a hardcore gameplay mode where healing did occur at “real world” rates, and wounds were as debilitating as in real life, haven’t you? And I bet you’ve even thought about a mode where any direct zombie inflicted wound would result in death from zombification.
Also, I've been meaning to ask you about attributes. With all the attention that you are giving to realism, have you every thought about increasing their number?
-
I know exactly what "no true Scottsman" is, and it's what you're doing, which is saying that "Realism is important when it meets my criteria and doesn't interfere with what I care about, but it's unimportant when it doesn't meet my criteria and/or interferes with something I care about".
A) That is not a No True Scotsman statement. If the argument had been "my concept of realism is real realism and yours isn't" with no justification given then we'd have a No True Scotsman on our hands. Statements like "deep mechanics are more important than realism" or "my criteria and values for realism are better than yours" are just value judgments.
B) That isn't even what happened. What I said was that sacrificing believability in exchange for a mechanical benefit is better than sacrificing believability for no benefit. I don't see how that could possibly be a controversial thing to say.
Anyway, there's another reason why level ups are less problematic than chainmail bikinis. Level ups and similar game mechanics are abstractions. Within the game's narrative your character isn't literally getting a sudden increase strength for punching out their 57th jackal. It's a mechanical representation of their knowledge and strength increasing as they learn and exercise. So long as the player understands that, the story remains coherent.
Not so for chainmail bikinis or Gears of War shoulderpads. Your characters really are dressed that way and there's no plausible explanation for any of it.
-
Credit where due, Whales' Cataclysm before we forked it was an incredible starting point, and within the context of DDA, I'm the lead, but my contributions are dwarfed by the contributions of the rest of the team. Speaking of, if it's the kind of game you want to write, feel free to join in: https://github.com/CleverRaven/Cataclysm-DDA
Oh, I meant to tell you, thank you for that invitation, but I don't know how to program.
-
Making the game is about much more than just programming, we have several very valuable contributors that know little to nothing about programming, and several more who have learned how to program in the past year *from* contributing to DDA.
I think one of the most valuable things I've done in the project is bend over backwards to help new contributors get started. At this point we have something like a dozen developers on IRC that will BURY you in help if you show up and ask ;)
-
Making the game is about much more than just programming, we have several very valuable contributors that know little to nothing about programming, and several more who have learned how to program in the past year *from* contributing to DDA.
I think one of the most valuable things I've done in the project is bend over backwards to help new contributors get started. At this point we have something like a dozen developers on IRC that will BURY you in help if you show up and ask ;)
Well, if that's true, I'll definitely look into it. Thank you.
-
Here's an idea: instead of "grinding", why not make your tedious chores involve (almost literally) "farming"? For example, make the player do something to start a process -- plant a seed, prune a fruit tree, sneak a dragon egg into the giant eagle's nest so she'll sit on it, etc -- and then require that a certain amount of time pass before the benefit is ready to be picked up. This could be a specified number of game turns, or even real-world elapsed time. Instead of grinding with repetitive actions, the player has to plan ahead and think about multitasking -- what can he do while waiting for the prize. You still accomplish your design goal, though, which I think I understand to be that you want the player to be able to guarantee a certain quantity of treasure is produced.
-
Here's an idea: instead of "grinding", why not make your tedious chores involve (almost literally) "farming"? For example, make the player do something to start a process -- plant a seed, prune a fruit tree, sneak a dragon egg into the giant eagle's nest so she'll sit on it, etc -- and then require that a certain amount of time pass before the benefit is ready to be picked up. This could be a specified number of game turns, or even real-world elapsed time. Instead of grinding with repetitive actions, the player has to plan ahead and think about multitasking -- what can he do while waiting for the prize. You still accomplish your design goal, though, which I think I understand to be that you want the player to be able to guarantee a certain quantity of treasure is produced.
I like that idea a lot. Would you want to do something similar to X-COM where the PC has a "base" area where they can assign workers to projects or build add-ons to the base that will unlock new features?
Is that how dwarf fortress works? I've never played it.
-
We're looking at adding features that utilize figurative and literal farming, so there's that.
For example fermentation-based foods, you need to kick off the process, but it needs to continue outside your control or presence.