Re: [glob2-devel] Is this project dead?

[Stéphane Magnenat]

Hi,

I saw the move to github, it's great, thanks a lot for doing it! I have 
started a mailmap file [1], currently adding Leo, Bradley, Martin and I. 
This file let git log to remap old mercurial authors to existing github 
users. Do people like it? If so, I can ask the people I know and who are 
not on the mailing list what users they want.

On 26.12.19 22:08, Kyle L wrote:
> Yes! It would be really cool to create Globulation3D! I tried creating 
> a globule once in blender. From that experience I decided I'm not the 
> right one to be doing graphics. My thought was to pick some subreddits 
> and spam asking for help creating 3D assets. What were you thinking?

Globules were rendered in Blender at some point in 2004 (originally they 
were made for Glob1 in 1999 with a MacOS classic renderer whose name I 
forgot), you can find them here:

https://github.com/Globulation2/glob2/tree/master/datasrc/gfx/globules

Regarding the most urgent things to do, I agree with Kyle about the 
networking code, sending UDP packets with NAT-hacking headers is clearly 
not the way to go in 2020. Nowadays, if we want P2P we could try to go 
for WebSocket, but if we accept a slightly larger latency and a tiny 
server forwarding the packets, we could massively simplify the network 
protocol. Given the work force available, that is probably the way to 
go, but if someone is motivated to re-implement the current distributed 
communication using WebSocket or a similar modern technology, it's great 
of course. I'm available to answer questions regarding the design of the 
network protocol.

I am not sure that the current 2D visual design is blocking Globulation 
in any way, but of course if people are motivated to do a 3D version, 
that's great. Maybe the easiest is to create an abstraction so that the 
engine and the rendering are only tightly coupled, this could even be 
extended to a model where only input events and delta on drawing lists 
are streamed through the network.

For the sake of evolvability of the project, the most critical piece 
that needs refactoring IMHO are the unit and building finite state 
machines, that should be implemented using co-routine/async programming. 
These FSA were a nightware to debug, and to do any change one needs to 
reconstruct them on a large paper. If nothing bad happens, stackless 
co-routine/async should be in C++ 2020 [2] and that could be a good way 
to start that refactoring.

I had a brief look at some random pieces of code (such as Building.h and 
Unit.h), it should not be too hard to do incremental modernization with 
a proper IDE with good refactoring tools.

Btw, do we actually have a maintainer?

I hope this helps!

cheers,

Stéphane

[1] https://github.com/Globulation2/glob2/pull/5
[2] https://en.cppreference.com/w/cpp/language/coroutines

--
http://stephane.magnenat.net