Starting

I know I just finished Druid Dash, but AGBIC is one of my favorites jams and really wanted to get back into it, as last time I ran out of time, due to overscope (I’ll get back to you Occult Nostalgia, don’t worry).

So, this year I wanted to be smart and not overscope myself. Looked around for carts that I think could be done with an enjoyable gameplay within the one month timeframe of the jam, calculating in IRL stuff.

One of the firsts that stood out is Kumatori Panic! with its cute style and just the idea of a bear gathering chicks who escaped from the coop. Color matching games are also something I haven’t dabbled in, so two birds with one stone. I get a cute entry and learn something new!

While I was still finishing Druid Dash, NerdyTeachers started a prototype for the PicoView monthly zine (hey check it out, it has a lot of articles about gamedev and reviews for amazing community games!) with a sokoban puzzle theme. That was the moment it all clicked. Puzzle pieces together a color matching sokoban game.

Actual Dev

I started today after reaching out to Eat Sleep Meep, the creator of Kumatori Panic! and started a little mockup.

As always, once the caffeine kicks from the supporters and code starts rolling in, we don’t stop! Looked into a quick and dirty map generation (which still is the engine behind) and generating the garden where they all escaped, with tress sprinkled over for obstruction!

But then I wanted to walk around this map, so hey, bear doodle! I struggle with it for a while but I think I ended up in a cute place with him/her? Will have to ask for that info.

Why stop with walking. Quickly jumped into moving things from map tiles into objects and placing them in arrays to be able to check what is where on the map, so I can push things and get stopped when no place is there to push into.

The code gets really easy if you store the map as a 1D array and push objects into that with an index, calced from x and y positions. You read about this already in my Colony Management game, but if you haven’t a simple equasion of index=x+y*16 will get you the tightest array for a 15x15 map (the size of the pico screen in tiles) so we pack into that. After this checking for obstruction position is a simple index check into the array to see if there is something there! Code example!

And it works like a charm, first try, didn’t even need 3 hours of debugging and cursing, of course, why would it. So now that we can push, we have the sokoban element, but can we match? Sure we can, Tinder got nothing on us!

The algorythm is really simple. When I push a chick to a new place I invoke a flood fill algorithm on it’s point. Flood Fill https://en.wikipedia.org/wiki/Flood_fill is a pretty basic function to determine connecting areas. You add an origin point, check it’s neighbours if they are the same, add them, check their neighbours etc… basically imagine it as pouring a cup of water and letting it see where it goes.

Implementing it is not that hard either. We need a point to start from, a color to check and an array to gather all the matching chicks into. After the we check if our point is inside the map ( 0 < index < 256 ), as those are first outside map (0,0 -> 0+016, and 15,15 -> 15+1516). Check if there is a chick on said position, and is not a chick already added, check for the color, add it if matches and call this to the 4 places, up, down, left and right. We need the already added check as otherwise we would bounce back and forth from the first to the second to the first to the second etc… And done. After it is finished, check if this array is bigger than 3, the matching minimum number, and if they are, remove them!

Code for your nerd reading pleasurses

Now add a little particle spice to it, draw a cute blinking animation and bam, we have a really cool looking proof of concept for the game!

And this is where we are. As I haven’t got permission to actually work on it till later this day I haven’t realy thought into where to expand, but I know one thing. I want replayability, not a set campaign. I want people to pick this game up for a quick run every once in a while instead of being a once and done, so we are gonna have some procedural generation for sure.

As for game mechanics? Not really sure. I do plan on having a few chick that are more “tricky” to catch, maybe wander off from time to time, not willing to sit next to trees idk, some spice as we say.

We have a lot to do still, so I’ll take my leave back to the embrace of lua code and pixelart, while you can read away on my other articles if you want!

(This article was taken from my Ko-fi page, where you can read a lot more gamedev, reviews and pixel art stuff.)

Socials 🌳

Kumatori Panic! Devlog #2 - Menu system, gameloop, difficulty

So with all the basics in place, let’s actually crate a game! For that we need a Menu from which you can start, and a proper gameloop of winning and losing! For this we need to create a state machine first to handle our scenes! Basically we do a simple codebase to be able to branch the code, depending on which “state” we are. Are we in the menu? Call the update and draw for the menu. Are we in the game? Call that for the game. Did we lose? Set state to menu for basically a “return to menu option”.

Here is the code on how I do all of this, feel free to take it for your own usage.

But for a menu we will need an art, so I quickly tried to do my own rendition of the cartridge art, and just draw it into the menu scene upscaled, just like how I did it in Druid Dash.

With the menu completed we need rules to end the game. One of the easiest to handle is to see if we have chick that cannot be matched anymore (1 or 2 of the same color, as we need 3 to match). If so, just do a state=3 and the update will automatically go into the update_gameover() code.

But that is not all, I wanted to have a limitation for the player. Limiting all steps would be to harsh, so at the moment we have the following! An energy meter that depletes only when we push a chicken, and refills when we match chickens. Refilled amount depends on the number of chickens matched. If you ran out of energy, the game ends.

One last thing after this is how we handle level loading and unloading as random heavily plays part in the map generation. Luckily PICO-8 has a handy function called SRAND(seed) which will let you to manipulate random calls. If you call SRAND(2) for ex before your generation, every random call will be individually the same no matter how many times you redo. So if you save the seed before each map, you can just call the loading function, set the SRAND() to the map’s seed and the generation will be the exact same! Magic!

With all this only one thing is left. Handling the difficulty of the game. At the moment I have a very rudementary method. There is a difficulty variable calculated with difficulty = flr(level*4.5) and for the stage we generate this many chickens. Furthermore to avoid overloading the player, we introduce the many type of chicks later in the game with a pretty trick of manipulating a random table to choose colors from. If we are later in the game, we add all colors into the table, and all color could appear on the map! Limit the number and slowly let it grow and you got an interesting difficulty curve of increasing amount of chicks and colors!

Code example

So what issues do we have left? Currently, there is no checks if the player can complete the stage. For example you could get 3 chicks that are surrounded on 3 sides by trees, you cannot push any, but the game doesn’t end as it sees the “option to match”. This I want to solve with the option of picking up a chick for energy and carry it around for energy to place it down in a new place. Not only this solves the issue of impossible placements, but it ties the original cart image into the game, where the bear is actually holding a chick! You can also run out of energy due to me not knowing how much to give you, so if that happens, feel free to try a few times, then restart.

That is all for today’s devlog, see you in the next one!

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.

Of course, Code example!

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!

Kumatori Panic #4 - Eggs, Better Movement, Lore Accuracy and mapgen!

7 days have passed since the last devlog and as I said in it, progress was slow. Heatwaves are upon us, work is busy and IRL stuff is happening, so I’ve got a much lower timeframe to work on the project as on the weekends.

So bring forth the first addition to the game in a while, eggs!

The idea is pretty simple and is present in a lot of tile matching games. Add a few blocks that can be only interacted after “freed” with matching next to it. This could be ice that breaks, candy wraps that tear or as in our case, an egg that hatches! If 3 or more chicks are matched while an egg is next to any of them, it will immediately hatch into a new chick.

That is all fine, but knowing what color hatches is a really good QoL feature and I don’t want to RNG to F you over with matching all your greens next to an egg only for that egg to hatch a green chick and lose you the game. So, introduce 4 marked eggs, always showcasing what will come out!

With this new tool in our arsenal let’s give our back in for some audience participation! MarinaMakes asked if it would be possible to introduce a proper walking animation instead of instantly teleporting to the next tile. With the help of LazyDevs this is easy, plop in a Tutorial from Porklike and follow the animation part, and bam, we have a bear that now walks and not just blinks into places! No code for you this time, go watch the OG I followed!

With these two little features done, we are entering a new QoL feature I wanted to add for a really long time. With random generation it is possible for a chick to be struck between 3 trees and you won’t be able to ever get it free from there. If you get 3 of these on the map, you are screwed as you cannot complete it. Same with chicks on the edge. Do you remember the Famicase art?

The bear was clearly holding a chick, so let’s quickly implement that feature. For this we introduce a new variable for the chicks as in “held” and two new ones for the bear, “pickup” and “carry”.

With these we can do the following. If we press a button, we set pickup to true. This will branch the control code to a new part, which handles selecting one of the 4 tiles around the bear. Upon pressing the pickup button, the bear will initiate the holding. We set the carry to the index of the chick, and signal the chick that it is held. In draw, when we loop the chickens, we check for held and if true, we draw it on top of the bear. Also we disable collision with any chick that is held. After this, we can move freely again, and upon pressing the pickup we do a check. If carry is -1 (a dummy selected value) we know our hands are empty, so pickup mode it is. If not, we clone the chick given by the carry index, delete the old, and place the new in the desired direction. Bam, pickups! https://gist.github.com/Achie72/7923483f3992248a66ddf0ee9e87288f

And lastly I wanted to create better gardens for you to chase chicks in. First I sketched up a whole new UI for the game, something chunky that can sit on top of the game. I wanted to follow the really big, chunky feeling of all the mobile UI these kinds of games have, but still follow some kind of minimal line. We moved the energy bar onto the top, with the counter. Right corner now holds the stage count and the goal of the stage (more on this later, if I don’t scope creep myself).

This all occupies a bit on the screen so the game had to change its generation either way. I always really wanted to introduce a white fence around the stage as I felt it rounded the whole experience out. But only a square one doesn’t feel engaging. Full random generation would lead to a lot of checks to correct fences, so I went with the middle line. Introduce schemas to the generation, 4 for each corner, and let it randomly choose from one for each stage!

This is not the prettiest solution but here is how it works. Dark blue lines signal the horizontal fence, light blue the vertical fence. Green indicates a top left corner, yellow a top right, pink a bottom left and red a bottom right one. Dark green is for the play area, black is for “outside”. After all this, we choose one for each corner upon generation, collect the colors into an ID list and then build the map based upon those ID-s. Thanks for the base idea to Nerdy Teachers and his Sokoban tutorial cart!

Code away!

In theory this will do 256 variations, but I still feel they look same-y at points so I might just go back and add more variations to the game. I have 2 free rows, which could lead to 8 more variants for each corner. Wild.