Need help for first game

119 views
Skip to first unread message

Luke Vader

unread,
May 24, 2026, 4:31:39 AMMay 24
to PuzzleScript

The whole mechanic behind this game is that there are two movement modes the player can switch between: tame and mad.

Tame mode works exactly like regular sokoban. The player can move freely and pushes blocks 1 tile ahead. 

Mad mode makes it so that the player charges in the direction you press, only stopping when they hit a solid surface. Afterwards, they return back to tame mode. Hitting blocks in this state causes them to be launched in the direction you were facing, as if they were sliding on ice.

Here's the problem though; the player can't turn mad when right next to a solid surface like a wall or crate. This is a really big issue as it shuts down a lot of opportunity for interesting puzzles.

Additionally, the brown line on top of the player at the start is supposed to be the top of their hat, since the whole sprite couldn't fit within the 5x5 aspect ratio. It moves with them (which is supposed to happen), but disconnects whenever they charge or try to move while up against a solid surface. I want it to stay attached to the player sprite regardless.

Stephen Lavelle

unread,
May 24, 2026, 4:43:06 AMMay 24
to Luke Vader, PuzzleScript
Let me answer some of your questions:

>Additionally, the brown line on top of the player at the start is supposed to be the top of their hat, since the whole sprite couldn't fit within the 5x5 aspect ratio. It moves with them (which is supposed to happen), but disconnects whenever they charge or try to move while up against a solid surface. I want it to stay attached to the player sprite regardless.

delete it and recreate it in the 'late' phase of each turn

late [ player_hat ] -> [ ]
late down [ | player ] -> [ player_hat | player ]

also in the prelude you want norepeat_action


--
You received this message because you are subscribed to the Google Groups "PuzzleScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/puzzlescript/461f8b4e-8625-4614-8ef2-9774046b41dbn%40googlegroups.com.

Luke Vader

unread,
May 24, 2026, 7:09:13 PMMay 24
to PuzzleScript
Thanks, now time for the bigger issue: the player being unable to get mad when right next to an obstacle.

This is the code for how getting mad works:
[ Action Bruno] -> [BrunoMad]

[ Playermad | Charge ] -> [ > Playermad | ]
[ > Playermad | no Solid | ] -> [ > Playermad | | Charge ] again
[ Charge Solid ] -> [ Solid ]
[ BrunoMad | Solid] -> [ Bruno | Solid]

The player is supposed to immediately revert back to their 'tame' state after colliding into something when 'mad'. However, with how the code's written, it makes so they can't get mad whenever they're right next to an obstacle. Another problem that arises from this code is that the player immediately reverts back to their 'tame' state when passing by a solid object instead of colliding with it. Also, one odd thing I noticed is that when the player's charge is cut off by this, they'll continue their streak when the action button is pushed again but haven't made any movements beforehand. Try it out in this updated test version and you'll see what I mean.

Sinan Huzaifa

unread,
May 25, 2026, 4:30:45 AMMay 25
to PuzzleScript

The issue is that [ Action Bruno] -> [BrunoMad] only triggers when the player isn't adjacent to a solid because the collision rule for [ Bruno | Solid] takes priority. You need to force the mad state change before the movement rule checks for solids. Try moving the mad transition to the pre or late phase instead of handling it as a direct action rule. That should decouple it from adjacency checks.

Sévan Kazandjian

unread,
May 25, 2026, 7:20:07 AMMay 25
to PuzzleScript
I couldn't make it work with only adding "late" keywords so I thought I'd dip in a bit:

[ BrunoMad | Solid] -> [ Bruno | Solid] is omnidirectional so Bruno will soothe when being adjacent to *any* solid. Hence your problem.
You'd need to specify somehow that you want him to calm down if he is walking *toward* the solid.

Since you already have the Charge set up you could replace / combine
[ Charge Solid ] -> [ Solid ]
[ BrunoMad | Solid] -> [ Bruno | Solid]

with 
late [ BrunoMad | Charge Solid] -> [ Bruno | Solid]

the "late" keyword makes it so this rule is checked after the movement phase.

It seems to be working in my case though it's not devoid of problem in some edge cases

Of note, for sliding behaviour people often decorrelates all directions LRUP as in :
https://www.puzzlescript.net/play.html?p=81b9430a6c09b355f6379c0f63beb04c
it's tedious but might be useful.

Of note 2, if you don't need animations, you could use simpler set-ups as in :

Have fun!
Sévan.

Luke Vader

unread,
May 25, 2026, 8:24:10 PMMay 25
to PuzzleScript
Also, forgot to mention that the box just sorta teleports after the player charges into it. It's supposed to slide tile-by-tile.

Luke Vader

unread,
May 25, 2026, 8:24:15 PMMay 25
to PuzzleScript
Thanks, but I've stumbled across another issue: the mad player pushes the box before they make contact with it. It also doesn't revert them back to their 'tame' state.

Try it out in this test and you'll see what I mean.

On Monday, May 25, 2026 at 4:20:07 AM UTC-7 Sévan Kazandjian wrote:

Luke Vader

unread,
Jun 3, 2026, 9:46:17 PM (6 days ago) Jun 3
to PuzzleScript
Since nobody has responded to this thread in over a week, I figured I'll post the code as to how charging and object interactions relating to it.

(Getting Mad)
[ Playermad | Charge ] -> [ > Playermad | ]
up [ > Playermad | no Wall | ] -> [ > Playermad | | ChargeU ] again
right [ > Playermad | no Wall | ] -> [ > Playermad | | ChargeR ] again
down [ > Playermad | no Wall | ] -> [ > Playermad | | ChargeD ] again
left [ > Playermad | no Wall | ] -> [ > Playermad | | ChargeL ] again
late [ AngusMad | Charge Solid ] -> [ Angus | Solid ]
late [ BeaMad | Charge Solid] -> [ Bea | Solid]

(Angus is the new name for Bruno. I just figured it would be more fitting for the main mechanic of this game.)

(Object Interactions)
up [ ChargeU | Box ] -> [ | > Box SlideU]
right [ChargeR | Box ] -> [ | > Box SlideR]
down [ChargeD | Box ] -> [ | > Box SlideD]
left [ChargeL | Box ] -> [ | > Box SlideL]

up [ Box SlideU | no Solid ] -> [ | Box SlideU ] again
right [ Box SlideR | no Solid ] -> [ | Box SlideR ] again
down [ Box SlideD | no Solid ] -> [ | Box SlideD ] again
left [ Box SlideL | no Solid ] -> [ | Box SlideL ] again

[ Charge | Cactus ] -> [ | CactusBroken]

The player is supposed to launch the box in the designated direction after they make contact with it in their 'mad' state, not before. I'm not sure if the lack of specificity is what caused this thread to be inert for so long, but I'm just desperate to continue working on this game.

Chris Pickel

unread,
Jun 3, 2026, 10:58:43 PM (6 days ago) Jun 3
to Luke Vader, PuzzleScript
Since the player and crates are supposed to slide similarly, you can simplify things by handling them similarly: have separate stationary and sliding crates, the same way you have calm and angry players.
https://www.puzzlescript.net/editor.html?hack=26a444e9b3e0878cdb0426771b855498
I’m not sure if the behavior is exactly what you want—if the player gets angry next to a crate and tries to push it, should the box move? Should they?

Message has been deleted
Message has been deleted

Luke Vader

unread,
Jun 7, 2026, 7:33:48 AM (3 days ago) Jun 7
to PuzzleScript
Figured I'd elaborate on this a bit more.

If the player gets angry next to a crate, they shouldn't be able to push it. They need to have a running start beforehand if they want to launch it. I feel like it would lead to more interesting and elaborate puzzles.

On Thursday, June 4, 2026 at 4:36:49 PM UTC-7 Luke Vader wrote:
To answer your question; no for both. I want the player to have a running start beforehand if they want to push the crate while in their mad state. It would lead to more challenging and interesting puzzles.

Sévan Kazandjian

unread,
Jun 7, 2026, 6:28:16 PM (3 days ago) Jun 7
to PuzzleScript
Hi,

It is not really clear what you're expecting from us.

Your builds seem to show a correct understanding of puzzlescript and we offered a few high level solutions so I feel like you have all the tools you need to find solutions to your problems?

Sure you might need some trial and error, and stuff might not work on the first try, but you seem perfectly capable, and I look forward to seeing this game progress.

Cheers,
Sevan.

Reply all
Reply to author
Forward
0 new messages