Stephane Magnenat wrote:
Hi everyone,
[...]
I propose to split glob2 in a server and a thin-client. The server would do
the actual game logic (core engine) and the client will do the rendering. The
client will connect to the server through TCP, and download game media
(graphics, music) dynamically. Only the server will do computations. This
should solve both the synchronization problem and the gradients limitations
for slow computers. The client will be generic (i.e. not limited to glob2):
you can see the client as a sort of webbrowser but with server-side layouting
and optimized for games (binary protocol, animations support, ...). I propose
to base the whole thing on Qt4, because it is very well done, documented, and
provides lots of features (nice themable gui, network, reflexivity,
serialization, several graphical backends, ...). And of course it is GPL.
In theory, this would be a great idea, but it definitely won't scale
well. If you have one central server (say, the current glob2 meta
server) do all of the logic, you will have a huge issue with load when
the game becomes bigger (at least I really hope it does). Imagine 100
people playing with each other when the game hits stable. With all of
the different things going on the AI in that would totally bog down the
server. Well, maybe not at a 100, but eventually it will. There has got
to be a better way to do it.
I will definitely turn this over for a while
_______________________________________________
glob2-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/glob2-devel
