Use these names when naming attack sprites and attack hurtbox sprites. For example, your dash attack should consist of dattack_strip10.png and dattack_hurt_strip10.png.
Attack Names
By George — February 11, 2019
By George — February 11, 2019
Use these names when naming attack sprites and attack hurtbox sprites. For example, your dash attack should consist of dattack_strip10.png and dattack_hurt_strip10.png.
By George — February 11, 2019
These are the names you will have to use when naming your sprites. For example, to automatically replace the double jump animation with a 9 frame sprite, you will name the sprite doublejump_strip9.png. Other names than those listed are acceptable for sprites, but will not be automatically used for any states.
By George — February 11, 2019
A sprite should be a strip of animation frames, sequenced one after another from the left to the right. All frames should have the same dimensions. Sprites should be named in the following pattern: [name]_strip[frames].png. For example: walk_strip8.png, telling the parser the animation has 8 frames.
To convert a gif into a sprite sheet, you can either use Game Maker to import and export it as a .png or use an online converter like this one (use the “Stack Horizontally” option to make sure everything is on a single row).
Hurtbox sprites for non-attack states (_hurtbox, _crouchbox, _hurtbox_air, _hitstun_hurtbox) use rectangular collision. Hurtbox sprites for attacks (_hurt sprites) use precise collision instead.
The origin for all sprites is set to top left (0, 0) by default. To help place origins correctly, use the Rivals Workshop Helper.
You can directly reference any custom sprite by calling sprite_get( name:string ) in animation.gml. For example, forcing walk animation to use the dash sprite instead:
if (state == PS_WALK) {
sprite_index = sprite_get( "dash" );
}
(reference on available player states).
You can also change offset and bounding boxes for your sprites in load.gml. For example:
// changing offset of the jump sprite to [94, 138]:
sprite_change_offset( "jump", 94, 138 );
// making it precise:
sprite_change_collision_mask( "jump", true, 0, 0, 0, 0, 0, 0 );
Hit Particles have a couple differences to how normal sprites work; visit the page for Hit Particles to learn more about how to change those for your character.
By George — February 10, 2019
Custom stages can be created directly in the game’s Stage Editor by selecting (+ NEW STAGE) in the Workshop menu. There are two types of custom stages:
Advanced custom stages are structured similarly to other custom items, with config.ini and the following folders: /sprites and /sounds. You can read more about this structure on the introduction page, use the default blank stage template in the editor program, or reference Bamboo Lodge (our official example for an Advanced Stage).
For Advanced stages, the core stage folder should also include:
Advanced stages support a total of 9 image layers including 1 ground layer, 2 foreground (FG) layers, and 6 background (BG) layers.
The image files are automatically detected in the /sprites directory upon loading the stage, using the following naming format: bg#_strip#.png, where “bg#” denotes the layer number and “strip#” denotes the number of animation frames the image contains.
By default, all graphics (aside from ground_strip#.png) are positioned at the absolute center of the stage, but this can be changed by adjusting the Offset X and Offset Y options in the editor’s Stage Parameters menu.
In Aether mode, stages will use image files that have the prefix “a_” if one exists, otherwise using the normal version. For example, you can override the ground layer’s image in aether mode by adding a file named “a_ground.png”.
In order to conserve texture memory and ensure smooth performance, it is recommended that you use smaller background graphics combined with the BG-Tiling option in the editor’s Stage Parameters menu.
Custom stages have access to all stage music from the game soundtrack in the editor’s Stage Parameters menu, and also support up to 4 custom tracks like the base stages.
To add a custom track, go to the /sounds directory and add or replace music_loop.ogg with an ogg file of your choice. Additional tracks can also be included under the names music_loop2.ogg, music_loop3.ogg, and music_loop4.ogg.
The game will randomly select one of these ogg files to use as the background music when the stage begins.
Visit the stage scripting page to learn more about writing code for Advanced stages.
By George — February 10, 2019
Custom buddies are structured the same way as custom characters, with config.ini and the following folders: /sprites, /scripts, /sounds. You can read more about this structure on the introduction page, use a blank buddy template, or reference our example buddy Sandbert Jr.
The core buddy folder should also include:
A buddy can only execute load.gml and update.gml custom scripts.
Buddies’ animation names also differ from the ones used by characters.
By default a buddy is not affected by its owner’s custom colors. However, you can define a list of characters you want to affect your buddy’s colors by calling add_compatiable_urls(). The function accepts both urls of published workshop characters and ▼ default character indexes. If you want the buddy to be affected by any character’s custom colors, pass all to the function.
Example, called from load.gml:
// this buddy can only borrow Zetterburn's and Sandbert's custom colors:
add_compatiable_urls( CH_ZETTERBURN, 1865940669 );
// this buddy will borrow any character's custom colors (including both workshop and default ones):
add_compatiable_urls( all );
These are all the variables you can access for pet_obj:
Variable | Default | Description |
---|---|---|
type | 0 | The type of buddy 0 = grounded 1 = flying |
can_switch_type | false | Whether the buddy will automatically switch type after going through the wait animation (in the air, the buddy will fly toward their landing point, then go into the wait animation) |
idle_spr | sprite_get( “idle” ) | The sprite to loop when idle |
run_spr | sprite_get( “run” ) | The sprite to loop when running |
turn_spr | sprite_get( “turn” ) | The sprite to play when turning around (should turn from facing left to right) |
ledge_spr | sprite_get( “ledge” ) | The sprite to play when idling at ledge |
wait_spr | sprite_get( “wait” ) | The sprite to play when idling normally |
taunt_spr | sprite_get( “taunt” ) | The sprite to play when taunting |
pet_w | 30 | The approximate width of the buddy, in pixels |
run_speed | 3 | The speed of the run state, in pixels per frame |
max_run_dist | 200 | The distance you can get away from the buddy before it starts to run toward you. Should be a fair bit more than double pet_w to avoid stuttering |
state | The current state of the buddy: “idle” “run” “taunt” |
|
teetering | If the buddy is in their ledge animation. Only relevant if state == “idle” | |
waiting | If the buddy is in their wait animation. Only relevant if state == “idle” | |
state_timer | The number of frames since starting the current state. This value is also reset when starting the ledge or wait animations |
In case can_switch_type is set to true, you will also need to initialize the following variables in load.gml:
Variable | Description |
---|---|
grnd_idle_spr | The sprite to loop when idle on ground |
grnd_run_spr | The sprite to loop when running on ground |
grnd_turn_spr | The sprite to play when turning on ground. Should turn from facing left to right |
grnd_wait_spr | The sprite to play when idling on ground. Should transition from grnd_idle_spr to air_idle_spr) |
grnd_taunt_spr | The sprite to play when taunting on ground |
air_idle_spr | The sprite to loop when idle in the air |
air_run_spr | The sprite to loop when moving in the air |
air_turn_spr | The sprite to play when turning in the air. Should turn from facing left to right |
air_wait_spr | The sprite to play when idling in the air. Should transition from air_idle_spr to grnd_idle_spr) |
air_taunt_spr | The sprite to play when taunting in the air |