pingback: Reality, Sleight of Hand, & Videogames.

I'm reading The Beginning of Infinity in a close reading thread, and am reminded of this thought i had about randomness.

If i program a "shuffled deck" object for the purpose of drawing cards off its top, one at a time, then it does not matter if I really shuffle the deck or simply pick a card from the remaining pool at random. That is, there may in truth be an order to the cards in the deck or not, but someone may draw either conclusion about the "reality" of such a system.

For a long time my conclusion was that you might as well perform the cheapest and laziest approach, if they're all the same in the end.

However, consider the new lens: if a subtle detail of a consistent world cannot be understood and discovered, the solution is to surface it, rather than to resign oneself to see it as vestigial.

Make those beautiful unnoticeable edges of the system visible, rather than erase or discredit their existence.

data-driven design is an instrument of the, in this example, prophet and gambler - not concerned with understanding reality but instead which inputs give which outputs...

Quote from: p14-15I may predict that if the conjurer appears to saw someone in half, that person will later appear on stage unharmed. [This is a] testable prediction[..] But that does not even address, let alone solve, the problem of how the trick works.

Quotewhat is the vital, process-enabling ingredient that is present in science [and not] the prophet and the gambler?

[..] prediction is not, and cannot be, the purpose of science.

Quote[We] resent its allure; we resent that knowing the term sans serif does not make you immune to sans serif's appeal. The desire for individuality rebels against its sameness, even as the sameness feels reassuring, feels good.

Infinity! This book puts forward the idea that knowledge is an infinite climb towards truth, if constructed and approached properly. FL recommended it when I brought up Lulie.

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:
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
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.

Quote from: ash kgod damn!!!!!
how do you manage to make high quality stuff so fast and so consistently?

[..] I gave a long-ish answer, which ash (correctly) paraphrased as:
so i guess the short answer is YEARS of practice?

I'm not really happy with this exchange because it seems like a very imprecise answer, and more importantly, not useful. Sure, years of practice, but everyone knows experience/practice makes you better. Surely that can be broken down further. Is there an answer I could give to how do you make stuff so fast and consistently that would help someone get on the right path of building up the experience to get there?

Breaking down the process of making this inky droqtober game (day 5!)...

1. Brainstorming ideas, eventually arriving at this idea: Bucket that you use to splash ink on the environment. Includes: TILE MODIFICATION ON HIT, and BUCKET IS AN AWKWARD PHYSICS OBJECT, and a little ONE-STICK SHOOTER. Also Splatoon inspo.

Past experience: I know how these subsystems work, how they feel, how to implement them.

- Modifying tiles in a tilemap is something I've done before.
- Awkward physics-ish objects, Rigid Bodies that like to stick to you but which you can push around and whose position you care about, has an interesting and particular feel.
- HMDL issue 0 was the end result of, like, months of experimenting with one-stick shooter controls, so that's also something I have familiarity with.

2. Implementation.

Past experience:

- Particles: The 'ink' particles use a lot of 'object particle' experience that I have. I was relying on this ahead of time; that is, I knew I could make ink particles that I would enjoy.
- Drawing tiles that I like (there are 5 unique ground tiles at various levels of inkage between 'fully clean' and 'fully black')
- In general, feeling comfortable with designing this kind of control scheme. Reading player inputs, animating things, etc.

Implementation had new things too! None of this is to say I didn't do anything new, but I wanted to sort of point out a bunch of specific things that I have experience with. New stuff:

- I didn't know exactly how I was going to do the inky droplets, and I'd never done anything like the 'squash' that happens at the end of their animation.
- I used a Path2D and PathFollow2D node pair to help me spawn the enemies around the edge. (I've sort of done something like this before in its separate components: I've done enemy spawning and I've played with Path2D/PathFollow2D nodes, but this was my first time connecting the two in a time-saving way. Very happy with how enemies spawn.)
- I have done sticky ground before, as well as 'entities that leave path behind them', but I came up with a novel solution for how to make the landscape change in a meaningful way. Your attacks ink the ground, and walking on ink makes you slow. Enemies also ink the ground as they move around. It is a bunch of familiar pieces (e.g. "TILEMAP MODIFICATION", as well as "READING NONCOLLIDING TILES AT THE PLAYER'S LOCATION") put together to create a particular dynamic that I'd never created in whole before.

^ That's all the VERY LONG ANSWER.

The very short answer that isn't "years of practice":

I'm familiar with a lot of mechanical implementations that dovetail well together, and/or that i am good at making work together. In general I feel like there are no absolutes and prefer a subjective perspective, but I think these are basically the same idea. Get familiar with building mechanics that you can re-use in novel contexts, and with mechanics that can work with each other.

As a counter-example, learning how to build a First-Person Character Controller and also how to build a 2D Platformer Controller do not really fit together in the same scene. You can build a game in which you do both of these things, but I don't really see them as mechanics that can 'combine' to create a larger mechanical thing.

Then, of course, to make games quickly/consistently, you need to actually put this 'mechanical library' into action. It's important to become familiar with a mechanical domain that you're actually interested in working with, and this is where learning how to build a First-Person Character Controller and also a 2D Platformer Controller comes in handy: if you don't know exactly what you want to do, this type of breadth will help you explore until you figure it out.

Notes (mostly unused):

"COLOUR."
unseen systems
the joy of finger painting
colour is seen; what does it mean for the systems to be unseen?
a system seen through a colour tint
(i.e. mostly you cannot see it)
but still: what is the system?
systems are better when seen. they need SKIN.

good health and spirits; ruddy complexion.

that which covers or hides the real character of anything; semblance; excuse; disguise; appearance.

to show your true colours.

applying paint to objects in the world; enemies attack things based on colour; including each other; including you (maybe you're always the bad colour)
HMM get away, get away from enemies
but how does hiding the real character of anything benefit you if you're not hiding it *from* something or someone...?

a colour: a reason: an influence, a flavour
a skin-centric system cannot be unseen. interesting. maybe it's not seen at first, but revealed later?

fucking love Webster's 1913. https://www.websters1913.com/words/Color

Day 5: COLOUR

I want to do some kind of interesting UNSEEN system that you have to learn, since I shied away from that yesterday...
Maybe potions/ingredients?
I don't want to make something that relies heavily on telling colours apart.

Day 4. Rock Blaster! Happy with how I imagine this game can be approached by a beginner without feel-bads. I regret the death hole though.

Tweet

for posterity, the note on my computer:

form
sculpture?
stone
rock formation.
army formation.
pushing units into formations?

and tho i had the idea of being a 'sculpture-carving wizard' my first idea that i really made any sprites for and gave serious thought to was 'a game where you push an army into shape to see it fight against another army'. but i realized that was more of a system to design and wasn't sure iw as up for the task.

What's polish? It's what's not needed.. Make sure you communicate everything you need to communicate (main content); then add stuff after that which stands on its own! Prose and descriptions and lore, for example, can be added and nothing relies on them, so this frees them up -- frees the polish up -- to be good for its own sake.

Prose - I like it in novels because it's the main content

Fluff, polish, whatever - Not the main content, but making the main content better? Supporting it?