Re: [glob2-devel] Glob2 salvage proposal

[Andrew Sayers]

I'm rather operating out of my area here, as I don't know much about
graphics or networking (in general, not just in Glob2).

If rewriting the front-end in QT means we can do more stuff with less
code, and spring-clean parts of the program I'm never going to be able
to look at, I'm all for it.

I'm less certain about the client/server system.  I don't think a single
central server would really be feasible, because the processor and
memory requirements would be too high.  It would also mean the game
required a lot more bandwidth to play, and while there are things we can
do to reduce the processor load of a game, there's nothing we can do to
increase people's bandwidth.

That said, I'm sure you're right about the complexity of the current
system.  Since I'll most likely have to visit it anyway as part of the
map rewrite, could you tell me which files define how the network code
works and some of the problems of the current implementation?  If it's
possible to get an easy-to-use system without changing the overall
architecture, that strikes me as the best solution.  Also, do you know
whether Nuage's method of traversing NATs resembled this one:
        http://en.wikipedia.org/wiki/UDP_hole_punching
If so, does the YOG server act as the intermediary described there?

Actually, this all leads on to what I was trying to say in my previous
post.  The reason I suggested you work on documentation etc. is that you
have a great deal of knowledge about the game - what's in it, why it's
there, what has been tried and failed, etc. - that nobody else here has.
To put it another way, if this is to be a community project, it's
important that you write down the things we would need to know if you
suddenly had to stop contributing to the project.

        - Andrew