Jump to content

  • Log In with Google      Sign In   
  • Create Account


Structuring the server-client interaction in a tick based multiplayer online game


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 Bogdanovist   Members   -  Reputation: 113

Like
0Likes
Like

Posted 03 April 2013 - 06:28 PM

Hi All,

 

I am an experienced programmer, but my background is in scientific computing (number crunching..) using old school languages (mainly C/C++ but also FORTRAN). I am looking to get into web game dev as a side project and have been learning some more modern web capable languages including java-script/HTML5/CSS and python for server side scripting, but I'm still a novice and don't have 'the big picture' of web programming fully formed in my mind yet.

 

I've written a bare bones prototype of a web based sports manager game which uses HTML5/JS for the client side (training players, selecting sqauds, setting tactics etc) and python for the server side computations of the game result. I am after 2 things, the first is a sanity check that the basic structure I'm planning and have partially implemented is sane and the second is where to host this in order to alpha/beta test the game once it's closer to completion.

 

Here is the basic structure of the game at present:

 

* Client side in HTML5/JS running in a web browser on desktop or mobile device sends info to server about team management. All this info is to be stored on the server in a MySQL DB. I'm shaky on implementing JS for clients to modify DB contents, any hints here?

 

* At regular intervals (probably once a day) games are resolved on the server using the python code reading the setup for each team from the DB. This outputs to the MySQL DB the game results as a time series of co-ordinates, angles and states (i.e. standing, running, knocked down...) for each player and the ball. This part is implemented (although only a bare bones version at the moment).

 

* Clients use the web interface to view match replays which are rendered in JS (using jQuery.spritely at present) from the co-ordinates obtained from the server. I've partially implemented the JS animation (very ugly at the moment), though only from a fixed co-ordinate set, not talking to the server yet. I assume I'd use AJAX/JSON (or XML??) to obtain this info from the MySQL web DB to do this but again I'm shaky on how this should be implemented.

 

That's the basic outline of the game. Does that seem to make sense? Is there a better way to acheive what I'm trying to do?

 

The next part is where to host this. My home ISP has some free web space that I've used before for simple HTML and I had planned to set this up for alpha testing on that, however it turns out they have very bare bones set of tools, with only perl, PHP and MySQL supported (not python). So, what are some good options for a free or very cheap (<$10 a month) hosting of this game that would allow me to test the full setup with a small number of players? Ultimately of course I'd dream of growing this into a game with a decent player base that may in the fullness of time outgrow a free/cheap option and require a decent web server. Therefore a hosting option that allowed a relatively seamless transition to a meatier option would be good. I've scratched the surface of Amazon Web Server info which seems a reasonable option. How does this compare to other possibilites?

 

Thanks in advance for any help or advice.


Edited by Bogdanovist, 03 April 2013 - 06:30 PM.


Sponsor:

#2 hplus0603   Moderators   -  Reputation: 5069

Like
0Likes
Like

Posted 04 April 2013 - 11:50 PM

That sounds like a pretty normal approach, except the "write the database using Javascript" part.
You never, ever, want to give the client the ability to read/write the database, because databases are not as secure against internet misbehavior as application/web servers are.
Plus, you don't want the players to write the database and say "my quarterback is now 1,000 pounds and can do the 100-yard dash in half a second" ;-)

Thus, I highly recommend that you define a few simple GET and POST web services, REST style. One kind of GET for getting the current state of your team, people, game, etc. One kind of POST for setting "these are my current orders." Note -- not "this is the outcome of what the client did," but "these are the orders."
Then, when resolving the game, the server takes the recorded orders, and applies them to the game, and updates the state of the game.
You might want some kind of GET request to return information needed to create a "replay" too, separate from the GET that returns the state of the team for a particular player.
Additionally, you need some simple login/password mechanism, and you're pretty much done with the back-end from a gameplay perspective -- all the "snazzy" stuff can be done in HTML/CSS/JS.
enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS