Messages

151

Programming / Re: Roguelike Gameflow - Alternatives

« on: October 18, 2013, 07:35:26 AM »

Like half of the appeal of roguelikes is that you can play 100% serious, min/max, take every advantage you can get, show no mercy, and still get a good challenge.

It's rare to see that in single player games, and basically doesn't exist at all in non-RL RPGs.

So, my question is this:  Do you still consider that sort of min/maxing to be "playing" a game?  If your only concern is victory at any cost, hasn't your entire experience become something far less organic (and fun) than game play? 

I realize this will be a highly controversial statement, but maybe you should reconsider the way you approach the games that you play.  If you are min/maxing, are you really role playing at all?  I mean, isn't the whole point to become so engrossed in being someone else in a way that elevates you above your mundane life?

By that argument, is there any way that a game could ever be too hard?  It sounds like the idea here is that you should create a game that is impossible to exploit in any way, no matter how much of a slog it was. 

It's relatively easy to make games that make a player feel trapped and restricted.  All you have to do is take away their options.  It's a subtractive approach to design.  And that can be useful for streamlining, but I don't think it is so much a useful tool for generating a sense of awe. 

I think that what's hard, what's the holy grail, even, is to create games that make the player feel so free they become lost in the experience.  And, ironically, I think that rogue like games are excellent for providing this sort of liberating experience despite the demands that they make on a player.  Aspects of roguelikes that seem like they would be limiting, like perma-death, ultimately accentuate and add immediacy to the gameplay experience rather than just constraining players, similar to the way that our own mortality makes our real life experiences more vivid.   

152

Programming / Re: "Game time"

« on: October 18, 2013, 06:57:41 AM »

They still won't.  No one's going to figure out how many 2-second turns they are away from sunrise.

*Sigh* and in fact, that's exactly my point, Vanguard.  I wouldn't measure time using turns at all, and I wouldn't do so for exactly the reason that you just pointed out: turns are not a unit of time measurement that is quickly understandable to the player. 

153

Programming / Re: "Game time"

« on: October 18, 2013, 06:53:20 AM »

They still won't.  No one's going to figure out how many 2-second turns they are away from sunrise.

It has not escaped my notice that the player needs an easily accessible way to reference the current date and time, thank you.  I would include both that and time and the amount of time consumed by the PC's last action in the HUD.  That way the player would know what time it was and how fast their character was able to perform a given action.

Again, let me point out that most (or maybe no?) roguelikes tell you the amount of (player) turns it takes an opponent to perform an action, and the length of player's turn is variable depending on the player's speed anyway.  So communicating the duration of events to the player in a constant unit of time other than a "turn" is a useful thing.

Obviously you use the player's current speed in cases like that.  If you want to also communicate absolute time in whatever units, that's fine too.

That's right, both are fine, and one actually tells the player how much time has passed in a way that they can understand.

I just don't think there are many situations where seconds would be more useful than ticks or turns.  If you want to do it it's still ok.  There's nothing wrong with it.

I don't know what you mean by "many situations".  All the examples I have listed are situations where it would be important to use real world measurements rather than time.  Most people may not make games that involve the situatoins that I am talking about, but that does not mean that my arguments are not logically sound for the type of game that I would like to make.

154

Programming / Re: Roguelike Gameflow - Alternatives

« on: October 18, 2013, 02:27:04 AM »

You know, I've been thinking more about this.  I think that when I have heard the term "grinding" in the past with regards to console RPGs, it has usually been used in a way that reflected negatively on the player, rather than on the game developer.  In those types of games, it is generally accepted that if you spend enough time building your character, pretty much any challenge can become trivial. 

So, what you usually hear is something like this: one person says "X level/boss/whatever was too easy", and then another person says "Well, did you grind a lot?" if "yes" is the response, then whoever originally complained the game was easy is generally dismissed as being unreasonable.

I think it's interesting that in these console RPG's, as opposed to roguelikes, there is that expectation that the player shouldn't try to grind and then complain about difficulty.  I know it seems like a cop out to say that any game can be broken if the player tries hard enough, but, well, that's usually true.  Perhaps a better way of putting it might be that if you make a game which absolutely cannot be exploited by anyone, you are going to make it less fun for a lot of players who are genuinely trying to enjoy it and play it as it was intended.

155

Programming / Re: "Game time"

« on: October 18, 2013, 01:32:47 AM »

I guess it's because, at the end of the day, does it really matter if you call your time units "ticks" or "seconds" or "slartibartfasts"?

...Except for the situations that I just listed where it does matter?  Maybe what I would want to accomplish with timing isn't important to you guys, but there are significant differences between the timing systems we have been discussing, at least to me. 

Honestly, I think what it boils down to is that people who make games have a tendency do things a certain way because it has become ingrained in the collective thinking of game makers and game players.

As far as what Quendus said, I guess that "straw man" is just a term he uses to mean "a claim that I disagree with"?  I think the expression has pretty negative connotations, though, so I was kind of taken aback by his choice to use it.

EDIT: Or, maybe what he means is that I seem like I am arguing just for the sake of arguing.  I'm honestly not, these are things I think a lot about and are actually important to me.

156

Programming / Re: "Game time"

« on: October 18, 2013, 01:31:10 AM »

Sorry, double post.

157

Programming / Re: Roguelike Gameflow - Alternatives

« on: October 17, 2013, 05:15:49 PM »

because while some players - like akeley - will ignore perverse incentives in the name of their own fun and freedom, many will see the possibility of grinding to win and fall for that trap, boring themselves instead of playing the game. And why would anyone set such traps for their players?

I admit that you probably need some system of diminishing returns to discourage grinding somewhat, but, ultimately, if players want to spend their time grinding instead of building their character using more entertaining means that are available to them, isn't that their loss?  I mean, this doesn't sound like a problem with game design any more, it sounds like a problem with the way that people are choosing to play the game.

I feel like games are always going to require the participation of the player to be good, in some sense.  If the player spends a long time grinding, they kind of know that they are going to reduce the difficulty of the game.  That's why they are doing it.  So, I would say if the game is less fun or too easy because of that, it's the player's own fault.

158

Programming / Re: "Game time"

« on: October 17, 2013, 05:06:00 PM »

I can smell a strawman,..

Also, I'm not sure how this is a straw man.  There's not any opponent here who's argument that I'm trying to misrepresent.  A lot of roguelikes really do use turns or ticks rather than real world time units.  I don't think there's anything deceptive (or even controversial) about that statement.

EDIT: Is it because I was making too broad of a statement by saying that roguelike games in general would be better with my sort of timekeeping system?  I guess I should have been more specific?  I certainly wasn't trying to deceive anyone with my statements, either way.

159

Programming / Re: "Game time"

« on: October 17, 2013, 05:00:46 PM »

That's why you communicate that information in terms of the player's turns.

But the length of the player's turns varies over the course of a game as the PC's speed stat changes.  Just like in ADOM.  So that can't always be the standard. 

160

Programming / Re: "Game time"

« on: October 17, 2013, 04:55:49 PM »

I can smell a strawman. Ticks are a useful abstraction for designing and programming games with fine-grained timing.  This is standard practice when making real-time games. They don't have to be a round number of milliseconds. A developer can use them without exposing them to the player.

That's true, but I, personally, would want to show my time keeping system to the player.  That's the main reason that I would use the methods that I am talking about for my particular purposes.  I want to show the player the amount of time that their actions take using a type of measurement that is easy to recognize and understand.  And I don't want to measure time internally using non-millisecond ticks and then convert that measurement back to milliseconds to show the player. 

If there's a lot of variation in the time taken by individual player actions, or if there are infrequent timed events on the clock, then it's sensible to write them in real-world units of time.
If there's no day/night cycle and most actions take the same amount of time, then there's nothing wrong with calling it a "turn" and letting players' experience with board games and card games inform them about the concept.

No, I get that.  But I am imagining a game where the things that you just mentioned, like a day night cycle and variable turn lengths, are important in gameplay.  I am talking about exactly the types of situations that it seems like you are saying would be reasonable instances not to use ticks.

Look, a better way of putting my previous statement might have been: "Don't you think that in games where the passage of time is important and turns are of variable length, real world time measurements can work as well or better than made up ones?"

161

Programming / Re: Roguelike Gameflow - Alternatives

« on: October 16, 2013, 11:50:29 PM »

But as AM says, it`s probably a different angle than using it as a punishment for players actions. And in most RLs tension is omnipresent since one wrong move can mean curtains, so I`m not sure we need additional, more artificial, stress inducers.

I actually feel the same way.  I enjoy being able to explore the world and build a character rather than scurrying around, trying to avoid the threat of imminent death that is constantly looming over me.  But I think the real problem here is that different players respond better to different difficulties.  Most people who play rogue-likes are much, much better at them than I am, so what seems like a game with a fun risk to reward ratio to me would probably be quite boring to most people. 

162

Programming / Re: "Game time"

« on: October 16, 2013, 11:21:08 PM »

Ticks can be milliseconds, or any other unit of time you'd like, but mechanically speaking, it isn't important whether the 500 ticks needed to attack represent 500 milliseconds, 5 seconds, or anything else. 

Maybe, but non-mechanically, I can think of good reasons to use real world time measurements rather than made up ones.  What about keeping the player connected to the flow of time in the game?  Ticks and turns are both ambiguous, because they don't give the player a sense of how much time an action requires or how much time has elapsed since they started playing.  Telling the player that 1000 turns have passed since they started their adventure doesn't really have the same meaning as saying that 2 days, 12 hours, and 30 minutes have passed.

This is particularly important if a game has a day-night cycle.  Without some sort of time piece on the HUD, they player only knows what time it is if they are outside and happen to get a message that describing the environment, which won't occur really often.

Turns are useful because they're the units in which the player interacts with the game.  If a badguy starts doing a super move that takes 5 turns to fire off, you know exactly how much time you have to prevent it, but if it takes 15 seconds, things aren't as clear.

I would argue just the opposite.  If the game has a speed stat, the length of a creature's turn depends on who they are.  So, saying that a very fast creature needs 5 turns to ready and execute an attack means something different than saying a very slow creature needs 5 turns.  Also, most roguelikes don't let you know how many turns it will take an opponent's attack to resolve to begin with, do they? 

163

Programming / Re: "Game time"

« on: October 16, 2013, 02:26:25 AM »

So, as I read this, I notice that a pattern similar to what I have observed in other rogue-likes, which is that there is  a tendency to adopt unusual units of measurement.  Why not use units that are immediately understandable to the player, like milliseconds, rather than made up ones, like "ticks?" 

This is similar to the problem of saying that an action takes "X turns" to perform.  I'm not sure that this is exactly what is being suggested here, but I have seen this concept used in other games, and I don't think it is the best way of doing things.  Why use the concept of fixed length turns at all?  In my thinking, a "turn" would consume an amount of time that depends on the specific action performed, since it lasts from the time an action is input/scheduled by a creature/actor until that action is completed and a new action can be scheduled.

164

Programming / Re: Roguelike Gameflow - Alternatives

« on: October 16, 2013, 02:15:11 AM »

EDIT: How about this. The game releases a new higher level enemy not by level, but by number of turns. So if you spend your time dinking around level 1 for forever, eventually a dragon will show up. Like this:

100 Turns - Release rank 2 baddy.
500 Turns - Release rank 3 baddy...
1000 Turns - Rank 4 released, etc...

I can see how that idea has definite advantages.  And it would add a sense of tension and urgency.  But I think the bigger question here is this:  If the PC wants to hang around level 1 for a thousand turns scumming/grinding, isn't the bigger problem that they aren't being given anything more interesting or rewarding to do for that time?  I'm a proponent of the idea that if you want the player not to do something, you can give them a better alternative, rather than punishing them for it.  And I realize "punishment" is probably too strong of a word to use to describe your idea, but you get the idea.

Also, in response to the ideas about story and procedural generation: When I think of "story", I tend to conceptualize it differently than most of you guys.  "Story" to mean would mean the chance to learn more about the history/cosmology of the game world through books or NPC conversation, stuff that would be completely skip-able for a given play though.  That might better be called "background", but I think it is still a legitimate way to set the tone of the game and convey information to the player.

165

Programming / Re: Ideas for generally better procedural algorithms and procedural content

« on: October 16, 2013, 02:01:12 AM »

You're right - small things aren't very noticeable. What I did is to change the subtitle of the game, which is always visible at the top of the screen, based on what variations were picked. So one game may be called "Pugnacious Wizards 2: Of portals and archers." and the next could be "Pugnacious Wizards 2: Swords, armor, fire, and traps.". That works ok for such a small roguelike but probably would be odd for a larger one. The idea still needs some work because I'm not sure what the best way to do it is.

That's a really creative solution.  I like that.

It's weird because I mainly play ADOM, and in that game "metagamey" observations made by your character are so ubiquitous that they are often completely taken for granted.  And somehow that completely works. 

For instance, so-called "tension rooms" contain many, many duplicates of a particular creature type (say, goblins) and presumably are meant to be the lair of a particular tribe of monster.  They are called tension rooms because entering the level containing them generates the message "you feel a certain tension."

There are a number of these coded messages to players that you run into semi-regularly.  And it's quite cool.  The only thing I might change about that is to make their appearance dependent on the PC's perception attribute.

I do think it is work pointing out that dungeon encounters can be about more than just changing the number and type of monsters in a room.  Rooms can have themes that includes items and monsters-an armory could be populated only by heavily armored creatures and animated armors and have a high chance of spawning armor type equipment.

Other themed room ideas include:  Encountering a traveling merchant,  danger rooms with doors that seal until monsters are defeated like in Zelda, a statuary which contains gorgons and the stone versions of monsters they have petrified, an antimagic room where spells cannot be cast and or MP is drained, or a room of misery, where damage dealt by all creatures and the PC is increased.  Some of these are copied from other games, but you get the idea.