UI Layout - Email from Sal

Sebastien writes:
I don't see the point of UI extensions in Atlas. Atlas is not tied to a 2D or 3D layout, it doesn't imply a representation of the information it transports.

Yes, but no matter what client you are using, you will need to send information to the server about your character. The player needs to pick from many different classes, abilities, etc. I'm just saying that the servers needs to tell the client somehow about the information that it requires for its ruleset.

Also because rulesets may change over time, and people are going to copy servers just to change one aspect of the ruleset. All these server-side changes need to be seen when a client reconnects. So if I add 10 new character classes, then the client should be able to select from a list of those new classes. The ruleset info needs to be stored serverside, and sent

You say it would allow a single client to adapt to several rulesets ? I think, done this way, it would make all clients seems the same, every one using the same layout.

I don't think so... If the server requests: "I need a string, for the character name" then the 2d client could show a graphical edit box, the text client would simply prompt for the information "Please enter your character name:", and a 3d client, if so desired could show a scroll or something, that you write on. I still think the clients would be very diverse. They all are inputting a string, but there are many different ways to do so...

However, I'm with on this point, we don't want a client dedicated to a specific ruleset, this means Atlas has to transport information relative to the ruleset:

But you are hardcoding the possible games here, already. You are assuming that 1) there will be characters with attributes (what if I wanted to do a flight sim?) 2) that there will be violence in the game

3 & 4 are 'okay' :-) but do you see my point?

In the early days of WF, I was thinking to have several rulesets installed on your HD, and when connecting to a game, you could select the ruleset that matches the game. This way, the ruleset information is not sent via Atlas but is like a configuration file. This mean, it can be customised for 2D, 3D or text. I compare the ruleset to a "skin".

This is what I am suggesting we do, except that the ruleset is not stored clientside, but sent by Atlas. That file will have to contain descriptions of the data needed by the ruleset, and how to obtain the data from the user. It could be very specific, actually describing widgets (but I think that may be overkill). Or it could be a tad bit higher level, simply saying that it needs an 'int', 'string', 'float', etc. And the client will decide how to obtain the information...

I don't think describing a ruleset would be an easy task, but I can give it some time. What we should do is take at least two rulesets and try to describe them, making as litle asumptions as possible.

Good idea. We should take some rulesets (Maybe Circe, Warforge, and Old-fashioned dnd)? And try and flesh out how Atlas will convey the ruleset descriptions.

One more idea, in case of a new ruleset not known by the client, this one can query the server to make an "approximation" of the ruleset, asking the above questions.

I think those questions are a bit too high level, and assume too much about the ruleset... It may need to be lower level...

I'm thinking of something along the lines of:

ServerSide:
[UI]
    [static_text]  Would you like to Generate another character?
[/static_text]
    [option] [caption]Yes [/caption] [id] 0 [/id] [/option]
    [option] [caption]No [/caption] [id] 1 [/id] [/option]
[/UI]

Text Client side: Would you like to generate another character? (Yes/No)

2d client & 3d client: They would show a simple dialog with a string saying 'Would you like to Generate another character?' and two buttons, 'Yes' and 'No'.

then the clients respond with the id of the option (button) selected

Maybe replace 'response' with 'event'?

[ui] [response] 0 [/response] [/ui]

=============================== Then they go on to select character attributes:

[static_text] Select Race [static_text] [list] [text] Human [/text] [id] 0 [/id] [------ can be omitted? [/element] [element] [text] Dwarf [/text] [id] 1 [/id] [------ can be omitted? [/element] [element] [text] Elf[/text] [id] 2 [/id] [------ can be omitted? [/element][/ui]

[...] [/list]

[ui] [static_text] Character Name [static_text] [input_field] string [input_field]

Please enter the character name:

Please select race: 1) Human 2) Dwarf 3) Elf

Graphical clients would show a dialog, an edit box, and a list box of the availiable races. Note that the client is behaving exactlly how the ruleset dictates, but does not know anything about it.

I don't think that it would be too hard to implement, we would only need to add a few tags to the existing atlas implementation:

ui
    static_text
    button (option?)
        caption
        id
    input_field
        caption
        type (float/int/string)
    list
        caption
        id
        [ caption
        id
        caption
        id ]
    radio_group    (group of options, only one can be selected)
        caption
        id
    check_group   (a control that can be checked or not checked)
        caption

These may be all we really need for most rulesets, though it would be nice to have a couple more that were a bit more advanced. Like a list that could be sorted by clicking on headers, or even a tree control...

As a client coder I feel it would be really easy to implement these things if we decide to do so. Crystal Space already has a very advanced built-in UI library, and UClient has a nice windowing interface also. And a text client would just take a little creativity :-)

-Sal

General WF-Dural UI Layout Notes - Cerebus


So far it must have:

Here is a new independant game

http://members.xoom.com/nspgames/

This might give us some ideas for the user interface.

also check out

http://www.gdconf.com/indiegames/finalists.htm

Entity hierarchy tutorial mail -Aloril

Here

Text client: