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?

Gametober (Droqtober) is keeping me occupied every day. I'm working on a new little game, conceiving of one and then putting in the work to make it real. And... as much as these games are really tiny things, and feel mostly devoid of artistic value, I've found the practice of doing it every day to be extremely valuable. Who knew, right?

It's not that I know this will lead me to making a new Great Game or anything. This isn't even a 'game quality practice' thing, though I suspect game quality will increase; it's in Focus and ADHD after all.

I'm absolutely certain that I could spend my life making a game every day. This is why I'm in pursuit of this career, and it's nice to remember that! Given time, I'd like to figure out how to fit this sustainable habit (of making a new thing every day) into a process that produces more reliably good works.

Hypothesis:

The process will likely involve discarding projects. The rate of 'good output' will never reach 100%.

Do I need to be concerned with sharing 'too much' output? What do I want to share? Do I have a brand? Hu-brand-ity

Is it selfish to see our performance as central?

QuoteThe ball and the clubs and the rules of the game[..] the fairways and roughs and greens[..] The golfer's own strength, experience, adeptness, and tactical wherewithal[..] other material conditions that might intersect with the game: the weather, such as the effects of heat on the golfer's stamina or the effects of a prior rain on the ball's ability to rebound from a bounce on the fairway; the time of day and week, and its impact on the crowds on the greens;[..] familiarity[..] novelty[..] the languor or pressure of a particular foursome[..]

^ Many factors which might be brought from ground to figure by the game of golf; that is, things that we may have experienced in tier usual contexts enough for us to stop caring to notice them, which golf might draw a novel attention to.

QuoteA supposedly inferior experience, like the novice golfer at [a difficult course like] Pebble Beach, is only terrible if we are so selfish as to see our performance as central to the encounter with a sublime place like Pebble Beach.

Any or all of these things other than our performance, and of course even more than what is listed, might be central.