Category: Process

You can click to scroll to the endings guide, and of course it has spoilers

Week 13

• Recompiled entire project, and when I say recompile, I mean make a brand new project and slowly drag in things from the old project while trying to avoid compile errors, because my old project became unsalvageable from the mess
• Created .yarn dialogue files… Many of them…
  • Included Destroy and Instantiate of GameObjects to change out dialogue files… Because I didn’t know how to… Replace the dialogue files via script directly…
  • Provided hints on surroundings, what to expect, what might be needed, etc
  • Provided pathway to some endings through dialogue
  • Projected my paranoia 2k20 of what people want to say to me
• Connected Yarn Spinner to gameplay
  • Created command to destroy bugs once they’re done (assumes a certain sequence, but no one has been able to sequence break yet, so shouldn’t lead to any game breaking?)
  • Derived player jump capabilities, and a hidden counter for a certain ending from Yarn Spinner dialogue progressions, with bugs and NPCs respectively
• Removed namespaces. Not very significant, but significant to me, because that was really troublesome.
• Connected the ending scenes to the game scene
  • Created a click-based mechanism for a certain segment, looks very like you could break the game, but by some miracle it doesn’t happen
• Aesthetic things
  • Included some sounds and music
  • Touched up sprites slightly, made a few new sprites
  • Adjusted sizes and fonts of dialogue and UI things
• Adjusted difficulty again, in terms of difficult of platforming (i.e. easier)
• Gave up on certain bugs lmao, visually annoying but theoretically harmless, and tragically appropriate

Week 12

• Added Yarn Spinner for dialogue management
• Recompiled entire project to fit Yarn Spinner systems, which includes… Everything…. Bugs, portals, resetting, endings… Basically, it was like redoing the entire project from scratch, and trying to copy-paste whatever I thought could be reused
• Fixed the levels a bit more, again for less frustration, less sequence-breaking
• Fixed the “R” prompt, where it previously didn’t cover all the space it should have
• Created the 3 endings, and no spoilers, but it included new systems of input, new animations, new option-based dialogues, new variables….

Week 11

• Finished the remaining level designs for Forest & Field
• Adjusted levels slightly for slightly less frustration and slightly more sequence-breaking nullification
• Fixed bugs related to getting stuck in between platforms; you can now only pass through platforms which are 1 unit in height
• Added Debug.Log, which shows the current state of your jumping abilities
• Added error message which activates when attempting to use a function which hasn’t been unlocked
• Adjusted “R” prompt; now also plays an error message, and returns you to a “last checkpoint” than “last accessed portal”

Week 10

• Fixed dialogue and dialogue trigger issues; it now collides properly, disappears properly, and plays properly
• Removed unnecessary portals and added “R” prompt; whenever you press it, you are returned to the last portal you came through
• Added levels for Field
• Switched levels to tile sets from sprites
• Added preliminary sprites for interactive items
• Added a cheat code, just for fun; if you figure it out, you get the debug controls

Week 09

• Created basics of game, from player to dialogue
• Allowed for variations in jumping capabilities through key pressing, in anticipation of allowing it to occur through bug fixing

Things I Should Have Done But Never Got To Doing

• The bugs auto-going into your inventory than having to pick up, as long as you’re close enough
• Animations, to drive home the difference between the player as a literally square while everyone else is animated
• Allowing dialogue progression with Z key than left mouse
• Sizing, where the UI goes bonkers when it’s not full-screen

How to get different endings

There are 3 endings in total, corresponding to 3 potential responses to bugginess (i.e. being insufficient, flawed).

ENDING A: MY ETERNITY

Ending A is triggered by a hidden counter, countSadness. This is alluded to by Tomato, who mentions the flute as an indicator of your negative feelings. You can increase or decrease the counter through dialogues with NPCs, though there’s no fixed pattern as to who increases/decreases it. In fact, it might be possible for someone to decrease it, then later increase it for you.

As a general guide, whether it increases, decreases, or has no impact, depends on what the NPC tells you (i.e. if they’re supportive, degrading, or neutral).

The meaning of this ending is to give up; resorting to self-harm when you’re faced with bugs and insufficiency. My Eternity of falling to shame, self-degradation, suffering and tears.

 

(The next two endings actually need a map reference, so)

 

ENDING B: VILLAGE LIFE

Ending B is triggered by collecting all 7 ordinary bugs, and speaking to Daisy. In other words, the default ending which you’d probably aim for from the start. Most bugs are fairly easy to access, with some areas being significantly harder, or straight up impossible if you try to sequence break. Some NPCs will thus advise you not to do certain things yet, or the like.

The meaning of this ending is to face your problems; if you’re plagued by bugs and insufficiency, work to get rid of them. A Village Life that you’ve rightfully earned, with acceptance by everyone else.

Ending C: ASCENSION

Ending C is triggered by reaching the top of the Axis, which necessitates that you collect the gold bugs (it is narrowly possible to do without Midair Control+, but the rest are crucial). A sort of secret ending, where only Clover and Crysanthemum allude to this possibility. Basically, why fix bugs when you can just become a bug yourself? And, maybe eat(?) your friends while you’re at it.

The meaning of this ending is to rise above and manipulate instead; use your bugs and insufficiency to your advantage, and break away from the norm. Ascension to a higher plane of existence, beyond the ordinary.

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.