Re: Where to put interface?

At 23 Oct 2005 17:33:57 -0700,
Jeff Lait wrote:

> Milesss wrote:
> I will note that the same abstraction is required.
>
> 1) You need your device dependent API which returns characters. This
> can't just be curses or SDL. Both have peculiarities (ie, arrow keys,
> etc) that you want to normalize. You Only Live Once has this in
> gfxengine, along with some #defines for cross platform/engine arrow
> keys.
>
> 2) You should have a second level which translates your generic
> keypresses into roguelike specific actions. This has to be context
> sensitive. When you are wating for an action, 'y' may be "move north
> west". When you are waiting at a prompt, it may be "yes". You want
> this layer to allow for user defined keyboard mappings. You Only Live
> Once pretty much lacks this layer, instead just hard coding
> translations of keys to function calls.
>
> POWDER does a bit of a better job, first translating the keys into
> ACTION_ enums which are used to trigger different behaviours. This is
> necessary in POWDER as dynamic key remapping is an integral part of the
> GBA version.
>
> 3) Your AI code is equivalent to your Keyboard Input Code. As such,
> both routines should call the same set of functions. An extreme
> approach to this would be to have the AI code just return the ACTION_
> tokens that it wishes accomplished. I'm less pure and suggest one can
> avoid the level of marshalling by just calling whatever action_ method
> those tokens correspond to.

I'd say there are (at least) two aspects of input and output.
The most common output is as you described -- displaying the map, the
messages and the effects. It is tied with the dungeon harder than with the
player input, and I think it's a good idea to have it separated.
Similar with the 'action' input.

But then there's that meta-game, ui-related input and output. The
simpliest form is the 'Direction?' prompt, but there are more
sophisticated ones, like 'Drink what?' and the look command.

Count in the procedures that display various menus, character stats,
inventory, help screen, etc. -- these are tied pretty closely with
the input.

They are not really 'input' in game terms -- they are not directly used
for controlling of the characters. But they surely use the computer's
input and output, and I'd say they are pretty different from what you
described, including totally different requirements for helper functions.
Sure, they can be simulated, to some extent, with the messages, but
I think it's very liiting and crippling for the ui.

--
Radomir `The Sheep' Dopieralski @**@_
(Qq) 3 Sob?
. . . ..v.vVvVVvVvv.v.. .
.

Relevant Pages

  • Re: The Last Remnant
    ... Smallish 3rd person characters rushing around with the screen flashing ... One thing I thought was poor design is that you can control the 3rd person ... of as RPG. ... that even help any if one knew exactly what all those keys are for? ...
    (comp.sys.ibm.pc.games.rpg)
  • Re: Great SWT Program
    ... failing of the GUI user-interface paradigm. ... And that probably works fine if the remote files aren't too big, ... the keys used for movement and cut, copy, paste can't even be depended ... characters and then type in the resulting number before hitting my ...
    (comp.lang.java.programmer)
  • Getting the correct size of a glyph in a font
    ... the text for the differing keys. ... however I found that those characters which have a descent ... GLYPHMETRICS and use the origin and its blackboxy, ...
    (microsoft.public.win32.programmer.gdi)
  • Re: Text Messages in Chinese and Japanese (WAS: Writing French without accented characters)
    ... > characters in text messages. ... > characters for the string of pinyin text I input using the digit keys ... > "occidental phones". ... Once the appropriate key is entered, lists of kanji would ...
    (sci.lang)
  • Messed up keyboard
    ... Some keys ... are displaying wrong characters. ... Than2s! ...
    (microsoft.public.windowsxp.perform_maintain)