Built-in Doodad Script Templates #47

New Issue

kirsle · 2021-08-16T03:51:26Z

kirsle commented

2021-08-16 03:51:26 +00:00

Make it easy to make basic solid or hazard doodads in-game, no scripting required.

In-game Script Selection UI

In the in-game Doodad Editor there should be a UI window callable for managing the JavaScript source of the doodad being edited.

Features would include:

Browse the filesystem for the user to select their own JS file.
Select from a set of built-in, generic Doodad scripts built-in.

The idea is especially that the user can draw a "hazard doodad" like a Prickly Cactus, draw the sprite in-game, be able to use a "hazard template script" that marks the whole hitbox as a FailLevel on collision.

Built-in Script Templates

Specific ideas:

Solid.js

The whole surface of the doodad acts as a solid obstacle.

Hazard.js

The whole surface of the doodad is dangerous, like fire pixels.

Warp Door.js

The doodad acts like a warp door. The frames of animation are assumed to go from closed to opening; the door will animate them forwards and in reverse for the door to swing open and shut.

State (Blue/Orange).js

Make it easy for the user to create their own boolean state blocks. The script will assume two frames in the doodad for the two states.

The doodad would behave just like the standard blue/orange solid state blocks.

Player Character.js

This one is doable, some ideas:

Have a "New Doodad Template" where the user deliberately wants to make a
custom player character.
The Doodad will initialize with a bunch of pre-built layers named with
standard names like "walk-left-1" similar to existing characters.
The JS template would assign animations by those names and generally do
what you expect.

This should work well since all player characters are very basic right now anyway, nothing but animations and keypress handlers to change animations.

Basic A.I. Scripts?

"Walk back and forth," etc. - maybe? Handling animations may be tricky tho.

Hitboxes?

Currently, Doodads define their hitbox at run-time during Play Mode by calling Self.SetHitbox(), and most doodads have hitboxes smaller than their square canvas size.

Hitboxes may be hoisted to top-level Doodad attributes so they can be defined inside the editor. The "Solid" and "Hazard" templates would depend on the hitbox size of the user's actual doodad if they don't want the hitboxes to be the whole square!

HasInventory, etc.?

Should attributes like these also be hoisted to top-level Doodad flags? Scripts don't often toggle these on and off anyway:

HasGravity
HasInventory
IsMobile

In-game UI could show a Doodad Settings window with checkbox lists like these, and free up the JS scripts from needing to call these. Of course, the script can still call them if it wants to.

Make it easy to make basic solid or hazard doodads in-game, no scripting required. ## In-game Script Selection UI In the in-game Doodad Editor there should be a UI window callable for managing the JavaScript source of the doodad being edited. Features would include: * Browse the filesystem for the user to select their own JS file. * Select from a set of built-in, generic Doodad scripts built-in. The idea is especially that the user can draw a "hazard doodad" like a Prickly Cactus, draw the sprite in-game, be able to use a "hazard template script" that marks the whole hitbox as a FailLevel on collision. ## Built-in Script Templates Specific ideas: ### Solid.js The whole surface of the doodad acts as a solid obstacle. ### Hazard.js The whole surface of the doodad is dangerous, like fire pixels. ### Warp Door.js The doodad acts like a warp door. The frames of animation are assumed to go from closed to opening; the door will animate them forwards and in reverse for the door to swing open and shut. ### State (Blue/Orange).js Make it easy for the user to create their own boolean state blocks. The script will assume two frames in the doodad for the two states. The doodad would behave just like the standard blue/orange solid state blocks. ### Player Character.js This one is doable, some ideas: * Have a "New Doodad Template" where the user deliberately wants to make a custom player character. * The Doodad will initialize with a bunch of pre-built layers named with standard names like "walk-left-1" similar to existing characters. * The JS template would assign animations by those names and generally do what you expect. This should work well since all player characters are very basic right now anyway, nothing but animations and keypress handlers to change animations. ### Basic A.I. Scripts? "Walk back and forth," etc. - maybe? Handling animations may be tricky tho. ## Hitboxes? Currently, Doodads define their hitbox at run-time during Play Mode by calling Self.SetHitbox(), and most doodads have hitboxes smaller than their square canvas size. Hitboxes may be hoisted to top-level Doodad attributes so they can be defined inside the editor. The "Solid" and "Hazard" templates would depend on the hitbox size of the user's actual doodad if they don't want the hitboxes to be the whole square! ## HasInventory, etc.? Should attributes like these also be hoisted to top-level Doodad flags? Scripts don't often toggle these on and off anyway: * HasGravity * HasInventory * IsMobile In-game UI could show a Doodad Settings window with checkbox lists like these, and free up the JS scripts from needing to call these. Of course, the script can still call them if it wants to.

kirsle added the

enhancement

doodad

labels 2021-08-16 03:51:26 +00:00

Sign in to join this conversation.