Roadmap: Interface

[crazzymad777]

I want to start work on user interface (for consoles, gas tank, pumps, fire alarms, air alarms, gas mixers, etc) but I don't know archicture of project.

So I need consultaion, how much better introduce it, interaction between objects and ui, etc..

E.g. Gas Tank, I already made window for that one, it will show pressure and valve's status and player with it will can toggle valve.

But how introduce it? Where place it? In client/represation? But when player clicks on gas tank, it should create form probably through an interface (I supposed). For example,

void GasTank::AttackBy(IdPtr<Item> item)
{
    IdPtr<Hand> hand = item;
    if (!hand.IsValid())
    {
        return;
    }

    if (state_ == State::BROKEN)
    {
        return;
    }

   eazytouch_interface_->CreateForm("gastank", this);
}

Or something like that.

[crazzymad777]

States of objects changes only when Process() called? If yes, we can update user interface form (e.g. gas tank, pressure's value and valve status, if it is broken then close form) for object at the same time with Object's Process. Else preferred make separate process.

[kremius]

This issue is actually pretty complex by its nature, so it will request some time from me to describe my vision properly. So I will answer in details in couple days probably. But TLDR: changes everywhere will be needed (server, core, client), the issue is big.

[kremius]

Some notes can be found here #106

What do we want?

We want a way to display an arbitrary complex interface to user and interact with game via this interface. There will be plenty of such interfaces, and it would be nice to have ability to create them in a swift manner.

Some internal details

The game has 3 main parts: representation, core and server. All visible information is passed via frame https://github.com/griefly/griefly/blob/5445dda253aa8a9bac27de23a97c6cc4a18409bc/sources/core_headers/CoreInterface.h#L19 so it should be possible to fully draw interface from frame data (i.e. no chain dependencies from previous frames). Obvious choice of a data format in frame for UI is JSON, but maybe there are better ways. Overall:

1. With some way (e.g. browser) the UI is drawn on user screen.
2. When it is needed to make some interaction with the world then the UI passes the intention to the client. There should be certain standart way to do it, just like with usual UI and clicks.
3. The client passes that intention to the server (something like MakeClickMessage, but with some JSON as a parameter).
4. The server broadcasts such message to all cores (just like with other messages).
5. Each core handles the message and changes something if it is needed.
6. When Represent is requested (basically, every tick) the game object which represents the UI generates an appropriate JSON (or something) for client-side.
7. Goto 1.

Currently I think to pick HTML and JS as base for such UI, because they are easy tools for flexible interfaces. QWebChannel/QWebEngine can be very helpful here. UI should have 1 main entry point - something like stateUpdate(json) which will be called with new data each tick.

There are a lot of other small details, and they can be discovered only during the development. It may request a lot of testing and changes.