Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

HEXvolver | A Match-4 Spinning Hex Puzzle

A topic by zment created Mar 25, 2024 Views: 339 Replies: 4
Viewing posts 1 to 5
(6 edits)

A match-4 puzzle by spinning in a hexagonal grid!

HEXvolver is a Match-4 hexagon based puzzle game. By grabbing a gem and moving to neighbour gem, you can orbit the other gems around to line up groups of matching gems. Match 4 or more to gain points and more time to play. With 5 matches, you get a fire gem that explodes on match, and with 6+ you get a lightning gem that destroys rows of gems in all 6 directions. Get a good high score and win the leaderboards!

HEXvolver | A Match-4 Spinning Hex Puzzle


A bit of history and some ramblings

Originally started as a solo gamejam with the intention of getting a game out quickly on Google Play - just to get more familiar with the whole process. The very first version was uploaded in September 2022, with ~24 hours on the work hours clock. It was a very barebones prototype of my idea, and I was confident I could use the remaining 24 hours to fix any bugs remaining, slap ads on it, and push it to Google Play store. 

Oooh boy.

Every now and then I have put some hours in the game, and it's finally starting to look and feel like, well, an actual game. The current work hours tally? ...110. A smidge over 48, heh. And there's still a lot of stuff to be done. Especially as I'm also trying to get the game to Google Play...

As a mini-postmortem (even tho we aren't even there yet), the biggest timesinks thus far have been CI/CD related, or other metawork like setting up and managing PlayFab and Google Play. If people are interested to hear more how I've managed to waste hours upon hours with these, I'm up for explaining more (it's mostly my own incompetence paired with stiff policies and systems), but for now, let's just leave it at that.

Biggest gamedesign issues thus far has been how to make the game interesting. Early on I noticed, both by playing myself and seeing others play, that yes, the basic premise itself is interesting, but after a few minutes the gameplay... is just dull. Originally the game had a bigger board (btw. which I will be bringing back, or, well, at least the second iteration of the big board, so, yeah, medium board), and a timed 60 seconds to make matches, and getting some more time on each match, with the global score multiplier increasing every 10 seconds.

This tho might result in an "endless" gameplay, and with no other pacing, yeah, it could get a bit hairy.

For 0.3 (the currently just released version), I made the board one-layer smaller - this makes the game both easier and more difficult: it's easier to keep track of the gems as there are less of them on screen at once and they are bigger, but it's also harder to just willynilly maneuver the gems whichever way you want in multiple steps - and added "levels" or "rounds": once you get to full time, the board shuffles, and your global multiplier increases only at this point. This imo makes the game more interesting and the pacing feels a lot better.

To make it more interesting, the re-up of time per match/gem decreases slightly per level, and to prevent from getting to a difficulty level that forces you into an endless loop once again where you just hover around the midpoint mark in time, every first match of a combo the player makes increases the "time scale" - both time left and time gained are increased slightly. This increases the "risks" but also the "rewards", forcing you to either game over or go to the next level. 

This tho, might have the unfortunate side effect of making the game impossible to go forward to the next level after a certain point. I have yet to figure out how to make sure this doesn't happen - I kinda want it to be possible (but difficult) to basically go indefinitely if you are so inclined, but needing something like laser focus at the most difficult levels. Maybe just limit the maximum difficulty increase (you'd still progress to next round and get the next multiplier, but the game wouldn't get any more difficult?)

One of my personal pet peeves is the fact that when you have a match, you start to immediately try to set up the next match BUT there is actually a combo coming, and you don't realize it's still going, and then you don't also realize when you have control back again. The only thing I can think of fixing this some kind of visual and audial feedback/indicator that you have/don't have control, but I don't really have any good ideas what that could be. Maybe just darken the whole gemboard a bit?

Design issues aside, for completely transparency part of the reason I'm writing here is to get more traffic and eyes on my game. It's not _necessarily_ just because of that, but part of that want/need is that I really could use some feedback, bug hunting and testers in general, and all ideas are welcome - like mentioned before, I have some design issues still to figure out, and I'd appreciate it a bunch for any help people can give. 

As you might have guessed from the timeline presented, I might forget to develop the game for a day or a few months, but I'm currently very close (even if I'm only at 50%) to my first real Android release (currently in internal testing) for Google Play, which I kinda denote as 1.0, so I'll try to be at least somewhat active here as well.

Thanks for reading my long wall of text, and in advance for any eyes you can give my project, every little bit helps! 

(2 edits)
26th of March 2024

Good morning!

I was thinking about how to give the player some feedback on when the controls are blocked, so that one wouldn't keep trying to move the gems around even tho there is stuff happening around. My first idea was to modify the whole board in some way:

The effect is subtle, yet still somehow distracting. If you make it more evident, it's definitely distracting, and if you make it more subtle, it doesn't really work. So hmm. Other ideas? Maybe just change the color of the time progress bar when it's inactive:


I mean hmm sure I guess? Just make the color transition a bit smoother, I guess it could work... it feels a bit boring tho.

How about just an icon?


Hm. Not sure I like that. The icon would need to change at at least. And feels a bit lazy. But in the end better than nothing I guess?

How about instead of just color, make an image/effect to overlay it? Like, you know, it's frozen?


Hm. Maaaaybee? I'll try out some or all of these 3 ideas after the work day. Currently I'm leaning towards the "frozen" time, either with color, image, or maybe eventually some juicy effects. The icon and board darkening feel both distracting and/or lazy, tho at least both of them would be better than nothing. But I can get the time progress bar color change implemented just as quickly as the board color change, so I'll probably start there.

(3 edits)
27th of March 2024

Good afternoon!

I fiddled around with the time progress bar functionality and graphics yesterday a bit, and opted to implement the feedback that player control is disabled and time is frozen with, well, frozen graphics. I also added a minor "burn" visual to the active time bar. 


At least for now it seems to work quite well, there's a lot less confusion on when you can manipulate the gems yourself. The update is currently live with v0.3.19 and up for testing! There's a weird discrepancy tho, between built versions and in-editor, as in the timing is mildly wrong on the builds. I will have to figure out why that's happening and fix that.

I've been pondering my next steps, and I think the biggest step is to implement and improve account management. The game automatically creates a PlayFab account with a custom UUID that's created at first play. For Android, this means that if you uninstall the game, you will lose access to your account. So I'll probably start there, add linking to this customID with AndroidDeviceID so that the account won't be lost on phones on uninstall. For Google Play and GDPR compliance, I also need to have a method of deleting all player data and account, so that's going to be implemented after that. This account deletion will be in the WebGL version too. I am also thinking about adding a Link To Google Account, for the ability to get back to your account from another device, tho it would require some specific pondering and planning to get it properly working and have the correct workflow.

In the meantime, I'll keep trying to fix outstanding (and newly introduced bugs), and fiddling around with the leaderboard implementation. After the account management has been handled, I'll be going for ads for Android (WebGL version won't have ads, but also won't have all the features either - for example, push notifications on stuff like winning a daily, or being a top 3 on a monthly or so on leaderboards probably won't be there). I'll have decide in the future how and what I'll separate between the versions, but I will be keeping at least some version on itch.io with WebGL version. 

(6 edits)
28th of March 2024

Good evening!

Yesterday I wanted to fix the outstanding, since day 1, bug where sometimes the gems that you rotate flip around to wrong positions on release. I have an inkling that I know what causes it, but all my previous fixes have not been successful. The current version checks the closest hexagon empty hexagon cell to attach the held gem to, and then in a round robin fashion does the same for all the others. If the gems happen to be on the edge of the cells, some of the intended cells get to be filled before the correct has it's chance to get attached to it, and the gems "flip".

It's very difficult to reproduce, so I opted to figure out some debug visuals to help me understand the problem. I figured out a way to go thru the gems so that everytime the gems cross the cell threshold, the assigned cells just rotate around. This works well, in theory, and actually, when testing practice, it seemed to do the trick too! 

...however. If the change isn't from one cell to the next, but for instance, from top to bottom (which you can do if you go through the center gem fast enough), it goes haywire. 


So yeah, that's a problem. I think I could fix this method of handling the gems too, but I feel like this one is a lost cause. So, the next idea: First, when starting rotation, get the vector from the anchor gems cell to the next cell. Then, when I am calculating the correctly assigned cells, rotate that vector with the same rotation that has been done to the rotating gems. Now, get the anchorgems cell normally, by just translating world position to cell position. This is gem 1, or the anchor gem, or the one gem you are "holding". Now, get the world position of this cell position, to get the cell center position. Now, add the vector to this center world position, and get the cell position for this position now. This is gem 2. Then rotate the vector by 60 degrees (360/60). Rinse and repeat.

I feel like this is a lot easier to implement and also would result in a definitively zero amount of position-flipping gems. I'll be trying to implement this today, and maybe fix some other bugs too.

Oh yeah, I'm going to be making a change to my versioning. Currently I have X.Y.Z where X is either 0 or 1, 1 meaning release, Y is the current development milestone, and Z is the build/commits since version number. Well, I'm not actually going to change that, but how Y behaves: currently I've been adding new features to the same Y version, and then when I feel like it's "done enough", I'll increase Y to the next level. However, that feels a bit like I can't "trust" the Y version number to really mean anything. For instance, a 0.2.1 is a LOT different from 0.2.90. So, going forwards, I'm trying to have an odd Y to mean "we are implementing new and possible experimental features", so basically what is happening now with all Y version, but even would then mean "the features we introduced in Y-1 are now 'good enough' and this is the 'official' release". 

What this means is that I'll be promoting the current version to 0.4, and once I start working on something like improved account handling and some menu stuff, or Android ads, or puzzle mode, I'll increase the version number to 0.5, implement them within that version number and once I feel they are good enough, I'll promote that to 0.6, which denotes that "it's preliminarily done" but I'll keep fixing bugs on it.

To put it short: Odd ones (like 0.5) are unstable, and even ones (like 0.6) are stable - not that stability has anything to do with (or well, maybe a little).

29th of March 2024

Good evening!

Today I didn't get much progress on the game. I did manage to do some minor changes, and I did spend _massive_ amount of time to fix some longstanding bugs, but as something to show, it's not that much. 

What I did tho is decide that yes, the new version numbering is even numbers "stable", and updates are bugfixes and minor improvements, and even versions are feature implementation versions, where they start probably janky, and get updated until the next "stable" one. As such, the version has been bumped to v0.4

I managed to fix the flipping gems problem, and the way I'm doing the check now actually will help me in the future implementing puzzle mode and edge rotations. These won't happen until v0.7/v0.8 tho. I also fixed the floating gem problem, as well as added a mute button to both main menu and in-game. This has the added bonus that a player might realize that "hey, this game has sound!", as I think many mobile players play without sound. I've also tried to mix the volume of the sounds better so that they aren't too jarring.

For v0.5/v0.6 I'll start implementing the needed account handling system, which means a settings menu and ways to delete account data and disable online features. I'll also add sound configuration and linking to android device id as well as google account. 

In the meantime I've been fixing the "accidentally to production" fudge-up I made, and soon I can start using closed testing again, or the alpha track. At that point I can ask people to join the testing on Android phones.

I've also been thinking of changing the way the current RUSH game mode plays. I like that it gets progressively harder, and I like that if you spend too much time on a level, you are kind of "forced" to either game over or the next level, but I do also want the possibility for a good player to just continue leveling up "indefinitely". So, I'll be implementing a "difficulty level cap" to around level 8. You can still go to the next level, and your level multiplier will increase, but that's the cap for increased difficulty. I'll be testing and fudging around with it to have a good cutoff point tho. Also some values might need balancing as well. ALSO also, maybe I'll change the constant multiplier from x10 to x25?