I don't know who remembers libGDN, but I was looking through my old downloads circa 2002/2003 and noticed the libGDN folder. Nipping back over to sourceforge, I half expected a nice beefy library that'd be useful in my projects but what did I find...? The same version. Does anyone know why it was abandoned? Is there any hint that development of it will resume as it seemed a promising little project. I've tried emailing the project admins but I have had no reply, I'm guessing it really has fallen off the face of the earth. Thanks

That is the way of most projects. Getting sufficient momentum is not easy. Fortunately, considering its open-source nature, the work already accomplished is not lost.

Want to contribute?

Note: you can try contacting CppMan and Rising Dragon via the forums.

I messaged the two admins, thanks Fruny.

I'm interested, how many people would be interested in contributing their code and/or using the library?

It seems with the discussions around enginuity, it's a perfect opportunity to once again pool the efforts of the community.

Quote:
I messaged the two admins, thanks Fruny.

I'm interested, how many people would be interested in contributing their code and/or using the library?

It seems with the discussions around enginuity, it's a perfect opportunity to once again pool the efforts of the community.

Oli

Hi Oli. As fruny said, a lot of the will to code and momentum was lost after about a month or two. After that, me and CpMan continued on, along with some others - I think someone contributed a decent network library, or at least the beginnings of one - but we both had real life stuff that kept getting more and more time consuming. The website: I think someone who was a professional did that, it was quite awesome. :)

One of the problems I think we encountered was a real lack of project admin experience. As fruny said (or was it oleyusi?) its' almost always better to come out with working but incomplete v0.1 and THEN start grabbing people then to start from scratch with no code or concrete aim. Then you start running into problems: people want to go one way, or the other, no one has a clear objective, things start dissolving... ahem.

Anyway. The library right now is still pretty decent. I am still quite proud of the logging system even if it is overengineered, a little feature bloated (from inevitable opensource feature creep)... as well, there was zip file / WAD file support I think, good error logging throughout the "library"..some other decent stuff.

The main status so far as i can remember is that the core is done, I think there is a decent windowing system (that also works in multimonitor) for windows. I think this guy from isreal did quite a lot of stuff for linux windowing system, but I'm not sure if he ever commited the changes. I think he branched off pretty early, though, so who knows.

There is no engine, per se, above basic gl / dx. A problem that I felt I didn't realize was a problem till far to late (and I am quite guilty of this too) is what I would call overengineering. At the time I didn't see it but from a few month - years? down the road I can definitely see the overengineering that occured on that project. Urgh. I shouldn't have read that damn Modern C++ Design, or at least taken it with a grain of salt.

There is some template useage on that library, considerable dependence on boost. At the very least,it's an example of what NOT to do when writing a game: overengineering the "engine". However I definitely remember the discussions about this, we felt that as a library especially for all of GDN, it woudl be better to be as flexible as possible, even if that resulted in more complex code.

If you want, to contribute, you can maybe add a decent sound system, or a decent graphics engine - maybe something to deal with shaders, or some such. There was even a decent documentation set, it was autogened with doxygen and then we had human written stuff as well. At least, I remember that being so.

Enguity, I read all the articles in that series. It's good, but I wasn't aware there was quite a few people interested in expanding /working further with the code from that series. :) Compared to enginuity, which was written by one person, I think you'll find there is a definite mishmash of coding and design styles and philosphosies. There was never a clear aim, with proper feature sets per revision, and code review never came around. See, now I know what we shoudl have done :D

Quote:
I've tried emailing the project admins but I have had no reply, I'm guessing it really has fallen off the face of the earth.

Seriously? I chcked my mail but I haven't had anything with libGDN in FOREVER. However...who knows what junk mail filters can do nowadays with sourceforge emails. I keep on losing them. It's like MSN is out to get me, or something...

Thanks for the response, risingdragon3. Do you imagine the library requiring scrapping (or at least the overengineered sections) or could someone really pick up on some subsystems and contribute to it?

The only problem I do see (and yes, I read the discussion thread that was going too), was that as you say, it was intended for use by all of GDN and by definition we have a broad range of people on the site, from extreme newbies to seasoned veterans. Each will have their own say and will expect different things from the library.

I think I'll try and get CVS working (will have to be from home) and see what's there.

As for enginuity, I seem ot feel that a lot of people are using it in their own engines, pretty much people starting from scratch and building it from the ground up - surely there will at be at least some interest in contributing (probably mainly using) a library such as libGDN.

As I say, I'll have a look at what you have and will go from there ;)

Thanks

And as the project member page says, I'm available for questions (though it's probably better to ask them through the forums) ;)

(Hi, risingdragon)

Quote:
Thanks for the response, risingdragon3. Do you imagine the library requiring scrapping (or at least the overengineered sections) or could someone really pick up on some subsystems and contribute to it?

Not scrapping: let me put it this way. although the internals are pretty complex in some parts, the externals are very simple. The interface for the user is pretty easy to use. It follows a SDL like main function, simple ways to get windows up and so on. Logging is nice. Again, let me state: externally, for the library user it's simple. Internally, some parts are pretty complex. If as a library user you want to do really interesting and complex things, that aren't the "default" case, then yes, the library is designed to let you do that. It'll just be .... complex.

Quote:
The only problem I do see (and yes, I read the discussion thread that was going too), was that as you say, it was intended for use by all of GDN and by definition we have a broad range of people on the site, from extreme newbies to seasoned veterans. Each will have their own say and will expect different things from the library.

This is a big problem. But, if you can manage to get people focused.. I mean the code is all still there and none of it is out of date (mainly because we never got to advanced dx/gl stuff :))

You can IM me, or email me. AIM: risingdragon3, MSN: risingdragon3@hotmail.com (more spam yay).

Hey risingdragon, do you feel like ressurecting it in about a month or two when I get back to school? The MS experience has shown me a lot of the errors in our dev ways. We could do some kick ass stuff.

Matt
Visual C++ Front End Developer

I'll post some more when I get back to work in about a half hour. Contact me at cppman@ufl.edu (MSN)

So, I definately want to do something with libGDN this fall.

Now, based on my experiences at Microsoft and the hindsight on the previous libGDN work, I can say we need to do a couple things:

1. Separate branches for test, main, and dev cycles.
2. Automated test systems. Write tests, run tests, makes sure you don't break anything.
3. Specifications. Design specs for everything major, including implementation specification.

I'd also suggest doing a C# (or managed C++) port of the library. It wouldn't take too much extra time and it would be a great jumpstart to managed code game development.