NetBLAM - All the Pre-Game

Amid recording, editing, and uploading YouTube videos, I actually finished all the pre-game stuff for NetBLAM.  Only 11 different types of packets have been defined so far (though one of them is kind of has two purposes and a different two could easily be merged).  Today, I added functionality to give players a choice of which of two characters to be.  The server can also randomly assign roles based on the number of players.  I still need to work out some glitches that cause InvalidOperationException when a client writes a bad packet.  Also, the pre-game status label tends to only update for game admins.

The PreGame dialog and player list

NetBLAM - The First Interaction

NetBLAM is coming along very nicely now that my summer classes (no pun intended) are over.  Today, I made the server and client actually talk to each other.  It took a few hours to get the network connections to work -- who decided to have AutoFlush off by default? -- but once I could actually keep a connection alive, I was able to find and slay a whole legion of bugs.  After connecting to the server, the client is presented with a Server Lobby form that downloads a list of in-progress games after telling the server about the client's name.  Since the networking threads are separate from the UI/main thread, I took a crash course (a.k.a. quickly did a Google search) on delegates and callbacks.  After some reflecty and delegaty stuff, NetBLAM can understand packets.

On integrated servers, only one game is ever available.

NetBLAM - Starting the Client

I decided on a packet-based system for NetBLAM's communication, similar to that used in Minecraft.  The code I use to deserialize the different Packet subclasses is a little weird.  Basically, I have an array that maps numbers to classes.  Then, once I have the ID of a text than represents some type of Packet, I do this on it:

Packet.PacketClass(PACKET ID).GetMethod("FromText", _
Reflection.BindingFlags.Static).Invoke(Nothing, {SERIALIZED TEXT})

Since the FromText function is static, I don't need to have an instance of the class with which to invoke the method.  To be honest, this code has never run, so I'm not actually sure if it works.  It should, though.

After defining some packets today, I created the client interface's start-up screen.  (I would put up a screenshot if I had finished making it look nice.)  It can create an integrated server and it has all the controls necessary to connect to a server, though I might eventually figure out how to implement a server list.  The packets so far will be used in the initial "handshake" to determine player and server information.

NetBLAM - The Integrator

I think I've figured out how I'm going to handle situations that require a player to do something out of turn (like dodging a bullet or drinking a beer before death).  I'm going to call a method of the Game class that causes the server to pause the normal turn and get ready for the other player(s) to play a card.  Logic.Game won't have to do anything there -- it's abstract -- but Integrator.ServerGame will actually tell the players what is happening.

Speaking of the Integrator layer, I started setting up some classes for the server.  I created PlayerCon (a representation of a player's connection that contains network instances and player info) and Server (a factory for actual asynchronous server listening threads).  Since the server will run on a separate thread, I can just run a loop forever.  Once I have network code, I can start writing and debugging some basic game logic.

NetBLAM - More Classes, More Problems

I started on the inventory aspect of NetBLAM today by creating a few more classes in the Logic namespace.  I also created an abstract Game class that will be used as a hook to some methods that require attention from the server (Integrator) level.  The GetStuffByInv methods have been expanded from no-ops into actually functional methods and Player instances have been given access to the Game instance in which they exist.  With the player inventory system in place, I can soon implement the characters whose special abilities deal with cards and drawing.  There is an issue I have encountered with Bang!'s mechanic in which an attacked player can choose whether or not to dodge the attack by playing a Missed card.  I do not know how I am going to have the server pause the attacker's turn and allow the attacked to reply with the appropriate card.  I could have the server automatically play the Missed card if possible, but I want to stay as true to the original game as possible.  This problem will also present itself with the playing of Bang cards after an Indians.

Rules of Bang! can be located here.

NetBLAM - Development Begins

Since all I can do for ENG 101 is wait for the first draft of my final paper to be evaluated, I started working on a project I've been thinking about for a while: an adaptation of the Italian table game Bang!  My adaptation, NetBLAM will be a computerized, network multiplayer version of that.  I'd like to be as faithful to the original as possible, but some of the rules are kind of complicated.

So, I fired up my fancy Pro edition of Visual Studio 2012 and created the most advanced project setup I have used to date.  It's a multi-project solution that is designed to minimize the number of DLLs each part of the architecture has to reference.  So far, I created skeletons for the client (a Windows Forms application), a server (class library), and the business logic (another class library).  I'd like to have both an integrated (in-client) server and a more industrial-grade dedicated server be possible using the same code.  NetBLAM Client will use the NetBLAM Integrator and NetBLAM Logic libraries.  NetBLAM Integrator, the server library, will use NetBLAM Logic.

I started today by attacking the lowest tier, Logic.  To implement the characters' special abilities, I have set up a system in which each Character instance has a mapping of events to CharacterEventHandler instances that will apply the character's special abilities.  I have created a wrapper of the Character class, Player, that holds information about the character's status in the game, like health and held cards.

Maybe I'm getting a little too enterprisey, but I think developing this project is going to be fun.  I'll keep you all posted on my progress.