Blade Edge

Transposed from Gaiiden’s Scroll

So I got all the block interactions working last night, which made me happy. But it also prompted me to rethink some aspects of the game design. I had mentioned earlier that I had thought I would need some sort of logic to feed the players blocks they could actually use with effect on the play field. The real need for this became quickly apparent as I began dropping blocks and got to a point where I was having trouble finding spots to place blocks that would prove to be effective in some way. To add to the complication is the fact that even if the game chooses a block type that would fit within the existing play field, that block could possibly be behind as many as 11 other blocks (player clips hold 6 blocks max, so if each player has a loaded clip, the block on top could possibly be the 11th one dropped (5 from that clip, 6 from the other)), so by the time it’s ready to be dropped the play field could have changed enough that it’s now useless. I’ll have to code some basic AI to help me out with play testing this.

Another thing that I’ve been pondering is what should trigger a block interaction. Currently I use arrows to denote which direction a block will attack, and blocks only attack when they land. So in the following example, the green block landed first, followed by the red block. Since the red block’s arrow is pointing down, it doesn’t interact with the green block even though its arrow is pointing at the red block

The reason I decided to do it this way is because when you have something like the following image, things can get complicated

Here, the red block is about to land and interact with the green enemy block below it. However, the blue block is also an enemy, and its pointing towards where the red block will be when it lands. Well, okay I guess I could impose an order of attack – when a block lands first it attacks in the direction the arrow points, and then if it’s not destroyed receives any attacks directed at it from neighboring blocks. But then you get into an even more tangled scenario (deleted the green block on the right and flipped the blue one to make this example)

Now which blue block attacks first after the red block finishes its attack? Should it always start with the block on the left? And then check down and to the right? I have to admit this sounds a bit like an easy answer rather than a real solution, and so I’m not really satisfied with it.

I’ve also thought of just abolishing the arrows altogether once a block lands on the stack, in essence making them “dormant” unless provoked by a dropping block. When a stack is dropped if a block is destroyed in it, all the blocks that drop down would get randomly-assigned arrows so that when they land they would interact with other blocks. This way you wouldn’t always be playing on the top of the stack. However that’s also what chain reactions are for – attacking blocks deep in the stack. Removing arrows also makes chain reactions easier to propagate since they don’t have to follow a set path, and can also branch as well. It also clears up the issue of what happens when you get two blocks with arrows pointing at each other – does that cause a feedback loop?

So I guess my next step will have to be implementing some rudimentary AI so I can play test the game and see what actually needs to be done.