poobslag / turbofat Goto Github PK

The screen should show the buttons the player is currently pressing, as an overlay. Regardless of how they've customized their controls, this will simply show 6 inputs for up (hard drop) down (soft drop) left, right, and the two rotate buttons.

These inputs are intended to double as pressable inputs in the android version. But depending on how big or obtrusive they are, they might either adopt a different visual style (smaller or transparent) or they might be toggleable via a settings dialog.

As customers grow in size, the camera should zoom out to keep more of them in frame.

We don't want the customers to look grotesque, but it might be nice to add a few minor touches so that we're not literally scaling up an oval shape:

• belly button should become more pronounced
• fatty neck rolls to the left and right sides of the head
• fatigued facial expression
• body sweat

We currently have a few art assets such as head-outline.png which go behind sprites and help characters "pop" slightly. These assets could be generated in-game by an object which looks at an object, figures out which pixels are opaque, expands the selection by 2-3 pixels and fills it in with this brown color.

This will reduce the number of assets and also reduce the burden on artists to draw these effects themselves. It also eliminates the risk of artists accidentally drawing these outlines too thin or too thick, or varying their style over time.

This could be implemented as gear in the corner of every top-level scene. Clicking the gear would launch an overlay which lets the user customize their controls. It would list all of the controls one-per-line.

Users need to be able to bind multiple keys to the hard drop and soft drop actions. There could be a 'Hard drop" and "Hard drop (Alternate)", "Soft drop" and "Soft drop (Alternate)" to allow users to specify multiple keys for those specific actions.

This issue specifically refers to 'keyboard controls' to avoid an ambiguous interaction with #34, as far as which gets finished first. Don't worry about customizing joystick controls for now.

The current solution for drawing a 2D isometric scene is a little hacky and will start being more cumbersome as the scene changes:

• As objects move, we need shadows to move with them. We don't want to manually reposition shadows.
• As scenes involve more and more objects, shadows should be derived automatically based on the object's size. We don't want to manually define and draw shadows for every object.
• As objects move, we need them to occlude each other visually. We shouldn't need to manually decide "this object is in front of this object," the framework should do that for us
• As objects move, we need them to bump into each other and not pass through each other.
• Some objects might not be directly on the ground, for example characters sitting on tall stools, or objects hurled through the air. They need to be drawn appropriately, and their shadows need to be drawn appropriately, and they need to bump into things appropriately.

We should implement a robust solution which either uses 2D sprites in a 3D world as seen here, or which customizes 2D sprites in a way that they have a Z coordinate.

We also need to come up with a more expandable shadow system which handles a variety of types of shadows, or automatically generating shadows for 20 different objects in a scene of different sizes. It's OK if these are all same-shape shadows like simple ovals, but it's not OK if they're all the same size.

At a small size, the customer's torso is in shadow because his head casts a shadow. At larger sizes, his head is dwarfed by his body and his body should be mostly illuminated, except for the areas directly beneath his head, arms, and legs.

The same is true for his arms and legs, which also have shadows from his head. We don't need anything too complex, but maybe just two arm/leg images based on when the head's shadow shrinks past the shoulders.

We display some text over the playfield, including countdowns like "3" "2" "1", "You Win!" and "Game Over". This text is not going to remain in its current state, but it should still have an outline to make it more readable.

Depending on the monster who's talking, their dialog faces should change. Blue monsters should have a blue face, fanged monsters should have fanged faces, etc...

Draw expressions for all of the different monsters, and try to make sure they overlay OK. While in the long run this could lead to an O(n^2) mess of facial combinations, where this guy's angry face with this type of eyebrow results in a visual glitch, I'm planning to sharply limit the different combinations. Rather than mixing all ~20 eyes randomly, a given mouth might only mix with ~5 of them, they'll have little pools of randomness.

Additionally, dialog faces for fat monsters should have their bodies shown appropriately.

The player should be occasionally prompted for a few dialog choices, like "Will you" "Won't you" or "I like it," "I hate it," "I think it's just OK".

The heavier lifting as far as a robust control flow can be handled by #74. For now, this should be focused on the UI. Make sure the options look pretty, and make sure the player won't press them by mistake if they're button mashing. Maybe each choice could be a direction, and they have to hold a direction on the joystick while pressing a button.

Currently, the top-level directory includes configuration files, resources and readmes but it also contains Turbo Fat.exe, Turbo Fat.pck and Turbo Fat.x86_64 files. These compiled artifacts should go in some kind of a generated bin, output, target or similar directory. If godot has a convention for this, we should follow it.

This directory's contents should also be in the gitignore. I've currently had some close calls almost adding huge 50 MB zip files to .git by mistake because we do not follow this practice.

After the new customer graphics in #62, game load times increased significantly from about 1-2 seconds to about 4-5 seconds, and that's on my computer. On other computers this might be even slower.

This is most likely to adding all of the new textures. This problem will only get worse over time if we add more and more graphics for the different bugs. We should pursue different options for speeding this up:

• Cache textures in a singleton so that they only load once on startup -- not every time a game starts
• Or the other direction, load textures in the background instead of loading them all up-front
• Make the textures faster to load; maybe instead of 1024x1024 images, we can scale them down to 256x256.
• Maybe using a tool like "PNG crush" to shrink the PNGs could help. It's doubtful, but there's a chance that if they become indexed PNGs it'll clue Godot in that it can be more efficient with them.
• Maybe GLES2 loads textures faster?
• This is a pretty simple problem so others may have suggestions online. These people think disabling etc2comp could improve performance. These people wrote some sort of custom 'texture caching' thing. These people think having too many unique shaders takes time to compile.
• Maybe tweaking some of our texture filtering options could improve performance too, such as mipmaps or 'lossy quality'. I'm not certain whether we rely on mipmaps.

Seat.tscn (and perhaps some other places) have some convoluted parallel scene hierarchies for the sole purpose of keeping shadows and outlines behind other objects. I think Godot gives 2D sprites a "Z" component for this exact purpose; we should use it more intelligently.

Eventually the vision is that there would be an entire animated chef who walks or runs depending on how fast the player plays, cooks and hurls food in the air, and animates in different ways based on what the player does.

For starters though, let's just have a chef in a kitchen-type environment who swats food at the customer with a single animation. The chef's animation should sync up with the customer animation when food is served. Both should share the same restaurant scene.

When a piece locks, there's a good audio cue but no visual cue. It would be nice to see 4-6 particles poof out of the bottom of the piece like > < wherever it lands. The algorithm could just be something like: When the piece locks, if a block in that piece lands on a block in the playfield and is horizontally adjacent to a cell unoccupied by the piece, two particles poof into that cell.

Make sure the particle lifespan scales with the difficulty.

The player character should be able to walk up to other characters, hit a button and have some text pop up.

For now, the dialog will be text only (no picture of who's talking) and it will be uninteractive (no choices). But, we should nail the look and feel:

• Player should be able to flip forward through multiple sections of dialog
• ✔️ When a player is in range of a person who can talk to them, they should see a visual indication (maybe their head tracks you, or a speech bubble appears, or they highlight or something like that.)
• ✔️ Windows should look nice, and we should use (and license) a nice font
• ✔️ Windows should appear and disappear gracefully. If blinking looks good, just have them blink in. But maybe they can unfurl or swoop in or expand or something.
• ✔️ Text should appear one letter at a time, like in an RPG. But, the entire message should still appear quickly.
• ✔️ Player should be able to mash a key to make all of the text visible quickly
• ✔️ There should be a "skip" button, and dialog should also be skippable with escape.
• ✔️ There should be a "previous" button, some way for the player to page through previous dialog lines.
• ✔️ There should be some sort of bubbly typing sound as letters appear. Not the character's voice, as we'll eventually overlay vocal reactions later.
• ✔️ Dialog should be loaded from a file. We don't want this in code, we want this to be something a person can export or edit even if they're not a coder.

If this ends up being an epic, we can split it up.

When the player nudges a piece against a wall or fails a "piece smush" they currently have no feedback. Sound effects should play for these events:

• failed 'piece smush'
• failed rotate
• failed piece movement

When the customer gets very large, their body clips behind the table and looks strange. The table should be pushed out or swatted away.

It might also be nice if the stool broke.

It would be nice if the customer bodies weren't always monochromatic. Maybe some of them could have belly colors, stripes, or spots. For starters, let's just consider something like brown customers with green bellies.

• The customer's antlers should animate slightly, they should wiggle them up and down.
• The blinking animation should be slightly randomized, and not on a strict 7 second cycle. It should vary between about 6-10 seconds.

The player, and the characters they talk to, should have a few samples based on the dialog they're saying. "What?" "Augh!!" "Ha ha!" things like that. They shouldn't be attached to every dialog prompt; maybe like 30% of them. Attaching them should be a manual process, with a tag like {voice:00} or something like that.

As the player walks around the world, the shaders should seamlessly transition between one another over time. So it should go from being morning, to half-morning-half-afternoon for example.

There are about 15 different types of boxes the player can make. Upon forming a box, the box should have one food item embedded in it per row. For now, these gobs of food can be some sort of a generic chip or something. Eventually we'll have different types of food depending on the type of box you make.

Boxes should have food items embedded in them. one food item per row, never vertically adjacent:

3x3: 123, 132, 213, 231, 312, 321
3x4: 1231, 1321, 2132, 2312, 3123, 3213
3x5: 12312, 13213, 21321, 23123, 31231, 32132
4x3: 124, 134, 142, 143, 214, 241, 314, 341, 412, 413, 421, 431
5x3: 135, 153, 234, 243, 315, 324, 342, 351, 423, 432 , 513, 531

For now, just supporting one type of controller is fine. The keyboard controls let you hard-drop with the left or right hand, so the joystick should support this as well.

For now, just 1-2 variations for eyes, mouths or antenna is OK. We can go crazy with this later, but we want the framework to be in place.

• Two different kinds of antennae

• Two different mouths

• Two different sets of eyes

The placeholder Nullpomino sounds are appropriate for blocks, because they sound like pieces clicking around. TurboFat should use more muted 'whooshy' 'smooshy' sounds for its pieces which aren't as obtrusive.

Additionally, the game audio is much louder than anything else on my PC. The audio levels should be in line with other games.

When the customer is fed, there's a 1-pixel wide vertical line briefly visible. This is because the "hurled food" sprites don't have a border. They need to be reexported with a 1px border similar to the block sprites.

There's a few approaches to this, it could be a little square window next to the text with a facial expression, or some games have a static facial expression there but big pretty character graphics above the text.

For now, let's just have support for one face with about 12-14 expressions. This should be comingled with the dialog, perhaps with some kind of a keyword like {face:00}, {face:12}.

When playing the game, the area surrounding the playfield is currently grey, and the playfield is black. The following areas should be skinned appropriately:

• The playfield should have walls surrounding it.
• The area around the playfield should have some sort of tiled wallpaper, perhaps just a checkerboard, striped pattern or gradient like Dr Mario or Mr Driller
• The playfield should have a muted background behind it.
• The next pieces should have walls around them, and they should appear in their own little tunnel.

The newest release should be exported in HTML5. Ideally, this would be a zip file with an index.html which is the file format sites such as itch.io expect.

Dialog should be able to fork and reroute. For example, a typical conversation might look something like this:

0 {smiling}We've been together so long
1 You know the rules and so do I...
2 -> 10, 20, 30

10 Never gonna give you up
11 -> 50

20 Never gonna let you down
21 -> 50

30 Never gonna run around and desert you
31 -> 50

50 Never gonna make you cry
51 Never gonna say goodbye
52 Never gonna tell a lie and hurt you
53 -> done

After the player sees "You know the rules and so do I", they should have 3 dialog prompts. The rest of the dialog should continue uninteractively.

We should also be able to hook all these into a little directed graph, and diagnose if some of them are unused or don't terminate. That should result in a red flag or something.

The newest release should also be exported for iOS.

The newest release should also be exported for Linux.

When the player forms a box, the piece shouldn't just "blink" into a box, it should have a brief animation:

• Frosting should splash in from the top of the screen
• Some frosting particles should splatter around
• The pieces should transform into a box shale, but be completely white and illuminated (perhaps with some sort of lighting/halo effect)
• The illumination should gradually fade away

This animation needs to run at a different speed depending on the current level's speed. On beginner, they should see all of the nuances of the animation. On expert, it'll blink past most of the effects but they'll still happen.

There should be a new 3D scene with a static 2D sprite representing the player. The player should be able to move this sprite around a 3D plane with the keys, this should correspond to the "UI_UP" "UI_DOWN" "UI_LEFT" and "UI_RIGHT" actions. The look-and-feel should be similar to the Disgaea games or Enter The Gungeon, so a fixed non-perspectivey camera angle.

It's hard to separate this from #30, but this should definitely involve:

• a blobby shadows which moves below the player character
• a thick outlined cartoony style which matches the puzzle mode

The current game's sound effects use some sound effects taken from old video games. These should be replaced with properly licensed sound effects, possibly with packs like these:

https://sonniss.com/sound-effects/cooking-game/

https://sonniss.com/sound-effects/cartoon-voices/

These should be used for decoration, and maybe occasionally as obstacles.

The world should look differently in the morning, afternoon, or dusk. (Nighttime is harder so that's s separate story.)

This could be implemented with something like a gradient map shader.

We can go crazy with this later, but we want the framework to be in place for a few different colors.

I have an older Ubuntu laptop but the game doesn't run very well on it. It pauses and stutters frequently. It'll freeze up for 2 seconds, and then rapidly catch up and replay all your inputs.

This game shouldn't have any significant hardware requirements, it should be able to run on older PCs and PCs without gaming-related graphics cards. We should figure out the performance bottlenecks and provide a "Low Detail" mode if necessary.

These could be drawn as sprites, either just propped up flat or possibly plastered over a 3D wall. Look to Gungeon or Pokemon for inspiration.

Each day should last a fixed amount of time which is visible on a clock-type graphic. When that time is up, it should be night-time and the player can't do anything meaningful until they rest. (For now, resting can just be a button they hit or an object they interact with)

The clock-type graphic shouldn't be an actual clock, but a more abstract representation of time. Maybe a slider or a semicircle. It can go from showing a sun to showing a moon, or something like that.

When it becomes midnight, there's still a little space left in the clock. But the meter never reaches the end, it just gets closer and closer like an asymptote. Maybe the moon gets angrier and angrier the later you stay out.

This is the first step in creating our world, so we'll also want to think about the time or environment the story is set in. It could be set in the past with arbitrary pieces of modern technology like cell phones and the like.

Eventually the player will be able to walk around a map and talk to other monsters, but for now let's just have them sitting there, blinking and taking up space.

The player shouldn't be able to pass through other characters, they should have hit boxes.

At night things should be very dark, except for areas illuminated by fire or moonlight or stars, things like that. This would be a good time to explore Godot's capabilities with light.

Customers should scale based on the number of points in your combo. Logically they should scale based on the cube root of the combo, since that's how volume works. But if that's not exaggerated enough, we can throw realism to the wind and just make them scale however we want.

A +100 point combo is pretty typical, so they should probably just look fed.

A +500 point combo is a good accomplishment, so they should look big.

A +1,500 point combo is a tremendous accomplishment, so they should look ridiculously gargantuan.

Customers should be animated; they should blink and animate. Maybe they wiggle their arms a little or look bored. They should be sitting at a table and maybe reading a menu.

When you clear lines, gobs of food should be hurled into their mouth.

When you stop clearing lines, the customer should pay and the screen should pan to a new customer.

The restaurant should have seats for 3 customers. When the combo ends, it'll pan to one of the other customers in the restaurant.

Piece kicks should be unit tested. This is especially true for the pentomino kicks, but we should also test some of the edge-cases for quadrominos, such as T-spin triples.

The V-piece needs to be able to curve around O-pieces which are above, below, or to the side of it. It also needs to be able to kick against the floor.

The P-piece and Q-pieces need to be able to rotate their "nub" into little 1x1 cell holes. They can each combine with a V and U piece to make a 5x3 box, so it's important they're able to rotate into those gaps as well.

The U-piece should rotate similarly to L and J pieces, but needs to not get stuck when it's face-down on top of a "spire". (This was a problem in earlier versions.)

When the player character moves around the main map, their character should animate. They should be able run in 6 directions or so; maybe north-east, east, south-east, north-west, west, south-west.

Let's base the look and feel on the Disgaea/Gungeon series -- it's OK if the animations are a little choppy or imperfect, their feet don't have to exactly line up with the floor. The player will get the idea.