Spikes

Not the experimental kind, the stabby kind. Though there will surely be experimentation involved.

Arcade has an event in the event loop, on_update(delta_time), that is called in the same thread as on_draw. It appears to be the official OK way to update things needing updating. We’d prefer not to send on_update to every content item, not least because we’d have to implement the update method in all the classes, or inherit it somehow. So I’m thinking, why not let the items use PubSub to subscribe to the update if they want it.

Our spike textures just have two states, I think. Yes. 1=down, 2=up. So I envision making a Spikes content subclass, as we did with Button, perhaps giving it a more generic name, since we have a prototype now in the DungeonControl class. Then it’ll subscribe to some message, probably ‘on_update’, and we’ll send it along with publish in the real on_update.

I guess one would start with an on_update in DungeonView, where the loop is. We already have some code there:

class DungeonView:
    def on_update(self, delta_time: float):
        def receive_announcement(msg):
            self.scroller.append(msg)

        self.dungeon.announce_via(receive_announcement)
        self.scroller.update()

I think we should just go ahead and publish:

    def on_update(self, delta_time: float):
        def receive_announcement(msg):
            self.scroller.append(msg)

        self.dungeon.announce_via(receive_announcement)
        self.scroller.update()
        self.dungeon.publish('on_update', 'view', delta_time)

I figure that subscribers will want to know how much time has passed. I imagine that our Spikes will sum up delta-time until it exceeds some threshold and then cycle.

This code is harmless. Commit: on_update publishes ‘on_update’-‘view’ with delta_time.

I think there’s nothing left to do but create the Spikes. I’ll replicate the DungeonControl, I think, then bash it into submission, then refactor. That seems simplest.

class Animated(Content):
    @classmethod
    def spikes(cls, name):
        resource1 = '/Users/ron/Desktop/DungeonTiles/png/objects/trap/1.png'
        resource2 = '/Users/ron/Desktop/DungeonTiles/png/objects/trap/2.png'
        resources = [resource1, resource2]
        return cls(name, resources)

    def __init__(self, name, resources):
        self.resources = resources
        self.name = name
        self.time = 0
        self.scale = 0.75
        self.state = 0

    def interact_with_player(self, dungeon):
        pass

    def run(self, dungeon):
        self.state = 0
        self.time = 0
        def callback(event, delta_time):
            print(delta_time)
            self.time += delta_time
            if self.time >= 1:
                self.time = 0
                self.state = (self.state+1)%len(self.resources)
                dungeon.publish('state_number', self.name, self, self.state)

        dungeon.subscribe('on_update', 'view', callback)

Nothing much to it: on update we get the callback, update time, and when it exceeds 1 second, roll it over and signal our state change to update our view. Of course I forgot to reset time to zero the first time out. But now it works as intended, up in the eleven o’clock direction, near the lever.

So that’s about what I intended to do, and just about how I intended to do it. Next time, we’ll connect it to the lever and figure out how to stop and start it. Should be easy enough. Some if statements or a tiny state machine or something.

We’ll also have to have them deal harm, but as yet Dot has no ability to be harmed. All in good time.

See you next (good) time!