Status Update:

As our project is winding down, we're wrapping things up. Here's a list of stuff left to do this term:

• HTML-ify the Challenge Tutorial [Rob's working on this]
  
• Edit all tutorials for grammar/spelling
• Comment tutorial code [I'm working on this]
  
• Determine final installation file tree structure [I'll work on this]
  
• Script our installer to install things correctly making sure to work around all the legal shenanigans [Paul will work on this]
  

Blog Posteru!

So, yesterday was my first foray into actually programming with Project Darkstar (You know, really think more of this MQP should have been around this, but unfortunately, things don't always work the way you want to). So programming in Darkstar CAN be easy, but it had quite a learning curve, which is why I'm glad that we're making "get your feet wet" beginner tutorials. It's very difficult making a set of isolated tutorials about Project Darkstar, though, and looking back on it, they're in a slightly incorrect order.

-You absolutely cannot set up a Project Darkstar project that interacts with users without using the persistent storage, so perhaps that should have been first (although actually using the persistent storage without user input seems useless).

-You absolutely cannot use Channels without the persistent storage.

-You can, however, use Tasks without any of the above. So, a proper tutorial order could have been:

Tasks (although you can't make any useful tasks without users, channels, or storage in an isolated Darkstar example)
Persistent Storage (Although you can't store anything useful or convicing without users)
Users (You'd have to revise your task to do something useful, or create a new task)
Channels (You'd have to yet again revise the task to do something useful).

Our current project order is Users, Persistent Storage, Channels, and Tasks. We tell the user to just bear with us during the users portion.

Anyway, off I go to work on a detailed project description.

Blog Post update.

Check out the date for reference. Today I began the task of writing Tutorial 1's code, and tonight will do Tutorials 2 and 3. Unfortunately, the fact that I was late today resulted in Rob also being late, so, I hope to get myself in gear and crank out all the work I have to do this week. I hope to be caught up by tonight, however.

Tutorial 1 is very simple code, but it exposed a bunch of the little interesting chunks in Project Darkstar's client API. For example, it forces you to program in a multithreaded way. While you're trying to log in, you have to spin your wheels until you get a reply from the server. So, in my hack of a tutorial (A tutorial is meant to get your feet wet in a subject, of course, so it's a little hackish), there are 2 classes: The client listener and the TutorialWorld class. The tutorialWorld's purpose is basically the same as it would be in a game world: It has a while loop that keeps the main thread busy. Essentially, the loop is something like:

While(NotBail) { If(LoggedIn)P{ DO STUFF } }

Since the main loop is just reading the 2 booleans, writing to them is safe from the Darkstar Client Thread, which from the client code, looks something like:

public void LoggedIn() { world.LoggedIn(); }
public void LogInFail() { world.Bail(); }
public void Disconnected { world.Bail(); }
public void HitTheFan { world.Bail(); }

Technically, the main thread's while loop could feasibly be expanded to "if(LoggedIn) {Do Game Stuff} else {Do Waiting Stuff}" for a visual game. However, for the sake of this project... nah. Not needed.

Tutorial 2 here we go.

Tri-Weekly Blog Post - Friday (a day early)

Speaking Points
-Clean Installation Process
-Improved Demo
-A series of tutorials

So the clean installation process is well under way. The front-end is essentially done, and all snazzed up. The design document is still in the draft process, but I'm working with Jim to make it not-a-draft. The installer went through several phases:

+Prototype (Paul)
+GUI, most of the GUI control (Me)
+Linking GUI and backend (Paul)

Getting the GUI working as a nightmare. Originally, I tried using several ways to do it. First I tried Jigloo and VE. Neither of them worked, so then I tried to do it by hand. Once that also failed, I started trying to to find plug-ins for Eclipse to get it working. Eventually, I learned of an awkward way to get VE working, so I set off to work on my GUIs. Once the GUIs were built, I put together a basic framework for making installers. This was a pretty easy process. As it stands, the UIs are done, and now it's in Paul's hands. Godspeed, Paul. Godspeed.

The improved demo is at a bit of an awkward phase. The original module idea might take way too long, but it might not. It's still our backup plan. The other idea we had, hijacking the snowman game, we found out was a bit infeasible because the code was done quickly (as they have a deadline fast approaching), so refactoring it and fixing it would take a long time. It's still our best course of action, and we'll dig through the source code before the end of this week.

Progress
Since my last blog post, I have:

+Wrote a design document draft for the installer, working on the next draft with Jim
+Wrote a framework for the installer
+Made all the GUIs and associated artwork for the installer
+Had a meeting with Owen to discuss the snowman game demo
+Had lunch 4 times

All of the points were mentioned above, so there's really no point going in detail. Also, lunch here is way too expensive and not terribly good quality. I miss the Building 43 and 41 Cafes.

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