The Design is the Implementation
danshumway.com
danshumway.com
The closer I get to following this principle in my designs, the more practical and reusable the implementations become, alongside the major benefit that it's easy to reason intuitively about the behaviours that will arise from their interactions.
When you build software you can go down two routes - you can find the "correct" implementation that matches your design's intent, and not have to deal with many (if any) edge cases and escape hatches. Or, more commonly, you can find a close-but-not-quite-right implementation and spend way too much time coding explicit edge case handling that ends up acting like a translation layer between the theoretical best implementation and your chosen implementation anyway.
I agree with your post SO much. It is usually easier to have a system with a couple of simple rules that are extremely robust and that can be composed and reused than it is to have a system with a separate toggle or setting for every scenario.
In general, I'm finding that I prefer very small systems that favor consistency over bigger systems that are supposedly more 'intuitive' because they have a bunch of extra layers on top of their internals. It's kind of amazing how much simpler and easier it is to teach things like testing, browser automation, build tools, and so when you strip out all of the stuff that gets shoved on top of them and just start working at the implementation level.
that's one weird assumption. I always worked with shape the data as the real world and shape the ux as the user workflows, with businness logic doing whatever transformation needed
that's the only way I see that works for long term project. if you try to semplify the real world model, you'll always come to regret it later
i.e. I'm modelling now leaflets. We're supporting many grid per spread om the datamodel, eac with their shape position and dimension, but the ux will only show one grid unless a client happens to need more than one
I guess need and solutions change dramatically between a project and a saas
or, splitting hair, yeah if the ui needs some hierarchy rendered out of a flat table then the javascript controller should transform it before passing to the renderer.
depends where you place the cut at this point.
I've first had this intuition when working with d3, where the visualization becomes trivial if your data is in the right shape.
Workflowy is another example of an app where there is a minimal disparity between data structure and interface.
Does anybody have other examples of apps or games that share this deep integration of structure and interaction?
For examples of games I've played that I consider fairly systemic and enjoyed on this level: the deus ex series, minecraft (a very strongly systemic game), factorio, watchdogs. Apps-wise I can only think of my own app right now but I'm sure they're out there. Actually, come to think of it, the product planning software I use (productboard.com) is pretty great in this regard but not to the extent that games are. Most software just isn't big enough to have enough features to be truly "systemic" in my eyes.
A lot of effort has gone into making interactions consistent and universal, so really interesting stuff can happen and it's not difficult to figure out why it happened.[0]
Spelunky was a big motivator for me to think more about building what I think of as these kind of "honest" systems, for lack of a better word.
[0]: https://www.pentadact.com/2012-07-13-shopstorm-a-spelunky-st...
Do you suddenly jump back 1 minute because somebody else pressed a button?
Neither the article nor the game website gives any kind of idea about how this game plays or why time travel is even a useful mechanic.
It's also a great deal simpler than Achron, partially because I am not a math PHD, and also partially because it's a game about players learning how to time travel. By the end of the game, you should understand the mechanics about as well as I do. It's also paradox free; not in the sense that I hand-wave paradoxes, but in the sense that it is just literally not possible to cause a paradox.
Getting rid of paradoxes simplifies time travel dramatically.
From a gameplay perspective, the short answer is that time travel in Reset Hard is less about thinking about cause and effect, and more about thinking about time as a traversable space, and you're hopping around that space to get access to certain events, or a better vantage point on another player.
There's only one timeline in Reset Hard, and it's constantly getting overwritten. It's also OK for different parts of the timeline to contradict each other, in the same way in the real world that it's OK for someone to break a hole through a wall or to erase part of a line.
Everything in Reset Hard is deterministic, but objects and information can be stored in meta-time and then projected back onto the timeline. This means you can do some kind of weird stuff - you can have a door that only opens in the past. You can have gun that shoots people in the future.
Whenever the player dies, they reset to the beginning of the level and begin pushing a new wave forward from the beginning. Their brain is stored in meta-time, so they can choose to do different things. Importantly, if they force another player into a situation where a they would need to make a decision (ie, by shooting them, by walking into a room, etc), that player's focus is pulled through time so that it can make that decision.
This means that you can pull a person back in time before they complete an objective, or by setting up a trap in the future and then resetting, push yourself forward in time to skip part of a level.
I guess when I think it through, it'd go like this: you seek your opponent out asap. You shoot him. He goes back in time and changes his path so that I don't find him. Or maybe he ambushes me, knowing where I'll be. And then I do the same. Wouldn't games end up being heavily weighted towards early actions? Or are there other mechanics that open up more options?
You're competing with another person to unlock a door and get out of the level. The moment you unlock that door and step through, you win, no matter when you are on the timeline. And different events and pieces of the level either become available at different points on the timeline, or are linked to meta-time so that they can persist between resets.
This means that killing someone is not always advantageous - you might prefer to leave someone in the future without a method to kill themselves so that you can accomplish an objective in the past without them bothering you. You also might want to avoid getting killed if you know you need to do something at 3 minutes into the level. Going back to the start means you now have to wait for that event.
The temptation when thinking about time travel is to focus on the cause and effect parts of it, but that's not really what Reset Hard is about - it's about learning to think of the timeline as if it's a physical space you can traverse to get different vantage points.
So one of the weapons I'm going to be playing with is the temporal sniper rifle. The first time you pull the trigger it marks when you shoot. The second time you pull the trigger it marks where you shoot. This means you can pull the trigger once, wait a minute for someone to exit a room, and then shoot them from the future into the past. The cause and effect is really weird for that, but it feels more natural when you start thinking of "when" as being just another form of "where." This means that getting ahead of other people on the timeline is a big advantage when you're using the gun.
Or in regards to reverse doors, which are doors that are open before you unlock them, but not after - getting to a late enough point in the level before you unlock them means you have more space in the past to use the door.
So a scenario might be, "you open a reverse door in the future, then travel back in time and use it to get into a separate section of the level. It closes behind you, separating you from another player and allowing you to complete an objective in peace. While you're doing that, the other player travels forward into the future and completes a different objective. They pick up a temporal sniper rifle and pull the trigger as you walk out of the door, then they shoot themselves, reset, and snipe you from the past, forcing you to reset and preventing you from completing the future objective they just finished. They go through the door in the past and lock you out, completing the past objective while you wait for the future objective to become available, then they shoot themselves to reset and walk out of the level, winning."
By prioritizing an early objective instead of a later objective, you put yourself in a situation where the second player could block you off from completing the entire level.
In regards to dominant strategies, yeah, there's a ton of risk for that, and that's why I'm being so public with development. I basically plan to play-test the heck out of everything so that it doesn't devolve into one or two "correct" ways to win. But the short answer is that there's stuff to do throughout the entire match, so if you spend all of your time at the beginning of a match you're not going to be able to accomplish much.
Your 'focus' can be pulled and pushed backwards based on other player actions - when a wave moving through time would force you to make a decision (ie, a player being in a different spot than you remember them), your focus will shift to that point in time so that you can make the decision.
This is important because it allows you to kind of grapple people towards you if they're about to complete an objective at a certain point on the timeline.
I hinted at this system near the end of the article when I was talking about how much of the world entities were aware of during updates, but this means that Reset Hard is closer to a tactical, Counter Strike kind of game than it is a twitch-based Overwatch kind of game. You won't be able to see where players are unless they're in the same room as you.
But, just as an example:
That means if you have two things you need to do at the end of a level and you don't want to waste real-world time going through the entire level twice, you could do one of them, and then run into me and trick me into shooting you. Then, you could unload my gun in the past before I pick up and push a wave with that gun unloaded forward on the timeline at 2x speed. When I tried to shoot you in the future, both you and I would jump to that time to respond to the new situation. Then, you could overpower me and you'd be right next to whatever second objective you wanted to complete.
That'll be all pre-alpha gameplay, but it's just designed to allow people to get a handle on how time travel works, because Reset Hard tackles it a little bit differently than other games.
I just need to find a free weekend to add a step into the build process where I spit out the XML.
W3C tells me this is a valid RSS feed, but I am generating it myself during site compilation, so let me know if something is formatted wrong.