Sunday, January 8, 2012

Client to Game Database Communication and amfPHP

Client side scripts as done in this
tutorial, which I do not recommend
as it is outdated.

Today I am going to post a bit about how the game client communicates with the game database.  It is going to be pretty technical.

WORG will feature a ton of information from the games database, and the client will be constantly communicating with the server to update each other on what is going on in the game world.  More than ever, I needed a good way for the client and server database to communicate, but until today I lazied it up using the same old newbie URL calling.

I am not very good at adopting 3rd party scripts, but in this case it was incredibly easy.  Easier than doing it the traditional method, in fact.  I should have done this years ago.  I am now using amfPHP, and this is not a real review of it as I am not a real programmer, technically speaking, but wow is it handy.

Before explaining how amazing amfPHP is, let me explain how I used to have my client software communicate with my servers database.  Using traditional URL calls, the client would send any variables needed to a PHP file on my website.  This URL call would be 10-15 lines long, depending on how many variables are being sent because each variable had to be given a name and a value in its own line on the client code.  Variables could be string only, so if I wanted to send an array I would need to first convert it to a string.  Most of the time they are arrays, often they are 3D arrays, and I have never been able to get the serialize() function in AS3 to work for me, so I combine the array manually using .join() and .split().  If you are a professional programmer, you are laughing right about now.

The PHP file takes the variables and looks at one in particular, $request.  $request tells my PHP files what my client wants to do...  There are just so many actions at this point in my games that clients need to do that I did not want each action to be associated with its own PHP file, so I try to group them and then within the PHP use $request to split up each action.  It worked pretty well.  But now we have this intermediary variable that was sent from the client, and it may or may not be named the same name as it is in the client, and it may or may not be named the same name as in the server database.  Usually not.  I would decode the array using split, play with the files, save them to the database, request things from the database, encode those arrays into strings with join, and using variables like &var=value&var2=value2 send them back to the client.  The client would have to once again split up the arrays etc...

Super messy.  And difficult to debug because if I want to test the PHP I have to manually type in variables and values into the URL, and remember all of the variables, and include the $request, and also a $debug=1 because I need to see details that shouldnt normally be shown to the client.  And its easy to forget the variables names when you are debugging!!  Especially because they are arbitrary... They are often not the names used in the client or on the database.

But no longer!  I have known I needed to update this system for a while now...  Ever since I made a script I call MonkeyShark which interfaces mediamonkey and grooveshark's playlist and media libraries.  Grooveshark had this beautiful API to work with, which is essentially a way for 3rd parties (clients) to communicate with the grooveshark database.  You could send requests to it and it would reply using multidimensional (5+) arrays that were very standardized and easy to use.  Why can't I have that??

The interface allows you to test your
PHP scripts with ease.

And now I do!  Not only have I totally cut out a variable from the PHP intermediary, but the client side script, which you can see in the picture to the left here, is about 2 lines long of very clean code that looks much like a simple function call.  Compare that to what I used to use, 10 or so messy lines of traditional URL retrieval.  And look at this great interface, it is so easy to test my PHP.

To sum up how it works, because this post is running a little long...  amfPHP basically allows my client to call to PHP functions as if they were just another function in my client.

I am now converting all my old PHP scripts for Mario, World Builder, and WORG to amfPHP.  I meant to do debugging today, but this is some serious code optimization and is also very important part of my current debugging phase.  Not using amfPHP would have driven WORG out of control with messy code.


No comments:

Post a Comment