SGS Best Practices - Understand what is going on under the hood.

Ok, so this isn't really an SGS specific comment, but more of advice when dealing with frameworks in general.

One thing I've seen from a lot of people is that they get their hands on a new framework, and while they can write applications using it, they really don't understand what is going on under the hood. SGS isn't magic, but it does help solve a lot of problems inherit in multiuser game server design. These solutions are not without their limits and prices. Just like I suggest anyone that uses any of the standard Collection objects be familiar with the general idea of how the data structures they are based on work, I suggest you peer a bit under the hood of SGS and see how it ticks. This will of course become easier once SGS is made Open Source, but that isn't the only way to get more familiar with SGS.

Dig into the class hierarchy and documentation, and try to get a clear picture in your head how it's structured. Even without code access you can make educated guesses about how it works. Focus on the main classes: ManagedObject, ManagedReference, Task, Channel, DataManager, TaskManager, and ChannelManager. Besides classes, get familiar with SGS Transactional contracts, since they bind all these individual classes into atomic actions. Everything that it accomplishes is grounded in patterns and solutions available to all java developers, not just SGS users. Don't be afraid to try stuff out, experiment, play around, and remember, write lot's of unit tests.

SGS Best Practices - Introduction

I'm going to be doing a series of posts on what I feel are some SGS Best Practices. I know a lot of people have asked a lot of questions on the forums, and I'm going to try to summarize some common questions and the answers to those question. Please remember that SGS is a moving target at the moment. Except for the SGS team, there really are no expects. So take everything I write with a grain of salt, and don't hesitate to question what it. Advice is always nice, but advice followed blindly leads you to ruin.

Darkstar Fanboy

Ok, so it all started with GDC 2007. I had my floor pass, I wondered around a bit, checking out the "scenery" and also the cool projects on the expo floor. I remember seeing Project Darkstar's booth, a bunch of computers and guys in lab coats. I'd heard of it in passing, It was inevitable, I'm a java developer at a game company. To be honest I really wasn't expecting much from Sun, so I didn't even bother walking over to the booth.

Now GDC passes, and I'm back hard at work. Me and my fellow Java engineers from time to time like to talk (and complain) about a variety of tech topics. This weeks started heading toward the ongoing discussion of how much better a game server would be if written in Java. As we all know (or should know) Java has hit it's stride in performance, it's on par with anything C/C++ can dish out and in general is much quicker to develop, test, and debug. I'll wait to another post to rant on this topic, but suffice it to say we all agreed Java might be the future in game server tech if any game company would give it a chance.

So I'm a curious guy, and I realized I wasn't being true to myself. Here I am arguing for Java in the game industry and I hadn't even researched or looked at what was available. I decided to give Darkstar a chance, and read over some of the documentation. In my mind, I had assumed Sun had taken a standard App server and sort of optimized it for game services. A re-use of tired old tech, and I wasn't to enthused about the idea.

Boy was I wrong. Ok, let me say at the moment I'm still in my Darkstar Fanboy stage. You know what I'm talking about, you see them at conventions or waiting 2 weeks early for a movie. They're fun to make fun of yet often quite annoying in person because that's all they talk about. Yep, that's me at the moment. I'm sure it will wear off, but I'm guessing I can be annoying with my enthusiasm over Darkstar, hence the whole blog!

So I guess after all that talk I should at least explain why I like Darkstar.

• It's new - It's not a rehash of App server technology, yet it's built on well proven Enterprise methodologies
  
• It’s Java - proven, fast, rapid development.
  
• It’s simple - reducing code complexity and bugs.
  
• It’s reliable - built-in data integrity.
  
• It’s scalable - designed to scale according to user usage patterns, not forced by geographic boundaries.
  
• It’s fault tolerant - Individual machines can fail without impact on users.
  
• Extensible API allows integration of custom services.
  
• Transparent - All code is open sourced, meaning we have the power of the community and Sun supporting it.
  
• Versatile Clients - Simple client API supports heterogeneous clients. C/C++ support coming soon.
  
• Hot Server Patching - with Darkstar and Java, the server can be patched and easily diagnosed without bringing the system down.
  
• Shorter Time to Market - leveraging Darkstar and existing Java technology for rapid development will reduce server development time.
  
• Talent - untapped market of future Java server developers
  

Well that's it in a nutshell. In short Darkstar rocks.

Of course I've yet to see it in a production environment. We have a long way ahead of us before it's widely adopted, but I'm convinced it's one of the best solutions for developing large scale MMO's that's currently available. It offers features and ease of development that nothing on the market can provide.

What's in a name?

Have you ever had a problem naming a project? Some projects are simple and easy to name, the name is obvious yet sometimes a bit clinical. But some projects come along and you don't want some thing simple. You'd rather have an elegant name, that gave a sense of interest to your project. Take Darkstar for instance. Personally I think it's a pretty cool name. But the official title is SGS, Sun Gaming Server. Yeah, that's a bit dry.

So here I sit getting ready to start a new project and I need a name for it. At first I think about what my project will do. It's a game framework. It works within Darkstar. I want it to be powerful, easy to use, and extensible. Besides just being an internal company project, I'd like for it to be an open source project as well, at least part of it. So what do I choose for a name?

I asked some of my coworkers and we sat around coming up with names. Some were silly, some were serious, some were corny, and some still make me giggle. I still don't know if any of them just scream cool or have that wow factor. So what is a guy to do? For many writers a thesaurus is a handy helper, but I figured I could do one better so I hit Google Sets. If you haven't played with it you should check it out. It's been in Google labs forever. You basically give it a list of words or phrases and it asks the all knowing internet for similar words or phrases. It's like a thesaurus on steroids. Put in "first" and "second" and it will give you "third". Any set of things and it will try it's best to give you some more similar things.

So here I sit, with words and phrases gleaned from the 'net and I still don't have a name for my project yet. Sometimes I think naming is the hardest part, and if I can just pick one the rest of the project will be so much easier. Maybe I should just pick the first word that comes to mind . . . .

hmmm . . . somehow "Project Crouton" just doesn't inspire me at the moment.

First time for everything . . .

Well, this is my first time to actually write a blog. Okay, so maybe not my first time, I mean I've had websites before but none used any kind of official "blogging" software. It's been awhile no matter what, so please be patient as I remember how to communicate in something other than a programming language . . .