I've actually thought using this idea in a game. It will be interesting to see how people respond. I also thought about have some stat determine how long you got to think about your next move before you made it, something like mental processing time or a 'reflex' stats. I guess here the closest thing to that would be Pe.

Nice to see people voting against a game mode they never even have to play.

That's an interesting take on it.

It would certainly give those who say 'this game is too easy' something to test their mettle against. The added pressure of having to make turns in a timely fashion that I could previously walk away from the computer to ruminate about would certainly separate the merely intelligent from the intelligent-under-pressure. I think I would get destroyed by such a game-mode.

Honestly, I don't think that a lot of ADOM's menu systems are user-friendly enough for this to be tolerable. If the timer only counted on the main screen, I guess this would kind of work, but if the timer extended to players having to dig around in the inventory/skills menu/whatever I think it would probably turn into a bit of a mess (including how actions that happen while you're in inventory would be reported to the player).

Good point. I always thought it would be an interesting experiment to see if ADOM could be overhauled to require far fewer buttons (heck, maybe even playable on a gamepad) without loss of functionality.

I think a workaround would be simply to slow the timer down on the menus. 1 second that passes on a menu screen is half a second on the main screen, or a third.

In regard to reporting things that happened, perhaps take you back to the main screen, show what occurred, and provide a 'last menu' button that takes you back to whatever you were last looking at (including scroll position). Hm, that could probably be a new feature anyway separate from this one.

You're not trying very hard to figure out a way to make this work...

You could have the open menus take up half the screen and still have the action visible on the other half.

You could blit the menu screen on the main screen with partial transparency.

You could print the message buffer and stats like HP on the menu screen so you could still get info about what was happening.

TB might think this is too much trouble to code, sure, but it's not like good solutions are unimaginable.

Thanks for those ideas, I prefer them to mine.

I agree. Programmers are problem solvers by trade. If TB had the will he would find a way.

I do think the UI is one of the weakest aspects of the game--although I'm to understand that other roguelikes had far worse interfaces and ADOM's was an improvement? I still think the game could be even more intuitive and compress functionality onto fewer keys, and have people spend less time in menu screens (although this is a common problem in a lot of RPGs).

I think it's hard to beat the diablo type of visual inventory management. The main problem with menus in ADOM, and the reason that would never work for it, is that there is *so much junk* that fills them up. There are a zillion item types that are just subtle variations of each other. Potions of boost stat, gain stat, gain potential, missiles with very subtle differences that stack separately, etc. There's the same problem with skills, actually. Metallurgy and gemology should be combined, bridgebuiliding and woodcraft, archery and fletchery, first aid and healing, food preservation and survival, trap detection and disarmament, and so on.

It's hard to write a good interface if the things you are interfacing *with* are so cumbersome.

True enough and there are a variety of solutions to that. While simply reducing the number of skills, or criterion for piling into separate stacks is one, another would be to simply have new ways of sorting and filtering or grouping into menus. For instance, I could view all the potions that act on stats, act on strength, or boost stat. Or even show 'everything that affects strength' whether equippable or drinkable. A tag system perhaps? With enough organisational tools even a very bloated inventory could become manageable (although that perhaps would increase the learning curve of the game in having to learn those tools)

I'm sure there are solutions. There are lots of real-time RPGs out there that have approached this problem in various ways--generally by being much, much simpler than ADOM. I don't know that there are many complex turned based games that have successfully grafted real-time onto them at the end of development. Regardless, this becomes a much more complicated proposal than simply "make turns elapse if you wait too long", because you need to do a substantial overhaul on the interface to make it work.

Which is why I am saying that feature bloat should be removed to make it easier to navigate menus.

Unless you just freeze time in the inventory screen, in which case no overhaul at all is necessary, like you yourself said.

Freezing game-time while in inventory (and possibly other screens) will allow players a method to stall game-time whenever they want. The menus are transparent in the NotEYE versions, so you can still see the play-field, and consider your move without the intended auto-moves of challenge mode.

I tend to agree with JellySlayer, in that is may sound like a simple change to implement at first, but the massive complexity the menu system has evolved into over the years makes it hard to do in a way that's playable and/or can't easily be worked around. Of course the menu system could be completely re-written, but that's just going to alienate you from the player-base already familiar with the current system. And to what end?

I think this is one of those ideas that's nice to consider, but probably impossible to implement without gutting and re-designing the game UI -- which I'm certainly not in favour of.

Nobody can stop a player from pause buffering in real-time games , tkoyah. The 'issue' that you are describing has been around since Nintendo games (and probably before that). Players in speedrunning competitions pause buffer to input frame perfect button presses, for instance. This is no different that that, and I don't know anyone who has even complained and said that being able to pause in mid air while playing Mario so you can consider your next move is a design flaw.

If nobody wants this feature, fine, but again there's nothing really *wrong* with it that isn't made up.

I do think the game shouldn't be easily paused, as that defeats the whole purpose. The only way to stop and consider your next move should be to save and exit the game. Or, alternatively, have a pause feature but it forces a turn elapse. You can 'buy' an unlimited pause at the cost of a turn. And/or, have the number of times you paused/time spent on menus (if they pause the game) factored into your final score.

Sorry, this is a turn based game and it's one of the crucial features precisely because it doesn't expect you to act due to some ridiculous time constraints.
I hate games that force you to make what are often very complex decisions in a very short time.
It's too much stress and too little fun.

For a challenge game, it's maybe fine, though I dare you to point out five people that will regularly play it.
I know that the regular weekly challenge games are not exciting for me at all.
Having a challenge go further would probably result in even less people willing to play that.
Poor allocation of programming resources if you ask me.

Adom's main feature is it's complexity and thus, long time required to make an educated choice due to a multitude of possible resources, factors and outcomes.
This RFE is just not applicable for this genre.

Yeah, you'll hate fighting games then.

Since the difficulty would not be adjusted, keeping the complexity while adding the pressure of having to think quickly without degrading the quality of your thinking would help one discover where ones potential really lies.

Like I said, I'd probably get destroyed by such a mode. I'd still be curious to discover how well I would actually do. I suspect it would make me a lot better at the vanilla game, just as quitting the habit of save-scumming made me better at the game.

'Crypt of the necrodancer' was a game written based on this principle. According to it's developers, the timing idea actually came before the music did.

It's wrong to think that the premise is flawed for a roguelike, especially given that 'necrodancer' is one of the best roguelike games this decade, although one as complicated as Adom would have to give a *lot* more than the 1/5 second that 'necrodancer' gives between actions.

https://www.google.co.uk/url?sa=t&rc...RfcMN7EpQ_8d1Q

No way, superman needs a game to challenge him.

I think it would probably actually make you worse at vanilla, because your instinct wouldn't be to take your time in situations when you actually needed to. A lot of people believe that playing speed/blitz/bullet chess leads to similar problems in regular play--you train yourself not to evaluate your moves properly, shorten your attention span, and play erratically. Although a typical ADOM move doesn't take nearly as long as a chess move, I suspect that the outcome is probably similar.

The game being written based on this principle is very different from the game being written based on an entirely different one and then changed at the end of the development cycle. If you were building a game from scratch and wanted to do this, I don't see any reason why you couldn't. But you wouldn't make a game that looks or feels like ADOM.

Yes, pause-buffering has been around for a long time. Most gamers are aware of this. But the OP suggested an auto-elapse mode could provide a challenge. I was merely pointing out that the challenge can easily be nullified, so...

The more relevant point: Do you try to counter this? Should menus not be transparent in this mode? Should auto-elapse still continue within menu's? (I think "yes", but maybe not to the same degree.) ..Important side point: can ADOM's code can even handle gameplay continuing behind menu's? <--- This might be the point that shuts the whole idea down. It might well be virtually impossible to code, depending on the implementation.

Or, it will become a mental test of whether that happens: whether I am easily conditioned by the constraints of one mode when switching to another.

The whole intrigue of the idea for me is simply, to quote mortal kombat "Test your might".

And you don't have to play it.

I also don't care for people who vote against things based on an estimation of Thomas's time and resources, like they're quarterbacking as his personal assistant.

I'd vote on any presented suggestions as if the person suggesting it were Thomas's doppleganger/sock-puppet (i'm not, at all) who's testing out the sentiment toward certain ideas.