One of my favorite follows!

I believe Orion Reed stops by from time to time if you have any questions.

Indeed! I really need to spend a lot more time here, the limited history of Slack gives me mild anxiety for some reason though.

Happy to answer any questions!

I'm curious if you've figured out something hard-hittingly useful to do with this sense of depth. I feel like showing proximity and history are squarely neat but sort of solutions in search of problems.

To be clear — I'm 1000% in favour of trying stuff for the sake of it. I'm just wondering what findings you've found thus far.

(This stuff is surely also super early / under-explored, so I'm not expecting any grand revelations beyond what you shared in the tweet/masto threads)

Definitely under explored, came up with the idea yesterday…

Two things that stand out so far are making larger topologies legible, when you have edges/connections to things further away, you can really “see” that distance with the edge visualisation.

The second is similar, where you gain a sense of context beyond the viewport, like “oh there’s a cluster of shapes to my left…

I have a bunch of ideas I wanna try, I think there’s some potentially quite useful stuff among the neat-ness

The "best" (or maybe, "most") idea I've had for using depth in an otherwise 2d canvas is in the context of visual programming, as a way to represent different levels of abstraction. That is, things further behind the current plane are functions / subroutines / whatever that stuff on the current plane can call into. So in the context of node-wire, you can have wires between things on the same plane, or wires that go inward representing the invocation of some function defined elsewhere . You don't necessarily need to see those abstractions in full granularity, either. They can be fogged or blurred (like depth of field).

A "go to definition" would zoom you inward along the Z axis.

Anyway, something I've been meaning to explore. Not sure how well it'd work in practice. But it does feel like depth sits at an interesting place in the range of (gestalt-y) visual dimensions for representation (color, shape, spacing, etc), in that it's both a continuous dimension (like hue and spacing, unlike shape) but also more useful as a discrete difference (deep vs shallow) than something with fine gradations (different meanings for z = 1, z = 2, … z = 100, z = 101…)

The other notable thing about depth is that it’s made legible through motion, so it might naturally be suited to information which is relevant when navigating — I think your “level of abstraction” example is good, as you often care about that when looking at multiple things, wanting to compare them in some way

And when static, it can stay out of mind more easily than stuff in-plane

Was thinking about motion today and thought if this thread. Frames with changing opacity is a nice way to visualize the past and the future (bret victor style). This is psuedo-design but you can imagine some system that could enable/disable shadows of the future, past, or both. Using a high numbers of frames making smooth gradients and using lower numbers both seems interesting. Could also imagine color delineating past v future if both are enabled. Very interesting thread to pull.

In rereading this thread- i suppose it's less 'depth' oriented since subsequent shadows aren't scaling, but useful nonetheless with just the changing opacity in the 'trail'

Yeah this one slaps

There is frustratingly little detail about how it was built; I googled a bit, but couldn't find anything. It would be interesting to know how it was put together.

There's a little more detail in a response on their blog (tomorrowcorporation.com/posts/how-we-make-games-at-tomorrow-corp-our-custom-tools-tech-demo)

"The act of going forward and back is not itself recorded – just the evolution of the game’s state.

The snapshots happen according to 2 different schedules – a coarse grain schedule that records a new snapshot every so often based on time (we do every 2 minutes currently) and a fine grain limited set of snapshots that move around depending on where you are currently working on the timeline. That’s why the initial reverse debugger step causes a brief pause and then becomes fast – the first one seeks back to the most recent coarse grain snapshot, simulates forward creating fine grained snapshots that are exponentially spaced out backwards from your seek target, and then the subsequent steps will tend to have a snapshot that is right on the frame you need (or very close – unless you step back far enough to need to go create more snapshots but that is the rare case.)

The state capture is mostly just a memcpy of the game’s heap (snapshots only happen on frame boundaries so the stack is never needed.) It for sure could be too big to keep as many snapshots as we currently do – that will just be game dependent. Something to use to calibrate what you expect is possible though is to remember that games like Metroid Prime, LOZ The Wind Waker, RE4, Mario Sunshine, etc. all ran on a system that basically had 24MB of RAM to use for your game. And it wasn’t just game state filling up that 24MB, it was your code and other read only resources – the kind of stuff that we don’t have to include in our snapshots. So while it’s true that this system is not a general purpose solution for any and all kinds of games, it’s also true that you can make some pretty incredible games with not a ton of actual game state.

Yes in theory you could totally fork the timeline in the past and create a new session based off of the old one up to that point. That is a feature that I had in the reverse engineering debugger I made before this because it was good for creating what were basically tool assisted speed run videos for code coverage purposes. For our current system though it hasn’t been something that I thought we would actually use enough to justify spending the time to implement it.

The code gen is totally custom but keep in mind that this toolchain only needs to run on our development platform which is Windows. To ship the finished game we will transpile the code to C and then compile it with the native toolchains on whatever platforms we’re targeting."

I made a toy time travel debugger for python that used a similar technique. You could run a much simpler simulation when calculating state forward from the snapshot because it didn't need to do any conditional tests. You could just save the series of mutations and reapply them. On a modern CPU it's very fast because there's no branch prediction failures.

This is really amazing! Great share

if you want to continue down the rabbit hole

youtube.com/watch?v=TzOJtZYsGSA

She’s always great

never looked into any of her work before and i cant believe how much I've been missing. Discovered her from @Alex McLean naming her as an influence in an interview!

(I'm trying to do a write up of my music-generation project, arroost)

Don’t miss her music, too!

I listen to this whenever I’m really sad about computers

Laurie Spiegel is great! I really love this paper:

lauriespiegel.net/ls/writings/musical_manip.html

.. not loading for me at the moment, so:

web.archive.org/web/20220630172626/http://lauriespiegel.net/ls/writings/musical_manip.html

Here's a web-based re-implementation of her music mouse software for those who don't have pre-OS X mac handy:

teropa.info/musicmouse

and her chapter in the algorithmic music handbook:

zenodo.org/records/1195007

This film is great for wider context

sisterswithtransistors.com

In case you don't know it DIN might be an interesting reference for you too Lu Wilson, on a mouse-oriented music environment tip dinisnoise.org

Jag is in London at the moment I believe

I started it at that point but before that there's more about the Resonite VR worlds. Very very cool stuff

That this language designed for non-programmers is what programmers are forced to use when they want to use relations is the biggest single reason for the mess that software development is today.

If developers had access to a variety of Datalog databases (noting that Datalog was first described 3 years after SQL was), not only the heavyweight client-server things that SQL assumes, but if developers could freely use Datalog to represent more of their code in first order logic, then software today would be very different and much better.

Note that there is now a serious effort to build an open source Datalog database: http://cozodb.org.