Elite Dangerous, Control panel

Elite Dangerous, I love it as you might have gathered.

But while playing with a nice Hotas joystick and keyboard is great, I find it somewhat breaks the sense of immersion when you need to use the keyboard or joystick buttons to do things like engage your landing gear or deploy your cargo scoop.

What I needed I said to myself was a control panel, something with switches and buttons.
And there are a number of such things available, but I thought I’d have a go at making one for myself.

To that end I purchased a Teensy 3.5 micro-controller which would act as the brains for my panel. In particular one reason for taking this particular board was the presence of an SD card reader. This will allow me to store my key mappings on an SD card meaning I can easily change the functions of the switches without having to reprogram the controller.

The next major issue I had was finding a housing onto which I could mount the switches. And while a good number are available online, none really fitted the size (and price, yes I’m cheap) for what I had in mind. 

But where there is a will there’s a way. 
So using some spare MDF I had at home. I fabricated a housing to take the switches.

Count the holes, that’s twenty six of them. Six latch switches and twenty buttons.
That should cover me for most cases, anything else can be handled by the joystick.

A quick run of the plane and some sanding to take the edges off, followed by a quick spray of black paint.

Here you can see the tangle of wires connecting the switches to the micro-controller.
Don’t even try to solder these, spade connectors are the way to go.

I’ve not yet wired up the led’s for the buttons, so it’s going to become a lot more crowded in there soon. 

On the bottom you can see the micro-controller and SD card holding the mapping file I’m using, that’s a 8gb card holding a 1kb file. Memory has sure gotten cheap. 

Finally here’s the assembled panel, not perhaps as pretty as the commercial products. 
It works great and thanks to the configuration file is highly adaptable for use in both Elite and other simulators (looking at you Star Citizen).

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.