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 [email protected] https://lists.nongnu.org/mailman/listinfo/glob2-devel
