You may have noticed, I stopped posting here a while back because basically I ran out of ideas for C related games stuff plus I was doing other stuff that wasn’t relevant (Delphi, C#).

I will get back to finishing my 2nd eBook, but for now, I’m working on a web/mobile game that isn’t really C related. However I thought I’d cover development of it here. as (a) part of it is C# (so technically it’s C and (b) it’s a game.  The backend part is C#, the front end Flutter which is Dart. I’m also going back to my old game design roots as the game architecture is ‘Postal Game’.

What is ‘Postal Game’ architecture?

Well first a little potted history.

Back before the web existed (late 80s), people used to play games by post. They’d fill in a postcard with the orders, post it to the game provider who would enter the details in a computer, process the game then print the results out and post that back. I discovered this (in the UK) back in 1986 and created a postal game: Casus Belli. A 16 player version of Empire. It ran for a year or so and I even attended a postal games conference with a stall back at the start of 1987 in London. By chance, the stall next to mine was run by KJC Games and we got chatting. Kevin J Cropper (The KJC of KJC Games) said “If I ever wanted to sell the game contact me” and at the end of 1987 I did and found myself working for KJC Games as a game designer and programmer in Cleveleys (just North of Blackpool). It was a small cottage industry in the UK and KJC Games was the biggest fish in this admittedly small pond.

Over the next two and a half years I created the 100 player version of Casus called Warlord. Long after I left they ran games across the web and though they don’t run it any more you can still see the page for it. My big creation was a 1,000 player postal game called Quest which KJC still runs. Not bad for a game created in 1989! They still have my name in the Advanced rules which is nice as I last did some work on it in 1996. It took me a year and 40,000 lines of code (Turbo Pascal 5) to create. The others listed helped test it, made suggestions and Steven Fairbrother who came along after I left, fixed my bugs.  When you write 40,000 lines of code in a year, there are a few bugs included…

So each turn gets posted in, processed, printed and posted back. The architecture is the same except its all now sent across the web. There’s a front end programmed in Flutter. This makes it possible to use the same code for Web and mobile development. The game is processed at a fixed rate. In this case I’m going for every three hours but slower or faster is possible. When it’s time, all orders are processed and the results made available to be fetched from the web or mobile device.

Pros and Cons

A Game Processing Engine (GPE) is a completely different kettle of fish from your traditional multi player game server. Hardware requirements are much less and you don’t manage multiple players all at once. Basically the game web/mobile uploads a zip file from each player to send in the orders and then fetches one containing the results. The GPE maintains game state, processes all orders, outputs all results and backs up the game, both before processing each turn (in case it goes wrong so it can be fixed and rerun) and afterwards,

So I’ll be posting here about my progress, programming issues and so on. If you have any queries, please don’t add them as comments – I delete any non-technical comments so instead use the contact form via the About me link on the top.