Doodad Ideas: Initial mobs, warp doors, checkpoints, etc. #13

New Issue

kirsle · 2019-07-15T17:32:04Z

kirsle commented

2019-07-15 17:32:04 +00:00

Doodle is in need of a handful more basic doodads to make interesting levels. Here's a set of ideas for possible new ones to add.

See also: the existing doodads in the game so far.

Mobs

Frog

The Frog would travel left and right by hopping, waiting a moment in between hops. If it collides with a wall (its movement was blocked) it immediately bounces off the wall and goes the other direction, without losing any momentum.

When swimming/underwater physics are added, the Frog would switch to free movement and have sprites accordingly.

Appearance: a tropical, multi-colored frog.

Crusher

A large, block-shaped enemy that sits high up in the air and attempts to drop onto the player and crush them.

Appearance: square shaped (rounded corners), red or blue skin, and wearing an iron helmet with a flat top. It should have a face consisting of eyes and a mouth.

Behavior:

If the player is not close by the monster would sleep (eyes closed)
When the player gets near the monster should "peek" in the direction of the player (one eye open, the other eye tightened in a wink)
When the player gets very close (directly under it or nearly under it), face turns angry and the crusher drops down until it hits the ground. It then slowly rises to its original height.
The top edge (helmet) is safe to stand on - the player could ride it back up.

Hostility:

The top, left and right edges are solid and don't hurt the player.
The bottom is dangerous only while it is falling. If not falling, the bottom is solid.

Snake

See #61

Bird

Status: Done.

Some kinda flying bird mob may be easy to design and with relatively few sprites needed.

Its AI behavior should be programmed to:

Fly left and right while maintaining its Y-coord of where it was placed on the level.
- When it comes near a wall, it should turn around, like the Red Azulian; but it should not TOUCH the wall. It should scan ahead and turn around before colliding.
It should dive bomb the player when it comes within range.
- Scan a 45-degree angle downward from the bird's current position and in the direction it is currently facing. If the player is spotted (and no solid wall is in the way) begin the diving animation (probably a single sprite).
- Upon hitting the player or touching the floor, it should leave the dive animation and slowly fly back up until it reaches its original Y-coordinate.
- If it encounters a wall while flying back up it should change direction and continue flying up in the opposite direction.

Thief

Status: Done.

The Thief would be a human character dressed in a cloak and pointy hat, purple/blackish.

The Thief will walk left and right along a surface similar to the Azulian.

When the Thief makes contact with the player character, he steals everything in your inventory (keys, etc.). If the player is not carrying any items, nothing happens. A message should flash on screen when your items are taken.

The Thief has an inventory and can pick up items itself and can unlock doors if it carries the right keys. The Thief does not steal items that it already has enough of, e.g., the four Colored Keys have no quantity and the thief needs only one. If the Thief already has the Green Key it will not steal another Green Key from the player.

The thief's behavior could lead to some interesting companion levels:

Give him a key at level start so he has a kind of door only he can open.
At some point the player contacts the thief and gives additional keys to him.

Azulians

Status: Done.

The current Red Azulian mob is a placeholder that simply walks left and right along the ground, changing direction after bumping into a wall, and does not harm the player (due to lack of HP system added to the game).

The Azulian should have a more aggressive AI that pathfinds towards the player character and jumps at them, causing damage.

Note: this AI may be given to a more official mob of some variety and only copied as the AI for the secret Azulian enemies.

General: A.I. Patterns

Just some quick ideas of basic AI patterns. Mobs should be designed around some of these patterns but exact details of what the mob looks like are to be determined.

Simple walking back-and-forth, falling off ledges (like the Red Azulian currently)
Walking back-and-forth, but move quicker when facing the player character.
Walk back-and-forth, avoid falling from ledges.
Flying back-and-forth without touching the ground (like the Bird described above)

Doodads

Anvils

Status: Done.

Anvils will be a simple doodad affected by gravity. If it is in freefall and it collides with another doodad from the top, it would harm the doodad it falls on:

The player character and other creatures (Bird, Frog, Azulians) would take damage. In the short-term (before HP bars implemented), this kills the player or destroys the mobile doodad.
If it falls on a crumbly floor, it should trigger the crumble-and-fall animation and then continue falling.
If it falls on a solid doodad (top of a closed door, etc.) it just lands on top and ceases falling.

Movable Blocks

Status: Done.

These should be large (taller than the player character) boxes that can be pushed left or right, and fall with gravity. Appearance would have 4 arrows on it to hint it can be pushed.

Use cases:

The player can push them and jump on top to reach higher ledges.
Puzzles.

TNT Blocks + Destructible Terrain

TNT blocks would act like Movable Blocks except if they are linked to a power source and receive a power signal, they'll detonate, destroying nearby level pixels that have a "Destructible" attribute on them.

The TNT blocks would come in two varities:

Respawning blocks: after they explode, they will respawn at their original location after a time.
Non-respawning blocks

They should be visually distinct from each other.

Collectible "Key Gems"

There would be four kinds of 'gem stones' that the player can pick up and place into appropriately shaped sockets, to create collectibles within a level:

Diamond shape
Triangle shape
Square shape
Circle shape

Each gemstone would be a different color similarly to the colored keys. The sockets would appear as stone blocks with an engraved shape fitting the gem. When a mobile doodad holding a gemstone makes contact with the socket, the gemstone is removed from their inventory and appears in the socket.

There may be a few variations on the socket doodads:

Single sockets that accept one gemstone: they would emit a signal (power?) when the gemstone is filled in, which could unlock a door for the player to continue.
Full sockets having all 4 shapes available: it would require all 4 gems before it activates its signal, so the player would need to collect them all.

Treasure Chest

The Chest should be able to hold an item or other doodad and release it upon interaction with the player.

A Chest will be dragged into a level, and then with the Link Tool you connect it to the item doodad that it will contain. The item can be placed anywhere in the level, probably close by to the chest, its level position doesn't really matter.

When the Chest initializes in the level on Play Mode, it should emit a hide signal to its linked item, which should turn the item invisible. (This may be handled at the game engine level rather than each doodad needing to be programmed to respond to this; tho they can still listen for the signal if they need custom code?)

When the treasure chest is opened by the player:

Teleport the linked doodad onto the chest, and make it visible.
Animate the item moving from "inside" the chest to hovering a number of pixels above the top of the chest sprite. During this animation, the item should NOT interact with the player, for example, a Key should NOT be picked up if the player is already 'touching' its sprite (as they likely will be).
After the item lingers above the chest for a moment, it will become active to be interacted with (a key may disappear into the user's inventory at this time).
In case the item doesn't disappear, after a moment it should "fall" back down to match the Y-coordinate of the Treasure Chest, and then the Chest itself should disappear out of existence.

The latter covers an edge case: what if the user linked a Chest with (say) a Button or some other doodad that isn't an item? The Button would not disappear into the user's inventory the way a Key would, so it should fall back to the ground taking the place of the treasure chest and remain there the rest of the level. This could also allow monsters to be kept in chests too (during the "rise above the chest" animation, a monster would not damage the player as interaction is disabled).

If a Treasure Chest is not linked to any doodad, the chest should immediately display an "opened" sprite and be purely decorative and non-interactable to the player.

Checkpoints

Status: Done.

The Checkpoint doodad will remember the player's progress when they arrive at the checkpoint on a level. In case they run out of HP they will respawn at the last checkpoint touched.

~~Each Checkpoint can only be activated one time.~~
The most-recently activated Checkpoint becomes the player's respawn point on the level.

~~However, if you use the Link Tool and connect two Checkpoints to each other:~~

Activating one Checkpoint will deactivate any linked checkpoint.

So for larger puzzle levels you could have a pair of mutually-exclusive checkpoints that can be activated in alternating order, and behave more like Mario Maker and less like Sonic the Hedgehog.

Warp Doors

Status: Done.

Warp Doors can be entered by the player which will take them to another door somewhere else on the same level.

To set up the warp you would drag in 2 doors and then use the Link Tool to connect them together. When the player "activates" a Warp Door it should play an opening animation, hide the player sprite, close the door and then the camera should scroll until the linked door is on screen and the player will appear there with the animations in reverse on that door.

In case a Warp Door is linked to 2 or more doors, the door the player is taken to should be "random" (fixed RNG seed at level initialization for predictable behavior).

State Doors

These would be a variant on the Warp Door that combines it with the ON/OFF State Block doodads. The doors would come in an Orange and a Blue variety similar to the state blocks.

When the state is "BLUE", the Blue Door should be solid and usable and the Orange Door should render as a hollow dotted rectangle. When the state becomes "ORANGE" the two doors shall switch roles.

Iron Locked Doors

The current Locked Door doodads come in 4 colors and have corresponding keys; once the player holds the key they can unlock unlimited doors of the matching color.

An Iron Locked Door however would be different, and act like "small key doors" in Zelda-like games.

Small Keys would be collectable items with a quantity and each key can unlock an Iron Door one time, which consumes the key.

Technical Doodads

Power Source

Status: Done.

These doodads would emit a "power(true)" signal immediately upon level load.

Any device linked to the doodad immediately enters its powered state, e.g., electric doors will open. Note: the sound effect spam of all doors opening at once should be suppressed by the game engine somehow.

If a Power Inverter receives a power(true) signal from a linked button, it will emit a power(false) signal to its other linked doodads. Note: infinite loops should be prevented, maybe Message.Publish() won't send a message on the same tick to the link which had sent a message this tick, so two power inverters linked together won't bounce back and forth.

~~The engine should be able to handle scripts getting caught in infinite loops, e.g. by destroying the actors and flashing an error message.~~

Update: it seems you get into a deadlock if two doodads publish to each other at the same time. Two of these doodads linked together couldn't receive the other's signal.

Invisible Goal and Checkpoint Regions

Status: Done.

Invisible Fire Region

Status: Done.

An invisible doodad that triggers a fail condition.

Stall Player

Status: Done.

A region that freezes the player character for 250ms one time, to stall the player in case of time-sensitive cinematic events and avoid the player racing the other characters.

If it receives a power(true) signal, it will reset the trap and stall the player again.

Invisible Start Flag

Set a spawn point without a visible flag.

Note: needs to make the start-flag.doodad non special. Use a doodad tag? Maybe add an official doodad tag named "class" with values being like "spawnpoint" or "warpdoor" (the latter which also depends on names to ID one another).

Gravity ON/OFF

Gravity regions that change the effect of gravity for any doodad that passes thru it.

Gravity ON
Gravity OFF: trigger free movement mode
Gravity INVERSE: change the direction of gravity?
Gravity LOW/HIGH: change the intensity of gravity (low grav levels)

Link Tool: apply gravity to another doodad whether or not it expected it. Make Keys fall with gravity! Ground the Bird! Let the Azulian walk on thin air!

Invisible Button

A region that emits a power signal to linked doodads when a mobile doodad enters it.

Invisible Warp Door

This doodad should be smallish in size and behave like an instant Warp Door for any mobile doodad -- not only the player character.

Link it to an exit door and doodads which touch the invisible warp will be teleported and exit from the other door.

TBD: how can the receiving door be invisible too? Maybe this doodad makes the exit door hidden too?

Thief Region

An invisible region which behaves like the Thief, removing all items from the inventory of the doodad who passes it.

Unlike the Thief, it will take infinite copies of singleton items like the Colored Keys, always emptying the inventory.

Clocks

Clocks could come in a few varieties (5 seconds, 10 seconds, etc.) and have a clock icon and their number of seconds in their sprite.

To linked doodads they would behave as a switch; on their interval sending switch:toggled and power(true) signals so linked doors will open and close etc.

Camera

A camera or TV monitor doodad could direct attention to a spot elsewhere in the level.

The camera would be Linked to its subject of interest, which could be any kind of doodad. When the player character activates the camera, the Canvas's focused doodad will switch to the camera's linked partner, which will cause the canvas to scroll until the doodad is in view -- same as how it follows the player character.

When the player character leaves the camera or presses Activate again, gameplay focus returns to the player character. There should be a dedicated function for this, the player character should be easy to focus back to no matter how quickly conflicting doodad scripts might run.

Doodle is in need of a handful more basic doodads to make interesting levels. Here's a set of ideas for possible new ones to add. See also: [the existing doodads in the game so far.](https://www.sketchymaze.com/guidebook/doodads.html) # Mobs ## Frog The Frog would travel left and right by hopping, waiting a moment in between hops. If it collides with a wall (its movement was blocked) it immediately bounces off the wall and goes the other direction, without losing any momentum. When swimming/underwater physics are added, the Frog would switch to free movement and have sprites accordingly. Appearance: a tropical, multi-colored frog. ## Crusher A large, block-shaped enemy that sits high up in the air and attempts to drop onto the player and crush them. Appearance: square shaped (rounded corners), red or blue skin, and wearing an iron helmet with a flat top. It should have a face consisting of eyes and a mouth. Behavior: * If the player is not close by the monster would sleep (eyes closed) * When the player gets near the monster should "peek" in the direction of the player (one eye open, the other eye tightened in a wink) * When the player gets _very_ close (directly under it or nearly under it), face turns angry and the crusher drops down until it hits the ground. It then slowly rises to its original height. * The top edge (helmet) is safe to stand on - the player could ride it back up. Hostility: * The top, left and right edges are solid and don't hurt the player. * The bottom is dangerous only while it is falling. If not falling, the bottom is solid. ## Snake See #61 ## ~~Bird~~ **Status:** Done. Some kinda flying bird mob may be easy to design and with relatively few sprites needed. Its AI behavior should be programmed to: * Fly left and right while maintaining its Y-coord of where it was placed on the level. * When it comes near a wall, it should turn around, like the Red Azulian; but it should not TOUCH the wall. It should scan ahead and turn around before colliding. * It should dive bomb the player when it comes within range. * Scan a 45-degree angle downward from the bird's current position and in the direction it is currently facing. If the player is spotted (and no solid wall is in the way) begin the diving animation (probably a single sprite). * Upon hitting the player or touching the floor, it should leave the dive animation and slowly fly back up until it reaches its original Y-coordinate. * If it encounters a wall while flying back up it should change direction and continue flying up in the opposite direction. ## ~~Thief~~ **Status:** Done. The Thief would be a human character dressed in a cloak and pointy hat, purple/blackish. The Thief will walk left and right along a surface similar to the Azulian. When the Thief makes contact with the player character, he steals everything in your inventory (keys, etc.). If the player is not carrying any items, nothing happens. A message should flash on screen when your items are taken. The Thief has an inventory and can pick up items itself and can unlock doors if it carries the right keys. The Thief does **not** steal items that it already has enough of, e.g., the four Colored Keys have no quantity and the thief needs only one. If the Thief already has the Green Key it will not steal another Green Key from the player. The thief's behavior could lead to some interesting companion levels: * Give him a key at level start so he has a kind of door only he can open. * At some point the player contacts the thief and gives additional keys to him. ## ~~Azulians~~ **Status:** Done. The current Red Azulian mob is a placeholder that simply walks left and right along the ground, changing direction after bumping into a wall, and does not harm the player (due to lack of HP system added to the game). The Azulian should have a more aggressive AI that pathfinds towards the player character and jumps at them, causing damage. Note: this AI may be given to a more official mob of some variety and only copied as the AI for the secret Azulian enemies. ## General: A.I. Patterns Just some quick ideas of basic AI patterns. Mobs should be designed around some of these patterns but exact details of what the mob looks like are to be determined. * Simple walking back-and-forth, falling off ledges (like the Red Azulian currently) * Walking back-and-forth, but move quicker when facing the player character. * Walk back-and-forth, avoid falling from ledges. * Flying back-and-forth without touching the ground (like the Bird described above) # Doodads ## ~~Anvils~~ **Status: Done.** Anvils will be a simple doodad affected by gravity. If it is in freefall and it collides with another doodad from the top, it would harm the doodad it falls on: * The player character and other creatures (Bird, Frog, Azulians) would take damage. In the short-term (before HP bars implemented), this kills the player or destroys the mobile doodad. * If it falls on a crumbly floor, it should trigger the crumble-and-fall animation and then continue falling. * If it falls on a solid doodad (top of a closed door, etc.) it just lands on top and ceases falling. ## ~~Movable Blocks~~ **Status: Done.** These should be _large_ (taller than the player character) boxes that can be pushed left or right, and fall with gravity. Appearance would have 4 arrows on it to hint it can be pushed. Use cases: * The player can push them and jump on top to reach higher ledges. * Puzzles. ## TNT Blocks + Destructible Terrain TNT blocks would act like Movable Blocks except if they are linked to a power source and receive a power signal, they'll detonate, destroying nearby level pixels that have a "Destructible" attribute on them. The TNT blocks would come in two varities: * Respawning blocks: after they explode, they will respawn at their original location after a time. * Non-respawning blocks They should be visually distinct from each other. ## Collectible "Key Gems" There would be four kinds of 'gem stones' that the player can pick up and place into appropriately shaped sockets, to create collectibles within a level: * Diamond shape * Triangle shape * Square shape * Circle shape Each gemstone would be a different color similarly to the colored keys. The sockets would appear as stone blocks with an engraved shape fitting the gem. When a mobile doodad holding a gemstone makes contact with the socket, the gemstone is removed from their inventory and appears in the socket. There may be a few variations on the socket doodads: * Single sockets that accept one gemstone: they would emit a signal (power?) when the gemstone is filled in, which could unlock a door for the player to continue. * Full sockets having all 4 shapes available: it would require all 4 gems before it activates its signal, so the player would need to collect them all. ## Treasure Chest The Chest should be able to hold an item or other doodad and release it upon interaction with the player. A Chest will be dragged into a level, and then with the Link Tool you connect it to the item doodad that it will contain. The item can be placed anywhere in the level, probably close by to the chest, its level position doesn't really matter. When the Chest initializes in the level on Play Mode, it should emit a **hide** signal to its linked item, which should turn the item invisible. (This may be handled at the game engine level rather than each doodad needing to be programmed to respond to this; tho they can still listen for the signal if they need custom code?) When the treasure chest is opened by the player: * Teleport the linked doodad onto the chest, and make it visible. * Animate the item moving from "inside" the chest to hovering a number of pixels above the top of the chest sprite. During this animation, the item should NOT interact with the player, for example, a Key should NOT be picked up if the player is already 'touching' its sprite (as they likely will be). * After the item lingers above the chest for a moment, it will become active to be interacted with (a key may disappear into the user's inventory at this time). * In case the item _doesn't_ disappear, after a moment it should "fall" back down to match the Y-coordinate of the Treasure Chest, and then the Chest itself should disappear out of existence. The latter covers an edge case: what if the user linked a Chest with (say) a Button or some other doodad that isn't an item? The Button would not disappear into the user's inventory the way a Key would, so it should fall back to the ground taking the place of the treasure chest and remain there the rest of the level. This could also allow monsters to be kept in chests too (during the "rise above the chest" animation, a monster would not damage the player as interaction is disabled). If a Treasure Chest is **not** linked to any doodad, the chest should immediately display an "opened" sprite and be purely decorative and non-interactable to the player. ## ~~Checkpoints~~ **Status:** Done. The Checkpoint doodad will remember the player's progress when they arrive at the checkpoint on a level. In case they run out of HP they will respawn at the last checkpoint touched. * ~~Each Checkpoint can only be activated **one** time.~~ * The most-recently activated Checkpoint becomes the player's respawn point on the level. ~~However, if you use the Link Tool and connect two Checkpoints to each other:~~ * Activating one Checkpoint will **deactivate** any linked checkpoint. So for larger puzzle levels you could have a pair of mutually-exclusive checkpoints that can be activated in alternating order, and behave more like _Mario Maker_ and less like _Sonic the Hedgehog._ ## ~~Warp Doors~~ **Status:** Done. Warp Doors can be entered by the player which will take them to another door somewhere else on the same level. To set up the warp you would drag in 2 doors and then use the Link Tool to connect them together. When the player "activates" a Warp Door it should play an opening animation, hide the player sprite, close the door and then the camera should scroll until the linked door is on screen and the player will appear there with the animations in reverse on that door. In case a Warp Door is linked to 2 or more doors, the door the player is taken to should be "random" (fixed RNG seed at level initialization for predictable behavior). ### ~~State Doors~~ These would be a variant on the Warp Door that combines it with the ON/OFF State Block doodads. The doors would come in an Orange and a Blue variety similar to the state blocks. When the state is "BLUE", the Blue Door should be solid and usable and the Orange Door should render as a hollow dotted rectangle. When the state becomes "ORANGE" the two doors shall switch roles. ## ~~Iron Locked Doors~~ The current Locked Door doodads come in 4 colors and have corresponding keys; once the player holds the key they can unlock unlimited doors of the matching color. An Iron Locked Door however would be different, and act like "small key doors" in Zelda-like games. Small Keys would be collectable items with a quantity and each key can unlock an Iron Door **one** time, which consumes the key. # Technical Doodads ## ~~Power Source~~ **Status:** Done. These doodads would emit a "power(true)" signal immediately upon level load. Any device linked to the doodad immediately enters its powered state, e.g., electric doors will open. Note: the sound effect spam of all doors opening at once should be suppressed by the game engine somehow. ~~If a Power Inverter receives a power(true) signal from a linked button, it will emit a power(false) signal to its other linked doodads. Note: infinite loops should be prevented, maybe Message.Publish() won't send a message on the same tick to the link which had sent a message this tick, so two power inverters linked together won't bounce back and forth.~~ ~~The engine should be able to handle scripts getting caught in infinite loops, e.g. by destroying the actors and flashing an error message.~~ **Update:** it seems you get into a deadlock if two doodads publish to each other at the same time. Two of these doodads linked together couldn't receive the other's signal. ## ~~Invisible Goal and Checkpoint Regions~~ **Status:** Done. ## ~~Invisible Fire Region~~ **Status:** Done. An invisible doodad that triggers a fail condition. ## ~~Stall Player~~ **Status:** Done. A region that freezes the player character for 250ms one time, to stall the player in case of time-sensitive cinematic events and avoid the player racing the other characters. If it receives a power(true) signal, it will reset the trap and stall the player again. ## Invisible Start Flag Set a spawn point without a visible flag. Note: needs to make the start-flag.doodad non special. Use a doodad tag? Maybe add an official doodad tag named "class" with values being like "spawnpoint" or "warpdoor" (the latter which also depends on names to ID one another). ## Gravity ON/OFF Gravity regions that change the effect of gravity for any doodad that passes thru it. * Gravity ON * Gravity OFF: trigger free movement mode * Gravity INVERSE: change the direction of gravity? * Gravity LOW/HIGH: change the intensity of gravity (low grav levels) Link Tool: apply gravity to another doodad whether or not it expected it. Make Keys fall with gravity! Ground the Bird! Let the Azulian walk on thin air! ## Invisible Button A region that emits a power signal to linked doodads when a mobile doodad enters it. ## Invisible Warp Door This doodad should be smallish in size and behave like an instant Warp Door for any mobile doodad -- not only the player character. Link it to an exit door and doodads which touch the invisible warp will be teleported and exit from the other door. TBD: how can the receiving door be invisible too? Maybe this doodad makes the exit door hidden too? ## Thief Region An invisible region which behaves like the Thief, removing all items from the inventory of the doodad who passes it. Unlike the Thief, it will take infinite copies of singleton items like the Colored Keys, always emptying the inventory. ## Clocks Clocks could come in a few varieties (5 seconds, 10 seconds, etc.) and have a clock icon and their number of seconds in their sprite. To linked doodads they would behave as a switch; on their interval sending switch:toggled and power(true) signals so linked doors will open and close etc. ## Camera A camera or TV monitor doodad could direct attention to a spot elsewhere in the level. The camera would be Linked to its subject of interest, which could be any kind of doodad. When the player character activates the camera, the Canvas's focused doodad will switch to the camera's linked partner, which will cause the canvas to scroll until the doodad is in view -- same as how it follows the player character. When the player character leaves the camera or presses Activate again, gameplay focus returns to the player character. There should be a dedicated function for this, the player character should be easy to focus back to no matter how quickly conflicting doodad scripts might run.

kirsle added the

doodad

label 2019-07-15 17:32:04 +00:00

kirsle changed title from ~~Checkpoint Doodads~~ to Doodad Ideas: Initial mobs, warp doors, checkpoints, etc.

2020-12-11 00:33:49 +00:00

kirsle added the

levels & doodads

label 2021-07-18 20:21:37 +00:00

Sign in to join this conversation.