Category: My Work

After watching videos on how to code jumping, I realised there’s a lot more depth to jumping than I thought: for example, it can mean a world of difference if you allow the player to control movement while in air, or not. So, I decided to focus on jumping exclusively.

It’s playable-ish up to the 3rd or so bug, but I haven’t built the maps for the rest. I also haven’t actually tied the bug effects to the picking up of bugs; in this video, it’s literally just pressing the relevant key when you get the bug.

I’ve coded in all the required variables, except for dropping through platforms (i haven’t figured that part out yet, so watch out, prof, i’m coming to your inbox). Here’s another video to show the effects:

Issues which I have not figured out how to solve:

• Aforementioned dropping through platforms
  • I can’t seem to find a suitable code which works with what I have, and me trying to hack at it doesn’t really work
• Jumping lines when dialogue is ongoing (e.g. even though there’s 5 lines, only the first line shows)
  • Apparently tied to number of other dialogue box-using objects; when I reduce to only 1 Person, the dialogue plays fine
• If I disable movement while the dialogue box is open, if the player is moving when dialogue is triggered, they will slide on forever until the dialogue box closes
  • I have.. No solution. It’s definitely related to the playerMovement() function, but I don’t even know why it would happen.

TO-DO FOR NEXT WEEK

I know I had a timeline, but I realise I greatly underestimated how important sprites are: the sizing will definitely be off once I implement them. Of the aforementioned issues, too, the only really significant one for now is the 1st one. So, I’ve decided to change it slightly:

I can see quite a few issues cropping up, like a) the sizing going haywire, b) the block tiling for platforms failing, c) failing to reference the correct bug, despawn it properly, or change the correct value, or d) the fact that my current Player has a really fun spin, to the extent that there’s no “right side up”: if I add a proper sprite, I might have to include code which stops it from doing so. (Unless I actively decide to make it have no right-side-up.)

What’s that about “game endings”? Well,

MORE IN-DEPTH CONCEPT ADJUSTMENT FROM LAST WEEK

My stretch goal is to amplify the emotional aspect, in terms of the parallels between “a buggy game” and “sadness over being incompetent”. As such, I’m thinking of having 3 endings, which have different activation conditions, and which correlates to “your relationship with bugs”.

I don’t know if I should spoil it, but I’m likely to forgo it since no time, so I’ll only talk about it if it comes to it, and just stick to the ~happy village life where you help the villagers catch bugs~ story.

The villagers may or may not have a role to play in this, which is why I’ve added them. That’s quite tedious, though, so I might leave them as hint-givers, as per right now. (They also don’t have changing dialogue based on changing progression rates, because I did that before, and boy, it was not fun.)

(It’s also kind of boring to only reach places just to get bugs, so I put people as hint-givers to mediate that.)

SOME REFERENCES

• Code Monkey series on Jumping (link)
• How to make a Dialogue System in Unity (link)
• Super Mario Maker 2: No Jumping Allowed (link)
• IDK it was a cute square so I was reminded of this (link)
• And like 3711748 Unity forum questions

i submitted at 0943, checked again around 1330, and was disappointed, as always, that i uploaded the wrong file, there’re bugs. life is suffer

VERSION BY-200214

• Implemented base version of Tetris
  • Includes generating blocks, falling mechanic, movement, rotation, play area, line clear, collison
• Implemented variations
  • Assigned to Key Pressing
    • Changed constants to variables
    • Included variations for falling speed, reverse controls, auto-rotation, camera zooming, changing block types

VERSION BY-200221

• Cleared up unnecessary code
  • Compiled into a single script, than attached to multiple objects
• Removed GetOutOfJailFree & HOLD indicators
• Implemented HISTORY indicator of past variations

200221 Shah (player) & Mus (key presser)

• • Shah is visibly done with Mus, who is abusing his abilities
  • It’s quite funny nevertheless
  • Falling Speed of Blocks is outrageous at 0.1f
  • Impossible to play at all after a certain point
  • An additional suggestion to go the route of a key presser who has to fulfil certain tasks before he can ruin the player’s life, e.g. minigames, or a timeout

200221 Kee Yong (player) & Shah (key presser)

• • Pretty much exactly the same sentiments

200221 Wei Ting (player) & Me (key presser)

• • Wei Ting is doing acceptably alright, since I try to act like an impartial algorithm
  • Not enough variations to be intriguing

In other words, rerouting the variations to activate through an impartial algorithm at specific invervals, than a partial algorithm at random intervals

VERSION BY-200228

• Modified variations to a random algorithm, from key pressing
• Implemented UI
  • A NEXT indicator area, to show the upcoming piece
  • SCORE tally of various items, such as total time elapsed
  • HISTORY indicator of last 5 variations
• Fixed bug where I Piece didn’t rotate around the correct point
• Fixed bug where O Piece rotates
• Fixed bug where Zoomed Camera doesn’t follow the falling piece
• Cleared up unnecessary code
  • Removed variations for changing height and width of play area

VERSION BY-200301

• Modified algorithm to be weighted, than 100% random algorithm
  • Instead of picking a random variation, the algorithm now picks a type of variation, then rolls for an outcome. 75% odds of getting a favourable outcome for that variation
• Implemented new variation types
  • ~2% chance for in-game music to change to 1 of 4 songs
  • ~4% chance for in-game background to change to 1 of 5 backgrounds
• Implemented SCORE system
  • Implemented counters for things like Total Number of Blocks, Total Time Elapsed, and so on
  • Implemented score algorithm, giving different weights to different segments contributing to score
• Implemented Tutorial at start of game
• Implemented Restart option (R) & Tutorial Skipping option (S)
• Implemented Speed Up (Q and/or W)
• Fixed bug where counter and visible grid didn’t align

200301 Prof (player)

• • Confused by names of variations,
  • Can’t tell what variation is occurring,
  • Doesn’t know that effects stack (than being dispelled),
  • Despises the auto-rotation (especially in conjunction with high falling speed)
  • Confused by information overload of UI
  • Total score of about 8.6k

200301 Wei Ting (player)

• • Too focused on playing the game itself,
  • Doesn’t notice that variations are occurring and affecting gameplay,
  • Just thinks she’s not good at Tetris
  • Total score of about 1.3k

In other words, fix the UI and information hierarchies.

VERSION BY-200306

• Modified algorithm conditions and weights
  • If the same variation is called up, instead of having no effect, it may reroll to give another another variation
  • Impossible to get absolutely no effect for a round. Increased chance of failing a roll to 40%, from 25%
• Modified Rotation Lock, from auto-rotating clockwise once per second, to rotating clockwise once per left/right keys pressed
• Modified SPD function
  • Pressing Q and/or W will cause falling speed of blocks to increase, not just the countdown to variations
• Modified UI by, like, a lot
  • Modified HISTORY segment to ACTIVE segment, which states presently-active variations than past variations
  • Modified SCORE indicator area, to only show at the end of a game
  • Modified text for about everything to be less Debug.Log-based
  • Implemented bar (and removed text) in indicating countdown
  • Implemented icons and animations for Key Press functions (Q, W, S, R)
  • Implemented tutorial image for Movement keys
• Modified activation conditions for certain keys
  • Restarting (R) and Skipping Tutorial (S) now requires holding for 1 second, than pressing the related key once
• Modified SCORE counters
  • Reduced max Score to 99 999, than 9 999 999
  • Reduced Speed Up bonus
  • Increased Line Clear bonus
• Implemented Game Over condition
• Fixed bug where I Pieces and O Pieces weren’t centralised in the NEXT indicator area

CREDITS

• Music
  • ff5_bigbridge (link)
  • Tetris – A Theme (link)
  • Tetris Attack – Poochy’s Theme (corrected errors – final submission) (link)
  • Video_Game_Themes_-_Zelda__Ocarina_Of_Time (link)
• All background images from Pixabay

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.