"Distance" score tracker/updated bottom right bar

[grady404]

EDIT After you finish this, see #65.

In addition to the "moves" and "time" trackers that appear in the bottom right status bar within the play screen (EDIT: about the time tracker, see issue #29), add a "distance" tracker that is incremented any time any block moves one unit. Make the counter increment in real time as the block slides across the screen, rather than simply updating it once the block comes to rest.

Eventually, when/if light blocks are added to the game (not hollow blocks), these should also increment the counter when another block pushes them, so that the counter increases by 2 every time the pair of blocks slides one space.

EDIT: Oh, and make sure that when you update the bottom right status bar, it's set up so that the text won't get pushed off screen. To help with this you might want to implement a maximum for the counters, such as 999, 9999 or maybe even 99999, depending on how wide you want the bar to be. I don't think the bar should change size since that would look strange. ANOTHER EDIT: It does change size, and it's fine, that's probably the best way of doing it.

[cooperuser]

In the redo of the game, I have methods for when a block Boards, Slides, and Departs, so I can just make it that when the Slide method is called, it increments the value, which is updated realtime.

[grady404]

Ok, what is boards? I assume departs is when the block begins moving.

[grady404]

Another feature you should include in the game is the ability to calculate the consequences of any move instantaneously without delay, and of course the ability to determine all possible moves of any given block (up, down, left, right). With both of those features, it will be very easy to implement the solving algorithm.

[cooperuser]

grid[x][y].tile.Boards(grid, position)is a function that gets called when a block stops moving on a tile.

[grady404]

Why Boards? That's a really strange name for that function. I would suggest you use Terminates, Halts, or Stops.

[cooperuser]

Board as in Boarding a plane, or boat

[grady404]

But it seems weird to have that for when the block comes to rest... they mean completely different things. I like the sound of Departs, Slides, and Halts.

[grady404]

Or better yet, Departs, Advances, Halts.

[grady404]

Or you could do it like Python's list splicing: Starts, Steps, Stops. Not sure which I like better.

[cooperuser]

hmm, not sure

[cooperuser]

oh, but this is a method on the tile, that does the triggering on the plates and switches, so Starts, Steps, and Stops wouldn't make much sense.

[grady404]

Why wouldn't that make sense?

[cooperuser]

because, the tile is being boarded, not stopped

[grady404]

Oh wait weird, why are they tile methods and not block methods?

[cooperuser]

because it is the tiles job to trigger everything on it

[grady404]

Explain...

[grady404]

You're saying the methods that make the blocks move are tile methods?

[cooperuser]

no

[cooperuser]

When the block either Boards, Departs, or Slides over a tile, it triggers an event

[cooperuser]

and this event triggers other things that are on that specific tile

[cooperuser]

For if, later on, we ever decide that there would be a reason to have multiple types of plates on a single tile for some reason

[grady404]

Oh I get it. It's not a method of one of the actual physical tile objects, it's just a method of the space the block crosses/stops on/starts moving on. Right? Or is it actually triggering something in the physical floor tile?

By the way, Arrives would be a better word than Boards.

[cooperuser]

It is actually triggering an event in the physical floor tile. This way, besides having it trigger plates and switches, it can also act as a pit trap for stopping blocks by setting their .moveable attribute to false.

[cooperuser]

And I do like the sound of Arrives, I might rename it.

[grady404]

Uh... that is a very strange way of doing things. Personally, what I would do is have those as block methods, and every time the block triggers one of these methods in a certain location, check to see what interactable (that's STILL not a word) objects are in that location. That way, if the block Slides for instance you only need to check for objects that will respond to a slide (so no plates or switches), which would make your game a tad more optimized.

[cooperuser]

How will this make it more optimized? there are no extra checks being done.

[grady404]

The block doesn't need to trigger anything if it slides over a tile that doesn't react to slides. But being optimized isn't the main draw at ALL. The main draw is that it's much more organized and a better way of doing it

[cooperuser]

But this way, if there is a subclass of Tile that has a Slide feature, we don't need to change anything

[grady404]

What subclass of Tile would have that?

[cooperuser]

Pit

[grady404]

I don't think you should add pits. But even if you did... let me try to explain what I am thinking

[cooperuser]

okay?

[grady404]

I think the way I was saying it before was wrong... but it shouldn't be the tiles that have those methods, it should be the plates and switches themselves. With the way you have it, if a block boards/arrives on a tile with a plate on it, the block will trigger the Arrives method on the tile, which will then proceed to cause the player to win the level. But the Arrives method should be on the plate itself, it seems very weird to have it on the tile.

[grady404]

And the reason I don't think you should add pits is, they don't really add much to the game puzzle-wise.

[cooperuser]

But there will be a Press() method on the plates, and by using this method(method as in the literal definition, not the programming term) we can have block "clusters" that are welded together triggering the plates through the tiles

[grady404]

But I think the Press() method should be the Arrives() method. I think that every non-solid object in the game should have Arrives(), Departs(), and Slides() methods, and the functionality of the method depends on the purpose of the object. Whenever a block arrives, departs, or slides over any square in the game, the corresponding method will be triggered on all non-solid blocks occupying that position.

So if a block comes to rest on a tile that has a plate on it, the Plate.Arrives() method is triggered, which causes the plate to become active, and the Tile.Arrives() method is triggered, which does absolutely nothing.

Hopefully this seems more clear now.

[grady404]

Also, this way you don't have to modify the tile code every time you add a new object to the game, you just add code to that new object.

[cooperuser]

Yeah thats the plan

[cooperuser]

everything is gonna have those methods

[grady404]

Ah, that makes a lot more sense now

[cooperuser]

And because I am using subclasses, if I create a new Tile subclass, and I do not specify new methods, it will just inherit the superclass methods

[grady404]

Also, see general discussion

• [x] ok

[grady404]

And yeah, makes sense