Thanks for considering my feedback! I totally understand about the minimal design for focus on functionality. I'm looking forward to future updates! Regarding characters/game overall feel, I was hoping for a "japanese-esque, cute" approach, maybe something akin to 100% Orange Juice by fruitbat factory? although I don't mind whichever direction the main skin goes for! (Perhaps I could ask some art friends to contribute? I can't promise I can follow through with that, though...)
In general, having various characters like Puyo for this game would be absolutely fantastic, and I'd love to see where this project can go with that!
Cool I am open to adding anything as long as I have the assets, but at the same time I would like to keep everything customizable.
@TricksterGuy
Just a suggestion and question: Is it possible to add a complete adjustable block timing tweaker via in-game menu? The block flash delay just before it disappears seems off when compared to Tetris Attack, side-by-side. Thanks for sharing this -- it's looking better everyday.
that'd be some work, and by that I mean busy work because of all of the UI work needed to add it, and I wouldn't want to keep such a setting in the final project.
The speed settings are controlled by 6 constants.
struct PanelSpeedSettings
{
int swap;
int pending_fall;
int falling;
int pending_match;
int first_removed;
int subsequent_removed;
[...]
};
swap is the number of frames it takes to swap a panel
pending fall is the small delay in frames when you swap a panel over a gap before it falls
falling is the number of frames before a panel moves down 1 row
pending match is the number of frames for blinking
first removed is the number of frames before the first panel disappears.
subsequent removed is the number of frames to remove the next panel that has been matched.
Below is the current settings for these per mode
PanelSpeedSettings easy_speed_settings = {4, 6, 4, 66, 33, 11, ...};
PanelSpeedSettings normal_speed_settings = {3, 5, 3, 45, 25, 9, ...};
PanelSpeedSettings hard_speed_settings = {2, 4, 2, 33, 17, 6, ...};
The numbers are in frames and the order matches up with my struct above (e.x. in easy a swap takes 4 frames, pending_fall is 6, falling is 4, etc).
About how much of a difference is it?
Yes, it was a 0.1.5 replay in 0.1.5. Granted, it's over 28 minutes long, but getting over 100K in Normal isn't the fastest thing.
I was wanting to be sure I was getting some chain types, even if their timings are unreasonably strict., 'cause I know I've done late slips, grounded midair switches and even late drops (but the timings seem off, especially on late drops).
While composing: Yep. Replays are borked. I tried to save a replay losing immediately after achieving a late drop chain, and there's no hint of it.
Next, C-Links seem to make transferring chains just a little too easy. In TA, if a 'C-link' doesn't start to actually pop before the chain hit ends, it will be counted as a x1. In BBB, I've had chains seeming to continue out of nowhere because a C-Link takes on the full properties of the chain.
Another thing that needs revisited is stop timers. I've had stacks start moving much sooner than I'd logically think it should, and I think it's because a shorter stop timer from when the stack is lower is somehow overwriting the longer stop. Maybe checking to see if the remaining timer is greater than the current bonus's timer and discarding it if it is would fix this seemingly errant behavior.
Finally, it may be a pretty simple thing to implement Time Attack. You've already got a time counter, and if you let it run for 00:02:00, and then have it switch to Game Over after that, there's Time Attack.
Yeah as a reminder the whole replays thing I added only for my debugging, so the code for this I would say isn't production ready code. I was playing with it yesterday and it seems to work for me. Can you try with a shorter replay. I have never saved anything that was more than 2 minutes of gameplay.
And I saw that with my playtesting yesterday, it does allow you to extend a chain, but it shouldn't. This may require some extra thought as to how my code determines if something is a chain or not.
That is the main piece of logic behind time attack. I can really have the mode implemented with no fancy things in about 30-50 lines of code or less, the timer would have to count down instead of count up.
Extras would be stats display at the end (number of combos, number of chains, etc.).
The stop timer I may have broken at some point. For each match you make I make some calculation on if it is eligible to cause a timeout and how much seconds of timeout you should get. Right now if you are already in timeout and you create a match the two values of the remaining time you have left and the amount of time you have earned are compared and the timer is reset to the greater of these two values.
Hey, so right now the lift should behave as if Exploding Lift was off, right? Well you're gonna have to disable the lift when blocks are falling then, because right now it's only disabled when blocks are popping.
Also, when blocks start dancing from being too close to the top, only the columns that are too high should be dancing (it helps draw attention to them)!
Alright fast rise should only be allowed if all blocks are currently idle. Got it.
You learn something new everyday! Misconception on my end I always start by flattening the stack and then rising the blocks to the top then making my matches, so that's where that incorrect behavior came from. Actually that makes a lot of sense why the blocks would do that by columns and not the whole board. That is a nice user interface thing.