next »

[goshki]

Nothing fancy, just a mobile implementation of an idea I've done some time ago in Flash. A tribute to the gameplay mechanics of RussianSoviet electronic games, like Eggs, Octopus and Cook (which were mostly ripoffs of Nintendo's Game & Watch series, as SoulSharer has pointed out):



Btw. you can play most of those games online on PicaPic.

Current status (new mockup):



Day X: Worked on a crate fall algorithm.

[goshki]

Day X+1: After a little bit of fiddling, the crate fall algorithm now supports random number of conveyor belts and fall lanes. Also, each lane has a different fall offset meaning that no two lanes have crates fall in the same moment.

[goshki]

Day X+2 (last friday): Implemented movement ticker from another project using signals. Movement ticker is a kind of a system that orchestrates step movement of crates on screen. It has a defined tick interval, when this interval has passed it sends a signal to all crates to move themselves by one step. Each crate monitors it's position and state and knows when it has reached a position to begin falling instead of horizontal movement. The tick interval is configurable therefore it's possible to increase the game difficulty by shortening the interval and making movement faster. The movement ticker can also be paused so when the player makes a mistake, she gets some rest time to recover.

[goshki]

Day X+3: I've noticed that crate generation algorithm places crates incorrectly sometimes and some of them end up overlapping. Will have to investigate it more later but meanwhile I've added some debug code that colors overlapping crates red.

Apart from that, I've made the crates collectable when they reach a defined height. When a crate becomes collectable, it turns blue.

[goshki]

Day X+4: Worked on internal project structure and some boring stuff like crates dispatching signals when being collected or dropped on floor. Reacting to those events (like increasing points or reducing lives) will be outside of crates.

[goshki]

Day X+5: Further work on internal project structure. Began moving crate set generation algorithm from prototype to actual game (not working yet). Added music that will be playing on the menu screen.

[psyguy]

I don't think I've ever played the games you're styling this one after.  The previews you have posted so far almost makes it look like the crates fall randomly... I tried looking at the numbers on the crates and seeing if they correlated somehow, but so far I haven't figured out any pattern yet.  Can you explain a little more about how it works?

[goshki]

I don't think I've ever played the games you're styling this one after.  The previews you have posted so far almost makes it look like the crates fall randomly... I tried looking at the numbers on the crates and seeing if they correlated somehow, but so far I haven't figured out any pattern yet.  Can you explain a little more about how it works?

Sure! :D The last preview has numbers mixed up. On earlier screenshots the first number is the lane number (vertical row in which crate falls) and the second number is the belt number (the blue strips, and one yellow). But quite frankly those numbers are mainly for debug. They won't be shown in the final game.

What matters most for the player is to click crates as soon as they become collectable (indicated by a light blue color on the last preview).

And here's a gameplay video from the old electronic game I've mentioned in the beginning:

[goshki]

Day X+6 (yesterday, saturday): Finished moving the crate set generation algorithm from the prototype to the actual game. Then worked on debugging the algorithm as sometimes there's a situation that two crates overlap and they shouldn't.

Also recorded the whole dev session:

[goshki]

Day X+7: Another day of crate set generation algorithm debugging. Implemented a design mode that let's me insert and edit crates manually and later analysed a method that lowers all falling crates in the same column that colliding crate is. Unfortunately the bug is still there.

Below is a GIF showing how the design mode works:



And here is the recording of the whole dev session:

[feminazi]

time 2 crate

[goshki]

Day X+8: Third day of tracing down a bug in the crate set generation algorithm, ended with success. The offending code was responsible for randomly spreading the lowered crates when a collision was found. Fixed some other bugs along the way and implemented the ability to restore a crate set from a string in the design mode.

Recorded dev session is here:

[goshki]

Day X+9: Implemented demo mode on the menu screen.

Recorded dev session is here:

[goshki]

Day X+10: Turns out that crate set generation algorithm bug has not been squashed. Apart from that I've realised another problem with multiple conveyor belts - the crates fall too sparsely and they tend to accumulate on either left or right side of the screen. And it makes the game boring and there's no real challenge.

Therefore, I'm trying another approach to crate generation - one conveyor belt and several crates riding in at once.



Recorded dev session is here:

[psyguy]

I wonder...  If when you wanted to generate a new crate, maybe you could start by randomly selecting the time and location that you wanted it to "arrive" at the bottom of the screen.  From there, you could select one of the multiple conveyor belts at random, then base the speed of the crate's movement and the fall slot on that first calculation, kind of like a reverse logic of sorts.  Of course, that might already be what you were doing! 

[goshki]

I wonder...  If when you wanted to generate a new crate, maybe you could start by randomly selecting the time and location that you wanted it to "arrive" at the bottom of the screen.  From there, you could select one of the multiple conveyor belts at random, then base the speed of the crate's movement and the fall slot on that first calculation, kind of like a reverse logic of sorts.  Of course, that might already be what you were doing! 

The original version of algorithm is quite similar to what you describe, the only difference is that I don't calculate the speed. I crate the initial layout of crates below conveyor belts and then I start to "rewind" their movement, that is, I step each crate up and if it reaches it's target belt then I switch it to "not-falling" mode and move it out of the screen (left or right). I repeat this until all crates are non-falling and out of the screen.

The problem is, there's a possibility that some crate is non-falling and moving back on belt but there comes another crate from below that has the same target belt and they happen to want to occupy the same location on the belt. I don't want it, therefore I lower the colliding crate (the one that's still not-falling) and all the crates below on the same column. And because of this lowering, the crates tend to accumulate on one side of the screen. If you watch the last recording you'll see it clearly when I rewind the crates and then forward them again. There are long streams of crates first two or last two columns.

The algorithm is quite fascinating to watch but doesn't produce a fascinating gameplay.

[goshki]

Day X+11: Fiddled with new crate generation algorithm.

Recorded dev session is here:

[goshki]

Day X+12: Mostly tuned parameters of the new crate set generation algorithm. The initial crate falling speed, number of lanes and density of falling crates will be dependent on the current level.

I've also flipped game window dimensions, so now it's horizontal instead of portrait. This way I can fit more falling lanes on the screen without having to scale crates down. Also the problem of waiting for the first crates to reach the collectable area is gone. A crates takes only three steps before it becomes collectable.

Recorded dev session is here:

[goshki]

Day X+13: Day two of tuning starting level parameters. Mostly trial and error. On each level the player has to collect a given number of crates and the plan is to choose the number so that on each level player spends roughly two minutes (considering other parameters, i.e. tick interval, crate fall probability and number of lanes). I'm almost there so I'll leave it as it is.

Recorded dev session is here:

[DeadPixel]

Crate job so far.  Keep going!