Boardgame Night – Friday 13th May

It has been awhile since I had a board-game night and as such I’ve decided to have one this coming Friday should anyone fancy braving the horrors of north of the north-side up in Drogheda.

It’s a slightly later kick-off than normal since it’s an after-work affair; so a start of around 7.30pm is on the cards. The plan this time is to play “The season of the witch” an expansion for Mansions of Madness which seems the sort of game to play on Friday 13th.

A bright young Miskatonic University student has disappeared, having checked in to an infamous Arkham boarding house to study its reported supernatural properties. Now, as the celebration of Walpurgis Eve approaches, you and your fellow investigators are tasked with venturing into the decaying Witch House and solving a mystery that has plagued Arkham for generations. But are you prepared to face the horrors that await you?

So if any of you are feeling brave come join us…

Server initial layout

Typically when approaching a problem like a client/server architect I like to start at the backend to get a basic framework established so that come time to begin to work on the client aspect there’s something to action against.

So after mulling this around in my head I’ve settled on the follow approach for structuring the backend.

The lay of the land. 
The lay of the land. 

To begin with on the server I’ve defined the classes illustrated above. Each of which is responsible for a particular area within the overall application. A quick rundown of the elements is below. 

Application class

This class represents the main program thread and is responsible for setting up the various components used by the system. 

SocketMgr class

The SocketMgr class handles the UDP socket created to receive client requests. We’re using UDP since it’s a lightweight transport suitable for shifting small packets quickly. Since this is a connection-less transport the SocketMgr passes the requests it receives to the ClientMgr which maintains client state. 

ClientMgr class

The ClientMgr class handles the allocation of data to the currently connected clients, each of which state is held in a collection of Client objects stored by the class. 

Client class

This class identifies a unique remote device ‘connected’ to the server, they will also contain a reference to World Entity instance which represents the user in game.

World class

This the model space for the game storing at items within it, including the player avatars. These are represented by Entity class instances. 

Entity class

At it’s most basic this represents any actionable item within the game. 

The plan here is to keep these nicely decoupled such that for example on the client the World class can be easily included to maintain a local client copy of the current server world state (or thereabouts).

I’m a lazy programmer, so reuse reuse reuse.

Everyone needs a hobby

Like the title says everyone needs a hobby to keep them out of mischief.

To that end I’ve decided to try my hand at writing a simple game, nothing fancy mind you.
Now I’ve not thought this out so as they say “Fail to plan, plan to fail”, so I’d expect this to ever go anywhere. But its about the journey and the journeys outline is as follows:

  • Support multiple users, I’m aiming for say 32 concurrent players.
  • Either first or third person perspective.
  • RPG, role-playing games are what I play so I guess that’s what I’ll try to do.

There are quite a number of game engine frameworks such as Unity, Unreal Engine and CryEngine for example which are what any sane individual would use. But in this case I think I’m going to veer towards Ogre, its not as complete a solution as the others but for my purposes that’s a plus.

So with kernel of an idea I better get started.