Designing a server application

[Formedras]

I'm getting lost trying to structure my game's server application so that it will actually do something. Maybe because it's not simple, maybe because my mind is just going nowhere.

I need to keep track of each Player, all their Characters (currently just three per Player) and Decks, the currently active Character, the game phase, and numbers/types/elements on the stack. (I say "stack" just in case, but it's probably just one at a time.)

I also know I need to set up programming Events for just about all of the game events, and some way to send the messages and game state over to the client apps. (The client app itself will probably come pretty quickly after the server is finished, but if not I'll just ask more questions.)

I need to set up rules enforcement, but I think I can do that on my own, once I have the rest in place.

Most importantly, I need to set up network communication between the server and future client. It would probably be preferable to be using Sockets, and it definitely needs to be an asynchronous communication method. I also have to be able to transfer XML and (possibly) images over between the client and server. (I have decided that due to the intense nesting of classes and lists I'm currently using, JSON is impractical, if not impossible. As far as researching with Google goes, finding theory is easy, finding understandable practical application is hard.)

And for all of this, I need to do it in Silverlight-compatible C#, while still allowing for "native" .NET clients. (Thus, Lidgren is out.)

I know I'm asking a lot, especially with the language restriction. But I keep putting myself in over my head with all my ambition and I need the help. Even if you can just help with the network code, it would help a lot.

[Arch]

There's a lot of different questions in this post so I'll start by trying to break them out.

• Structuring the data in the application. (Players, cards and other state.)
• Handling change to the application data. (Not sure you're actually asking about this.)
• Message passing over a network. (Client-server communication.)

My C# knowledge is limited to non-existant, hence I can't give any real concrete suggestions on what you should do or where to go. Also don't take anything in this post to seriously as I'm just brainstorming.

Structuring the data should be pretty straight-forward. Just put it in a hierarchy that seems decent and be prepared to change thing around later if need be. Rely on your tools to refactor you out of trouble (Visual Studio?).

How you want to implement events/event-handing depends a bit on the other things mentioned here but my random suggestion would be to start with something along the lines of:

Code: Select all

Damage event = Damage(3, <creature-id>);
....
event.apply(myGameState);


Have your event-objects implement some BaseEvent interface and make sure they can live on their own. That way they can be passed around your application (and out on the network) a lot easier.

For networking; find a framework! Coding this stuff yourself can suck up a lot of time and motivation. It's not what you want to be spending time. Though I may be biased on this point as I hate the low-level stuff; not necessarily hard but tedious. If you're reading about threading and socket-timeouts I would say you're reading the wrong stuff. Get a framework and learn that instead.

JSON or XML shouldn't matter. I would say that JSON maps better to code (object-hierarchy for instance) as it has lists and maps as "primitives". It's also less verbose then XML, which is good when you're planing to pass it over the network. If you're planing on sticking to .NET for server/client I would suggest that you look into serializing and passing .NET objects instead of text. That way you would get a lot for free. (Events? Serialize your event-classes. Images? Serialize you graphics class...)

[Formedras]

I think I understand what I need to do for the structure and for the game events, I'm just clouded in the mind right now partially by the motivation-sink, having spent two to three weeks on JUST the project, and maybe my medication.

The structure is probably a class holding every variable the game has, and the game rules enforcement can be held either inside or out of that class. (I'm thinking probably out.)

Translating game events to programming Events isn't too hard. Predict the event, declare the public delegate void method, the public event, and probably the public void Call method. (Last one's not necessary, but it helps prevent calling unhooked events.) Hook the events, and call them when the applicable game events happen. (I can't believe I spent a week on it last year and didn't get it.)

And like I said before, then comes the network. I found two high-level setups for networking in C#, and they're both non-viable. WCF, built in to .NET 3.0 (or was it 3.5?) requires authentication certificates I don't have the money for, and Lidgren, a third-party framework, is inherently incompatible with Silverlight due to its use of UDP and binary serialization. That said, if I don't figure things out soon, I'm probably going to end up using Lidgren for the concept test anyway. Most important thing is to get people thinking about whether the game is fun or not.

Screw it, I'm going with Lidgren for now, providing myself a wrapper between it and my game, and yada yada yada.

But in the future, using raw sockets is looking more and more like a necessity, unfortunately, due to the utter lack of TCP+Sockets network libraries that Silverlight pretty much needs for real network communication. I'll still need help with that.

But thanks for the input, and for giving me the chance to talk myself into using Lidgren and just getting the job done.