GSOC2011 - Ember UI improvements
This page is work in progress and will be further edited. My idea is to track my progress here in addition to the weekly mailing list posts.
For full list of changes, please refer to https://github.com/mpreisler/ember/commits/master
Contents
Introduction
I am Martin Preisler and will work on improving several aspects of Ember's GUI, both in-game and out of game.
Organisation and time constraints
Unfortunately, May and June is examination period, as I stated on my application. I will try to work on Ember as much as I can afford to during this time but I expect to have much less free time during these months. My goal is to get the exams over with ASAP and theoretically, it's possible to have the critical exams done at the beginning of June, so lets hope I pass them at the first attempt :-D
Update: OK the theory didn't work so well :-) I failed, so I will have to go to the regular exam dates. Update2: I finished the exams before the end of June, so I can now focus on Ember.
What's finished
(I am trying to keep up with this list but at any point in time, there are likely to be more changes committed than listed here)
- learnt coding guidelines
- learnt git (bare basics, still lots to discover)
- moved QuickHelp fadeout to looknfeel
- added QuickHelp hide/show transitions
- fixed RiseOnClick bugs in Avatar (top left)
- window activate/deactivate animations
- coloured chat tab (with automatic colour allocation for different players) - http://www.youtube.com/watch?v=n0qQpc1v_mE
- coloured system/console tab with tags (I need to put tags to places where pushMessage is called to take advantage of this)
- put tags to most pushMessage calls
- added console bumping (console alerts the user when important stuff happens - somebody mentions his/her name or error/important console message appears)
- toggle visibility for all windows
- added inventory toggle button with icon from Jayr
- detachable chat window with history (directed entity to entity chat)
- merchant trading dialog (trading without typing)
- representation API
- settings window (fake icon for now, Jayr said he will make a proper settings icon though)
Planned timeline
Before May 24 (before the coding period)
- getting to know the coding guidelines
- familiarising myself with the codebase
- learning the versioning system (I have 'some' git experience but I am not using it on a daily basis)
May 24 - June 7 (coding period starts)
- moving as much UI as I can to datafiles (mostly leftovers)
- further exploring how all the UI code meshes up
- reviving my Lua skills
progress video from the first week: http://www.youtube.com/watch?v=egafToQh2L0 (transitions)
progress video from the second week: http://www.youtube.com/watch?v=ZYX0XPTVQhU (coloured logs and chat)
(since this I was slightly ahead of schedule so the videos sometimes cover features that were later in the timeplan)
June 8 - June 14
- window activate/deactivate animations
- colorized system log messages (https://blueprints.launchpad.net/ember/+spec/ember-colorized-logs)
this week lacks a progress video since
June 15 - June 21
- deciding which windows should be easy to show/hide on a regular basis
- design and implementation of window toggle buttons (for example inventory show/hide)
progress video from the fourth week: http://www.youtube.com/watch?v=RYiWCrWuu7Q (entity to entity dialogs)
June 22 - June 28
- entity to entity dialog design and prototyping
- exploring various options in terms of look and functionality and discussion with the community
progress video from the fifth week: http://www.youtube.com/watch?v=uEn-q6_IWHE (merchant trading)
June 29 - July 20
- entity to entity dialog implementation
progress video from the sixth week: http://www.youtube.com/watch?v=jcCBygy2Xp0 (more or less finished merchant trading, still needs server-side changes)
July 21 - August 1
- settings screen preliminary API design (varconf widget adapters)
- settings screen look design
progress video from the ninth week: http://www.youtube.com/watch?v=QWBbJ5X4-jY (initial settings window)
August 2 - August 14
- settings screen implementation
- integration of the settings screen to the starting menu/welcome screen
- integration of the settings screen ingame
progress video from the eleventh week: http://www.youtube.com/watch?v=obVnSGzVZqs (more finished and working settings window) progress video (help strings as tooltips): http://www.youtube.com/watch?v=Fa3FG5iDpf8 (soft pencils down)
August 15 - August 22
- final polishing
- documentation
(pencils down)
Entity dialog design
In my opinion the way entity dialogs work right now is strange and alien to most players.
What the current system lacks:
- any sort of contextual history (you can browse your entire chat history but you don't see history of the last dialog with a specific entity)
- focus on entity to entity dialogs, you can start multiple dialogs at once and answer both of them in parallel, whilst I think this is powerful I don't think it's very useful and mostly just confusing to players IMO, especially since most won't figure out "Touch" triggers a dialog at first
TODO
Things to consider
Other entities starting dialogs with the player
Other people wanting to trigger dialogs with the player. For example when a player spawns for the first time at the entrance point. Some NPC could walk to him/her and start an introductory dialog.
It would be very helpful if this dialog spawned a UI window to make it feel focused and important.
This suggests that some sort of a DialogRequest is needed under the hood and just wrapping the chat system in a UI window might not be enough.
Conference chatting
I think I will simply disregard this for now, but creating entire rooms for chatting might be desirable in the future.
WIP UI mockup
Trading / Merchant interaction design
After discussion with Erik, I have completely scrapped the old design that would have introduced new commands to the system. Instead the trading will work via natural language parsing via the Interlinguish system. This has several advantages and disadvantages. What I consider an advantage is that it's a more real and less rigid/rigged approach, it's also very unique to the whole genre. On the other hand it's unsafe for players to trade if they don't trust themselves fully, which also is real but very inconvenient. This mechanism won't (and can't by design) impose any locking/safety measures to protect players from scamming themselves.
If players want to make a safe trade, they will have to go to a trusted NPC that will provide such a service.
Obstacles to overcome
- We have to get a lot of information from merchants, parse that and make a nice UI around it to allow user to browse wares and query prices
- At the same time the client shouldn't spam the chat with messages that look fabricated and automatic
- Avoid having the same rigid chat messages
- Making it look natural for bystanders witnessing someone buying something
Example - buying an axe
| UI in Ember | Chat message / System |
|---|---|
| User clicks on a merchant and selects trade | |
| Ember automatically asks the merchant to query what he has to sell | <CurrentPlayer> Merchant: What do you have to offer? |
| <Merchant> CurrentPlayer: an axe, sword, ... | |
| Ember parses the response and populates a list of items that are available | |
| Player hovers over an axe, Ember asks for a price for that particular item | <CurrentPlayer> Merchant: How much is an axe? |
| <Merchant> CurrentPlayer: 10 gold pieces | |
| Player selects the axe and presses buy | <CurrentPlayer> Merchant: I want to buy 1 axe for 10 gold pieces |
| at this point Ember will Give the merchant 10 gold pieces | |
| the merchant should respond by Giving the player the axe |
Implementation
Merchant dialog was implemented as can be seen in this video: http://www.youtube.com/watch?v=jcCBygy2Xp0 There are some server side changes that would make this more robust (Entity saying that he/she is out of stock and so on, right now I the UI can't really know if it's just a lag or if the merchant is outstocked) but server changes were out of scope of this project.
Settings window
It was previously necessary to edit user config files manually to change things like graphics level of detail and so on. When ingame it was necessary to type commands to change such options. I think having a window that would expose these settings with help strings and allow immediate tinkering with them would really push Ember forward.
Representations API
To ease exposing new values it was crucial to make an API that you would just pass a varconf Variable to and it would do all the dirty work, including making a widget to show the value. I called these representations and they are templated and generic, possible to be used for other data types.
I realised that I would be duplicating a lot of AtlasAdapter functionality so I decided to join them under a common base class called AdapterBase (templated). Representations make use of these adapters. I have narrowed the scope of Adapters to just connecting values to existing widgets and Representations are required to construct the layout and then use an adapter (or more of them) to connect the values together.
Declaration format (exposing options)
One of the main goals was to make it as simple as possible to expose new options so I had to choose a self-documenting but lean syntax for this. I decided to use Lua's table nesting for this. Example of the syntax:
...
self.settings =
{
{
label = "General",
description = "Settings that don't fit into other category.",
contents =
{
{
label = "Startup help",
helpString = "if true, the startup help window will be shown at startup",
section = "general",
key = "startuphelp",
representationFactory = function(value) return Representations.VarconfCheckboxRepresentation:new(value) end,
requiresRestart = true,
},
{
label = "Log chat messages",
helpString = "If true, all chat message will be logged",
section = "general",
key = "logchatmessages",
representationFactory = function(value) return Representations.VarconfCheckboxRepresentation:new(value) end,
},
...
More in Settings.lua
Implementation
Video showing the initial implementation - http://www.youtube.com/watch?v=obVnSGzVZqs
More polished version (tooltips contain help strings): http://www.youtube.com/watch?v=Fa3FG5iDpf8
The settings dialog is accessible both in game and out of game in the server browser.
What's missing
As I implemented this I encountered a couple of varconf issues. I have added blueprints for them and once they are resolved the Settings dialog can get even more awesome by having a "Reset to default" feature.
