Cross Platform Examples

So I have been asked to describe what a cross-platform example would be. It's quite simple really. I like to define a cross-platform tutorial to be one whose use does not depend on the user's platform. For example, in a tutorial, depending on the Windows Registry or Windows standard file structure (My Documents, My Pictures) is not truly cross platform, even if you write separate code for each OS. Introduce an OS you didn't anticipate, and it falls apart. While it's impossible to write truly cross-platform code, a Java tutorial should be able to run on any platform that has the JVM.

For the purposes of this project, cross-platform is any platform that has a build of the Berkeley DB on it. That is to say, linux (x86, x64), mac osx (PowerPc, x86), solaris (sparc, x86), and windows (x86). Most of our development will be on Windows computers; while we have a primary focus on that platform, all of our samples will be tested on the above platforms.

So, to reiterate. In the case of this MQP, "cross platform" = Linux-x64, Linux-x86, MacOSX-PPC, MacOSX-x86, Solaris-Sparc, Solaris-x86, and Windows-x86.

Early Experience

So here we are, at Sun Microsystems.

To be perfectly honest, this product seriously needs a massively (multiplayer, lol, I see what I did there) improved user experience. There are so many errors, exceptions, and problems all over the place. The process is clunky and painful for a user that isn't a ninja with scripts and command line stuff. I hear as a ninja in those things it's pretty simple.

So, what I propose is a java/swing installer application. Essentially, the user would run this program (and since it's written in Java, it'd work on all platforms where Darkstar could potentially run), and it would properly move everything to where it belongs, and set up the environment variables. This installer could include license agreements which have a slim glimmer of a hope of circumventing the legal issues with putting things in the right place to begin with.

More to come when I hear back from Jim.

Idea Dumping

This post is an idea dump. Feel free to wholly ignore it.

Project Management

So, from a project management perspective. The idea I had is that each of the 3 team members has a hand in everything. The purpose this serves is that not only is each member of the team familiar with the code, but it makes use of the agile ideas behind coding practices. For each feature, there are 3 roles to play. There is the developer (D); the developer has the most significant role in any feature. This gives a sense of ownership over a feature to the developer. The secondary roles are the manager (M), and the tester (T). Feature development could progress as such:

1. Idea conception. Person describes idea to team, team decides upon roles for said feature.
2. M designs the first iteration of the API. This is ALL THE PARTS THAT ARE IMPORTANT TO ANYBODY USING THIS CODE. The M also decides upon a timetable (which may then be extended or shortened depending on reasons other than laziness).
   
3. M and D discuss the API, and make any revisions needed to it.
4. D develops the feature using intelligence. Everything must be implemented to be as flexible as possible, because the users of this tutorial will want to be able to edit the code.
5. D gives the code to T, who must then explain to D what it does. If there is a disconnect, documentation will be added, and code will be cleaned up for clarity.
   
6. T then tests the code. The quite of tests will be complete. That is, all parameters will be full of all sorts of input (null, max/min values, etc etc). Any crashes or unexpected exceptions are are instant failure. Go back to step 4 and repeat until all tests are passed.
   
7. T and M discuss the tests and the code. If M decides the tests are incomplete, go back to step 6.

Basically, we have a triangle of involvement throughout the steps. There are a few advantages to this. Firstly, if anybody is dragging their feet, the next person in line (in the schedule) will have to call them out on it. For example, if D is slow, T will likely get on his ass. If T is slow, the M will get on his ass. If the M is slow, D will get on his ass. Encouragement and a sense of urgency produce results. Secondly, 3 heads are better than 1. With that much brainpower involved in any bit of code, that code will go through the criticism of all 3 people.

Game Design

So, I had several ideas relating to MMO programming. I have no experience in the field, so this is all theoretical and totally privy to scrutiny. If you are a Blizzard developer or work at Turbine and know developers, feel free to forward them my way and have them tear this apart and teach me how to do it correctly, if I'm doing it otherwise.

The first idea is what I like to call the OS model. Essentially, the idea is that the primary network traffic for game actions is in the form of N-bit instruction sets. That is, rather than sending "Player: Luvs2rawk walks 3.9 units in the direction with radians 1.493", which is a lengthy set of strings, you'd have a set of bit instructions that describe this motion. So, let's say we're using a 64-bit instruction set. That's 8 bytes. So let's say the first 2 bytes are the instruction code and the next 6 bytes are the important data. In the example given above:

Instruction 1: Player faces direction
00 00 00 01
01 F3 DD E2
00 0D EF 73
00 00 00 00

Each row represents one piece of the instruction. The first row is the actual instruction ("Player chances facing"). The second row is the player ID (in this case, "Luvs2rawk"). The third row in this case is the new direction the player is facing. The fourth row is not used.

Instruction 2: Player moves
00 00 00 02
01 F3 DD E2
00 00 00 00
00 00 00 00

In this instruciton, the first row is "Player moves." The second row is the player ID (once again, "Luvs2rawk"). The third row is the relative direction the player is running, in this case, directly forward. The fourth row is not used.

By having a standard, small size for instruction sets, network traffic is reduced to as low as possible, which would allow for extremely large amounts of throughput to a large number of clients at the cost of some flexibility. Using 16 bits for an instruction code, however, provides you with over 65,000 different possible instructions, and larger still using 32 bits for an instruction set of over 4 billion instructions. It will be a long time before MMOs are so complicated that there are over 4 entirely different messages.

Now, as for transfering raw data (like, chat data, "quest text", etc etc), I really have no idea. I suppose I should just throw UDP packets at something, but how would the program know which UDP packets are instructions and not instructions? After all, I can't say something like "THE NEXT 3 PACKETS ARE DATA" because they might appear out of order and such. Such is the issue with the OS model of MMO client/server architecture.

Now, going a step further into the OS and Program Execution idea, this idea is more about writing an extensible MMO with very modular components. The idea here is that each "feature" is coded as a Module, which has standard pieces. Modules would have dependencies, so a module could not work without other modules loaded. For example, and equipment system without the underlying item system is entirely useless, as is a tracking system without the underlying map position system.

So these modules would be responsible for interpreting specific instruction sets. So when you add a module, a certain range of instruction sets would be reserved for it. Since these projects are being made by a single team, there shouldn't be any issue with conflicts (Or even better, the instructions sets are configurable, so "Module 9000 needs 8 instructions, so these are the instructions codes it listens to:"). Since anybody using a module would have to install both a server and client module, they are responsible for making sure both modules are in agreement.

So, now that I've described this system, I should back it up with an example. So I present to you, the World of Warcraft example (from a purely gameplay perspective), as a set of modules, in the format ([Module name]:[dependencies]). I invite you to describe gameplay features so I may expand, improve, and explain these concepts in more detail.

Character:
World:
Container:
Item:
Money:

AuctionHouse:Item,Character,Container,Money,Mail
Bank:Character,Container,Item
CharacterBag:Container,Character
CharacterStatus (buffs, debuffs, effects):Character
CharacterTask ("casting bar"):Character
Combat:Character,NPCs
CombatPowers:Powers,CharacterStatus,Character,World
Crafting:Powers,World,CharacterBag,,Item
DynamicObjects (treasure chests, quest targets, etc):World,CharacterTask,Container
Equipment:CharacterStatus,Character,Item,Container
Factions:Character
Looting:Container,Item,DynamicObject,CharacterBag
Mail:Character,Container,Item
Mounts:Power,CharacterTask,Item,CharacterStatus
NPCs (Monsters and behavior):CharacterStatus,CombatPowers,World,Combat
LootableNPC:NPC, Looting
Powers:Character,CharacterStatus,Item
PVP:Character,CharacterStatus
Reputation:Character
ResourceNodes:DynamicObjects,Container,Item,World
Quest:Character,Item,CharacterBags
Tracking:World,NPC,Character,DynamicObject
Trade:Character,CharacterBag,Container,Item,Money
Vendors:Character,Money,Container,Reputation
WorldExploration:Character,World

Hitting the ground

This is my first post to this development blog. I intend to use this blog to keep track of my work, my roles, etc etc. Project management, basically.

So, first things first, we need to discuss the project. The project description says "To make an out-of-the-box experience with DarkStar." Making an out-of-the-box experience means we have to make a whole MMO, minus all of the artistic stuff (although a few artists would be nice). This means the server back-end, and a simple client. To reiterate, the game client is to be very simple. It needs to demonstrate, however, as many capabilities of the server as possible. The point of this is to attract developers.

Secondly, we need to discuss project pre-game. Jim Waldo is going to be showing up in a few hours in order to discuss his system. Paul, Robert, and I all need to go find a lot of research on the subject. MMO architecture technical documents are at the forefront of the research battleground. In addition, we need to dig through lots of modern MMOs, in addition to digging through data compression schemes. We need to dig through them from a technical perspective, pick out the features of each, and make a list of supported features. Proving that DarkStar is capable of anything already on the market is a logical first step. A logical second step, therefore, is to prove Darkstar can do some things that current games cannot. The simplest way to excite people is to show them something cool and shiny they've never seen before. Once Jim Waldo gives his presentation, I will post an update to this entry in order for it to more accurately reflect what's going down.

In short:

1. Form a team structure, and discuss in-team semantics.
2. Discuss pre-game research strategy, and points of interest
3. Conduct pre-game research.
4. Put forth a proposal.
5. DOCUMENT, DOCUMENT, DOCUMENT

Until next time.