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