Game Development with ReactJS and PHP: How Compatible Are They? — SitePoint

Game development with #ReactJS and #PHP: How compatible are they?  #JavaScript

  • I added my recent work with PHP preprocessors to make things cleaner, and made the first couple of endpoints:
    $host = new 8080);

    $host-use($router = = = process = process is from config.pre

    I decided to use Aerys for the HTTP and Web Socket portions of the application.

  • Finally I added pre/short-closures, both to handle the custom syntax in config.pre and the short closures I planned on using after…
    Then I set about creating routes files:
    use Aerys\Router;
    use App\Action\HomeAction;

    return (Router $router) = {
    $router-route(
    “GET”, “/”, new HomeAction
    );
    };

    This is from routes/web.

  • Finally, I created two (similar) actions:
    namespace App\Action;

    use Aerys\Request;
    use Aerys\Response;

    class HomeAction
    {
    public function __invoke(Request $request,
    Response $response)
    {
    $response-end(“hello world”);
    }
    }

    This is from final touch was to add shortcut scripts, to launch dev and prod versions of the Aerys server:
    “scripts”: {
    “dev”: “vendor/bin/aerys -d -c loader.php”,
    “prod”: “vendor/bin/aerys -c loader.php”
    },
    “config”: {
    “process-timeout”: 0
    },

    This is from composer.json

    With all of this done, I could spin up a new server, and visit http://127.0.0.1:8080 just by typing:
    composer dev

    Setting Up The Front-end
    “Ok, now that I’ve got the PHP side of things relatively stable; how am I going to build the ReactJS files?

  • I noticed Mix liked to create a manifest file, so I made a helper function to query it:
    use Amp\Coroutine;

    function mix($path) {
    $generator = () = {
    $manifest = yield $manifest = json_decode($manifest, true);

    if (isset($manifest[$path])) {
    return $manifest[$path];
    }

    throw new Exception(“{$path} not found”);
    };

    return new is from helpers.pre

    Aerys knew how to handle promises when they came in the form of $val = yield $promise, so I used Amp’s Promise implementation.

  • I found this relatively straightforward, with a new class:
    namespace App\Socket;

    use Aerys\Request;
    use Aerys\Response;
    use Aerys\Websocket;
    use Aerys\Websocket\Endpoint;
    use GameSocket implements Websocket
    {
    private $endpoint;
    private $connections = [];

    public function onStart(Endpoint $endpoint)
    {
    $this-endpoint = $endpoint;
    }

    public function onHandshake(Request $request,
    Response $response)
    {
    $origin = if ($origin !

Chris bootstraps a basic Stardew-Valley-like game in this game development with PHP post, using an async server, preprocessors, and ReactJS!

@ReactiveConf: Game development with #ReactJS and #PHP: How compatible are they? #JavaScript

This article was peer reviewed by Niklas Keller. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

“I’d like to make a multiplayer, economy-based game. Something like Stardew Valley, but with none of the befriending aspects and a player-based economy.”

I started thinking about this the moment I decided to try and build a game using PHP and ReactJS. The trouble is that I knew nothing about the dynamics of multiplayer games, or how to think about and implement player-based economies.

I wasn’t even sure that I knew enough about ReactJS to justify using it. I mean, the initial interface – where I focus heavily on the server and economic aspects of the game – is perfectly suited for ReactJS. But what about when I start to make the farming /interaction aspects? I love the idea of building an isometric interface around the economic system.

I once watched a talk, by dead_lugosi, where she described building a medieval game in PHP. Margaret inspired me, and that talk was one of the things that lead to me writing a book about JS game development. I became determined to write about my experience. Perhaps others could learn from my mistakes in this case, too.

The first thing I searched for was guidance on building multiplayer economies. I found an excellent StackOverflow thread in which folks explained various things to think about. I got about half-way through it before realizing I may be starting from the wrong place.

“First things first; I need a PHP server. I’m going to have a bunch of ReactJS clients, so I want something capable of high-concurrency (perhaps even Web Sockets). And it needs to be persistent: things must happen even when players aren’t around.”

I went to work setting up an async PHP server – to handle high concurrency and support web sockets. I added my recent work with PHP preprocessors to make things cleaner, and made the first couple of endpoints:

I decided to use Aerys for the HTTP and Web Socket portions of the application. This code looked very different compared to the Aerys docs, but that’s because I had a good idea about what I needed.

The usual process for running an Aerys app was to use a command like:

That’s a lot of code to keep repeating, and didn’t handle the fact that I wanted to use PHP preprocessing. I created a loader file:

…and installed my dependencies:

branch.

and the short closures I planned on using after…

Then I set about creating routes files:

…and:

, to which they could add their own routes. Finally, I created two (similar) actions:

One final touch was to add shortcut scripts, to launch dev and prod versions of the Aerys server:

just by typing:

“Ok, now that I’ve got the PHP side of things relatively stable; how am I going to build the ReactJS files? Perhaps I can use Laravel Mix…?”

I wasn’t keen on creating a whole new build chain, and Mix had been rebuilt to work well on non-Laravel projects too. Although it was relatively easy to configure and extend, it favored VueJS by default.

The first thing I had to do was install a few NPM dependencies:

files. Finally, I added the Bootstrap files, for a bit of default styling.

Mix automatically loaded a custom configuration file, so I added:

. I planned to have single JS and CSS entry-points into the application’s various bits and bobs.

code can be removed.

Once again I created a few shortcut scripts, to save on serious typing:

switch enabled a lean production version of the bundles.

without knowing the hash. I noticed Mix liked to create a manifest file, so I made a helper function to query it:

I realised I could keep creating functions that returned promises, and use them in this way to keep my code asynchronous. My JS code looked like this:

… and:

function. Turns out it worked!

gives us), so we could resolve all the templates before the server starts up.

I was almost set up. The last thing to do was to connect the back-end and the front-end, via Web Sockets. I found this relatively straightforward, with a new class:

…and a slight modification to the web routes:

Now, I could alter the JS to connect to this web socket, and send a message to everyone connected to it:

object, it would connect to the web socket server, and add an event listener for new messages. I added a bit of debugging code – to make sure it was connecting properly, and sending new messages back.

We’ll get to the nitty-gritty of PHP and web sockets later, don’t worry.

In this part, we looked at how to set up a simple async PHP web server, how to use Laravel Mix in a non-Laravel project, and even how to connect the back-end and front-end together with Web Sockets.

Phew! That’s a lot of ground covered, and we haven’t written a single line of game code. Join me in part two, when we start to build game logic and a ReactJS interface.

Game Development with ReactJS and PHP: How Compatible Are They? — SitePoint