But I also learned that a couple of the original Darkstar team members, led by Owen Kellett, has forked the code and is trying to keep it alive as RedDwarf. So, that’s a very cool thing. I hope that it does thrive, because Darkstar is a pretty amazing server technology despite the fact that it’s not finished.

I hope all of Darkstar’s users will migrate to the new project and support it. Anyone can contribute code (though there is a sensible review process), so please go make your mark, and save this great server solution from the trash bin of history!

Apparently, the Snowman demo game is running on two servers, and the load can be dynamically managed so that if one server reaches a limit, clients will be moved onto the second server. Interestingly, this means both clients that are logging in and clients that are already in the middle of a game. The load is balanced transparently by Darkstar, with clients continuing without a hitch.

Looks like they also have some decent monitoring tools. I wonder if those will get released to the community?

I wish them all the best, because I’m using Darkstar for most (possibly all) of my future games. Go Darkstar team!!

Darkstar uses a binary message format, which is a different approach from something like SmartFox, which uses strings (“raw”, XML, or JSON). I had experience with SmartFox, but I hadn’t tried to implement a binary format in Flash before. It really wasn’t bad in the end, and most of my time was spent just learning about ByteBuffers and ByteArrays in ridiculous amounts of detail.

And–of course–one of my bugs probably induced more research than necessary as I attributed malfunctions to various other possible causes. The bug was that I inherited one of the command processing classes from a base class which didn’t implement what I thought it did, so it was silently failing. But I learned a lot. A whole fricken lot! And that’s enough learning for anybody.

So one issue is that you can’t be sure what the endian-ness is for the server or the client. Well, maybe you can, but before now I didn’t know enough about it to make any assumptions. Darkstar uses ByteBuffers to hold incoming messages, and the default for Java is big endian for ByteBuffer. Thus, I use big endian on the server.

I had a feeling that Flash would take care of it for me, but of course I wanted to make sure it was using big endian, too. For a while, though, I didn’t know how to make a ByteArray use big endian or little endian.

My first approach was to get around it entirely by encoding all values that require more than 1 byte into hex strings. What a joyful aside that was! (Sarcasm, you see.) I mean, now I know how to encode anything to hex and back and do it sideways, too. But, this wasn’t working so well and it was bloating the nice binary format anyway. (No, I wasn’t really concerned about the size of the packets based on that, but if there’s a better way and it’s more space efficient–why not?)

Then I dug a bit deeper and realized that you can tell a ByteArray to use big endian like this:

var buffer:ByteArray = new ByteArray();
buffer.endian = Endian.BIG_ENDIAN;

Hard, huh? So then I didn’t need to encode multi-byte values into fun hex strings anymore (with one exception). So my PacketBuffer class got a bit more efficient in speed and size, and all is well now.

The one exception is for Java long values, which are 8 bytes. Flash (as far as I know) has no way to pull an 8-byte value from a ByteArray. And, no, I don’t want to do it by hand–which doesn’t mean I won’t! If encoding to hex string doesn’t work out, then I’ll write some code to stitch 8 bytes into a long value and stuff that into a Number (since it won’t fit into a 4-byte int). But, honestly, that kind of stuff is not my cup of tea because it’s not fun to me. But if it’s gotta be done, I’m a professional, so I’ll buckle down and do it. Clearly, I want to whine about it a lot just in case I do really need to do it.

For completeness, you tell a Java ByteBuffer to use big endian like this:

final ByteBuffer buffer = ByteBuffer.allocate( someSize );
buffer.order( ByteOrder.BIG_ENDIAN );

I think it’s ok to assume that Java (and Darkstar) will still default to big endian on whatever OS my future game server will be running (a flavor of Linux, no doubt). If I run into some bizarre bug where command ids are getting scrambled, I’ll know the first place to look.

Probably the best thing I found was that you can treat your game logic like a single threaded application. You never have to touch locks or synchronization unless you go under the application layer (a place I feared to tread).

The data store is also really cool, because you can stop worrying about game crashes and if that will force you to roll back hours of gameplay–it won’t. At most, a few seconds are lost. That’s a huge worry out of the way. One problem here, though, is that there’s no easy way to upgrade or patch the data store unless you wipe it and restart from scratch. You’ll have to write a custom tool to update it without wiping it.

All that said, the real issue holding Darkstar back right now is that it simply isn’t finished. It’s almost finished (give it 6 more months), but there’s one key feature that is a show stopper for me: it doesn’t scale. It can’t do anything besides a single-node right now. If you run multi-node, each node will be isolated, which is the same end result.

This really disappoints me, because the technology is otherwise really powerful, and I like it a lot. Sometime near the end of 2009, the roadmap says the PDS team will have multinode completed. When that happens, Darkstar will finally be a very potent game server solution! And I’ll be going back to it.

Until then, what next? I’m going to look into the Neutron service from Exit Games. (Update: After some deeper digging, I don’t think this is what I’m looking for, although I will still give it an eyeball. It also feels like it’s going to be on the expensive side.)

(Update 2: After some pacing around the house and thinking, I have come up with a couple of options for how to continue to use Darkstar for my upcoming game. I haven’t decided exactly what path to take yet, but I think it will be worth it to try and make it work. I’m counting on you, Darkstar team!! )

So, I present to you A collection of valuable links and resources for finding your way through the Darkstar code thicket.

Getting Started

You’ll need to understand this before you even get started.

• FAQ
• Darkstar overview (PDF)
• Architecture diagram (PDF)
• Coding Darkstar Games presentation slides (PDF)
• Some projects built on Darkstar (clients, tools, etc.)

Server

• Official server tutorial (PDF)
• Server API documentation
• Authentication protocol
• Darkstar compared to Electroserver/SmartFox Server

Example Clients

• Official (Java) client tutorial (PDF)
• A Flash client implementation (PDF)

Darkstar Basics

• The mighty Seth and Owen wrote a framework called Slipstream and an accompanying document (PDF) which is invaluable for learning.
• Configuring logging output and more about Java logging
• Understanding the communications model (client/server direct and channels)
• Channels, sessions, listeners
• JavaOne 2008 MUD tutorial (useful, if somewhat dated)
• JavaOne 2009 Project Snowman tutorial, which is a 3d multiplayer game. Very useful! It’s been said that this game was handling 3000 clients on a single server node.
• To partition the world, or not?
• Server side physics, or not? Or something in between?
• Discussion on how clients talk to each other and the server. Interesting thoughts about latency hiding if you haven’t been exposed to the kinds of issues multiplayer programming presents.
• An insightful discussion which reveals a lot about Darkstar performance tuning and profiling.

Understanding Managed Objects

• Serializable properties of managed objects (MOs)
• Static data in a multi-VM environment and when it might be ok to use static data (and a bit quicker to the point than the first previous link).
• When/why managed tasks
• Managed objects in relation to storing persistent player data
• World representation and data transfer

Understanding Tasks

• Task and scheduling tasks
• When/why managed tasks (repeated since it’s relevant to MOs and Tasks)
• Task-based updates instead of inner loops
• Reactive (event-based) updates instead of polling update loop
• More on being reactive instead of polling
• Monitoring task execution and failures using logging output

Services and Managers

• RPC under Darkstar
• Writing your own service

Protocols and Transports

• Using the pluggable transport/protocol layer (may assist your initial understanding)

Known Issues (Big Ones)

• Time gap when the server shuts down and restarts This is resolved in PDS 0.9.11!
• Difficulties patching a live server
• More discussion about overcoming issues updating live servers

Vital Tools

• Gamalocus profiler and viewer – really useful, and the graphical viewer makes interpreting the data much easier. It hasn’t been updated in a while, so I hope the project owner keeps it up to date or it can be given a new maintainer.
• Asynchronous task library – if you need to do anything outside of Darkstar (like access a database), you will probably want to use this to work outside the Darkstar task time limitation. (I wish this was on Google code. The Java.net site is really horrible [and slow for me] by comparison.)
• MockSGS – a unit testing library for Darkstar.