Putting together all of the pieces of a full stack JavaScript application can be a complex endeavor.

In this tutorial, we're going to build a multiplayer tabletop game simulator using Vue, Phaser, Node/Express, and Socket.IO to learn several concepts that will be useful in any full stack app.

You can follow along with this video tutorial as well (1 hour 16 minute watch):

All of the project files for this tutorial are available on GitHub.

Project Overview

Our project will feature a Phaser game instance that will allow us to create tokens and cards on screen, and move them around on a digital game board.

The Phaser instance will be wrapped in a Vue component that will handle things like multiplayer chat and commands. Together, Phaser and Vue will comprise our front end (referred to from here on as the "client"), and we'll use Socket.IO to communicate with other players and tie together the front and back ends of our app.

The back end (referred to from here on as the "server") will be a simple Express server that receives Socket.IO events from the client and acts accordingly. The whole application will run on Node as its runtime.

You don't need to be an expert in any of the above frameworks to complete this project, but it would be a good idea to have a solid foundation in basic JavaScript and HTML/CSS before trying to tackle the specifics. You can also follow along with my series on Learning JavaScript by Making Digital Tabletop Games and Web Apps.

You'll also want to make sure that you have Node and Git installed, along with your favorite code editor and a command line interface (you can follow my tutorial on setting up an IDE here if you need help).

Let's get started!

Part 1: Client Basics

We'll begin building our client by installing the Vue CLI, which will help us with some tooling and allow us to make changes to our files without having to reload our web browser.

In a command line, type in the following to install the Vue CLI globally:

npm install -g @vue/cli

Navigate to a desired directory and create a new folder for our project:

mkdir tabletop-project
cd tabletop-project

Now we can use the Vue CLI to template a front end project for us:

vue create client

You can just hit "enter" at the ensuing prompts unless you have specific preferences.

The Vue CLI has helpfully templated a front end project for us, which we can view in our code editor:

Let's navigate to our new client folder in our CLI and run the template app:

cd client
npm run serve

After a little work, the Vue CLI should begin displaying our app in a web browser at the default http://localhost:8080:

Cool! We have the basic structure of our client. Let's break it by creating two new components in the /components folder, called Game.vue and Chat.vue (you can go ahead and delete HelloWorld.vue and anything in the assets folder if you're obsessed with tidiness like I am).

Replace the code in App.vue with the following:

<template>
    <div id="app">
        <div id="game">
            <Game />
        </div>
        <div id="border" />
        <div id="input">
            <Chat />
        </div>
    </div>
</template>

<script>
    import Chat from './components/Chat.vue';
    import Game from './components/Game.vue';

    export default {
        name: 'App',
        components: {
            Chat,
            Game
        }
    }
</script>

<style>
    #app {
        font-family: 'Trebuchet MS';
        text-align: left;
        background-color: black;
        color: cyan;
        display: flex;
    }
    #game {
        width: 50vw;
        height: 100vh;
    }
    #input {
        width: 50vw;
        height: 100vh;
    }
    #border {
        border-right: 2px solid cyan;
    }
    @media (max-width: 1000px) {
        #app {
            flex-direction: column;
        }
        #game {
            width: 100vw;
            height: 50vh;
        }
        #input {
            width: 100vw;
            height: 50vh;
        }
    }
</style>

As you can see, a Vue component ordinarily has three sections: Template, Script, and Style, which contain any HTML, JavaScript, and CSS for that component, respectively. We've just imported our Game and Chat components here and added a little styling to give it a cyberpunk feel when it's all up and running.

That's actually all that we need to do to set up our App.vue component, which will house everything else in our client. Before we can actually do anything with it, we'll need to get our server working!

Part 2: Server Basics

At our root directory (tabletop-project, above /client), initialize a new project in a new command line interface by typing:

npm init

Like with our client, you can go ahead and press "enter" at the prompts unless there are specifics that you'd like to designate at this time.

We'll need to install Express and Socket.IO, along with Nodemon to watch our server files for us and reboot as necessary:

npm install --save express socket.io nodemon

Let's open up the new package.json file in that root directory and add a "start" command in the "scripts" section:

  "scripts": {
    "start": "nodemon server.js"
  },

Create a new file called server.js in this directory, and enter the following code:

const server = require('express')();
const http = require('http').createServer(server);
const io = require('socket.io')(http);

io.on('connection', function (socket) {
    console.log('A user connected: ' + socket.id);

    socket.on('send', function (text) {
        let newText = "<" + socket.id + "> " + text;
        io.emit('receive', newText);
    });

    socket.on('disconnect', function () {
        console.log('A user disconnected: ' + socket.id);
    });
});

http.listen(3000, function () {
    console.log('Server started!');
});

Excellent! Our simple server will now listen at http://localhost:3000, and use Socket.IO to log to the console when a user connects and disconnects, with their socket ID.

When the server receives a "send" event from a client, it will create a new text string that includes the socket ID of the client that emitted the event, and emit its own "receive" event to all clients with the text that it received, interpolated with the socket ID.

We can test the server by returning to our command line and starting it up :

npm run start

The command console should now display:

Cool! Let's return to the Chat component of our client to start building out our front end functionality.

Part 3: Chat

Let's open a separate command line interface and navigate to the /client directory. Within that directory, install the client version of Socket.IO:

npm install --save socket.io-client

In /client/src/components/Chat.vue, add the following code:

<template>
    <div id="container">
        <div id="output">
            <h1>STRUCT</h1>
            <p v-for="(text, index) in textOutput" :key="index">{{text}}</p>
        </div>
        <div id="input">
            <form>
                <input type="text" v-model="textInput" :placeholder="textInput" />
                <input type="submit" value="Send" v-on:click="submitText" />
            </form>
        </div>
    </div>
</template>

<script>
    import io from 'socket.io-client';
    let socket = io('http://localhost:3000');

    export default {
        name: 'Chat',
        data: function () {
            return {
                textInput: null,
                textOutput: []
            }
        },
        methods: {
            submitText: function (event) {
                event.preventDefault();
                socket.emit('send', this.textInput);
            }
        },
        created: function () {
            socket.on('connect', () => {
                console.log('Connected!');
            });
            socket.on('receive', (text) => {
                this.textOutput.push(text);
                this.textInput = null;
            });
        }
    }
</script>

<style scoped>
    #container {
        text-align: left;
        display: flex;
        flex-direction: column;
        margin-left: 1vw;
        min-height: 100vh;
    }
    h1 {
        text-align: center;
    }
    .hotpink {
        color: hotpink;
    }
    #input {
        position: fixed;
        margin-top: 95vh;
    }
    input[type=text] {
        height: 20px;
        width:  40vw;
        border: 2px solid cyan;
        background-color: black;
        color: hotpink;
        padding-left: 1em;
    }
    input[type=submit]{
        height: 25px;
        width: 5vw;
        background-color: black;
        color: cyan;
        border: 2px solid cyan;
        margin-right: 2vw;
    }
    input[type=submit]:focus{
        outline: none;
    }
    input[type=submit]:hover{
        color: hotpink;
    }
    @media (max-width: 1000px) {
        #container {
            border-left: none;
            border-top: 2px solid cyan;
            min-height: 50vh;
        }
        #input {
            margin-top: 43vh;
        }
        #output {
            margin-right: 10vw;
        }
        input[type=text] {
            width: 60vw;
        }
        input[type=submit] {
            min-width: 10vw;
        }
    }
</style>

Let's examine the above from bottom to top before moving forward. Between the

Building 2D games can be a great way to learn JavaScript, especially when working through the basics of complex tabletop game logic.

In this series, I’m going to introduce you to the basics of programming, with a focus on exposing you to JavaScript development best practices and frameworks. Keep in mind that the things we’re going to learn will be applicable in other programming languages as well.

Throughout this series, I’ll be providing an emphasis on learning to code for digital tabletop game and web development. This should be useful for roleplaying, card game, and board game developers who want to create companion apps or digital versions of their games, as well as all JavaScript newcomers.

After learning JavaScript and some of the frameworks and engines that we’re going to work with, along with some practice projects and outside learning of your own, you’ll be able to:

• run simulations
• make your own apps, games, and websites
• and even develop and deploy multi-user “full stack” projects that you can share with the world.

If you’re not specifically interested in digital tabletop game development, you’ll probably still find this series to be helpful. We’ll be learning core concepts that are central to game and web development that you’ll be able to apply to other programming languages and frameworks.

I’m a big proponent of using digital tabletop games in learning to code. Tabletop games are great because they involve a lot of logic and complex rulesets, but not physics, vector math, animation, and that sort of thing.

We’ll be exploring real programming practices such as setting up an integrated development environment and using GitHub for source control. We'll also be taking on projects that will help you polish the skills that will be fundamental in your long-term development as a coder.

Start by learning the basics (Beginner Series):

Learn more about setting up an integrated development environment (Beginner Tutorial):

Learn how to use GitHub and ES6 to create and structure your code (Intermediate Tutorial):

Learn more about Phaser for digital tabletop game development (Intermediate Tutorial):

Learn more about Vue for digital tabletop web development (Intermediate Tutorial):

Build a multiplayer card game with Phaser 3, Express, and Socket.IO (Advanced Project):

Build a Multiplayer Tabletop Game Simulator with Vue, Phaser, Express, Node, and Socket.IO (Advanced Project):

Build a full stack roleplaying game character generator with MongoDB, Express, Vue, and Node (MEVN) (Advanced Project):

Learn how to deploy a full stack web app to Heroku (Advanced Project):

Happy coding!

If you enjoyed this article, please consider checking out my games and books, subscribing to my YouTube channel, or joining the Entromancy Discord.

M. S. Farzan, Ph.D. has written and worked for high-profile video game companies and editorial websites such as Electronic Arts, Perfect World Entertainment, Modus Games, and MMORPG.com, and has served as the Community Manager for games like Dungeons & Dragons Neverwinter and Mass Effect: Andromeda. He is the Creative Director and Lead Game Designer of Entromancy: A Cyberpunk Fantasy RPG and author of The Nightpath Trilogy. Find M. S. Farzan on Twitter @sominator.

I'm a tabletop game developer, and am continually looking for ways to digitize game experiences. In this tutorial, we're going to build a multiplayer card game using Phaser 3, Express, and Socket.IO.

In terms of prerequisites, you'll want to make sure that you have Node/NPM and Git installed and configured on your machine. Some experience with JavaScript would be helpful, and you may want to run through the basic Phaser tutorial before tackling this one.

Major kudos to Scott Westover for his tutorial on the topic, Kal_Torak and the Phaser community for answering all my questions, and my good friend Mike for helping me conceptualize the architecture of this project.

Note: we'll be using assets and colors from my tabletop card game, Entromancy: Hacker Battles. If you prefer, you can use your own images (or even Phaser rectangles) and colors, and you can access the entire project code on GitHub.

If you'd prefer a more visual tutorial, you can also follow along with the companion video to this article:

Let's get started!

The Game

Our simple card game will feature a Phaser client that will handle most of the game logic and doing things like dealing cards, providing drag-and-drop functionality, and so on.

On the back end, we'll spin up an Express server that will utilize Socket.IO to communicate between clients and make it so that when one player plays a card, it shows up in another player's client, and vice-versa.

Our goal for this project is to create a basic framework for a multiplayer card game that you can build upon and adjust to suit your own game's logic.

First, let's tackle the client!

The Client

To scaffold our client, we're going to clone the semi-official Phaser 3 Webpack Project Template on GitHub.

Open your favorite command line interface and create a new folder:

mkdir multiplayer-card-project
cd multiplayer-card-project

Clone the git project:

git clone https://github.com/photonstorm/phaser3-project-template.git

This command will download the template in a folder called "phaser3-project-template" within /multiplayer-card-project. If you want to follow along with our tutorial's file structure, go ahead and change that template folder's name to "client."

Navigate into that new directory and install all dependencies:

cd client
npm install

Your project folder structure should look something like this:

Before we muck with the files, let's go back to our CLI and enter the following command in the /client folder:

npm start

Our Phaser template utilizes Webpack to spin up a local server that in turn serves up a simple game app in our browser (usually at http://localhost:8080). Neat!

Let's open our project in your favorite code editor and make some changes to fit our card game. Delete everything in /client/src/assets and replace them with the card images from GitHub.

In the /client/src directory, add a folder called "scenes" and another called "helpers."

In /client/src/scenes, add an empty file called "game.js".

In /client/src/helpers, add three empty files: "card.js", "dealer.js", and "zone.js".

Your project structure should now look like this:

Cool! Your client might be throwing you errors because we deleted some things, but not to worry. Open /src/index.js, which is the main entry point to our front end app. Enter the following code:

import Phaser from "phaser";
import Game from "./scenes/game";

const config = {
    type: Phaser.AUTO,
    parent: "phaser-example",
    width: 1280,
    height: 780,
    scene: [
        Game
    ]
};

const game = new Phaser.Game(config);

All we've done here is restructure the boilerplate to utilize Phaser's "scene" system so that we can separate our game scenes rather than try to cram everything in one file. Scenes can be useful if you're creating multiple game worlds, building things like instruction screens, or generally trying to keep things tidy.

Let's move to /src/scenes/game.js and write some code:

export default class Game extends Phaser.Scene {
    constructor() {
        super({
            key: 'Game'
        });
    }

    preload() {
        this.load.image('cyanCardFront', 'src/assets/CyanCardFront.png');
        this.load.image('cyanCardBack', 'src/assets/CyanCardBack.png');
        this.load.image('magentaCardFront', 'src/assets/MagentaCardFront.png');
        this.load.image('magentaCardBack', 'src/assets/MagentaCardBack.png');
    }

    create() {
        this.dealText = this.add.text(75, 350, ['DEAL CARDS']).setFontSize(18).setFontFamily('Trebuchet MS').setColor('#00ffff').setInteractive();
    }

    update() {

    }
}

We're taking advantage of ES6 classes to create a new Game scene, which incorporates preload(), create() and update() functions.

preload() is used to...well...preload any assets that we'll be using for our game.

create() is run when the game starts up, and where we'll be establishing much of our user interface and game logic.

update() is called once per frame, and we won't be making use of it in our tutorial (but it may be useful in your own game depending on its requirements).

Within the create() function, we've created a bit of text that says "DEAL CARDS" and set it to be interactive:

Very cool. Let's create a bit of placeholder code to understand how we want this whole thing to work once it's up and running. Add the following to your create() function:

        let self = this;

        this.card = this.add.image(300, 300, 'cyanCardFront').setScale(0.3, 0.3).setInteractive();
        this.input.setDraggable(this.card);

        this.dealCards = () => {

        }

        this.dealText.on('pointerdown', function () {
            self.dealCards();
        })

        this.dealText.on('pointerover', function () {
            self.dealText.setColor('#ff69b4');
        })

        this.dealText.on('pointerout', function () {
            self.dealText.setColor('#00ffff');
        })

        this.input.on('drag', function (pointer, gameObject, dragX, dragY) {
            gameObject.x = dragX;
            gameObject.y = dragY;
        })

We've added a lot of structure, but not much has happened. Now, when our mouse hovers over the "DEAL CARDS" text, it's highlighted in cyberpunk hot pink, and there's a random card on our screen:

We've placed the image at the (x, y) coordinates of (300, 300), set its scale to be a bit smaller, and made it interactive and draggable. We've also added a little bit of logic to determine what should happen when dragged: it should follow the (x, y) coordinates of our mouse.

We've also created an empty dealCards() function that will be called when we click on our "DEAL CARDS" text. Additionally, we've saved "this" - meaning the scene in which we're currently working - into a variable called "self" so that we can use it throughout our functions without worrying about scope.

Our Game scene is going to get messy fast if we don't start moving things around, so let's delete the code block that begins with "this.card" and move to /src/helpers/card.js to write:

export default class Card {
    constructor(scene) {
        this.render = (x, y, sprite) => {
            let card = scene.add.image(x, y, sprite).setScale(0.3, 0.3).setInteractive();
            scene.input.setDraggable(card);
            return card;
        }
    }
}

We've created a new class that accepts a scene as a parameter, and features a render() function that accepts (x, y) coordinates and a sprite. Now, we can call this function from elsewhere and pass it the necessary parameters to create cards.

Let's import the card at the top of our Game scene:

import Card from '../helpers/card';

And enter the following code within our empty dealCards() function:

        this.dealCards = () => {
            for (let i = 0; i < 5; i++) {
                let playerCard = new Card(this);
                playerCard.render(475 + (i * 100), 650, 'cyanCardFront');
            }
        }

When we click on the "DEAL CARDS" button, we now iterate through a for loop that creates cards and renders them sequentially on screen:

NICE. We can drag those cards around the screen, but it might be nice to limit where they can be dropped to support our game logic.

Let's move over to /src/helpers/zone.js and add a new class:

export default class Zone {
    constructor(scene) {
        this.renderZone = () => {
            let dropZone = scene.add.zone(700, 375, 900, 250).setRectangleDropZone(900, 250);
            dropZone.setData({ cards: 0 });
            return dropZone;
        };
        this.renderOutline = (dropZone) => {
            let dropZoneOutline = scene.add.graphics();
            dropZoneOutline.lineStyle(4, 0xff69b4);
            dropZoneOutline.strokeRect(dropZone.x - dropZone.input.hitArea.width / 2, dropZone.y - dropZone.input.hitArea.height / 2, dropZone.input.hitArea.width, dropZone.input.hitArea.height)
        }
    }
}

Phaser has built-in dropzones that allow us to dictate where game objects can be dropped, and we've set up one here and provided it with an outline. We've also added a tiny bit of data called "cards" to the dropzone that we'll use later.

Let's import our new zone into the Game scene:

import Zone from '../helpers/zone';

And call it in within the create() function:

        this.zone = new Zone(this);
        this.dropZone = this.zone.renderZone();
        this.outline = this.zone.renderOutline(this.dropZone);

Not too shabby!

We need to add a bit of logic to determine how cards should be dropped into the zone. Let's do that below the "this.input.on('drag')" function:

        this.input.on('dragstart', function (pointer, gameObject) {
            gameObject.setTint(0xff69b4);
            self.children.bringToTop(gameObject);
        })

        this.input.on('dragend', function (pointer, gameObject, dropped) {
            gameObject.setTint();
            if (!dropped) {
                gameObject.x = gameObject.input.dragStartX;
                gameObject.y = gameObject.input.dragStartY;
            }
        })

        this.input.on('drop', function (pointer, gameObject, dropZone) {
            dropZone.data.values.cards++;
            gameObject.x = (dropZone.x - 350) + (dropZone.data.values.cards * 50);
            gameObject.y = dropZone.y;
            gameObject.disableInteractive();
        })

Starting at the bottom of the code, when a card is dropped, we increment the "cards" data value on the dropzone, and assign the (x, y) coordinates of the card to the dropzone based on how many cards are already on it. We also disable interactivity on cards after they're dropped so that they can't be retracted:

We've also made it so that our cards have a different tint when dragged, and if they're not dropped over the dropzone, they'll return to their starting positions.

Although our client isn't quite complete, we've done as much as we can before implementing the back end. We can now deal cards, drag them around the screen, and drop them in a dropzone. But to move forward, we'll need to set up a server than can coordinate our multiplayer functionality.

The Server

Let's open up a new command line at our root directory (above /client) and type:

npm init
npm install --save express socket.io nodemon

We've initialized a new package.json and installed Express, Socket.IO, and Nodemon (which will watch our server and restart it upon changes).

In our code editor, let's change the "scripts" section of our package.json to say:

  "scripts": {
    "start": "nodemon server.js"
  },

Excellent. We're ready to put our server together! Create an empty file called "server.js" in our root directory and enter the following code:

const server = require('express')();
const http = require('http').createServer(server);
const io = require('socket.io')(http);

io.on('connection', function (socket) {
    console.log('A user connected: ' + socket.id);

    socket.on('disconnect', function () {
        console.log('A user disconnected: ' + socket.id);
    });
});

http.listen(3000, function () {
    console.log('Server started!');
});

We're importing Express and Socket.IO, asking for the server to listen on port 3000. When a client connects to or disconnects from that port, we'll log the event to the console with the client's socket id.

Open a new command line interface and start the server:

npm run start

Our server should now be running on localhost:3000, and Nodemon will watch our back end files for any changes. Not much else will happen except for the console log that the "Server started!"

In our other open command line interface, let's navigate back to our /client directory and install the client version of Socket.IO:

cd client
npm install --save socket.io-client

We can now import it in our Game scene:

import io from 'socket.io-client';

Great! We've just about wired up our front and back ends. All we need to do is write some code in the create() function:

        this.socket = io('http://localhost:3000');

        this.socket.on('connect', function () {
            console.log('Connected!');
        });

We're initializing a new "socket" variable that points to our local port 3000 and logs to the browser console upon connection.

Open and close a couple of browsers at http://localhost:8080 (where our Phaser client is being served) and you should see the following in your command line interface:

YAY. Let's start adding logic to our server.js file that will serve the needs of our card game. Replace the existing code with the following:

const server = require('express')();
const http = require('http').createServer(server);
const io = require('socket.io')(http);
let players = [];

io.on('connection', function (socket) {
    console.log('A user connected: ' + socket.id);

    players.push(socket.id);

    if (players.length === 1) {
        io.emit('isPlayerA');
    };

    socket.on('dealCards', function () {
        io.emit('dealCards');
    });

    socket.on('cardPlayed', function (gameObject, isPlayerA) {
        io.emit('cardPlayed', gameObject, isPlayerA);
    });

    socket.on('disconnect', function () {
        console.log('A user disconnected: ' + socket.id);
        players = players.filter(player => player !== socket.id);
    });
});

http.listen(3000, function () {
    console.log('Server started!');
});

We've initialized an empty array called "players" and add a socket id to it every time a client connects to the server, while also deleting the socket id upon disconnection.

If a client is the first to connect to the server, we ask Socket.IO to "emit" an event that they're going to be Player A. Subsequently, when the server receives an event called "dealCards" or "cardPlayed", it should emit back to the clients that they should update accordingly.

Believe it or not, that's all the code we need to get our server working! Let's turn our attention back to the Game scene. Right at the top of the create() function, type the following:

        this.isPlayerA = false;
        this.opponentCards = [];

Under the code block that starts with "this.socket.on(connect)", write:

        this.socket.on('isPlayerA', function () {
            self.isPlayerA = true;
        })

Now, if our client is the first to connect to the server, the server will emit an event that tells the client that it will be Player A. The client socket receives that event and turns our "isPlayerA" boolean from false to true.

Note: from this point forward, you may need to reload your browser page (set to http://localhost:8080), rather than having Webpack do it automatically for you, for the client to correctly disconnect from and reconnect to the server.

We need to reconfigure our dealCards() logic to support the multiplayer aspect of our game, given that we want the client to deal us a certain set of cards that may be different from our opponent's. Additionally, we want to render the backs of our opponent's cards on our screen, and vice versa.

We'll move to the empty /src/helpers/dealer.js file, import card.js, and create a new class:

import Card from './card';

export default class Dealer {
    constructor(scene) {
        this.dealCards = () => {
            let playerSprite;
            let opponentSprite;
            if (scene.isPlayerA) {
                playerSprite = 'cyanCardFront';
                opponentSprite = 'magentaCardBack';
            } else {
                playerSprite = 'magentaCardFront';
                opponentSprite = 'cyanCardBack';
            };
            for (let i = 0; i < 5; i++) {
                let playerCard = new Card(scene);
                playerCard.render(475 + (i * 100), 650, playerSprite);

                let opponentCard = new Card(scene);
                scene.opponentCards.push(opponentCard.render(475 + (i * 100), 125, opponentSprite).disableInteractive());
            }
        }
    }
}

With this new class, we're checking whether the client is Player A, and determining what sprites should be used in either case.

Then, we deal cards to our client, while rendering the backs of our opponent's cards at the top the screen and adding them to the opponentCards array that we initialized in our Game scene.

In /src/scenes/game.js, import the Dealer:

import Dealer from '../helpers/dealer';

Then replace our dealCards() function with:

        this.dealer = new Dealer(this);

Under code block that begins with "this.socket.on('isPlayerA')", add the following:

        this.socket.on('dealCards', function () {
            self.dealer.dealCards();
            self.dealText.disableInteractive();
        })

We also need to update our dealText function to match these changes:

        this.dealText.on('pointerdown', function () {
            self.socket.emit("dealCards");
        })

Phew! We've created a new Dealer class that will handle dealing cards to us and rendering our opponent's cards to the screen. When the client socket receives the "dealcards" event from the server, it will call the dealCards() function from this new class, and disable the dealText so that we can't just keep generating cards for no reason.

Finally, we've changed the dealText functionality so that when it's pressed, the client emits an event to the server that we want to deal cards, which ties everything together.

Fire up two separate browsers pointed to http://localhost:8080 and hit "DEAL CARDS" on one of them. You should see different sprites on either screen:

Note again that if you're having issues with this step, you may have to close one of your browsers and reload the first one to ensure that both clients have disconnected from the server, which should be logged to your command line console.

We still need to figure out how to render our dropped cards in our opponent's client, and vice-versa. We can do all of that in our game scene! Update the code block that begins with "this.input.on('drop')" with one line at the end:

        this.input.on('drop', function (pointer, gameObject, dropZone) {
            dropZone.data.values.cards++;
            gameObject.x = (dropZone.x - 350) + (dropZone.data.values.cards * 50);
            gameObject.y = dropZone.y;
            gameObject.disableInteractive();
            self.socket.emit('cardPlayed', gameObject, self.isPlayerA);
        })

When a card is dropped in our client, the socket will emit an event called "cardPlayed", passing the details of the game object and the client's isPlayerA boolean (which could be true or false, depending on whether the client was the first to connect to the server).

Recall that, in our server code, Socket.IO simply receives the "cardPlayed" event and emits the same event back up to all of the clients, passing the same information about the game object and isPlayerA from the client that initiated the event.

Let's write what should happen when a client receives a "cardPlayed" event from the server, below the "this.socket.on('dealCards')" code block:

         this.socket.on('cardPlayed', function (gameObject, isPlayerA) {
            if (isPlayerA !== self.isPlayerA) {
                let sprite = gameObject.textureKey;
                self.opponentCards.shift().destroy();
                self.dropZone.data.values.cards++;
                let card = new Card(self);
                card.render(((self.dropZone.x - 350) + (self.dropZone.data.values.cards * 50)), (self.dropZone.y), sprite).disableInteractive();
            }
        })

The code block first compares the isPlayerA boolean it receives from the server against the client's own isPlayerA, which is a check to determine whether the client that is receiving the event is the same one that generated it.

Let's think that through a bit further, as it exposes a key component to how our client - server relationship works, using Socket.IO as the connector.

Suppose that Client A connects to the server first, and is told through the "isPlayerA" event that it should change its isPlayerA boolean to true. That's going to determine what kind of cards it generates when a user clicks "DEAL CARDS" through that client.

If Client B connects to the server second, it's never told to alter its isPlayerA boolean, which stays false. That will also determine what kind of cards it generates.

When Client A drops a card, it emits a "cardPlayed" event to the server, passing information about the card that was dropped, and its isPlayerA boolean, which is true. The server then relays all that information back up to all clients with its own "cardPlayed" event.

Client A receives that event from the server, and notes that the isPlayerA boolean from the server is true, which means that the event was generated by Client A itself. Nothing special happens.

Client B receives the same event from the server, and notes that the isPlayerA boolean from the server is true, although Client B's own isPlayerA is false. Because of this difference, it executes the rest of the code block.

The ensuing code stores the "texturekey" - basically, the image - of the game object that it receives from the server into a variable called "sprite". It destroys one of the opponent card backs that are rendered at the top of the screen, and increments the "cards" data value in the dropzone so that we can keep placing cards from left to right.

The code then generates a new card in the dropzone that uses the sprite variable to create the same card that was dropped in the other client (if you had data attached to that game object, you could use a similar approach to attach it here as well).

Your final /src/scenes/game.js code should look like this:

import io from 'socket.io-client';
import Card from '../helpers/card';
import Dealer from "../helpers/dealer";
import Zone from '../helpers/zone';

export default class Game extends Phaser.Scene {
    constructor() {
        super({
            key: 'Game'
        });
    }

    preload() {
        this.load.image('cyanCardFront', 'src/assets/CyanCardFront.png');
        this.load.image('cyanCardBack', 'src/assets/CyanCardBack.png');
        this.load.image('magentaCardFront', 'src/assets/magentaCardFront.png');
        this.load.image('magentaCardBack', 'src/assets/magentaCardBack.png');
    }

    create() {
        this.isPlayerA = false;
        this.opponentCards = [];

        this.zone = new Zone(this);
        this.dropZone = this.zone.renderZone();
        this.outline = this.zone.renderOutline(this.dropZone);

        this.dealer = new Dealer(this);

        let self = this;

        this.socket = io('http://localhost:3000');

        this.socket.on('connect', function () {
            console.log('Connected!');
        });

        this.socket.on('isPlayerA', function () {
            self.isPlayerA = true;
        })

        this.socket.on('dealCards', function () {
            self.dealer.dealCards();
            self.dealText.disableInteractive();
        })

        this.socket.on('cardPlayed', function (gameObject, isPlayerA) {
            if (isPlayerA !== self.isPlayerA) {
                let sprite = gameObject.textureKey;
                self.opponentCards.shift().destroy();
                self.dropZone.data.values.cards++;
                let card = new Card(self);
                card.render(((self.dropZone.x - 350) + (self.dropZone.data.values.cards * 50)), (self.dropZone.y), sprite).disableInteractive();
            }
        })

        this.dealText = this.add.text(75, 350, ['DEAL CARDS']).setFontSize(18).setFontFamily('Trebuchet MS').setColor('#00ffff').setInteractive();

        this.dealText.on('pointerdown', function () {
            self.socket.emit("dealCards");
        })

        this.dealText.on('pointerover', function () {
            self.dealText.setColor('#ff69b4');
        })

        this.dealText.on('pointerout', function () {
            self.dealText.setColor('#00ffff');
        })

        this.input.on('drag', function (pointer, gameObject, dragX, dragY) {
            gameObject.x = dragX;
            gameObject.y = dragY;
        })

        this.input.on('dragstart', function (pointer, gameObject) {
            gameObject.setTint(0xff69b4);
            self.children.bringToTop(gameObject);
        })

        this.input.on('dragend', function (pointer, gameObject, dropped) {
            gameObject.setTint();
            if (!dropped) {
                gameObject.x = gameObject.input.dragStartX;
                gameObject.y = gameObject.input.dragStartY;
            }
        })

        this.input.on('drop', function (pointer, gameObject, dropZone) {
            dropZone.data.values.cards++;
            gameObject.x = (dropZone.x - 350) + (dropZone.data.values.cards * 50);
            gameObject.y = dropZone.y;
            gameObject.disableInteractive();
            self.socket.emit('cardPlayed', gameObject, self.isPlayerA);
        })
    }

    update() {

    }
}

Save everything, open two browsers, and hit "DEAL CARDS". When you drag and drop a card in one client, it should appear in the dropzone of the other, while also deleting a card back, signifying that a card has been played:

That's it! You should now have a functional template for your multiplayer card game, which you can use to add your own cards, art, and game logic.

One first step could be to add to your Dealer class by making it shuffle an array of cards and return a random one (hint: check out Phaser.Math.RND.shuffle([array])).

Happy coding!

If you enjoyed this article, please consider checking out my games and books, subscribing to my YouTube channel, or joining the Entromancy Discord.

M. S. Farzan, Ph.D. has written and worked for high-profile video game companies and editorial websites such as Electronic Arts, Perfect World Entertainment, Modus Games, and MMORPG.com, and has served as the Community Manager for games like Dungeons & Dragons Neverwinter and Mass Effect: Andromeda. He is the Creative Director and Lead Game Designer of Entromancy: A Cyberpunk Fantasy RPG and author of The Nightpath Trilogy. Find M. S. Farzan on Twitter @sominator.

A few weeks ago, I posted about my experience attempting to make a prototype in a bunch of different 2D game engines/frameworks to learn what makes them tick.

If you're shopping around for an engine for your next 2D game, this article will provide some things to consider that may help in your discernment process.

Do note that I'm not attempting to cover every 2D game engine out there; nor am I positioning one engine or framework over another. These recommendations are from my personal experience using different engines and frameworks for prototyping.

And if you'd prefer to watch rather than read, I've created a video version of this post (26 minute watch):

React

At first glance, you might be thinking, "React is a front end framework for making interactive websites. It's not a game engine!" And you'd be mostly correct.

React doesn't provide native support for game development basics, like, for example, 2D physics, but it does handle state extremely well. If you're already a JavaScript developer and willing to pair React with something like boardgame.io to make a simple 2D game, you could potentially get a prototype up and running pretty quickly.

For all other types of 2D games, you'll want to look elsewhere.

Unity

Unity has made itself ubiquitous in the 2D and 3D game development spaces. I'd position it as an excellent 3D game engine, and a serviceable 2D one.

The Unity editor is fairly complex, with a lot of nested menus that take some time to wrap your head around (check out this article for a tour of its 2D features). If you don't already have a background in C#, which Unity uses for scripting, you'll want to brush up on it prior to learning Unity, as doing so will ease your overall learning curve.

Unity also does a lot of things the "hard way" when it comes to 2D game development, which doesn't feel native compared to other game engines. Creating a 2D game world in Unity, for example, feels like you're shoehorning a 2D plane into a large 3D space, and things like animation and pixel perfection are more clunky than in other 2D-specific engines.

You can make any type of 2D game with Unity if you're willing to wrestle with the editor and underlying 3D idiosyncrasies. It has extensive community support, and you'll find that working with C# is a delight. Additionally, Unity's Asset Store has all kinds of art and templates for you to download and purchase, but buyer beware: you might spend as much time rewriting someone else's code to fit your project as you would just starting from scratch.

Unity is, in general, free to use, but pricing becomes more complex if you want to use everything it has to offer (see this page for more details).

Godot

Godot is a free and open source 2D and 3D game engine that supports GDScript, C#, and even C++ and Python if you're willing to do a lot of the heavy lifting to make them work. It supports a node-style workflow and is super lightweight.

If you're a) willing to invest in learning GDScript or b) already super good at C#, C++, or Python, you'll probably be fine in Godot, particularly if you like working with open source software. If not, you may get easily frustrated, as there isn't nearly as much support for C# or other languages as there is for GDScript. Still, Godot is a pleasant engine with which to work, and although it may not have the same pedigree and community support as something like Unity, if you're a self-starter you might feel well at home.

Construct 3

If you just want to make 2D games and don't care about programming language or subscription fees, you'll find Construct 3 to have everything you need to get a demo up and running, and quickly. All of your work will be done in a browser, using drag-and-drop tools (and custom JavaScript support if you need it).

Don't expect to have a meaningfully productive experience with Construct 3 for free, however. There's a simple demo that you can try out, but impactful game development with Construct 3 is locked behind a paywall, and a subscription at that.

Game Maker Studio 2

Game Maker Studio 2 has a user-friendly editor that supports a proprietary language called, appropriately, Game Maker Language (GML), along with visual scripting. It also has a lot of tutorials, great community support, and an asset store (which comes with the same caveats as Unity's, above).

The general workflow of Game Maker Studio 2 and doing things like animating sprites, setting up your game world, and so on, are straightforward and intuitive. GML might not be your cup of tea if you're coming from another, more widely-used programming language, and I would not recommend it as your first introduction to learning how to code. It employs some of the basic concepts of programming, but not important details such as coding best practices or how to write clean code.

Additionally, you can try Game Maker Studio 2 with a free 30-day trial, but will need to pay to continue to use it after that time.

Phaser 3

If you want to code everything and learn a lot about the JavaScript ecosystem while doing it, check out Phaser 3 (or wait for Phaser 4, which is on the way).

Phaser is a lightweight and powerful JavaScript framework for making 2D games. Whereas Phaser 2 was extremely well-documented and had excellent community support, Phaser 3 is quite the opposite. There's good official documentation and a bunch of examples (without much context around them, it must be said), and a dreadfully small amount of tutorials.

Expect to build everything yourself, but if you're looking for ES6 or TypeScript support, or if you really want to polish your skills as a JavaScript developer, you'll be able to go a long way with Phaser 3.

In the interest of fairness, I should mention a two other 2D game engines that have been recommended to me since I started writing on the topic: LÖVE 2D, which uses Lua, and MonoGame, which supports C#. I haven't used either of them (or others, such as PyGame), and can't speak to their usefulness, but they may be worth checking out.

Let me know which 2D game engine you wind up using, and why!

If you enjoyed this article, please consider checking out my games and books, subscribing to my YouTube channel, or joining the Entromancy Discord.

M. S. Farzan, Ph.D. has written and worked for high-profile video game companies and editorial websites such as Electronic Arts, Perfect World Entertainment, Modus Games, and MMORPG.com, and has served as the Community Manager for games like Dungeons & Dragons Neverwinter and Mass Effect: Andromeda. He is the Creative Director and Lead Game Designer of Entromancy: A Cyberpunk Fantasy RPG and author of The Nightpath Trilogy. Find M. S. Farzan on Twitter @sominator.

I'm a tabletop game developer. In designing a new card game, I decided to build a digital prototype to help me run simulations and easily share a proof of concept with collaborators.

I have some background in JavaScript and C#, and I set out as many do: by spending an inordinate amount of time in "what framework should I use" threads and reading documentation without actually making anything.

Flash forward many months, and I've now spent more time working in (and wrestling with) React, Unity, Godot, Construct 3, Game Maker Studio 2, and Phaser 3, in an attempt to understand what makes them tick.

Admittedly, I think I've spent way more time in each of them than necessary to make my little game, and I probably could have just stuck with the first one and blundered my way through the prototype. I'm hoping the below info will be helpful for anyone else who is shopping around for an engine or framework.

Bunch of caveats: I'm not attempting to sell one engine or framework over the others, and I'm also not suggesting that one or any of these frameworks will work for your game better than another. I'm also not comparing pricing, back end functionality, or platform deployment. So depending on your requirements, the below information might be of differing value to you.

Additionally, this experience is based on development for a 2D card game, so I won't be discussing 3D engines, physics, etc.

You can also skip to the bottom for the TL;DR.

The Prototype

My game, Entromancy: Hacker Battles, is a competitive cyberpunk card game with TCG-light mechanics. You can read more on our website or watch how it's meant to be played in this video. But suffice it to say that, as a card game, it requires a potential digital framework to support basic things like state management, UI, drag-and-drop UX, and back end hooks for implementing multiplayer.

Given these requirements, I explored the following frameworks and engines to see which one would be most suitable for making my game...instead of actually making the game (I'm happy to say that now that I've settled on a framework, I'm making a lot more progress).

You can access a playable version here, and although the game is further along than the live prototype would suggest, this version is pretty stable (in Chrome at least).

React

Having already built a character generator prototype in React for a tabletop RPG I designed, I thought a natural step would be to give the framework a spin for the card game. I found state management to be a breeze (it's what React does, after all), whereas implementing simple drag-and-drop functionality for cards proved to be a nightmare.

There are some libraries out there that can help with basic drag-and-drop (e.g. React DnD), but I found that with a card game, I needed a more elegant solution for dropzones, as Hacker Battles is very specific about which cards can be played where, and when.

This experience led me to check out boardgame.io, which can work in tandem with React. But this ultimately required me to learn another framework on top of an existing framework, which was less than ideal for my purposes.

Unity

Out of general interest, I had spent a lot of time in Unity doing tutorials and learning how to use the editor before attempting to remake the card game prototype with it. The asset store is a great resource, and there's so much documentation, official and unofficial, out there that I was confident I could find an answer to any issue I might encounter.

My experience with Unity thus far has been a mixed bag. I really enjoy working in C#, and anything code-related has been a relatively pain-free experience. However, Unity is very specific about its implementation and can feel counter-intuitive at times.

The editor, on the other hand, is a bear to work with. To harness Unity's full potential, you need to spend a good long while wrestling with the UI to understand where everything is and how to use it. It's also desperately behind the times with 2D game development, clearly attempting to flatten a primarily 3D engine into a 2D plane, with mixed results.

To be fair, I quite enjoy working in the Unity editor, clunky as it is. But if you're looking for a 2D game engine, your quality of life will be a lot higher elsewhere (watch a video on Unity's animation system or achieving pixel perfection and you'll see what I mean).

Ultimately, Unity's handling of the 2D space is a bit more complex than I need for my prototype, but I will return to it for other types of games.

Also, a sidebar that might be useful to some: I was initially extremely excited about the asset store, with the idea that I could purchase a card game template that would make the development process that much easier for me. It didn't work out. Most of them were MTG/Hearthstone/etc. clones that would require just as much development time on my part to restructure them for my card game as it would to just start from scratch.

Godot

My first thought upon encountering Godot was: "open source game engine that supports C#? Sign me up!" Then I downloaded it, worked through a couple of basic tutorials, and had it crash on build. Hurm.

Several Google searches, reinstalls, and hairs pulled later, I figured out it had something to do with my version of VS Build (I think?), which led me down a separate rabbit hole. I knew from experience that other engines - Unity chief among them - could cause game-breaking issues completely outside of your own code, but this was an annoying hurdle that likely colored the rest of my experience with Godot.

In terms of the editor, I quite liked Godot's node-based implementation, which I actually found counter-intuitive coming from Unity's prefabs, but eventually warmed to. I'd actually go as far as to say that its 2D functionality is better than Unity's, but it's missing the community, asset store (see sidebar above), and especially, the documentation that Unity has. If you're intending in working in C# with Godot, for example, be prepared to look for answers in the engine's custom GDScript and then translating them to C#.

I have heard, however, of people experiencing great success with Godot while using GDScript, so if you're willing to invest the time to learn it you might enjoy what Godot has to offer.

Construct 3

In the caveats that I listed above, I mentioned that I'm not including pricing as a point of discussion. Still, I feel like I need to bring it up with Construct 3, as it turned out to be impactful in my experience.

Unlike the other game engines listed here, which are, for the most part, free to use (Game Maker Studio 2 has a 30-day free trial), the vast majority of Construct's functionality is behind a pay wall, and a subscription fee at that. Ugh.

I really, really like the cut of Construct's jib for simple 2D games. The editor feels a bit like an upgrade from MS Paint, but it handles sprite and object management really well, and is just plain easy to use. I don't love that it uses a "visual scripting" style, but they've recently added the feature of writing plain old JavaScript and it seems to more or less work.

I was able to spin up a very rudimentary architecture for the prototype in a brief amount of time before closing the Construct 3 demo (which runs in a browser)...and then trying it all again later with a new demo. I feel like, at least for this card game, I could do a lot with Construct 3, but I'm just not willing to pay $99/year (or more, as a business) for a prototype.

Game Maker Studio 2

YoYo Games has clearly done a lot of work to make Game Maker Studio 2 accessible and easily navigable, and it shows. Of all of the engines that I've used for this project, I like the GMS editor the most. For a small project, it's easy to find your way around and go about your business. I suspect, however, that a larger project might get out of hand pretty quickly.

This might be influenced by Game Maker Studio's proprietary language, GML (although GMS 2 supports visual scripting, which I did not use). It works, but if you're coming to it from another OOP language (or, truly, any other widely used language), you might scratch your head at the implementation or figuring out how to do some things. If you're a beginner or willing to spend time figuring out how GMS wants you to use GML, you'll probably be fine.

I experienced some quirkiness with Game Maker Studio's drag-and-drop functionality - namely, mouse pointer detection upon dragging is a little wonky and requires some scaffolding to make work correctly.

I think - and this is totally personal preference and laziness on my part - that if GMS offered the ability to use another, non-proprietary programming language, I would spend the time to do more damage here. I'm all for leveling up multiple skills while working, whereas spending the time to become an expert in the GMS editor and GML without being able to easily apply that knowledge elsewhere doesn't seem worthwhile.

Still, it's a pretty workable 2D editor, and although the community support may not be on par with Unity's, it's still pretty good. Beware, also, that once your free trial is up, you'll have to pay to continue using Game Maker Studio 2.

Phaser 3

Phaser is a lightweight, open-source JavaScript game framework. There are some Phaser IDEs around, but if you're of the sort that wants to work primarily in code, you might wind up here, using Atom, Sublime, or your favorite editor.

Phaser 2 was and is widely used and well-documented with a ton of tutorials to draw upon. Phaser 3 is the opposite. It has a comparatively high learning curve for beginners, with a bunch of examples and not a lot of context around them.

A lot of the tutorials out there support Phaser 2, and while the learning is transferable, the code is not. Additionally, the devs recently announced that they'll be moving support to Phaser 4 (and TypeScript rather than ES6), which is not great if you've spent time working in Phaser 3.

If you're not a professional programmer (I'm not) and up-to-speed with ES6 classes and JavaScript best practices (I wasn't), you might become quickly frustrated with Phaser's lack of handholding and having to set up your own IDE and work flow (I was).

However, I've found it to be a powerful, lightweight framework that does a lot of things in a much more streamlined fashion than other game engines. Drag-and-drop functionality for the card game has been a relative breeze, and the ability to separate card types into classes (sort of like Unity's prefabs) has compartmentalized some of the cognitive load that this kind of game requires.

If you're a front end developer, you might like or be comfortable with hard coding pixel coordinates for everything, but sheesh, is this painstaking work. Additionally, if you're not up-to-speed on everything JavaScript, you'll most likely be searching for answers in non-Phaser circles and then applying them to your project, which has its own benefit, I suppose.

One other note in case it's not clear: Phaser 3 does have quite a bit of official documentation and examples, but it doesn't have the community or Stack Overflow answers that a lot of other game engines enjoy. If you run into an issue or can't figure something out, you'll have to figure out your own solution or post your question on the Phaser Discord server, which has been helpful in my experience.

Conclusion

Given all of the above, the prototype I've stuck with and continue to iterate upon is the one I've built with Phaser 3. I realize that this may be anti-climactic, as Phaser isn't inherently "better" than the other frameworks and engines at 2D game development (except for, perhaps, React, which isn't trying to be a competitor in the digital game space).

Phaser does, however, seem to handle drag-and-drop and game loop management for Hacker Battles more smoothly, and for my purposes, that's important. I also enjoy that using Phaser is requiring me to invest more heavily in the JavaScript ecosystem(s) and communities, but I'm interested in doing that anyway so it feels like a bonus.

If you're more of the "what can I use to build something quickly and not care about the context in which the engine is situated" type, YMMV.

TL;DR

React: great for front end development. Wouldn't use it for games, particularly drag-and-drop.

Unity: you can make any type of 2D game if you're willing to wrestle with the editor and underlying 3D idiosyncrasies. Great community support, and C# is awesome. Asset store exists, but may not be useful for your purposes.

Godot: open source and supports GDScript, C#, even C++ and Python if you're willing to do a lot of the heavy lifting. Good 2D implications but not nearly as much community support as something like Unity. Also, my experience was buggy.

Construct 3: really easy to use, high barrier to entry because of the subscription paywall. Visual scripting may get on your nerves if you're looking to use or learn code, although there is now some JavaScript support.

Game Maker Studio 2: user-friendly editor with good community support. GML or visual scripting might not be your cup of tea if you're coming from another more popular programming language, but hey, when in Rome. Also, requires payment after a 30-day free trial.

Phaser 3: expect to code everything, and do a lot of searching to figure out how to make things work. It's working for me for this particular game and prototype, but Phaser 4 is on the way, so there's that.

I hope this post is useful in your own search and discernment process. I'd love to hear about your own experience(s), too, with any of these frameworks/engines or others!

If you enjoyed this article, please consider checking out my games and books, subscribing to my YouTube channel, or joining the Entromancy Discord.

M. S. Farzan, Ph.D. has written and worked for high-profile video game companies and editorial websites such as Electronic Arts, Perfect World Entertainment, Modus Games, and MMORPG.com, and has served as the Community Manager for games like Dungeons & Dragons Neverwinter and Mass Effect: Andromeda. He is the Creative Director and Lead Game Designer of Entromancy: A Cyberpunk Fantasy RPG and author of The Nightpath Trilogy. Find M. S. Farzan on Twitter @sominator.