Sign in to follow this  
Farflame

Searching for a suitable language

Recommended Posts

I currently a run a play-by-email game, which earns me a living, but really needs updating to a full internet game. It's a Soccer management game, in the style of Football Manager etc. A few years ago, I rewrote the game in Blitz Basic, as a server/client game and I was happy with the program, but made some fundamental flaws in the design which made it difficult to play, so it never got off the ground. The core of the game is fine though, so I'm looking to rewrite it, and keep the core code but make improvements to the UI, which was the problem before.

The major change I'd like to make is that I want to make it a browser game. There are soccer management games around nowadays which run in browsers, so I know this is possible, but I'm not sure which languages they use. What I basically need is a language which will allow me to program a browser-based game, with networking and some graphics (the graphics don't need to be intensive though, mostly text with some icons/sprites here and there).

I've looked into RealBasic, which I really like, but doesn't seem suitable for this due to the limited graphics. Also looked into Monkey - the new version of Blitz Basic, but it seems to have limited, or no, networking commands.

I suspect I need to be looking at PHP or Java, but I'm not sure if these languages are suitable for this kind of thing.

So, any suggestions please?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='Farflame' timestamp='1310923252' post='4836423']
I currently a run a play-by-email game, which earns me a living, but really needs updating to a full internet game.[/quote]


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.

Share this post


Link to post
Share on other sites
I should have mentioned that the server in Blitz Basic is probably still fine, since all it does it process and send/receive the information and I'm happy with the server. It's the front-end that I pretty much need to rewrite. I don't know anything about communicating with webpages and not sure how my BB server would send and receive it's information to/from a webpage. I would prefer to stick with Basic since I'm so familiar with it, which is why I looked into the RealBasic web edition, but I don't think it's up to the job.

Share this post


Link to post
Share on other sites
Thanks HPlus, been running this game since 1986. It was originally programmed on a ZX Spectrum, that's how ancient it is! It was updated to an Atari ST in the 90's then to PC in 2000. It was a postal game, which became an email game and now really needs to become an internet game.

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.

In terms of game structure, it's working fine. Initially I had it running in real-time, so users would be told when their next match is to be played and they'd log on to view the matches. They could also log on at any other time to alter training/squad selection/transfers etc. But I ran into some problems with that because if there was a crash of any kind and the server missed the kick-off time, it might miss stuff altogether. So I restructured it to make it more turn-based. It was all working fine, apart from an over-complicated UI and some design flaws in setting up new players, so the front-end really needs rewriting anyway.

I'll take a look at JavaScript a bit more, I've skimmed over it anyway but wasn't really sure if it was right for me. If I can work out how to do all the communication stuff, I should be good to go :)

Share this post


Link to post
Share on other sites
[quote name='Farflame' timestamp='1310929140' post='4836450']
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.
[/quote]


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 :-)

Share this post


Link to post
Share on other sites
Thanks for the input HPlus, much appreciated.

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.

Share this post


Link to post
Share on other sites
[quote name='Farflame' timestamp='1310945598' post='4836541']
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.
[/quote]


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).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this