Develop iiag protocol for front-end -> back-end communication

[richteer]

Front-ends, like the ncurses or SDL ones should communicate with a separate iiag instance that handles the game logic, so that the "clients" need only to handle displaying, and the "server" only needs to handle game logic.

This needs to be fully developed and stable before a lot of the other restructuring can take place.

[Lundar]

I've looked at this a little before, and came up with the following tasks that need to be serviced by the protocol.

Send Tile Update (update display of tile)
query clients last action. (Last sent command from player)
send message (old statmsg)
send question (like throw which way, inventory queury, etc)

This is probably the grounds for the most basic protocol, though more could/should be added to support more advanced front ends that may require more information about the game state.
-edit-
What kind of detail do we want on this before we continue?

[richteer]

At least enough to drive the game at a basic level: essentially design the pattern of the protocol, so that other extensions can be added in later sensibly. In other words, once we are satisfied enough that the protocol won't be changed, just extended, then we can start migrating things.

On that, I think too that the connection to the server should be abstracted as well (obviously, just wanted to make sure that was mentioned).

Dunno, something like

if arg == "socket":
   init_socket()
if arg == "pipe":
   init_pipe()

...

send_msg("Move player to the right")

so that the connection can be fielded by either a Unix socket, TCP socket, FIFO, pipe, carrier pidgeon, whatever.

[Lundar]

It would be easiest to force everything to use the same type of connection, I don't forsee any instances where a TCP/UDP socket wouldn't work or would have a significant performance impact. In other words abstracting connections sounds like extra work for no real benefit, except for perhaps the novelty of carrier pigeons. I've had good experiences working with ENet, an rUDP framework.

[richteer]

The point of the suggestion was to avoid having any networking specific code in the game logic, similar to how the front-end abstraction is being done. Furthermore, we can reduce external dependencies needed if the abstraction is there to support alternate methods, such as simple TCP/UDP sockets, or whatever exists in the standard libs provided by the OS or whatever

[Lundar]

I have similar goals of avoiding network specific code in game logic and portability. I am suggesting we standardize the way that client and server communicate, so that we can reduce the amount we need to code and avoid creating clients that can only communicate with servers that support a specific protocol. Also I'd prefer to avoid talking to the OS directly as it produces much less portable code.

[sjrct]

Not necessarily advocating this, but what about compiling the core game logic into a shared library and then have frontend link into that library and communicate to that library? Client/server protocols could then be independent of this interface. In theory, then only the server would need to know how to speak iiag, and the client could be simple telnet or something similar.

[sjrct]

If not, I agree that we should abstract the communication method such that it can communicate through whatever so the end points need only speak iiag. Besides flexibility it means the game logic devs nor the client devs need care about the protocol.

[richteer]

Even if we only support one communication method, the abstraction should probably still be there in case there is a reason for adding others. As for linking against a shared library that contains the game logic: that would probably nuke networking entirely, unless I am understanding this incorrectly. For simplicity's sake, I wouldn't really mind that just so at least the core functionality can be done. Unless however, a dummy front-end is written that links against the library the drives the game via network. Dunno.

Either way, I would like to keep external dependencies to an absolute minimum, especially after the mess that was Lua support.

[sjrct]

Linking against a shared library has some other problems as well, like sharing state between multiple iiag instances, so it is probably a bad choice.

So, core game repo that runs as a daemon and talks to clients through iiag-speak, whatever that may be? Should we make a new repo called iiagd or something?

[richteer]

iiagd works, I was somewhat thinking that even just iiag is fine, and each frontend would be iiag-ncurses or whatever. Nice and confusing. (I think weechat does something like this)

Also, the iiagd probably doesn't really need to be fully daemonized, the client could probably just spawn the process then kill it when it is done or something.

Oh man, I can see it now:

$ sudo systemctl start iiag.service
$ iiag-ncurses

[sjrct]

Just iiag is fine with me as well, certainly more elegant. Should we still make a new repo then, or just continue with this one? I don't really have an opinion either way on either matter.

[richteer]

Eh, we should maybe move the current one to some iiag/iiag-legacy or something and recreate iiag/iiag so that is clean and seperate from the original one, namely issues and whatnot.

I have no strong opinion on the matter, would prefer to avoid cluttering either repo with too much legacy crap.

[sjrct]

Agreed.

[sjrct]

Moved to iiag-legacy

[sjrct]

Created a new iiag repo.