Hi
I would love to see attribution of BB commits on my GH account.
I am totally fine with the 2d version. Main issues were bugs and
gameplay
inconsistencies, not the lack of tilting cameras. In RTS I don't like
tilting
the camera, to not lose orientation.
Let me know what a good IDE is for C++. I doubt I will have time but I
would
like to re-learn coding in C++, too.
The maintainer is Kyle. He created the repo :D
On 12/28/19 10:05 AM, Stéphane Magnenat wrote:
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
_______________________________________________
glob2-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/glob2-devel