# [W5GD] A Really Rough Prototype, and About Ten Different Thoughts Behind It

I wrote this as my thought process and guidelines while making the 1st prototype, which has a video as found here:

So I figured, I might as well post it.

JUST TETRIS

Literally, just the base game. I’m following this tutorial, though I’m unsure if I need to make any adjustments to prepare for implementing the effects and audience. For example, if I should already change the algorithm to select 3, then 1 from those 3 effects.

Things to consider, on if it should be excluded or included:

• Very basics, like T-Spin, if the falling speed increases when Down key is pressed
• Inclusion of a getOutOfJailFree thing. Start with 3x usage. If J key is pressed, clear the bottom 4 rows. This should be an anti-frustration feature, especially for new players who might be easily caught by new effects. You can acquire more usages through extreme luck.
• If there should be a Next queue, and a Hold ability.
• No transitions after certain number of lines cleared: most likely, the combination of effects will cause too much suffering, and I’ll need to put more anti-frustration things.

DIFFERENT EFFECTS

While the Player plays Tetris normally, different effects will manifest at certain intervals. I haven’t decided the exact timing, but it might be something like this. I assume that the Algorithm has 0 delay, and that there is an audience. If there is no audience, we can just assume that the Algorithm takes the role of the audience, just with 100% randomised selection rate.

• (TIME): (PLAYER) / (ALGORITHM) / (AUDIENCE)
• 10 seconds: Normal Play / Nothing / Nothing
• 20 seconds: Normal Play / 3 Selected / Audience Voting
• 10 seconds: Normal Play / 1 Implemented / Nothing
• 20 seconds: Normal Play / 3 Selected / Audience Voting
• And, so on, until the Player dies

The turnover rate might be too slow, so we’ll see how it goes.

A PROPER ALGORITHM

I decided against having a max limit of co-existing effects, since 1) that’d be annoying to make, you’d have to decide how to dispel effects, e.g. after 10 turns, or based on the number of effects currently present. 2) It’d help to increase the difficulty as more and more effects appear, plus the intended algorithm (as shown below) is supposed to be quite lenient.

I’ll try to avoid 100% RNG, since it might make the game too easy or difficult if you happen to get certain effects by luck. So, I’ll use a weighted percentage, based on an effect’s “type” and “last appearance”.

Types can be divided into Variables and Booleans, where some things are either on a scale, or present/absent. For example, fallingSpeedOfBlock is a variable, while reverseControls is a boolean. There’s a third category, which is just Specials, which includes things which shouldn’t be subsumed under either of the suggested two categories.

Last Appearance refers to the last time an effect was manifested. I considered a new category like Potency, but decided against it since the impact of an effect can’t really be judged easily (e.g. maybe Garbage might benefit/disadvantage based on circumstance).

Variables

The maximum chance of reappearing decreases with each increment. At the maximum/minimum value of the variable, the possibility of increase/decrease is capped at 0%. For example,

• when fallingSpeed = 1.0, up to 100% chance of fallingSpeedUp & 100% fallingSpeedDown appearing (of original chance value),
• when fallingSpeed = 1.2, up to 60% & 140%
• when fallingSpeed = 1.4 up to 30% & 170%,
• when fallingSpeed = 1.6 up to 0% & 200%,

Possible variables would thus include these:

• fallingSpeedUp / fallingSpeedDown
• stageWidthUp / stageWidthDown
• stageHeightUp /stageHeightDown

Booleans

The chance of appearance is constant, and will never fall to 0%. If same effect appears again, it simply switches the boolean value, such that the effect is undone if it’s already manifested.

Possible booleans would thus include these:

• reverseControls
• reverseStage
• onlyLPieces, or onlyTPieces
• AutoRotate (i.e. no manual rotate)

Constants

Things with a constant rate of appearance, and no on/off state. I have almost nothing right now though. Maybe under New Asset Based (see below).

• onlyLPieces: similar to the boolean type above, but only for 10 rounds. May be slightly less painful than the boolean, so I might do this instead.
• In fact, about any of the booleans can be shifted here, on the premise of “it lasts for 10 turns”. But I wouldn’t really want players to waste brain energy calculating when something runs out.

Specials

Usually, things with a constant rate of appearance, and things which may not affect gameplay too significantly. In other words, bonuses and Easter Eggs. The two here are New Asset Based, but I think I should add them anyway (or the first one, at least).

• getOutOfJailFree: you can clear bottom 4 rows without penalty, by pressing the J key. Likely, a low chance of manifestation (like 2%), and should already be available at the start.
• Skins: literally no effect, it just changes what the interface looks like. Probably also a low chance, more for player/audience entertainment, to make them feel pretty lucky! Maybe like 3 different themes, including the default theme.

Yeet me off the mortal coil

A special category for things I’ve considered. It’s either too painful for anything to bear, or it might be hard to implement since it involves additional things than just changing values in the system.

New Asset Based

• garbageAbove / garbageBelow: introduces garbage to the level, either below the existing stage or falling from above (Constant)
• newBlocks: introduces new types of blocks, such as 9×9 (Boolean)
• changeVisibility: darkness except around falling piece, or zoomed onto falling piece, such that you can’t see the rest of the level (Boolean)
• sideGravityUp: blocks float instead of fall now, including the original set of blocks, which will fly up into a new position (Boolean)
• sideGravityLeft: blocks are pulled towards left, which doesn’t involve the original set, but all new blocks, upon being placed, will be pulled to the left (if possible) (Boolean)

Death Is Preferable

• AutoMovement: can’t translate left and right manually, which would be absolute suffering, especially at high speeds, since you need to wait for the system to move it to your preferred location, and by that time you might already be dead
• onlyMoveRight: similar to above, but you can only move blocks rightwards. Also, an easy way for immediate death.
• noRotationAtAll: again, easy death.

AUDIENCE INVOLVEMENT

The easier part would include changing the algorithm, such that it selects 3 effects than 1, then presents them. After which, the audience can choose 1 out of 3. I haven’t decided if the rate of appearance should be affect if an effect appears, but isn’t chosen.

The harder part would include bringing the audience in.

1. The Player selects “I’m a Player”. The system makes a room, and auto-assigns a Room Code. The Player plays as usual, with the algorithm doing the work.
2. If there is no Audience, the algorithm just continues selecting as per normal. (In other words, the Room Code is only used if the Player wants to share it with potential Audience.)
3. If there is Audience, but no Audience Votes, the algorithm just selects 1 out of 3 with 100% random rate.
4. If there is Audience and Audience Votes, the algorithm selects the effect with most votes. If there’s a tie, the algorithm selects with 100% random rate.

That also means that, on the Audience side, adjustments must also be made:

1. The Audience selects “I’m Just Watching”. The system requests the Room Code, which the Audience must input to enter the correct room.
2. The Audience gets to see the Player’s board. They also get to see what 3 effects are up for selection, and can pick within the Audience Voting time.
3. They select 1 choice. Once selected, they can still change their choice until the Audience Voting time is over. (Whether they can see the current number of votes per effect is unknown, but this might be interesting, since it might make the audience try to persuade each other to change their votes)
4. After Audience Voting time, the effect is implemented. The next Audience Voting time begins, with a new set of effects.

Things which I haven’t decided:

• If there should be a maximum audience limit
• If there should be a lobby where anyone can join any room (i.e. may have to provide private rooms as well)
• How much time to allocate (e.g. 30 seconds for audience voting, 5 seconds for Player to see what effect was attributed before it’s activated)
• If the Room Code should be just shown on the player’s screen (a little awkward for solo players, but useful for screensharing, e.g. like Jackbox)
• How to make it work for mobile & computer (most likely, I won’t implement playing on mobile, but it seems likely that audience would use their phone than a computer)

Alternatively, I may consider other ways of implementing the audience, such as Twitch Chat (a la Dead Cells). For now, I’m intending to try out Mirror, the substitute for the recently-deprecated Unity NetworkManager component.

AFTER CLASS

I’ve been recommended to use a single script for everything, which is the fairest judgment possible, because the cross-references between scripts right now are too… Much.

So I shall work on that, and attempt to implement the Next queue in the meantime. Also, to attempt to create an algorithm that selects the effects, than selection based on key presses.