Hello
Just another two remarks:
- One big advantage I see in the client/server model, specially with
thin-client, is a real split between engine, where features are being worked
on, and display. I think that connection through the network forces a good
abstraction and encapsulation. Furthermore, it solves the problem of people
having different and incompatible versions of config files.
I don't think it would be a good idea to make a generic protocol. If
you want to finish the task some day, be more specific. A very high
level protocol suitable for this particular game can be extremely
lightweight.
Also, think twice before dropping udp: latency is a big issue for games
and since the thin client displays dynamic stuff, the only thing that
needs to be reliable is sending orders from the client to the server.
- I was thinking about Qt because I've spent lot's of hours last 8 years in
making GUI for less than 1/10 of Qt's features. I think that using Qt can
very quickly gain us lot of development time. Let only take graphics
backends. We have several bug report of people complaining that the GL
backend does not work with their specific graphic card. With Qt, we can just
use Arthur, and we get OpenGL, X, GDI+, ... for free.