1
\$\begingroup\$

I'm implementing something like the electric balls seen in this video https://www.youtube.com/watch?v=MWyB56AlAWw (skip to 1:55 and you will see this electrical balls follow tile edges in the tilemap).

I have an algorithm working but I feel like it is a bit of a mess. I could summarize it as:

1) Setup

  1. The ball starts always falling
  2. I have an enum holding what side the ball is engaged to (side of tile it is traveling. It could be Top,Bottom,Left, Right and None). This var is inited to "None" at start.

2) While the ball is falling, as soon as it touches a tile we set the engaged var to bottom (the ball is engaged to a tile that is at the bottom) and we make it move to the left.

3) Now we have 2 cases

  1. the ball collides with another tile while moving to the left. In this case we set the engaged var to Left and start moving it upwards.
  2. the ball gets into a situation where there's no tile at the bottom to continue going to the left. In this situation we use the engaged var to know what edge of the tile we were moving along. In this particular case as we where engaged to a bottom tile we fix the ball position to be right at the left of the last valid tile and start moving it down.

This applied to all possibilities makes the ball run across all the tilemap.

I would like to know if there's a more clean way to do this without all this "mini cases" or a better way to accomplish this.

Cheers

\$\endgroup\$
  • \$\begingroup\$ When you have an algorithm which sort-of works but you wonder if you could solve it more elegantly, you might want to try codereview.stackexchange.com \$\endgroup\$ – Philipp Jun 8 '16 at 11:31
1
\$\begingroup\$

You can simplify the problem, and try to implement a tile-based entity that follows a wall, a.k.a. the Wall Follower algorithm. There's very little state required - you only need to know what direction you are currently going.

Assume we're already following the wall to the right. The entity moves one tile at a time, and at each step:

while (there is a wall in front of us)
    turn left
move forward
if (there is no wall to our right)
    turn right

That's all you need; the only difference between this and your proposed solution is that it uses the entity's local directions, so you don't need to repeat those states for all four cardinal directions.

Once that's working, you can

  • Add a setup state, where it's not following a wall yet
  • Position the entity so that it's snug against the wall
  • Animate it moving gradually, instead of one tile at a time
\$\endgroup\$
0
\$\begingroup\$

A finite state machine

Instead of coding individual cases for every single state of being, a finite state machine provides a simple, and more importantly, expandable approach to coding such awkward case structures. This method is even more advantageous when used in conjunction with an object-oriented language as states can be represented as class instances.

\$\endgroup\$
  • \$\begingroup\$ In the end, I'm using a state machine. Ok, the logic is not spread across several state classes. Im my case it is done this way because I think it does not bring anything different to the table because all code is just a copy paste of the main idea with some different values (moving direction, etc...). Anyway, I have it well splitted in different functions for every case. Again, simulating the multiple state classes approach. I am more interested in knowing if there's any "magic" idea that could lead to a cleaner way to do this. \$\endgroup\$ – Notbad May 12 '15 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.