Rez Authors Guide

Open the first_game.rez file and delete everything after the comment %% The game proper begins here up to the final } that closes the @game element (delete lines 35-75 inclusive) (see step01).

Let’s start super simple: Putting something on screen. For that we’ll need the existing @game element (because every game needs one), a @scene (again, every game must have at least one) and a @card.

Cards are the main way that we put content on screen. They require a content: attribute that is written using plain HTML, though you also have the power of Bulma CSS and Apline.js (for styling & dynamic content) at your fingertips.

If you are familiar with Twine then a Rez @card is metaphorically equivalent to a Twine passage. Twine has no real equivalent to a Rez @scene which you can think of like a scene in a play or a movie. We’re not making use of it yet but different scenes can present an entirely different "stage" for the cards to play out on.

So we’ve added a scene #s_first_scene and told it that the first card it should present is #c_entrance. We use the cards content: attribute to write what we want to see on screen. It’s this simple at the beginning.

When writing content, we are writing HTML and most of the normal rules apply here, although <a> tags will look a little funny to you. In this case we use the Bulma style is_italic to format part of the text.

As an aside note the use of s_ as a prefix to the id of scenes and c_ as a prefix to the id of cards. When you start referring to ID’s elsewhere in the game you’ll be glad for adopting this kind of approach.

Now, before we make any more changes, re-compile. You’re going to get an error:

When we deleted the previous content we deleted the scene #s_hello that used to opening the game. We need to tell Rez about the new scene #s_first_scene we have replaced it with. Find the line:

This instructs the game which scene to start with, amend it to:

Now when you compile you should see:

Load the dist/index.html file in the browser and you should see something like:

Congratulations, you are now an author with Rez!

How a game presents its content is a very important topic for authors and Rez gives you a lot of control over this. We mentioned that a scene can present a kind of "stage" upon which a part of your game plays out.

A simple game might only use one scene but as your game grows more complex you might find need for a range of scenes. For a character screen, an inventory system, a planetary exploration, and an NPC dialog are likely to present very differently and have different kinds of interactions.

Scenes lend themselves very naturally and support the idea both of changing from one scene to another (for example moving from an introduction or tutorial to the main game) as well as interludes where you switch to another scene and then back again (presenting an inventory or character screen) maintaining the players place.

We’ll talk more about this later but for now let’s look at how scenes can present their own interface by specifying a layout: attribute. In the same way cards have content: which is HTML they present, scenes have layout: which is HTML that they present, wrapped around the content from their current card.

Change the file so that the content now looks like this (see step02):

Re-compile and reload the game in the browser. You’ll notice a few things.

First, we now have a link that takes us from the starting card to the second card. Rez links are specified using regular HTML <a> tags but with some possibly unfamiliar attributes. To load a new card you don’t use href='…​', you use card='card_id'.

Second the scene itself is now presenting content directly via it’s layout: attribute. When you specify a custom layout you must include the ${content} expression somewhere because that contains the rendered content of the card (or cards) that the scene is presenting.

You can also add a layout: attribute to the @game itself. It works exactly the same way as a @scene layout and uses the ${content} expression to include the content being rendered by the current scene.

In this scene we’re also using a template expression to display the description: attribute defined by the scene’s current card. Scene layout can be a good way to present common content rather than duplicating this in the cards themselves.

Simple template expressions are of the form ${expression} where the expression starts with a binding. Bindings can look a little confusing at first but are actually a fairly simple concept: they give a name to something you want to refer to in a template expression.

Here’s a simple example: Every game has a single @game element with a title: attribute. At runtime this @game is represented by a Javascript object that stores the value of the title attribute. How can we refer to that object & value from a template?

That is where bindings come in, they associate a name with an object.

In practice you don’t need to make this specific binding because Rez automatically binds game, scene, card to the current @game, @scene, and @card elements respectively. You can make use of those straight away.

One role of a scene is to provide a layout and a context that can be shared among a number of different cards, making more complex UI easier to build. Scene’s do more than this as we’ll see later. But let’s expand on the layout theme a little. Let’s use a sidebar to display some information.

Fortunately Bulma makes this easy with its columns and column CSS classes.

Replace the existing #s_first_scene definition with this (see step03)

Note that the @scene now uses a blocks: attribute. This specifies the id of any additional cards we want to include within the game layout. Any card specified here gets rendered with the rendered content being bound to the same name in the bindings.

In this case #s_first_scene wants to render the content of #c_sidebar as well its current card. Rez renders the card so that you can include it in your template with a ${c_sidebar} expression within the layout.

The Scene layout is shared by the cards played into the scene. We don’t have to replicate it. Using different scenes is an easy way to have different parts of your game use a different layout and colour scheme.