Skip to content

Playtesting

Hayden Schiff edited this page Dec 2, 2019 · 8 revisions

Here's how you can work on the game, after you have everything installed.

Table of Contents

Running the game server

You can run a test server for the game with these commands in your terminal (access the terminal the same way you did in the Getting started § Installing the game section).

  • npm run play: Launches the test server and opens it in your web browser.
  • npm run start: Launches the test server without opening it in your browser (useful if you already have it open and don't want a second tab).

When the game server is running, it will automatically detect when any changes have been made to the game files and refresh your browser page. If the game fails to start or freezes up, there is probably an error; see the next section for more info.

Using the JavaScript console

Using the JavaScript console in your web browser, you can view error/debug messages from the game and issue commands to the game. Here's the keyboard shortcuts to open the JavaScript console in most popular browsers (note that on some laptops, you have to hold Fn while pressing F12):

  • Chrome: Command+Option+J (Mac) or Ctrl+Shift+J (Windows) or F12 (any OS)
  • Firefox: Command+Option+K (Mac) or Ctrl+Shift+K (Windows) or F12 (any OS)
  • Safari: Command+Option+C (but you need to have developer tools enabled first)
  • Edge: Ctrl+Shift+J or F12
  • Internet Explorer: F12

Reading error messages

In the console, there are three main types of messages that will appear: info, warn, and error.

  • info: Info messages indicate that something good/neutral has occurred.
  • warn: Warning messages indicate that something unexpected has occurred which might be a problem. The game will usually continue running when a warning occurs. Warnings typically appear in yellow.
  • error: Error messages indicate that something very bad has happened, and all or part of the game has crashed. Errors typically appear in red.

In most cases, the error message you should pay the most attention to is the earliest one; that is, the one that happened first and appears highest in the console log. Often, an error can have cascading effects and cause many other errors to happen, but you'll want to look at the original error to see what's actually gone wrong.

There are tons of warning/error messages that can occur; far more than I could list here. However, there are a few common message types used in this game:

  • Uncaught ImpossibleStateError: This error means that the game has entered a state that isn't supposed to be possible. This means that a bug has occurred, so you should report it to a developer.
  • Uncaught TilemapError: This error means that something is misconfigured in the level map, which you will need to fix in Tiled. The error message will include a description of the issue and the name of the map, and if applicable, the name of the layer in the map and the ID number of the object within that layer (object IDs can be seen in the Properties panel in Tiled).
    • example: Uncaught TilemapError: Player object #38: Unknown 'type' (Messages layer on test2 map)
      • This indicates that the game didn't recognize the type of an object. We can see that this is a Player object, but it's in the Messages layer – someone must have accidentally put it there instead of in the Mobs layer.
  • Invalid Tilemap Layer ID: This warning means that your map is missing one of its layers. This is technically fine – only the Platforms layer is required by the game – but you may want to add the missing layer so you can utilize all the game's functionality.

Console commands

In addition to viewing messages, the console can also be used for sending commands. Some of the commands include variables which you can replace. When inputting a text variable, you must surround it with quotes (numbers and true/false values do not need quotes, however). Here are some particularly useful commands:

  • Level switching
    • game.level – Shows the name of the current level
    • game.level = name – Switches to the level name
      • example: game.level = "test1" – Switches to the level "test1"
    • game.settings.startScene = name – Allows you to bypass the title screen and go directly to the level/scene name when the game loads (Note: This command affects what'll happen the next time the game loads, but doesn't have any immediate effect.)
      • example: game.settings.startScene = "test1" – Sets the level "test1" to launch as soon as the game loads
      • to disable: game.settings.startScene = null
  • Mobs
    • scene.mobs.children.entries – Lists all the mobs in the level.
    • You can access the Player mob with scene.player, and you can access any mob with scene.mobs.children.entries[n] (where n is the mob's number in the list from the previous command). The following commands can be run on any mob:
      • mob.damage() – Kills the mob
        • example: scene.player.damage() – Kills the player
        • example: scene.mobs.children.entries[1].damage() – Kills the 2nd mob on the level
      • mob.walkVel = n – Sets the walk speed to n
      • mob.jumpVel = n – Sets the jump speed to n
      • mob.iceAccel = n – Sets the ice physics acceleration to n
      • Any of the functions/variables available for ArcadeSprites, as listed in Phaser's API docs.
    • scene.layers.mobs.quickMake(type, x, y) – Creates a mob of a given type at coordinates (x, y). The mob types are the same as those that can be added to the Mobs layer in Tiled.
      • example: scene.layers.mobs.quickMake("DinoDog", 100, 200) – Creates a DinoDog at x=100, y=200
  • Physics
    • scene.debug = true – Turns on physics debug mode. Debug mode can also be toggled with the backtick/tilde key.
      • to disable: scene.debug = false

For programmers or advanced users, you can change just about anything using the global variable game, which contains the Phaser.Game instance. Additionally, the global variable scene contains a reference to the current GameScene instance (assuming there is one).

Clone this wiki locally