GUI Overview

The graphical user interface plays an important role for the game, because it's the component that makes interaction between the player and the game world happen. Therefore, it needs to follow certain rules in order to give the player a pleasant gaming experience.

  • Intuitive - There needs to be a low learning curve, new players should be able to accommodate themselves without needing to study a long manual or extensive in game explanations.
  • Efficient - An experienced long-time player should be able to use the GUI to its maximum and should not feel limited by the GUI's features (or the lack thereof).
  • Modable - We want to make it easy for people to make modpacks for our game. Therefore, we need to have a Graphical User Interface which is easy to understand, edit and change. We have choosen to let the GUI be based on XML and JavaScript, which gives us to possibility to keep the GUI code outside of the hard-coded C++ game code.

These fundamental rules need to be kept in mind when we are working on the technical specifications and the actual realisation of the GUI.

GUI Goals

Ease of use

  • Intuitiveness: Minimal learning curve. Most actions should follow the same logical structure. Make maximum use of interface features established in other RTS games to ensure that the methodology is comfortable.
  • Structurised: Actions which the player often uses (such as creating villagers or setting the behaviour of units) should be reachable with one or two clicks.
  • Comfort: Important information (such as unit stats) must be clearly, quickly and easily available.

Appearance

  • Quality: We are proud of the game graphics and the interface must meet the quality of them.
  • Minimum Screen Real Estate: Bottom GUI so that the interface doesn't block the player's view. The player can minimise components of the GUI to create a full-screen view if he wishes.
  • Clear Semiotics: The symbols and icons should be recognisable, since we do not want to have to teach the player what the food icon means.

Assistance

  • Tool Tips: Help easily available.
  • Online Help: This help should be accessible from nearly everywhere; context-sensitive online manual, similar to AoE's, but integrated into the game window.

Advanced Functions

  • Common Hotkeys for all buttons, and the main menu. Hotkeys should be configurable from the game menu.
  • Support for both mouse buttons and the mouse wheel, with corresponding hotkeys.

GUI parts

For the 0 A.D. GUI, we differentiate between two major parts of the interface: The Session GUI, which contains all the interface elements visible during the actual game (where you play and send your units around in the game world) and the Pregame GUI (aka Shell GUI), which contains all the screens you see before and after the game session (Main Menu, Options, Game Setup etc.). Those two GUIs share little to nothing with each other by means of the used art, but they are based on the same technical background.

Agenda

  • The direction of the GUI art: When are we going to start on full-scale art production? Concerns: Artists
  • Differences between shell and session GUI artwork - there are large differences right now, and we should decide if we want to coordinate them and make the art styles match each other (which would likely mean redoing some art) or if we want to deliberately keep the different styles. Concerns: Artists
  • Scripting standards. This one is important to me - even though I think it's extremely fortunate to have several people working on the GUI (+scripting), I've noticed with concern that there's several different styles of coding certain things (coordinate systems should ring some bells) in the current code already - I'm not innocent on that part myself, of course, as my coding conventions have changed a lot during the development but I've hardly rewritten any old code. IMO, we should create something like "GUI code guidelines/conventions" which would be made mandatory standard for all GUI code. Concerns: Scripters
  • Who's doing what? And who's responsible for which part? We should find clear areas of responsibility - which doesn't forbit people to give a helping hand in other areas, of course, but should give every developer some part of the GUI code/art which he feels responsible for and which he keeps up to date (for code - read: commented, working and documented). Concerns: Scripters, Artists
  • GUI scripting documentation. We've written over a thousand of XML and JS-code lines already, but there's hardly any documentation (again, me guilty, too!), which is essential to make new developers have a pleasant and immediate start (and benefits the modding community in post-release times, too). This probably belongs to the whole "code standards" part. Concerns: Scripters
  • Create a list of "alpha/beta-critical" GUI requirements. This means, we need to list what we still need to complete - both art and scripting are meant here - and which features we require from the engine code in order to be able to do that. Ideally, we'd be able to specify some clear technical requirements (e.g. "placeBuildingFoundation() function which takes these arguments: buildingID, vector foundationCoords, builderEntity; and behaves like this: ...". That would make things easier for the engine programmers and us, because we would have a central documentation of our needs which is always available and where we can strike out what we've completed (Wiki seems ideal for this). Concerns: Scripters, engine programmers
  • Running out of ideas now. But the mentioned points should be enough to keep a multi-hour-meeting running already, I guess... wink.gif Please note that some points only concern scripters, others only artists and some both. I'd suggest to divide the meeting and treat the art aspects first (because there are fewer of them) and then move on the the code side, making the artists being able to leave already (otherwise they might have to wait a long time while the code discussion takes longer than anticipated).

Design Draft

These are the initial design documents for the GUI, which are now largely outdated and need to be transferred to the Wiki.

Session GUI Pregame GUI Session Creation

Last modified 16 years ago Last modified on Feb 23, 2008, 4:19:00 AM
Note: See TracWiki for help on using the wiki.