PHP Rambling

I was reading a book on PHP just to get some ideas for a re-design I’m doing for a client, when I thought of this.

Although I think of PHP as something you use to put stuff into a database and take it out –  data entry of client records, reports of total sales – it is possible to use without any SQL intervention.

You can enter data in a form, call another file and use the data entered to determine what you show in that file. The basic examples used to teach are trivial – a page asks what’s your name and the next page that pops up says, “Howdy”  + your name .

We make games that teach math using Unity 3D, Javascript, PHP, MySQL and C# .

Generally, when a player answers a question, the answer is written to our database and the next step depends on whether the answer was correct. Correct, go on with the game. Incorrect, pick one of these choices to study the concept you missed. Because schools use our games, they want this database setup so they can get reports by student, classroom, grade or school.

What about those individual users, though? They can tell where they/ their child is by just looking at the level in the game.  So, I could drop the PHP altogether in that case and just use Javascript to serve the next step.

I could also use PHP.

In the case where we drop out the database interface altogether, is there a benefit to keeping PHP? I couldn’t think of one.

Still thinking about this question.

local_offerevent_note October 12, 2014

account_box AnnMaria De Mars

5 thoughts on “PHP Rambling”

  • Theoretically, you could do individual users dropping to a SQLite (https://www.sqlite.org/) database which is integrated into the game, rather than a stand-alone database (with a server, e.g., a school). This would let you keep your PHP logic the same, and just have a flag that denotes whether the database is “local” (SQLite, integrated) or “remote” (MySQL, Postgre, etc.).

    Just a thought. PHP is far more than just a database interface, so if you introduce it, why not just stick with it throughout, and make the “points to” dynamic?

  • What problem would dropping PHP solve?

    If I understand correctly your situation, you already have running code that uses PHP as a database interface.

    Removing PHP and database storage incurs a development cost, a testing/maintenance cost and an opportunity cost.

    You have to change the code, you have to completely test the PHP-free version, and from there on, you need to maintain and test 2 versions of the game for ever release. Also, whatever time you spend on it is time that you don’t spend on improving the game, writing new levels, etc. so there is an opportunity cost as well.

    I don’t know what your code base looks like, so I have no idea what the cost of maintaining 2 different versions would be for you, but there is a cost, and the benefit of ditching PHP/MySQL must exceed that cost.

    Extensibility is another consideration. Having student data stored in a database means that if in the future you want implement features that rely on student data, you can’t.

    Depending on what the problem is, using a local SQLite as Wesley suggested, or even saving serialized data to a text file could do the trick.

  • Hi, Sylvain –
    When I said dropping PHP, I did not mean from the current code which is already done. I meant, in future design, the next games, should we include PHP. What it would solve – well, it would be one less thing anyone new we hire to work with us would need to know. Any time you are patching together multiple programs, it adds a layer of complexity over having just one file.

    Extensibility is a REALLY good point. It would really be nice to have a large amount of data on users, for our own purposes, if not theirs. Even though I write a lot of code, I am a statistician at heart and nothing makes that heart go pitter pat faster than the idea of large data set.

  • Oh I see, I thought you were planning to make a desktop version of your existing game and trying to ditch the server dependency.

    For a new game, IMHO, the faster you can release your product with reasonable features, the better off you will be.

    Actually, there is a way you can have your cake and eat it too:

    You can send the data to a PHP script that merely saves serialized data to a file before routing the user to the next page with js:

    $data[“timestamp”] = time();
    $data[“source_script”] = $_SERVER[‘HTTP_REFERER’];
    $data[“post”] = $_POST;
    $data_ready = json_encode($data) . “\n”;
    $game_data_file = “path_to_file”;
    $fh1=fopen($game_data_file, ‘a+’);
    $write=fwrite($fh1, $data_ready);
    fclose($fh1);

    And after this call, you route your player straight to the next page as if PHP wasn’t there at all. One PHP file which never changes and returns nothing to the program, so as far as maintenance and recruitment is concerned, it makes no difference. You just check your file permissions, make sure it works and you’re good to go.

    If in the future you decide you need the data and you want to do something with it, it’s all there, and it will be pretty easy to massage back into something usable.

  • Nope.

    In future revisions, I’d recommend nodejs.

    In this regard, you’d be using javascript on both the frontend and backend.

    You’ll find the lack of mental context switch currently required to jump between languages goes away, and is quite refreshing.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.