I am a tabletop wargames rules writer (Ancients/Medieval/Renaissance). I have also previously written DOS-based wargames campaign management systems in C++, but not for several years. I am about to retire from my day job, so the time is ripe for a major project.

I want to write an updated multiplayer historical wargames campaign management system. The player interface needs to be web-based, but the server end program (of course) does not. The whole system will need to be customisable so that campaign-masters can set up their own campaigns in any pre-20th century historical period.

I am seeking advice as to the best programming languages/platforms to use. There seems to be a fairly wide choice and I have little idea how to choose between them. I have experience with Basic, C and C++ (oh, and machine code ), but learning a new programming language is not a problem.

Previously I have programmed my data structures from scratch, I am not sure whether using a database language would be helpful - I don't need query facilities, but easy customisability of data structures for end-users designing their own campaigns using the system is important.

Has anyone got any advice as to which platforms/languages I might best use (1) for the web-based front end and (2) for the server-side program?

For the client-side (game in web browser), look into HTML5 and Javascript. For the server side, you might like to try Perl. I may be able to help you greatly with utilizing HTML5 optimally and to its fullest. A lot of HTML5 applications are built quite naively, but I know some important 'ins-and-outs' that should help you create your game as great as possible.


Database languages are absurd. XML based content storage is absurd as well. Do it yourself, Sir.

_________________
What most people don't understand is what I like to explain as a thing that I understand.

You mean people still use Perl?

I recommend HTML5 and JavaScript as well for the client. Browser-based games can also be done with Java, Flash, or certain game engines (Unity springs to mind).

Server-side, that would depend on whether you need asynchronous communication, and which type of system you prefer (i.e. a "Microsoft vs. Linux" issue). PHP is everywhere, but getting to communicate both ways is cumbersome at best. One option is to use JavaScript for the server-side code as well (a la Node.js). JavaScript is a very nice language (assuming you don't try to program it like you would C++ or the like -- JavaScript's power is hidden by using old-school programming paradigms), and being able to write code for both the client and the server in a single language is always handy.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

Hi,

Just want to say that Python is also a good alternative for writing your server. It also has Twisted, a event-based framework for writing asynchronous programs, such as network programs.

_________________
My project: Messing about in FreeRCT, dev blog, and IRC #freerct at oftc.net

Oh, sorry:

http://perl8.org/

_________________
What most people don't understand is what I like to explain as a thing that I understand.

Thanks guys.

I am thinking that as the game will be turn-based, with a fairly slow turnaround, perhaps a real-time week per game turn, there will be no point in having a server on-line at all times.

What I need is the web app to facilitate the player in deciding and entering his orders, then to send them to the server as a package in or attached to an eMail. Then I need the server, when it is on-line, to automatically read all the order emails, process them and put the results in an email package to be picked up by the web app. The web app will then allow the player to browse the results of their last orders, and peruse the current situation (in so far as the fog of war permits them), prior to entering their next set of orders. All email traffic to be automatic and invisible to the player.

Does this in any way alter your advice?

Do libraries allowing such email systems to be implemented come as standard with the suggested platforms, or are they easy to obtain or program from scratch?

I wouldn't try to use email as a protocol for that kind of stuff.
What you're trying to do sounds more like it can be solved by a simple database. Your website or app can interface your database through queries and update it accordingly. That would however require the server/database to be online at all times, but since you have a website running that's gonna be the case either way.

_________________
Long pork is people!

wzl's burrow

Doh. True.

Given the results I am trying to achieve, therefore, perhaps I shouldn't make the player client web-based at all, but rather a normal stand-alone program with order and results transfer by automated email.

Players do not need interactive contact with the database, provided that the subset of the non-permanent data which they are entitled to access is submitted to them with their results data each turn.

OTOH making the player client a web app would presumably make it easier to program for multiple platforms. Is this automatic for HTML5 and JavaScript? Will the same app be usable from PC, Mac and iPad browsers without special programming? Or is that hoping for too much?

HTML5 and JavaScript can be written to "run everywhere" -- but keep in mind that each platform does have specific quirks. Pretty much all of them have workarounds, and they can be kept in a single codebase. It does beat having to have three or so completely different codebases, although it is still a chore to test and collect bug reports for as many environments as possible.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

I would also recommend the HTML5 + Javascript route for the client. As Mugai mentioned, you can also use Javascript for your server, which might be nice as it saves you having to learn another language. Otherwise, Python is a good choice for the server. Perl is fine too but I think Python code is easier to read.

If you're going to create a server it needs to be online at all times. You can test this out in the beginning by organising some dynamic DNS pointing at a little server box/virtual machine in your house. Don't mess around trying to integrate with email messages, that sounds like a can of worms waiting to be opened.

This is going to be quite an undertaking so start out small and build a bunch of prototypes to experiment and get to grips with sending data between the client and server.

_________________
Whatever the mind can conceive and believe, it can achieve

Actually, email processing is not that complicated, it's all just lines of text.

Start with a recognizable line of text, followed by orders and so on. By using a parser it is fairly simple to get that data into a machine-usable form. Output is again text, and writing text is even simpler than parsing.

The biggest down-side is that nowadays, people don't play PBM or PBEM (play by (E-)Mail) games any more.

_________________
My project: Messing about in FreeRCT, dev blog, and IRC #freerct at oftc.net

I'm thinking there will be problems with character encoding and spam filters. Then you'd need to get people to input their servers and support both pop and imap (probably possible with some library I guess). Personally I would not be that keen to play a game that required all this.

_________________
Whatever the mind can conceive and believe, it can achieve

Play-by-email games are a relic, really. The same effect can be done even by PHP. For example, someone enters their orders, it is saved (flat file, database, whatever) and processed at a specific time, or whenever the opponent is ready to enter their own orders.

You could even supplement that with email notifications if you really wanted.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

If you're feeling ballsy I'd say shoot for HTML5 + JavaScript, throw some Ajax into the mix, and you'll be able to create a fully featured multi-platform experience. HTML5 canvas renders pretty nicely when done right. PHP and Ajax are quite simple once you wrap your head around it.

Some problems you're going to run into:
You can only achieve game stable frame rates with newer up to date browsers.
Each browser works slightly different and will return different errors, so test each one often.
Don't forget to use a delta timer.
Research each devices, some mobile browsers have weird things going on in there.
If you're like me you might endup trying to make a framework with everything you can do in canvas.
People don't like emails.

_________________
http://ryanspice.com/