Kumatori Panic #3 - Move, Backend, Duplicate and Materialize
Last time we managed to get into a proof of concept state, where we could actually play around, but to be honest, this version of the game is pretty boring. We can move around, push chickens and that’s it. So how about we spice things up?
We have four types of chicks (ignore the pink for now) and that is for possibilities to introduce something unique! Yellow ones will serve as the baseline “boring” sit around and push around version.
One easy and basic idea is to let some chicks move! So how about we let the green chickens move around on the map? This is quite a simple task, each frame with a set chance, check for the chick if one of their neighboring tiles is empty, and if it is, move it there. For this we need one thing to not do. If a chick randomly moves into a disappearing position (connecting 3 or more chicks), skip the completion. Why? If we allow it, chicks could randomly walk into each other and disappear, leaving the player with 2 or less of the same type making them lose the given stage.
This led to a really stupid bug on the backend, of the chickens only being there visually, while leaving behind phantom chicks all over the map. In the gif below I was unable to move from the phantom chicks. This happened, because I was doing it like this:
-- i check for some stuff, then I create the new chick
local newChick = chick
newChick.x = xSpot
newChick.y = ySpot
-- delete old first doesn't work
chicks[newChick.x+newChick.y*16] = newChick
chicks[chick.x+chick.y*16] = nil
Why? One reason is Lua passing references instead of values. This means that you don’t copy each member variable of chick, while doing newChick = chick, but just set newChick to point to chick. Second is some weird bug I’m still not aware why, probably because of a weird corner issue coming from this references. Because of all this, the solution is somewhat hacky. First we do something that is called a shallow copy:
local newChick = {}
for k, v in pairs(chick) do
newChick[k] = v
end
This will actually create a new object with the same member values of the original one. This way we can call the equation to nil out the old one, which works! … Almost. You see, now we will run into the issue of the for cycle failing when you iterate this through. Why? We have something called an Iterator in the background, which has a next() function to jump into the next item. But what happens if we delete items runtime? Yeah, bad things. The solution for this is the hacky one. We introduce a new “object”, vacant = {}. This is a placeholder element that is not technically null, but we can handle it as that.
So in the beginning we fill up our chick array with these vacant type objects, and then when we would want to delete a chick, just do a
chicks[chick.x+chick.y*16] = vacant
This way in our code we can handle vacancy check:
function chick_at(index)
local chk=chicks[index]
if(chk!=vacant) return chk
return false
end
And we switch a few if’s into this vacant check and all done! Thanks to Heracleum for the amazingly simple hacky idea of this, it works like a charm. Now that we fixed the backend, let’s go add some more wacky stuff!
Blue chicks! Fiancé came up with a cool idea for them. How about creating a new chick every now and then after you push one? For this the code is easy after all the backend changes we did. Push a chicken, check its neighboring tiles, and spawn one if one of them is free. One issue with this is atm, it is bound to randomness, but to be honest I want some kind of ruling to it, which would need further indications. Maybe create one after each third push, but now, I need to indicate those, which is not easy at low resolutions.
After the rules are figured out, we can play around if we need the non completion check that the greens are doing.
One last thing added is a classic Bejeweled/gem movement type game must have. Remember when matching 4 or more chick had special benefits? Clearing all the same color, maybe just a horizontal or vertical line? Since we don’t have a refilling board those effects would be quite impactful, so here is my suggestion.
Enter the pink chick! Upon matching four chick she comes into play with her special own rule. Pink chick can be matched against any other color (or themself). They act like ever working joker cards. Worried about finishing a game with a 4 match and losing because 1 pink chick remains in the garden? Fear not, they are only created if there are enough other chickens on the board to match to!
And this is all I have for you today. Work week was crazy and sadly I got a little bit sick so I haven’t had all the energy in the world to progress after work hours. The game is getting along and that is what matters! Hope you had a good read and see you on the next Devlog!