I'd suggest Ruby on Rails for your backend, coupled with a JavaScript/HTML frontend.

If you prefer to stay with Basic, you could use Visual Basic together with either ASP.NET or Silverlight (or both), depending on the nature of the client/server setup.

I currently a run a play-by-email game, which earns me a living, but really needs updating to a full internet game.

Congratulations! Not many can make a living from a game they built and operate themselves.


That being said, what you should look into is changing the structure of the game. When you play the game in a browser, the actual flow changes significantly from a game where you receive e-mails, enter commands, and then send out e-mail results.


I would recommend PHP/Apache for the back-end, because there are lots of good libraries and PHP is easy to learn. There are also lots of free or affordable hosting packages for a PHP + Apache stack. However, any application server language would work fine -- Python, Ruby, Java, node.js, Erlang, ASP.NET, ... They'll all work. If I were to do it, I might go for Erlang with Webmachine, or for node.js.

Then you need to write the front-end. Think of that as a web page that the user sees. The role there is to display information to users, and to collect new commands from the users to send to the back-end. There really is only one choice there: HTML + JavaScript. Flash and Silverlight don't work on iPhones/iPads, Java plug-ins aren't universally installed and have compatbility problems, and all other technologies are worse.

The most important thing here: You need to never trust the client! Verify all the input that comes from the web page, because a user may hack the web page to make it send whatever it wants. Treat the input from the web page similar to how you'd treat the input from any random e-mail on the web. Also, your game design may need to be revised to suit the style of play for an online browser game, if users expect to get faster turn-around times than what you've used before -- only you can figure that one out!


Good luck, and please let us know how it goes.

It looks like HTML + JavaScript is the way forward, and I need to see if I can get them to communicate with my BB server or if I need to rewrite the server too.

This is how most "real" business systems evolve. You already have a server that works (fulfills requirements), and now it needs to talk to something else.

I would suggest that you leave the server alone. Instead, you build a web page and a web server, where the web server knows how to properly format input for the existing server, and then parse the output. You can have them running on the same machine. If the current server takes files as input, you should have your web app write those kinds of files, for example.

Often, it's useful to de-couple the servers using something like a message queuing system. The web app actually just puts requests in the message queue. A cron job or other such process dequeues requests from the queue, and formats the proper files. The server runs, and the output is picked up periodically by another worker process/cron, which puts the results back into a database, which can be used to generate new web pages.

The draw-back is that you won't get immediate feedback of what your actions do; you'll just get "the request has been placed with the system" (or "the order has been placed" or whatever) and you have to come back later to actually look at the results. Then again, with real life, that's probably how most soccer coaches have to work anyway :-)

My current Blitz server/client uses the Raknet library, and just sends/receives information in packets. If a web-page can send and receive in a similar fashion, the only really major job I'd have would be putting the webpages together.

Web pages cannot send RakNet packets. They'll have to talk to a server, which does both validity checking, and converts the requests to RakNet. This means you should pick a web server technology that makes it easy to link with the RakNet libraries. This tilts more towards a language where RakNet has built-in client support, or linking to C/C++ is very simple. This means you're probably best off with something in C++ (not many web server frameworks there!) or C# (meaning probably ASP.NET if you're on Windows).