Are we supposed to be able to use mimic for rooms?

I have 2 rooms, but will have many in the end.
Different rooms will have small differences in function, but many functions will be identical.

I already use mimic for tiles, e.g. in one tile's scipt:

// script within a tile
on any do
    mimic "name-of-other-tile"

(side note: if you use "on any do" AND you implement a local handler for the same event, both handlers are called and the any event handler seems to be called first. this is unfortunate - i'd love to be able to treat these as overloaded functions so I only call "on any" if there isn't some other satisfying local handler)

anyway, main point of this post: i can't get mimic to target a room... I can create a tile to host all my code (like i'm doing elsewhere) and do something like this in my room script:

// script within a room
on any do
    mimic "tile-that-implements-room-code"

it feels really odd that i need to do that though. is this intentional or is it a bug?

Not an intentional omission or a bug. We just never considered rooms mimicking other rooms. We basically thought of them as dumb places that might set a few variables on enter and either tiles or the game itself were the engine that did something with those variables.

Wait. Are you saying that rooms can mimic tiles? That’s definitely an oversight. We only envisioned tiles mimicking other tiles, not rooms mimicking tiles.

As for the any and specific event handler duplication, any was imagined as a way of having all parts of a multi-tile sprite behave the same way. Its use as a way of subclassing is a happy accident.

Gotcha - it's not part of the design intent.
I might be strange for wanting intelligence in my rooms, but i've been focused on having very dynamic, randomized rooms. right now I have this concept of a "base class" for all rooms, then specific room variants that do slightly different things. Mimic is the obvious path for doing this, but i haven't explored deeply enough yet to know how valuable (or not) the feature might be in the long run.

My current experiment is to make something kinda like Robocode where players will have to define scripts, in-game, to control a robot. Making the room logic fancy is mostly a placeholder so i can eventually allow players to have their robot modify the rooms a bit depending on the type of space they are in.

oh yes, rooms can absolutely mimic tiles right now! that's actually how i'm exploring the above concept. i've created a tile called ROOM which serves as my "base class" and then i have my actual rooms mimicing that tile's behavior. now the only stuff in my room scripts are those parts that are unique to the room.

I'm using tiles for a lot of stuff that might have been outside the design intent... e.g. i also use tiles as something like a storage class. i have another tile called TOOL which tracks the tools a player has access to - each frame represents a different tool, so i can use the frame attribute to know which tool the player has selected and therefore what to do when i pass the "useTool" event to this tile. I instance this tile along with my other storage class tiles, in my room under a HUD along the top edge. I'll have nearly a dozen storage class tiles in my project by the time i'm done implementing the current planned features.

i'm still just playing around with Pulp, but for now all of my usage of "any" is the happy accident itself - and for me oh boy would i love to have a simple mechanism to say "if i have a local handler for this, use it - otherwise mimic the base class"

if the 'any' handler would execute last rather than first i could write something like this:

on myEvent do
    // do stuff

on any do
    if _handledLocally==1
        log "event was handled by the subclass"
        log "event was not handled by the subclass, calling base class"
        mimic "baseClass"

This would even allow for multiple generations of inheritance:
bathroom is a unique house_room; house_room is a unique room; room is a unique space...

I'm making an assumption above that events are always handled sequentially - that i can't have two events in flight at the same time and therefore need some sort of mutex around this flag... i think that's a safe assumption though, right?

Anyway, the above is meaningless in the current implementation because "any" seems to execute first, so i can't constrain the call to mimic in this way. Maybe there is another way to accomplish this that i just haven't thought of yet?

Whoa. This is incredibly cool...and way beyond the scope of what PulpScript was designed for :smiley: I think your ideas would be better (and much more easily) realized with the full Playdate SDK once that becomes available.

1 Like


yeah... patience is a virtue and all, but i'm feeling all motivated and stuff!

I know you're right, this particular project is much better suited to the SDK - but i'm hoping that learning Pulp with this admittedly inappropriate project will help me come to grips with what it can and cannot do.

Best case scenario: I figure it adds to the collective mindshare for playdate. Worst case: I had fun trying to spread so much butter over too much toast - and i'll find a big bucket of butter in the SDK when it's released!

Had an idea! You could do this in your “subclass”:

on any do
	// handled here
	if"anEvent" then
	elseif"anotherEvent" then

	// handled elsewhere
		// do the same thing
		mimic "baseClass"

on anEvent do
	// do the unique thing

on anotherEvent do
	// do the other unique thing
1 Like