The thing that is enjoyable about a 'Horizon Break' is identical to the pleasure of resolving a problem in the above sense.

Quote from: Breaking the HorizonBreaking the Horizon is when a player's comprehension of a game is expanded so much that his or her previous understanding has been SHATTERED.

A horizon break is this process:

1. A person holds an existing idea of how the world works.

2. Something (we can call it a 'trick') is presented that conflicts with that existing idea.

A game might do this in order to propel this very important desirable outcome:

3. The person seeks (and finds?) a new explanation that does not have the conflict.

This is what Horizon Break is. I think it is possible to simplify and say that a horizon break is 'subversion!' or a 'surprise!' but I think, even inexpertly imagined and conveyed as it was nine years ago, that the heart of breaking the horizon comes from a strong belief in understanding reality. There is a domain which represents your total understanding of the game, your best fallible explanation -- with the information you are given, you nonetheless develop a model and forge ahead. Then, something comes which 'breaks' the horizon, i.e. which conflicts with your explanation. Defining the horizon ahead of time was a mistake. The horizon does not really have any meaning until it is broken. After this breakage occurs, this problem, you must still believe in understanding reality enough to try and develop a new theory despite the conflict.

There are many games which do not attempt to simulate or present a coherent sort of reality that is worth believing in in the first place, let alone through the beautiful horizon break process.

'Breaking The Horizon' is closely related to the concept of problems described in David Deutsch's 'The Beginning of Infinity':

Quote from: p.16-17 of The Beginning of Infinity[..]if we are simply curious about something, it means that we believe that our existing ideas do not adequately capture or explain it. So, we have some criterion that our best existing explanation fails to meet. The criterion and the existing explanation are conflicting ideas. I shall call a situation in which we experience conflicting ideas a problem.

[..]a conjuring trick is a trick only if it makes us think that something happened that cannot happen.

[Members of the audience] can detect that it is a trick only because of the explanatory theories that they brought with them into the auditorium. Solving a problem means creating an explanation that does not have the conflict.

Quote from: @GameDevDylanWI want to know that there's a simulation going on, the more complex the better, and I want to participate in that simulation as deeply as possible.
//
Generally spellcasting sims are what interest me the most, but city/village simulators can be pretty interesting too

tweet thread

spellcasting sims are like 'studying science in a fictional magic-themed world'. explaining reality... and then in the case of most games, using good explanations in order to triumph.

game goals/challenges aren't Deutsch's "problems", but may motivate them.

Quote from: p27You may not like these predictions[The ones that follow from your explanation of something]. Your friends and colleagues may ridicule them. You may try to modify the explanation so that it will not make them, without spoiling its agreement with observations and with other ideas for which you have no good alternatives. You will fail. That is what a good explanation will do for you:  it makes it harder for you to fool yourself.

Quote from: p18no amount of observing will correct [a] misconception until after one has thought of a better idea;

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?