What's the Latest?

'Yack it up.'
User avatar
Styrj
Posts: 47
Joined: Sun Mar 03, 2013 6:45 pm
Location: Atlanta, GA, USA

What's the Latest?

Post by Styrj » Sat Jun 08, 2013 9:59 pm

nem: Ain't heard from anyone here, what's goin' on? :?
If it ain't broke, don't fix it!

User avatar
nemerle
Posts: 398
Joined: Thu Jan 10, 2013 3:40 pm

Re: What's the Latest?

Post by nemerle » Mon Jun 10, 2013 10:13 am

I'm in high-workload mode :|

Also, since we've had a few offers of developer help, and none have come through, I'm considering what to do.
Problem is, I have no idea if the SEGS codebase really sucks and needs to be rewritten from scratch, or it's just too dense or chaotic. Since I've gotten almost zero feedback, I just don't know :/

Whenever I could, I've been doing some more client-sleuthing for useful bits, and beneath the hood the world/map simulation is starting to take shape.

Next thing to work on is client<->client visibility + chat. ( the client-client will require a test-client app, and that can be a bit of work )
"Ich was in one sumere dale,
in one suthe diyhele hale,
iherde ich holde grete tale
an hule and one niyhtingale."

User avatar
Styrj
Posts: 47
Joined: Sun Mar 03, 2013 6:45 pm
Location: Atlanta, GA, USA

Re: What's the Latest?

Post by Styrj » Mon Jun 10, 2013 11:20 am

I can certainly understand work before pleasure, but, I for one sincerely hope you don't get too frustrated and abandon this project. Its such a thrill just to run around AP again. I can't prescribe anything relating to the codebase, since I'm not a programmer. (Have you tried to touch base with Codewalker (Icon)). However, should you require a good beta/QA tester, that is something I'm pretty good at. I always look forward to your progress with this project.
If it ain't broke, don't fix it!

User avatar
nemerle
Posts: 398
Joined: Thu Jan 10, 2013 3:40 pm

Re: What's the Latest?

Post by nemerle » Mon Jun 10, 2013 2:33 pm

Have no fear, I'm not going to abandon anything :)

It's just a bit frustrating to have people offer help and then disappear.
I think the SEGS codebase has achieved consciousness and is hunting and killing any hapless soul that tries to read it :)
"Ich was in one sumere dale,
in one suthe diyhele hale,
iherde ich holde grete tale
an hule and one niyhtingale."

User avatar
Styrj
Posts: 47
Joined: Sun Mar 03, 2013 6:45 pm
Location: Atlanta, GA, USA

Re: What's the Latest?

Post by Styrj » Mon Jun 10, 2013 3:49 pm

Haha! I hear that. BTW, what is the latest version so far? Whenever I get into AP, the chat window says 3.0. Also, don't be burnin' the candle at both ends. :lol:
If it ain't broke, don't fix it!

User avatar
nemerle
Posts: 398
Joined: Thu Jan 10, 2013 3:40 pm

Re: What's the Latest?

Post by nemerle » Mon Jun 10, 2013 5:06 pm

Right now the candle is a endlessly forking set of every smaller candles, all burning :)

And the latest 'version' is 0.3 alpha, but the test server's codebase is a small bit ahead of the github repository.
"Ich was in one sumere dale,
in one suthe diyhele hale,
iherde ich holde grete tale
an hule and one niyhtingale."

Codewalker
Posts: 2
Joined: Tue Jun 11, 2013 1:55 pm

Re: What's the Latest?

Post by Codewalker » Tue Jun 11, 2013 3:26 pm

Oh, I never re-created my forum account after the crash. Guess I should do that.
nemerle wrote:Also, since we've had a few offers of developer help, and none have come through, I'm considering what to do.
Problem is, I have no idea if the SEGS codebase really sucks and needs to be rewritten from scratch, or it's just too dense or chaotic. Since I've gotten almost zero feedback, I just don't know :/
nemerle wrote:It's just a bit frustrating to have people offer help and then disappear.
I think the SEGS codebase has achieved consciousness and is hunting and killing any hapless soul that tries to read it :)
Aw, that's no good. I had seen a few developers sign up, but it's very disappointing that none have come through. :(

Part of it may be fear of legal action shutting the whole thing down, which is unfortunate because the community needs something it can see to rally around.

All right, well, if it helps, here's what scared me off:

Code: Select all

Description: Stores bits in a special "packed" format.  Though i've
                         written a working implementation of it, I don't entirely
                         understand how it works

TODO: Learn more about the "packed bits" format, and write a better
          description of it, and if necessary a better implementation
That's not the only thing, it's just one that I like to pick on. Now, I don't know who wrote that comment, or if they're even still with the project. For all I know, you understand perfectly well why packed bits work like that and just haven't bothered to delete that.

However, browsing through a code repository from the outside, seeing something like that doesn't inspire confidence. I'm not sure if that's more or less because I know where that comment comes from, since the code in the function below it is an instruction-by-instruction re-creation of exactly what the client does in its network code. Someone disassembled it and pasted it in there without understanding what it does.

Other things that make this particular code base difficult to work with (trying to be constructive here):
  • Organization is all over the place. It looks like a Java programmer came in and created a bunch of modules, because there's so many subdirectories, and most of them are empty or have one file.

    One of the first things I tried to glance through was the network code. Finally located it under Components/Common/CRUDP_Protocol (why is it there instead of under CoX when it's a proprietary protocol?). It uses Bitstream, which is itself under a different module with a src/ and include/ subdirectory having a single file. Bitstream itself isn't used by anything else except for the network protocol. It it turn makes you chase down GrowingBuffer to figure out how that works.

    The Codec class also seems unnecessarily split off from the main network code when it's not used by anything else.

    I'd recommend taking a serious look at the structure and determine if there's any kind of rhyme or reason for where things are split up, especially with regards to what goes in Common vs. Clients. vs. Servers. vs. Projects. CoX even has a Common/Servers/ in addition to Servers/.
  • Overuse of certain language constructs. I'm not going to go on a language crusade; and C++ is a perfectly fine language to write a game server in, personal preference aside. However, when some of the lower layers in the performance-critical path are overengineered using multi-layered classes that waste a lot of time working around their own very design, something is wrong. Just look at all of the redundant getters and setters, reinterpret casts, and one-liners that do effectively nothing, as well as how many objects are created and destroyed in normal operation.

    That much running around at the very lowest levels makes makes me wonder if the design will be able to scale beyond a few dozen players without massive revamps. Which is perfectly fine for a first draft to get things working, but the danger is that the same thing will carry over into other systems and become a nightmare to untangle when it does need to scale bigger.

    IMO, doing the lower levels procedurally for performance and ease of understanding; and using heavier object-orientation for higher level things like entities and world state makes more sense.
  • Some of the places STL containers are used (and which ones are in use for certain structures) are questionable. They're easy and handy, but in performance critical paths they can be problematic, especially when templated for complex objects. Of course it doesn't help that I had just come off of a big project that was fighting massive code bloat due to STL containers causing template explosion, so there may be some bias there.
  • I understand the reason for the multiple projects and generic game support. However it makes things much more complex and harder to figure out where to go to work on things. Just look at all the empty interfaces under Common/Server/.
Anyway, not trying to nitpick or anything, just some observations that may or may not be related to the difficulties.

User avatar
nemerle
Posts: 398
Joined: Thu Jan 10, 2013 3:40 pm

Re: What's the Latest?

Post by nemerle » Tue Jun 11, 2013 4:03 pm

Oh wow, Thank You :)
Codewalker wrote: Part of it may be fear of legal action shutting the whole thing down, which is unfortunate because the community needs something it can see to rally around.
Well I do understand that fear. but is it a fear of 1) wasted effort, or is it 2) a fear of legal ramifications to the coders in question ?
If it's no. 1 then we have to remind those fine people that code IS available through github.. and is pretty much un-killable ATM, the people hosting servers might be more exposed that's true, but we're talking about our fellow code monkeys, not server-admin orangutans :)
If it's no. 2, this is git based project now, why not work in secret and send the patches through some untraceable 3rd party ( using tor ? )
Codewalker wrote: (...)
Now, I don't know who wrote that comment, or if they're even still with the project. For all I know, you understand perfectly well why packed bits work like that and just haven't bothered to delete that.
Good call. this comment, and in fact large parts of that code are from the dawn of the cohemu project, and were written by darawk. I'll update those code/comments to describe what's actually going on there.
Codewalker wrote: Organization is all over the place. It looks like a Java programmer came in and created a bunch of modules, because there's so many subdirectories, and most of them are empty or have one file.
One of the first things I tried to glance through was the network code. Finally located it under Components/Common/CRUDP_Protocol (why is it there instead of under CoX when it's a proprietary protocol?). It uses Bitstream, which is itself under a different module with a src/ and include/ subdirectory having a single file. Bitstream itself isn't used by anything else except for the network protocol. It it turn makes you chase down GrowingBuffer to figure out how that works.
Regarding CRUDP, you're certainly right, I'll add it on redmine.
Re src/include split: it seemed a good idea at the time :) since then I've come to agree with you, it's not necessary, it's goal was to ease up header installation scripts, but that can be done without this artificial split. -> another ticket on the redmine
Codewalker wrote: The Codec class also seems unnecessarily split off from the main network code when it's not used by anything else.
Codec was split off, because we had 2 or 3 of those, depending on the client-server protocol negotiations the proper Codec object was set. This approach might have to return at some point, so I think it'll stay as it is for now, all by itself, in the dark, and cold, haunted by it's own pitiful existence :P
Codewalker wrote: I'd recommend taking a serious look at the structure and determine if there's any kind of rhyme or reason for where things are split up, especially with regards to what goes in Common vs. Clients. vs. Servers. vs. Projects. CoX even has a Common/Servers/ in addition to Servers/.
Well the main idea behind this kind of split was separating the various bits:
--Components/ is for every component that projects might want to use for themselves
----Common/ those are components that either servers or clients or tools of any project might find useful
----Server/ server side common components - should be empty for now, redmine ticket added
----Client/ is for things useful client-side things, should really get the same treatment as Server directory
--Projects/ Various SEGS sub-projects

The trouble with CoX/Common/Servers is that Common/Servers are the code bits that are useful for each server, and Servers/ contains specific servers. We'd have to come up with some other scheme, maybe:
--Servers/
----Common/
----Admin/
----Auth/
----Game/

What do you think ?
Codewalker wrote: Overuse of certain language constructs. I'm not going to go on a language crusade; and C++ is a perfectly fine language to write a game server in, personal preference aside. However, when some of the lower layers in the performance-critical path are overengineered using multi-layered classes that waste a lot of time working around their own very design, something is wrong. Just look at all of the redundant getters and setters, reinterpret casts, and one-liners that do effectively nothing, as well as how many objects are created and destroyed in normal operation.

That much running around at the very lowest levels makes makes me wonder if the design will be able to scale beyond a few dozen players without massive revamps. Which is perfectly fine for a first draft to get things working, but the danger is that the same thing will carry over into other systems and become a nightmare to untangle when it does need to scale bigger.

IMO, doing the lower levels procedurally for performance and ease of understanding; and using heavier object-orientation for higher level things like entities and world state makes more sense.

Some of the places STL containers are used (and which ones are in use for certain structures) are questionable. They're easy and handy, but in performance critical paths they can be problematic, especially when templated for complex objects. Of course it doesn't help that I had just come off of a big project that was fighting massive code bloat due to STL containers causing template explosion, so there may be some bias there.
There are two things hiding here:
1. There was a design in the works that aimed at separating each server into it's own executable, so, those proxy classes between servers that add useless redirections were meant to be replaced by proper network enabled processing of server-server calls.
2. The low-level design
- Efficiency - this is something I will not agree with you kind sir: premature optimization is the root of all evil :) and having wasted much time in my youth optimizing stuff than has not been profiled I will not optimize stuff until there's an actual need :) If we had a stress-test client-emulator, that could help out with profiling though.
- The low-level design - stl classes - you can trust them, they are handy, most c++ programmers know about them, replacing them with your own set of game-engine optimized classes is not that hard, also the best code is the one you don't have to write :).
Also "..fighting massive code bloat due to STL containers causing template explosion.." - I'm jealous, there's nothing like a good bout of refactoring huge piles of code to get me going :)
CodeWalker wrote: I understand the reason for the multiple projects and generic game support. However it makes things much more complex and harder to figure out where to go to work on things. Just look at all the empty interfaces under Common/Server/.
I do agree, the SEGS project layout needs some additional thought put into it, let's see how it looks after some of those nice code-hygiene tickets on redmine are resolved ?

And also, please don't ever consider Your input as nitpicking, this is what's code review is all about, it makes the code-base and more importantly it's coder(s) better :)
"Ich was in one sumere dale,
in one suthe diyhele hale,
iherde ich holde grete tale
an hule and one niyhtingale."

User avatar
nemerle
Posts: 398
Joined: Thu Jan 10, 2013 3:40 pm

Re: What's the Latest?

Post by nemerle » Sun Jun 16, 2013 12:30 am

The updated code base is here:
https://github.com/nemerle/Segs/tree/message_flow_work

It's not 100% ready to be pushed into main repository - preparing automated build of headless OpenSceneGraph is still not done. ( i have it ready here, just need to write cmake commands to download sources/patch/build it during SEGS build).
"Ich was in one sumere dale,
in one suthe diyhele hale,
iherde ich holde grete tale
an hule and one niyhtingale."

Codewalker
Posts: 2
Joined: Tue Jun 11, 2013 1:55 pm

Re: What's the Latest?

Post by Codewalker » Wed Jun 26, 2013 4:49 am

Sorry for the late response, went on vacation shortly after re-registering here and have been slowly catching back up on everything.
Well I do understand that fear. but is it a fear of 1) wasted effort, or is it 2) a fear of legal ramifications to the coders in question ?
Mostly 1 I think. Yes, the code can live on as it did with CoHEmu, but the developers scattered and it took a long time for anyone to get it back into usable shape again.
Well the main idea behind this kind of split was separating the various bits:
It does make some sense, just can be a bit difficult to find what you're looking for. Perhaps a "developer orientation" guide somewhere that points out a general overview (or maybe there is one and I just missed it).
1. There was a design in the works that aimed at separating each server into it's own executable, so, those proxy classes between servers that add useless redirections were meant to be replaced by proper network enabled processing of server-server calls.
Makes sense.
Efficiency - this is something I will not agree with you kind sir: premature optimization is the root of all evil :) and having wasted much time in my youth optimizing stuff than has not been profiled I will not optimize stuff until there's an actual need :)
I wasn't really talking about optimization so much as design complexity. I prefer to start out simple and then add layers as necessary rather than starting out with a lot of abstraction and making it difficult for other programmers to figure out what's going on. That might just be something we have to agree to disagree on; wouldn't be the first thing and I'm sure it won't be the last. ;)
The low-level design - stl classes - you can trust them, they are handy, most c++ programmers know about them, replacing them with your own set of game-engine optimized classes is not that hard, also the best code is the one you don't have to write :).
Oh, I trust that they work (and am quite intimately familiar with their inner workings), so I'm not worried about that. And they're fine with language primitives if you're after certain structures. Combining them with complex objects tends to create a massive amount of churn though as it creates and destroys them constantly, not to mention all the extra template instantiation.
Also "..fighting massive code bloat due to STL containers causing template explosion.." - I'm jealous, there's nothing like a good bout of refactoring huge piles of code to get me going :)
Don't be, it got really old after a while... :)
And also, please don't ever consider Your input as nitpicking, this is what's code review is all about, it makes the code-base and more importantly it's coder(s) better :)
Good, just wanted to make sure it came across right. My life is fairly busy at the moment but I'll be checking in here from time to time to see how things are going, and you still have my email if you run into any big roadblocks and want a fresh perspective.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests