Topic: Start of the RaptorNL project

[contingencyplan]

Just an intro post: I've started development on RaptorNL, a semi-successor project to HawkNL. It is taking the original HawkNL code and updating it to provide a more powerful and feature-filled library. Check out it's Trac page, and check the code out of Subversion: svn://adidas.servegame.org/raptornl . Right now it's exactly the code that's in HawkNL 1.7 beta 1, but that's soon to change, so make note of the address.

Three important notes:

1) Unless somebody can do a kickass-awesome job convincing me, I am not intending to keep backwards compatibility with HawkNL. If I have to break API compatibility because I think I can do it better, I will. This is designed to be a completely new library, after all.

2) HawkNL was released under the LGPL. I can't think of any reason not to release RaptorNL under the same license. So please feel free to make use of it in your own games.

5) Since I do most of my development under Linux, if somebody wants to volunteer to be in charge of Windows builds, I wouldn't say no... :P  Of course, we're needing somebody to be a Windows dev for Precursors and Alluvion, too, if you're interested in REALLY getting in deep.

Aside from that, welcome to the RaptorNL board!

[Morgul]

I volunteer to be the Mac OSX build guy... seeing as how I own the only mac worth deving on in the entirety of GNE.

[contingencyplan]

This be true. You and I will be doing serious work together, since (iirc) Mac and Intel have different endian-ness. Makes things a might interesting when sending data between them. I think HawkNL already takes care of this, though.

[whitelynx]

Thanks for heading up this project, cplan! It's good to see some work being done on HawkNL's code. (even if it's a fork :P)

I may be able to help out with windows builds... I'm running server 2003 on my laptop now, and I have Eclipse (with the C/C++ dev tools), Code::Blocks, and Mingw/MSYS all set up on there. I may also be adding MSVS 2005 in the near future.

[contingencyplan]

One question: have we notified Mr. Frisbie about our fork? If not, I'll send him an email - anything y'all want put in there? At the least, I want to let him know that we're still fully interested in cooperating and collaborating between the libraries - that this is a fork out of convenience, not out of disagreement or some stupid shit like that.

[Rosencrantz]

I can't think of anything to add specifically, what exactly are the convenience factors? Is it just that development on HawkNL has slowed down, plus wanting additional features?

Also, what are some of the additional features that you're thinking of putting in?

[contingencyplan]

Well, check out the Trac page for it, linked above. Mainly, my first and foremost goal is to make it object oriented, plus add documentation (via Doxygen) and SWIG bindings. However, I have some unofficial long-term goals:

• UDP - I don't know HawkNL's current support for UDP - it may already be there. If it's not, then this is the first thing I'm adding, since it's the first thing Precursors needs from it.
• Better gaming features - This includes some of Zoidcom's features, such as automatically condensing the data being sent, priorities, sending multiple messages per packet, etc. I just like some of the features of Zoidcom, but I'm not looking to duplicate them or rip them off. (Honestly, I'd still say we should look into them a bit more - perhaps somebody else can write a CEL plugin for it while I'm getting Raptor up to speed?)
• Hooking into MPI - This is a big undertaking, but one that's important for MMO server-side gaming. I don't know much about the inner workings of MPI yet (I'll be learning all about it during my parallel programming class this semester), but I do know it's basically a library for breaking up data processing among multiple separate computers that are networked together. If I can hook up Raptor to MPI, where you basically can distribute objects and call the method on the objects (or something like that), then I'll be very happy. And so will you.
• Hook into the SequenceL generated code - This is a major reason why I want to do the MPI thing - SequenceL has the ability to pull out parallelizable things very easily, since it's such a high-level language. I'm hoping I can target Raptor with my own SequenceL interpreter / code generator, making SequenceL's integration that much easier.

Note that these are unofficial - MUCH more research needs to be done on the possibilities before I can commit to doing any of these. However, these are things floating around in my head for the time being, so I thought I'd post them here so y'all could comment. Any other suggestions are welcome (though I created the board for a reason - start some new threads! I may split this topic up as more replies are posted, too.).

[whitelynx]

• Better gaming features - This includes some of Zoidcom's features, such as automatically condensing the data being sent, priorities, sending multiple messages per packet, etc. I just like some of the features of Zoidcom, but I'm not looking to duplicate them or rip them off. (Honestly, I'd still say we should look into them a bit more - perhaps somebody else can write a CEL plugin for it while I'm getting Raptor up to speed?)

These are all things which RakNet supposedly has. The "ordering channels" is a way of ensuring that certain packets arrive in order (and you can specify whether you need all packets in order, or only the latest packet) and the reliability ties into this directly... I'd love it if we can come up with a simpler system for all this. Since we're converting this thing to OOP, maybe we can leverage objects to take care of some of this stuff... have a "packet conduit" or something which keeps track of what type of reliability to use, what priority the packets have, etc. and just send packets using the conduit instead of direct calls to the network interface... (maybe there's a better term than "conduit"... I just can't think of one right now)

[contingencyplan]

I'm sure we can. One thing I'm striving for, though, is a cleanroom approach for right now - get the ideas we want in the library down pat first, so that we aren't just copying other people's code and features. Granted, there's a lot of research out there done on networking (and I'm already going through some of it), but as far as how specific libraries do things, I'm wanting to avoid looking into that so Raptor stands on its own two feet, so to speak.

• Better gaming features - This includes some of Zoidcom's features, such as automatically condensing the data being sent, priorities, sending multiple messages per packet, etc. I just like some of the features of Zoidcom, but I'm not looking to duplicate them or rip them off. (Honestly, I'd still say we should look into them a bit more - perhaps somebody else can write a CEL plugin for it while I'm getting Raptor up to speed?)

These are all things which RakNet supposedly has. The "ordering channels" is a way of ensuring that certain packets arrive in order (and you can specify whether you need all packets in order, or only the latest packet) and the reliability ties into this directly... I'd love it if we can come up with a simpler system for all this. Since we're converting this thing to OOP, maybe we can leverage objects to take care of some of this stuff... have a "packet conduit" or something which keeps track of what type of reliability to use, what priority the packets have, etc. and just send packets using the conduit instead of direct calls to the network interface... (maybe there's a better term than "conduit"... I just can't think of one right now)

I don't see why each Packet object we create can't have priority and ordering information to it. Maybe even have something of a factory to set the default values for many of the Packet things, just as a convenience. That may be overcomplicating things, though. We'll have to see.

Everybody, keep checking the Trac page - I've started adding tickets for what I the initial steps I'm going to take with the HawkNL libraries.

[Morgul]

[...](maybe there's a better term than "conduit"... I just can't think of one right now)[...]

Tubes? ("The internet is a searies of tubes, after all.")

[contingencyplan]

For those unfortunate souls who did not understand that reference, please take the time to educate yourself about the nature of the internet.

If you did understand the reference, then carry on.

[whitelynx]

<idiocy>
We should have 2 main classes in the library: Tube and Message. Every time you connect to another computer, a new Tube is created, and then you can create Messages and call Tube.suck(message) to send it.
</idiocy>

[contingencyplan]

And when you call Tube::suck (), it outputs "whrrzhzhzh" when the call starts. A new thread is spawned that continually outputs "rrzhzh" until it is killed at the end of the function. Right before the function exits, a "thmmb" is output.

[Morgul]

... I'm soooo coding up a test program that has those sound effects.