poobslag / turbofat Goto Github PK
View Code? Open in Web Editor NEWBlock-dropping puzzle game
License: MIT License
Block-dropping puzzle game
License: MIT License
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:
As customers grow in size, the camera should zoom out to keep more of them in frame.
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.
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.
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 newest release should also be exported for iOS.
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 restaurant should have seats for 3 customers. When the combo ends, it'll pan to one of the other customers in the restaurant.
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.
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.
The current solution for drawing a 2D isometric scene is a little hacky and will start being more cumbersome as the scene changes:
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.
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
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.
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}
.
The newest release should also be exported for Linux.
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 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.
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.
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.
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.
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.
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.
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.)
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
We can go crazy with this later, but we want the framework to be in place for a few different colors.
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:
If this ends up being an epic, we can split it up.
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:
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.
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.
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.
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.
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:
These should be used for decoration, and maybe occasionally as obstacles.
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.
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 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:
When the player forms a box, the piece shouldn't just "blink" into a box, it should have a brief animation:
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.