wiki:CoreUiSplit

As [discussed on the development mailing list][1], the game could do with having the user interface split apart from the game mechanics better than is currently the case.

The aim of the current (2.6.0 - 3.0.9) Term package is to provide a way of showing the same display and taking the same inputs across any platform possible, a task it does very well. However, this means that certain enhancements that people want (such as graphics and mouse support) have to implemented in a somewhat hackish way, and limit the possibilities of these things. Maps, for instance, even if drawn in graphics, have to fit into a text-based grid rather than be drawn separately from the textual parts of the game.

The solution is pretty simple in outline - split the game mechanics apart from the display of the game so that one section of code is responsible for displaying the maps, stores, etc and telling the game what the player wants to do, and the other is responsible for acting on the player's commands, moving monsters and suchlike, and then telling the UI what things have changed, so that it can update its display as it sees fit. Then to add graphics you can just change the UI layer to draw the map differently, because the game tells you when the map has changed without caring how it's displayed.

The basics of this have already been done in the development version, (see changes [522] [2] and [523][3] for instance). The events that have always been considered "updating" or "redrawing" events can easily be set up to be triggered by an event system rather than directly drawing things. For instance, instead of redrawing stats, the game sends a ui_STATS_CHANGED event and code the game knows nothing about can do what it likes in response.

The extension of this system might present some problems in where and how to split the game from the UI. It makes sense, for instance, that the game shouldn't be handling things to do with moving the map display panel directly, as it shouldn't care if the whole map is on screen or just a 9x9 section of it. However, this means that, for instance, the "look" command also cannot move the screen about to make sure the currently observed thing is on screen. When you consider this, you realise that many of the commands in the game are effectively user interface commands, and the "game" should only be supplying the information to allow them to work, and not have any say in how they work.

These commands/UI features are:

  • "Look" command - it should supply a list of grid squares that can be 'l'ooked at.
  • "Target" command - as for the look command, including when we already know what we're firing.
  • Linked to these is the monster/object recall. The UI knows what is being "looked at" and can update these if it is given the actual description by the game.
  • Likewise, the "monster health bar" - the UI can display the health of any and all monsters on screen however it wishes (just because this has gameplay ramifications doesn't mean it should be handled in-game). The game should just inform the UI which monster is being fought (or targetted?). Or should the UI remember what the last "attack command" was attacking?
  • Options (though setting an option is a command)
  • Knowledge screens (though setting/unsetting autoinscriptions is a command)
  • (please fill in any others you can think of - in general anything that doesn't take time is probably a candidate)

[1]: http://angband.oook.cz/pipermail/angband-dev/2007-July/000253.html

[2]: http://dev.rephial.org/trac/changeset/522

[3]: http://dev.rephial.org/trac/changeset/523

Game contexts/areas

The other commands the game will respond to might depend on the area of the game currently in use - not everything gets done in the main game interface. The areas of the game, and the non-UI commands it supplies are outlined below.

Initialisation

The game needs to signal the start of the initialising process so that the UI can display a splash screen of some sort (the news.txt file in traditional ports). Then it needs to supply text describing the stage it is up to in initialising the game. Finally, it asks the UI for a command:

  • New character (possibly with parameters
  • Load a savefile

Birth Screen

The birth process can be modelled as a default character (say race 0, class 0, sex 0) which can be modified by a series of commands each of which leaves you with a functioning character. Commands include changing race, class and sex, buying and selling stat points, and changing name.

Main Game

All the usual commands (might list them later).

Stores

Again, a signal would be sent to start the store process and give a chance for the UI to get the relevant store information. The commands allowed in store would be any inventory management commands with the addition of:

  • Buy an item
  • Drop an item in the home
  • Sell an item
  • Get an item from the home
  • Leave the store

Tombstone (Death)

No commands can change the state of the game (unless we add a "rebirth" or "restart" command), no nothing.

Always-available commands

  • Quit
  • Set/Unset? an option (including squelch and autoinscribe)

Others

I can't think of any off the top of my head, feel free to add them.

Last modified 6 years ago Last modified on 12/26/10 00:27:30