Scrolling Game Development Kit UI Help Up to Sprites and Paths

Defining Sprite Motion

This is part of a series of pages describing the Sprites and Paths dialog. This page describes the Motion tab.

This tab defines what controls a sprite's motions. The first field defines which tiles on the sprite's layer the sprite sees as solid. This affects the sprite's motion in that the sprite is prevented from moving through solid objects. To define this, you must have a "Solidity Definition" which can be created on the Tile Categories dialog. A Solidity Definition categorizes tiles within a tileset into categories representing various shapes, such as "solid", "uphill", "downhill" etc.

In order for the "Solid tiles" list to be populated, a path must be selected in the "Paths" list. This is because the path is the only reference a sprite has to the layer in which it resides, and therefore the only reference to the tileset which that layer uses. In order for the dialog to know which solidity definitions are applicable, it must know on which tileset the sprites using this template will be travelling.

The "Up requires solid" checkbox determines whether this sprite can go up when there's nothing solid underneath it. For a sprite that is supposed to be walking on the ground (with a side view, gravity going downwards) it doesn't make sense for the sprite to go up whenever it wants. Checking this box ensures that "Up" will only work when the sprite is in contact with solid ground. And when this is the case, instead of slowly accelerating upward, the motion acts more like a jump, immediately skipping to the velocity specified by "Jump height" (higher velocity = higher jump). If the sprite's gravity goes upwards, everything is reversed and "Up requires solid" effectively becomes "Down requires solid". Note: This setting does not apply to 360/10 sprites! I can't make sense of this setting for this type of sprite and it's therefore not implemented.

The "Controlled by" setting is the most interesting. This determines who's responsible for the sprite's movement. The possible values are:

The movement speed setting determines how fast the sprite can move (maximum speed). The maximum value is 10 pixels per frame and the minimum value is 1 pixel per frame. For sprites controlled by anything other than the input device, the movement speed determines how fast the sprites usually go since automatically controlled sprites are almost always in motion.

The jump height setting determines how high a sprite can jump if the "Up requires solid" box is checked. Before version 1.3, this value came from the movement speed setting. When loading a project older than version 1.3, this setting will default to the movement speed setting. But now you can specify a jump height higher (or shorter) than the movement speed setting would dictate. Now you can get more realistic jumps. Rather than affecting the height of the jump directly, this setting only affects the vertical velocity that the sprite adopts when up is pressed while standing on solid ground. (When down is pressed if gravity goes upward.)

The gravity power setting determines what kind of gravity this sprite experiences. Each sprite template can have its own gravity setting -- there is no overall map or project gravity setting. The maximum value in either direction is 1 pixel per frame per frame. Since the acceleration speed is also hard coded at 1 pixel per frame per frame, setting gravity at the most extreme values exactly counteracts acceleration. For a 360 sprite, this means that gravity can barely be counteracted when pointing straight up, but cannot be overcome. For any other type of sprite with "Up requires solid" checked, since acceleration for this type of sprite is instantaneous to maximum velocity, maximum gravity can be temporarily overcome.

The inertia setting determines how much of the sprite's velocity is retained after each frame. The right end of the scale corresponds to perfect inertia in which an object in motion remains in motion (unless it hits something). Setting the slider to the left end of the scale will cause the sprite to stop moving immediately when the thrust ceases, unless there is gravity.

There are two new settings with version 1.3 on this tab: