The Camera Manipulations Project

This project demonstrates how to implement intuitive camera manipulation operations by working with the WC center, width, and height of the Camera object. You can see an example of this project running in Figure 7-2. The source code to this project is defined in the chapter7/7.1.camera_manipulations folder.

You can find the following external resources in the assets folder: the fonts folder that contains the default system fonts and three texture images (minion_portal.png, minion_sprite.png, and bg.png). The Portal object is represented by the first texture image, the remaining objects are sprite elements of minion_sprite.png, and the background is a large TextureRenderable object texture mapped with bg.png.

Define Camera Manipulation Operations in camera_manipulation.js File

Recall that you have created an empty camera_manipulation.js source code file. You are now ready to edit this file and define additional functions on the Camera class to manipulate the camera.

1. 1.

   Edit camera_manipulate.js. Ensure you are adding code between the initial import and final export of the Camera class functionality.

    
2. 2.

   Import the bounding box collision status, and define the panWidth() function to pan the camera based on the bounds of a Transform object. This function is complementary to the clampAtBoundary() function, where instead of changing the aXform position, the camera is moved to ensure the proper inclusion of the aXform bounds. As in the case of the clampAtBoundary() function, the camera will not be changed if the aXform bounds are completely outside the tested WC bounds area.

    

import { eBoundCollideStatus } from "../bounding_box.js";

Camera.prototype.panWith = function (aXform, zone) {

    let status = this.collideWCBound(aXform, zone);

    if (status !== eBoundCollideStatus.eInside) {

        let pos = aXform.getPosition();

        let newC = this.getWCCenter();

        if ((status & eBoundCollideStatus.eCollideTop) !== 0) {

            newC[1] = pos[1]+(aXform.getHeight() / 2) –

                      (zone * this.getWCHeight() / 2);

        }

        if ((status & eBoundCollideStatus.eCollideBottom) !== 0) {

            newC[1] = pos[1] - (aXform.getHeight() / 2) +

                      (zone * this.getWCHeight() / 2);

        }

        if ((status & eBoundCollideStatus.eCollideRight) !== 0) {

            newC[0] = pos[0] + (aXform.getWidth() / 2) –

                      (zone * this.getWCWidth() / 2);

        }

        if ((status & eBoundCollideStatus.eCollideLeft) !== 0) {

            newC[0] = pos[0] - (aXform.getWidth() / 2) +

                      (zone * this.getWCWidth() / 2);

        }

    }

}

1. 3.

   Define camera panning functions panBy() and panTo() by appending to the Camera class prototype. These two functions change the camera WC center by adding a delta to it or moving it to a new location.

    

Camera.prototype.panBy = function (dx, dy) {

    this.mWCCenter[0] += dx;

    this.mWCCenter[1] += dy;

}

Camera.prototype.panTo = function (cx, cy) {

    this.setWCCenter(cx, cy);

}

1. 4.

   Define functions to zoom the camera with respect to the center or a target position:

    

Camera.prototype.zoomBy = function (zoom) {

    if (zoom > 0) {

        this.setWCWidth(this.getWCWidth() * zoom);

    }

}

Camera.prototype.zoomTowards = function (pos, zoom) {

    let delta = [];

    vec2.sub(delta, pos, this.mWCCenter);

    vec2.scale(delta, delta, zoom - 1);

    vec2.sub(this.mWCCenter, this.mWCCenter, delta);

    this.zoomBy(zoom);

}

The zoomBy() function zooms with respect to the center of the camera, and the zoomTowards() function zooms with respect to a world coordinate position. If the zoom variable is greater than 1, the WC window size becomes larger, and you will see more of the world in a process we intuitively know as zooming out. A zoom value of less than 1 zooms in. Figure 7-3 shows the results of zoom=0.5 for zooming with respect to the center of WC and with respect to the position of the Hero object.

The Camera Interpolations Project

This project demonstrates the smoother and visually more appealing interpolated results from camera manipulation operations. You can see an example of this project running in Figure 7-5. The source code to this project is defined in the chapter7/7.2.camera_interpolations folder.

As in previous projects, you can find external resource files in the assets folder.

The Camera Shake and Object Oscillate Project

This project demonstrates how to implement damped simple harmonic motion to simulate object oscillation and the injection of pseudo-randomness to create a camera shake effect. You can see an example of this project running in Figure 7-7. This project is identical to the previous project except for an additional command to create object oscillation and camera shake effects. The source code to this project is defined in the chapter7/7.3.camera_shake_and_object_oscillate folder.

As in previous projects, you can find external resource files in the assets folder.

Abstract the Shake Behavior

The ability to shake the camera is a common and dynamic behavior in many games. However, it is important to recognize that the shake behavior can be applied to more than just the camera. That is, the shaking effect can be abstracted as the perturbation (shaking) of numerical value(s) such as a size, a point, or a position. In the case of camera shake, it just so happened that the numerical values being shaken represent the x and y positions of the camera. For this reason, the shake and associated supports should be general utility functions of the game engine so that they can be applied by the game developer to any numerical values. The following are the new utilities that will be defined:

• Oscillate: The base class that implements simple harmonic oscillation of a value over time

• Shake: An extension of the Oscillate class that introduces randomness to the magnitudes of the oscillations to simulate slight chaos of the shake effect on a value

• ShakeVec2: An extension of the Shake class that expands the Shake behavior to two values such as a position

Create the Oscillate Class to Model Simple Harmonic Motion

Because all of the described behaviors depend on simple oscillation, this should be implemented first ;

1. 1.

   Create a new file in the src/engine/utils folder and name it oscillate.js. Define a class named Oscillate and add the following code to construct the object:

    

class Oscillate {

    constructor(delta, frequency, duration) {

        this.mMag = delta;

        this.mCycles = duration; // cycles to complete the transition

        this.mOmega = frequency * 2 * Math.PI; // Converts to radians

        this.mNumCyclesLeft = duration;

    }

    ... implementation to follow ...

}

export default Oscillate;

The delta variable represents the initial displacements before damping, in WC space. The frequency parameter specifies how much to oscillate with a value of 1 representing one complete period of a cosine function. The duration parameter defines how long to oscillate in units of game loop updates.

1. 2.

   Define the damped simple harmonic motion:

    

_nextDampedHarmonic() {

    // computes (Cycles) * cos(Omega * t)

    let frac = this.mNumCyclesLeft / this.mCycles;

    return frac * frac * Math.cos((1 - frac) * this.mOmega);

}

Refer to Figure 7-8. mNumCyclesLeft is the number of cycles left in the oscillation, or k-t, and the frac variable, , is the damping factor. This function returns a value between -1 and 1 and can be scaled as needed.

1. 3.

   Define a protected function to retrieve the value of the next damped harmonic motion. This function may seem trivial and unnecessary. However, as you will observe in the next subsection, this function allows a shake subclass to overwrite and inject randomness.

    

// local/protected methods

_nextValue() {

    return (this._nextDampedHarmonic());

}

1. 4.

   Define functions to check for the end of the oscillation and for restarting the oscillation:

    

done() { return (this.mNumCyclesLeft <= 0); }

reStart() { this.mNumCyclesLeft = this.mCycles; }

1. 5.

   Lastly, define a public function to trigger the calculation of oscillation. Notice that the computed oscillation result must be scaled by the desired magnitude, mMag:

    

getNext() {

    this.mNumCyclesLeft--;

    let v = 0;

    if (!this.done()) {

        v = this._nextValue();

    }

    return (v * this.mMag);

}

Create the Shake Class to Randomize an Oscillation

You can now extend the oscillation behavior to convey a sense of shaking by introducing pseudo-randomness into the effect .

1. 1.

   Create a new file, shake.js, in the src/engine/utils folder. Define the Shake class to extend Oscillate and add the following code to construct the object:

    

import Oscillate from "./oscillate.js";

class Shake extends Oscillate {

    constructor(delta, frequency, duration) {

        super(delta, frequency, duration);

    }

    ... implementation to follow ...

}

export default Shake;

1. 2.

   Overwrite the _nextValue() to randomize the sign of the oscillation results as follows. Recall that the _nextValue() function is called from the public getNext() function to retrieve the oscillating value. While the results from the damped simple harmonic oscillation continuously and predictably decrease in magnitude, the associated signs of the values are randomized causing sudden and unexpected discontinuities conveying a sense of chaos from the results of a shake.

    

_nextValue() {

    let v = this._nextDampedHarmonic();

    let fx = (Math.random() > 0.5) ? -v : v;

    return fx;

}

Create the ShakeVec2 Class to Model the Shaking of a vec2, or a Position

You can now generalize the shake effect to support the shaking of two values simultaneously. This is a useful utility because positions in 2D games are two-value entities and positions are convenient targets for shake effects. For example, in this project, the shaking of the camera position, a two-value entity, simulates the camera shake effect.

The ShakeVec2 class extends the Shake class to support the shaking of a vec2 object, shaking the values in both the x and y dimensions. The x-dimension shaking is supported via an instance of the Shake object, while the y dimension is supported via the Shake class functionality that is defined in the super class.

1. 1.

   Create a new file, shake_vec2.js, in the src/engine/utils folder. Define the ShakeVec2 class to extend the Shake class. Similar to the constructor parameters of the Shake super classes, the deltas and freqs parameters are 2D, or vec2, versions of magnitude and frequency for shaking in the x and y dimensions. In the constructor, the xShake instance variable keeps track of shaking effect in the x dimension. Note the y-component parameters, array indices of 1, in the super() constructor invocation. The Shake super class keeps track of the shaking effect in the y dimension.

    

class ShakeVec2 extends Shake {

    constructor(deltas, freqs, duration) {

        super(deltas[1], freqs[1], duration);  // super in y-direction

        this.xShake = new Shake(deltas[0], freqs[0], duration);

    }

    ... implementation to follow ...

}

export default ShakeVec2;

1. 2.

   Extend the reStart() and getNext() functions to support the second dimension:

    

reStart() {

    super.reStart();

    this.xShake.reStart();

}

getNext() {

    let x = this.xShake.getNext();

    let y = super.getNext();

    return [x, y];

}

Lastly, remember to update the engine access file, index.js, to forward the newly defined Oscillate, Shake, and ShakeVec2 functionality to the client.

The Multiple Cameras Project

This project demonstrates how to represent multiple views in the game world with multiple Camera objects. You can see an example of this project running in Figure 7-9. The source code to this project is defined in the chapter7/7.4.multiple_cameras folder.

As in previous projects, you can find external resource files in the assets folder.

The Mouse Input Project

This project demonstrates mouse input support in the game engine. You can see an example of this project running in Figure 7-12. The source code to this project is defined in the chapter7/7.5.mouse_input folder.

As in previous projects, you can find external resource files in the assets folder.

Game Design Considerations

You’ve learned the basics of object interaction, and it’s a good time to start thinking about creating your first simple game mechanic and experimenting with the logical conditions and rules that constitute well-formed gameplay experiences. Many designers approach game creation from the top-down (meaning they start with an idea for an implementation of a specific genre like a real-time strategy, tower defense, or role-playing game), which we might expect in an industry like video games where the creators typically spend quite a bit of time as content consumers before transitioning into content makers. Game studios often reinforce this top-down design approach, assigning new staff to work under seasoned leads to learn best practices for whatever genre that particular studio works in. This has proven effective for training designers who can competently iterate on known genres, but it’s not always the best path to develop well-rounded creators who can design entirely new systems and mechanics from the ground-up.

The aforementioned might lead us to ask, “What makes gameplay well formed?” At a fundamental level, a game is an interactive experience where rules must be learned and applied to achieve a specified outcome; all games must meet this minimum criterion, including card, board, physical, video, and other game types. Taking it a step further, a good game is an interactive experience with rules people enjoy learning and applying to achieve an outcome they feel invested in. There’s quite a bit to unpack in this brief definition, of course, but as a general rule, players will enjoy a game more when the rules are discoverable, consistent, and make logical sense and when the outcome feels like a satisfactory reward for mastering those rules. This definition applies to both individual game mechanics and entire game experiences. To use a metaphor, it can be helpful to think of game designs as being built with letters (interactions) that form words (mechanics) that form sentences (levels) that ultimately form readable content (genres). Most new designers attempt to write novels before they know the alphabet, and everyone has played games where the mechanics and levels felt at best like sentences written with poor grammar and at worst like unsatisfying, random jumbles of unintelligible letters.

Over the next several chapters, you’ll learn about more advanced features in 2D game engines, including simulations of illumination and physical behaviors. You’ll also be introduced to a set of design techniques enabling you to deliver a complete and well-formed game level, integrating these techniques and utilizing more of the nine elements of game design discussed in Chapter 4 in an intentional way and working from the ground-up to deliver a unified experience. In the earliest stages of design exploration, it’s often helpful to focus only on creating and refining the basic game mechanics and interaction model; at this stage, try to avoid thinking about setting, meta-game, systems design, and the like (these will be folded into the design as it progresses).

The first design technique we’ll explore is a simple exercise that allows you to start learning the game design alphabet: an “escape the room” scenario with one simple mechanic, where you must accomplish a task in order to unlock a door and claim a reward. This exercise will help you develop insight into creating well-formed and logical rules that are discoverable and consistent, which is much easier to accomplish when the tasks are separated into basic interactions. You’ve already explored the beginnings of potential rule-based scenarios in earlier projects: recall the Keyboard Support project from Chapter 4, which suggested you might have players move a smaller square completely into the boundary of a larger square in order to trigger some kind of behavior. How might that single interaction (or “letter of the game alphabet”) combine to form a game mechanic (or “word”) that makes sense? Figure 7-13 sets the stage for the locked room puzzle.

The screen represented in Figure 7-13 is a useful starting place when exploring new mechanics. The goal for this exercise is to create one logical challenge that a player must complete to unlock the barrier and reach the reward. The specific nature of the task can be based on a wide range of elemental mechanics: it might involve jumping or shooting, puzzle solving, narrative situations, or the like. The key is to keep this first iteration simple (this first challenge should have a limited number of components contributing to the solution) and discoverable (players must be able to experiment and learn the rules of engagement so they can intentionally solve the challenge). You’ll add complexity and interest to the mechanic in later iterations, and you’ll see how elemental mechanics can be evolved to support many kinds of game types.

Figure 7-14 sets the stage for a logical relationship mechanic where players must interact with objects in the environment to learn the rules.

It’s not immediately apparent just by looking at Figure 7-14 what the player needs to do to unlock the barrier, so they must experiment in order to learn the rules by which the game world operates; it’s this experimentation that forms the core element of a game mechanic driving players forward through the level, and the mechanic will be more or less satisfying based on the discoverability and logical consistency of its rules. In this example, imagine that as the player moves around the game screen, they notice that when the hero character interacts with an object, it always “activates” with a highlight, as shown in Figure 7-15, and sometimes causes a section of the lock icon and one-third of the ring around the lock icon to glow. Some shapes, however, will not cause the lock and ring to glow when activated, as shown in Figure 7-16.

Astute players will learn the rules for this puzzle fairly quickly. Can you guess what they might be just from looking at Figures 7-15 and 7-16? If you’re feeling stuck, Figure 7-17 should provide enough information to solve the puzzle.

You (and players) should now have all required clues to learn the rules of this mechanic and solve the puzzle. There are three shapes the player can interact with and only one instance of each shape per row; the shapes are representations of the top, middle, and bottom of the lock icon, and as shown in Figure 7-15, activating the circle shape caused the corresponding section of the lock to glow. Figure 7-16, however, did not cause the corresponding section of the lock to glow, and the difference is the “hook” for this mechanic: sections of the lock must be activated in the correct relative position: top in the top row, middle in the middle row, bottom on the bottom (you might also choose to require that players activate them in the correct sequence starting with the top section, although that requirement is not discoverable just from looking at Figures 7-15 to 7-17).

Congratulations, you’ve now created a well-formed and logically consistent (if simple) puzzle, with all of the elements needed to build a larger and more ambitious level! This unlocking sequence is a game mechanic without narrative context: the game screen is intentionally devoid of game setting, visual style, or genre alignment at this stage of design because we don’t want to burden our exploration yet with any preconceived expectations. It can benefit you as a designer to spend time exploring game mechanics in their purest form before adding higher-level game elements like narrative and genre, and you’ll likely be surprised at the unexpected directions, these simple mechanics will take you as you build them out.

Simple mechanics like the one in this example can be described as “complete a multistage task in the correct sequence to achieve a goal” and are featured in many kinds of games; any game that requires players to collect parts of an object and combine them in an inventory to complete a challenge, for example, utilizes this mechanic. Individual mechanics can also be combined with other mechanics and game features to form compound elements that add complexity and flavor to your game experience.

The camera exercises in this chapter provide good examples for how you might add interest to a single mechanic; the simple Camera Manipulations project, for example, demonstrates a method for advancing game action. Imagine in the previous example that after a player receives a reward for unlocking the barrier, they move the hero object to the right side of the screen and advance to a new “room” or area. Now imagine how gameplay would change if the camera advanced the screen at a fixed rate when the level started; the addition of autoscrolling changes this mechanic considerably because the player must solve the puzzle and unlock the barrier before the advancing barrier pushes the player off the screen. The first instance creates a leisurely puzzle-solving game experience, while the latter increases the tension considerably by giving the player a limited amount of time to complete each screen. In an autoscrolling implementation, how might you lay out the game screen to ensure the player had sufficient time to learn the rules and solve the puzzle?

The Multiple Cameras project can be especially useful as a mini-map that provides information about places in the game world not currently displayed on the game screen; in the case of the previous exercise, imagine that the locked barrier appeared somewhere else in the game world other than the player’s current screen and that a secondary camera acting as a mini-map displayed a zoomed out view of the entire game world map. As the game designer, you might want to let the player know when they complete a task that allows them to advance and provide information about where they need to go next, so in this case, you might flash a beacon on the mini-map calling attention to the barrier that just unlocked and showing the player where to go. In the context of our “game design is like a written language” metaphor, adding additional elements like camera behavior to enhance or extend a simple mechanic is one way to begin forming “adjectives” that add interest to the basic nouns and verbs we’ve been creating from the letters in the game design alphabet.

A game designer’s primary challenge is typically to create scenarios that require clever experimentation while maintaining logical consistency; it’s perfectly fine to frustrate players by creating devious scenarios requiring creative problem solving (we call this “good” frustration), but it’s generally considered poor design to frustrate players by creating scenarios that are logically inconsistent and make players feel that they succeeded in a challenge only by random luck (“bad” frustration). Think back to the games you’ve played that have resulted in bad frustration: where did they go wrong, and what might the designers have done to improve the experience?

The locked room scenario is a useful design tool because it forces you to construct basic mechanics, but you might be surprised at the variety of scenarios that can result from this exercise. Try a few different approaches to the locked room puzzle and see where the design process takes you, but keep it simple. For now, stay focused on one-step events to unlock the room that require players to learn only one rule. You’ll revisit this exercise in the next chapter and begin creating more ambitious mechanics that add additional challenges.