Some features of the script are an algorythm preventing the game to display already matched blocks when it first loads the grid, an algorythm that calculates the positions to where a blocks can be moved and lots of optimizations that enhances the performance of a grid based game (if anyone wants some advice with this topics, I can write some tutorials later).
The game is intended to be always beatable in one way or another, so if someone gets stuck please take a screen capture to check it.
Every opinion about the gameplay and performance (and corrections on my f***ed english grammar) are well received!
Sorry , I can’t test it (I’ve Ubuntu in this PC), but I want to ask:
Did you optimize the old tutorial match algorithm, or did you write a full-new one?
I take a quick look at the tutorial, but to be honest the only part of my project that resembles the tutorial indications are that simple algorithm that loads and locates the blocks (because that is the most optimized way to load the elements of a grid), I made everything else from scratch.
In fact, I have 3 different match algorithms: the first occurs when a block is selected and pre-calculates all the possible matches (matches, right?) for the selected block (because my game only allows to move a block to a position where it will match another block of the same color), the second occurs when a block is moved and it checks the effective matches for the blocks affected by the move, the third occurs after the second and simply checks if the is_matched variable of every block is 1 (this is the “win check” and it iterates trough all the blocks but it just have to check a variable because all the hard work is already done by the first and second algorithm, also, it stops when it finds a unmatched block so it’s very economical in processing terms).
The first and second algorithms are very extensive and when I say very extensive I mean they are HUGE, but despite their size they always take the shortest path to the match verification so they all execute very quick.
Even with all the optimizations, I also experience some lag problems when I test the algorithms from GD (maybe 1 second lag when a block were selected and a two seconds lag when it’s moved) but once the game were compiled to the native format the processing lapse were reduced a lot (there is always an almost imperceptible lag but the game works just fine).
You had to know my game works different to that the tutorial intends to create, the grid don’t scroll, there are not extra blocks added during the game, the matched blocks are not eliminated. The game is simplier but the algorithms are more complex. It’s a different gameplay but the match algorithm can be easily adapted to other games.
Tried the game. Noticed that after making a swap the square cursor stays on the last block and does nothing, and under the mouse pointer there is another square cursor which I can move. So, maybe it’s better to delete cursor after moving the block and leave the cursor which is under the mouse?
The game was hard for me and to keep motivation up maybe you can add points for every match.
Uhrmm… the default cursor is the white frame under the mouse pointer. When a block is selected a light-blue frame will remain on the selected block and the white one will still follow the mouse pointer. When a block is selected (under the light-blue frame) and the white frame hovers a block to where the selected one can be moved it will turn to yellow. This is how it’s supposed to work, is that what you mean?
About the points system, yeah, I had done some work in that direction but I just wanted to release a first version that focus on an effective gameplay. So maybe in further versions.
You mean the Game Develop project? There are some cryptic algorithms there. I’d prefer to make a tutorial to properly explain how it works. Anyway, I had no problem with the idea of release the project here in the forums, but I had to do some cleaning first (there are a lot of useless and non-sensical variables declared there).