A little more detail about the particular familiarities I have. These might be useful tips, but the actual familiarity is composed of a hundred tiny little neuron-data-points, so even if these sound useful, reading them is not the same as getting experience just building stuff out of them. Work with your material. These I give not as quick shortcuts to expertise, but to give an idea of the type of thing which accumulates to become mastery.
edit: note: These are also just things that work for me. It's not just mastery as in 'good game design,' but mastery as in 'you already made all the taste decisions ahead of time.' What works for me isn't necessarily what will work for you, or your work!
- For low-stakes effects such as minor slowdown effects, it's almost always good enough (and even has some interesting softness) to grab whatever tile is under the player's center point imprecisely, rather than worrying about detailed collision.
- Building a world out of non-colliding tiles and then changing those tiles to ones that have different effects feels very good. Destroying colliding tiles also feels great. Adding colliding tiles usually feels a bit weird, and has tech issues (you can get stuck inside them) that are solvable, but take more effort and time. So, I try to avoid that.
- Changing tiles looks jarring unless you have some kind of effect happening overhead. It does not have to be a really great effect, but something needs to be happening other than a tile snapping from one tile to another. Examples:
-- Player walking over a tile changes it. Just having the player sprite partially obscuring the tile can work if the change is subtle, like crushing grass. The note above, "grab whatever tile is under the player's center point," totally applies here.
-- Particle effect (explosion, splash, dust cloud) obscures the change. It does not have to completely obscure the change, don't sweat it.
- I could go on and on about physics. One example type of movement physics that I use often goes something like this:
- edit: Actually there is a better version I much prefer, since it gives me precise control over the resulting final velocity
-------
OK! Examples over. Hold onto these types of things. Re-use them when possible, and as you get more and more comfortable with these little repeatable patterns and how they fit together, work to define your output in a way that lets you re-use these patterns as much as possible, while still producing work that is variable in the ways that matter to you.
edit: note: These are also just things that work for me. It's not just mastery as in 'good game design,' but mastery as in 'you already made all the taste decisions ahead of time.' What works for me isn't necessarily what will work for you, or your work!
- For low-stakes effects such as minor slowdown effects, it's almost always good enough (and even has some interesting softness) to grab whatever tile is under the player's center point imprecisely, rather than worrying about detailed collision.
- Building a world out of non-colliding tiles and then changing those tiles to ones that have different effects feels very good. Destroying colliding tiles also feels great. Adding colliding tiles usually feels a bit weird, and has tech issues (you can get stuck inside them) that are solvable, but take more effort and time. So, I try to avoid that.
- Changing tiles looks jarring unless you have some kind of effect happening overhead. It does not have to be a really great effect, but something needs to be happening other than a tile snapping from one tile to another. Examples:
-- Player walking over a tile changes it. Just having the player sprite partially obscuring the tile can work if the change is subtle, like crushing grass. The note above, "grab whatever tile is under the player's center point," totally applies here.
-- Particle effect (explosion, splash, dust cloud) obscures the change. It does not have to completely obscure the change, don't sweat it.
- I could go on and on about physics. One example type of movement physics that I use often goes something like this:
Code Select
velocity = velocity * 0.95
velocity += dpad.normalized() * some_acceleration_value- edit: Actually there is a better version I much prefer, since it gives me precise control over the resulting final velocity
Code Select
velocity = velocity * 0.95
velocity += (desired_velocity - velocity).clamped(acceleration_value)'clamped' is a Godot function that takes a Vector2 and just clamps it if it's too high. Very useful.-------
OK! Examples over. Hold onto these types of things. Re-use them when possible, and as you get more and more comfortable with these little repeatable patterns and how they fit together, work to define your output in a way that lets you re-use these patterns as much as possible, while still producing work that is variable in the ways that matter to you.
