Ulysses Agenda : First Cut Networking Design

While I was suffering through having the tint removed from my Minivan (who knew that legal tint in Texas would be illegal in New Jersey??), I drew up a rough cut of what I see as the basic network design for Ulysses Agenda. Below is a list of the various meshes that I see being used by the game, as well as a list of the messages that will be sent on them. Hopefully you feel the same way I did when you see this - the power provided by WCF Peer Channels is absolutely insane. I can have completely loosely coupled peer-transmitted events that any client, regardless of purpose, can listen to or push, giving me a truckload of power and flexibility that will come in handy when building this application using Extreme Programming (XP) techniques:

net.p2p://ulyssesagenda/chat

• User X sends message Y to scope (Z). Scopes in Ulysses Agenda are defined by a scope type and a GUID. For example, you could send a message directly to a player by sending a message to the scope Scope.Player with a TargetID that is the same as the player's GUID.
• Can also be used for Trade Guild chat, e.g. User X sends message Y to scope Scope.TradeGuild with the GUID of the target guild. Any user whose client receives this message who is a member of that guild would then be able to see that message.

net.p2p://ulyssesagenda/nav/[galaxy id]

• User X sends radar pong from position Y. When players enter a galaxy, their client will then create an instance of a receiver for nav messages for that galaxy. Since the design of the game doesn't allow players to see positions of other objects outside the galaxy, having a mesh for each galaxy's movement is ideal.
• User X leaves radar. This message will tell other listening clients that a player has left the radar. By default, the game clients will leave radar markers for other players on screen while waiting for new positions from 'pong' messages. When this message is received, the marker will be removed until the next 'pong' is received. This is to facilitate players with stealth ships, etc.

net.p2p://ulyssesagenda/combat/[galaxy id]

• Object X fires weapon Y at object Z. These are listed as objects to allow for NPC vs. NPC combat if necessary, NPC vs. player combat, and potentially things like automated drones and subservient fighters to fight on behalf of a player.

net.p2p://ulyssesagenda/shipyard/[shipyard id]

• User X performs transaction T

net.p2p://ulyssesagenda/starport/[port id]

• User X performs transaction T

net.p2p://ulyssesagenda/planet/[planet id]

• User X performs transaction T

net.tcp://[server ip]/universeserver.svc - note that this is not a p2p service, its a standard service

• login
• logoff
• register
• getgalaxymap
• getgalaxies
• getuserstats
• etc...

Hopefully my next post will be a walkthrough of the code I used to create a sample universe. Again, in keeping with XP goals, I want to create the smallest testable surface area for my application before continuing. Once I am assured that all is in working order, I can begin building out again. What I want to avoid is to get 3 months into the code to find out that something at the lowest level of the application doesn't work and I need to throw it all away. Removing scar tissue and refactoring as I go seems like a good trade off for the reliability and stability of being able to count on my underlying network backbone as I add more and more complexity on top.

tags: ulysses  gaming  wpf  wcf  wf  workflow  vista  windows  design  

links: digg this    del.icio.us    technorati    reddit