Quote from: Ezra[re:] using platformer controller as a test case for building a video game sequence. @droqen what would your first stab at that look like, if you had to specify a sequence that would result in a platformer controller in, say, 7 steps
I've made a lot of platformer controls!
Too many, even!
I love to do it. So I'm going to think about this process. When I do think about it, I picture making something in Godot, and I definitely imagine... requirements, first. But the goal here is a sequence, not a list of requirements. The useful/interesting thing here is that when I am making a platformer controller, I absolutely use some sequence; I do things in order. When I am thinking about the theory of making a platformer controller, I imagine I must think top-down, in terms of a 'whole picture' of what is the platformer controller in theory.
Clearly the one that I actually use is more practical!
... I'm going to record myself for my own purposes.
Note that the first step in recording a sequence is actually doing the process. I have to do the process in order to see in what sequence I do the actions and make the choices.
1. I nearly always start by drawing a character sprite, and a walk animation.
Sense of motion --> Introducing motion to the character sprite
Wall --> Something for the character to collide with (visual)
**** You can introduce the wall later if you want... It's not important yet, maybe add the wall when we want to add collision?
Place the platformer in a world (generated however)
Left/right movement is what is obviously needed next, I press Left/Right and the player does not move
* This is the point at which input becomes relevant
Add smoothness:
At this point I could specify certain parameters, like, acceleration/s should be a lot (4x) higher than velocity/s? This is just intuitive, though, you could figure it out by playing with it yourself. And it's no hard rule.
Flip the player sprite when pressing inputs, that's the next one
Once I have this in I really want to add jumping (and gravity), which involves
1. activating physics?
2. well, letting the player fall
3. when the player is not falling, pressing a button to make them jump
lost in this soup is "bumping into walls"
RETROACTIVELY TESTED: How does it feel to not have a flipping character sprite? I'll say: Much worse, definitely. Directionality is great. Put this in the sprite drawing phase
DECISION POINT: Decide how high you want the jump to be, how fast... I think the parameters here vary wildly
But the key is that the high level decisions are mainly about these things
- How high is the jump
- How floaty is the jump
Maybe you can change the x-accel, but I'm not sure that even deserves its own step
... I'm not sure whether you should design the level before or after determining height, floatyness... You probably should scribble out a rough level feeling I think? What if I do it backwards? ... No, in that case I still imagine the level, so it's still a mental structure that comes into place first
IDK if I even needed this recording, but it took me 25 minutes to get it to a place with a basic character controller (gif (https://s12.gifyu.com/images/SWee2.gif))
1. Make a character sprite with a feeling of directionality (they are facing in a specific direction, left or right) and life (short animation), place the sprite on-screen with a single looping animation (i like to use 2 frames for now, literally just enough that they look like a living thing and not a static sprite)
2. use left/right arrow keys to move them around. They should not move too rigidly: add acceleration and friction. (Details of how to do that are techniques left to the maker) note: This should flip their sprite too!
3. imagine a space for them to traverse, imagine how they would traverse it [Re; Imagine the character (https://mutmedia.itch.io/re-imagine-the-character)] -- specifically jumping over and onto things
* how high can they jump?
* how floaty is their jump?
4. Add a jump button which gives them an impulse of high upward velocity. When they are not on a floor give them a steady amount of downward velocity (tweak to fit what you imagined)
5. Horizontal collisions? Is this a separate step? I get it for free in Godot, so I don't know when I need it
6. Add animation behaviours for standing still, jumping, being in the air, falling
Reflecting on this sequence, I'm imagining that the most interesting part of using it will be to push at its boundaries: not to break them, but to squeeze into the little corners of possibility space that still work, to see what can be done that I might have otherwise assumed (without having these rules plainly spelled out) would not work.
E.g. I would have assumed it's important that the character sprite "looks like a person" or at least a living thing, but I think it really is the directionality and sense of animation that matters. You could make your character a garbage can, an abstract fuzzy blob of pixels, a whole word, anything, as long as it meets certain criteria.
That's exciting. What can be done with all of the other patterns?
(Thought about this when thinking about proc gen: What can a person do differently from proc gen? Bend the rules.)
no, hold on, it's way deeper and more fundamental than that; a proc gen algorithm follows the rules, while a human is already capable of (infinitely?) many things and the rules are mere constraints; an algorithm is rules, a human is constrained by rules. these are insanely different
also, that's not to say that rules are purely constraints... i don't quite know how to describe it. for a person, a procedure or process is a starting point. for a computer, a procedure or process is the whole thing.
--------------------------
Trying this out seems really chill... I'm going to try this sequence today
Tried in pico-8 and ran into some issues with collision
I think I more clearly need to lay out a pattern that refers to collision, because of how key it is
In theory, a sequence's patterns could indicate what you're going to need to be able to do, and what skills you'll potentially need to develop to be able to execute the sequence -- that way if you get stuck on something, it's not as much of a surprise! You can be prepared ahead of time.
revised ver.
1. DRAW A SPRITE WITH DIRECTIONALITY AND ANIMATION. This can be anything, but the sprite should appear to be 'facing' or 'pointing' either to the left or to the right. The animation does not have to look like the sprite is doing anything in particular, just that it should feel somewhat 'animated' or 'alive', rather than static. (For this step, I like a 2-frame looping animation and I slightly prefer an animation that appears to contain around, say, 75% vertical movement, and 25% other movement - boiling or internal wiggling or scaling or whatnot)
2. ALLOW THE PLAYER TO MOVE THE SPRITE. For whatever input scheme, allow the player to move the sprite in every direction. It may feel better if the movement is more "smooth"; use feelings of 'acceleration' and 'friction'.
3. DRAW A SMALL LEVEL AROUND THE SPRITE. Draw a floor / platforms to stand on, and walls to block you.
4. ADD COLLISIONS. Make it so that the player cannot move through the floor or walls of the "level".
5. ADD GRAVITY AND ALLOW THE PLAYER TO JUMP. While they are in the air, apply a vertical force to a player that causes them to inevitably move "down" to the ground. While they are on the ground, give the player an input that allows them to "jump" up a certain distance, before being brought back to the ground again. (Questions to ask yourself: How high does the player jump? How fast does the player come back to the ground? Tweak the gravity and the jump until you have something you like.)
6. ADD ANIMATIONS FOR VARIOUS PLAYER STATES. Notice now how when the player is "standing still on the ground" they should look different from when they are "running on the ground" or "in the air", or how when the player is "moving left" they should look different from when they are "moving right".
Re-using existing sprites as much as possible, render / animate the player differently in each state that feels like it needs a distinct animation. (For this step I will usually start by flipping the player sprite horizontally to face the appropriate direction when the player uses left/right input, and stopping the player's animation when they are standing still on the ground.)
Note: Should 'animation' be something that happens in-line with each pattern? Does it come first? Last? It seems like something that happens in parallel, at the same time ideally, but in practice happens at various times during the process. Difficult.
Cleaning up - Not doing this
post-mortem: I think I'm just not too interested in pursuing this or polishing it further? This already lives in my head; who needs it on paper? Someone? i dunno. If I discover some real practical interest I am intrigued by the possibility of revisiting game design sequences: maybe for myself? That oculd be interesting.
TODO: In the future,, projects should have more clearly stated purpose. Note, however, that the purpose-statement must be understood as a keyhole to a Jupiter, not the jupiter itself.