Hacker News new | past | comments | ask | show | jobs | submit login
The Design is the Implementation (danshumway.com)
67 points by danShumway 8 months ago | hide | past | web | favorite | 21 comments



I'm working towards a similar system-oriented design but for a web app builder, and I'm starting to believe that this principle is actually one of the key missing features of the normal software development practice. It's closely related to the idea that the data representation of a UI should match the shape of the UI (a list should be represented by an array, a tree by a tree, and so on), but more philosophical and with more far-reaching effects.

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 tried to keep this article shorter, because it's doing double-duty as promotion for the game, but this could be such a longer, more generalized topic.

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.


Absolutely. I think it's a fundamental fact of human psychology that we are attuned to subconsciously figure out the underlying rules behind a system and then plan and act based those rules, meaning that a system that does in fact follow fundamental rules is both predictable and a pleasure to use - that's probably partly why systemic games are so enjoyable. With the corollary that systems without an underlying and consistent ruleset are harder to understand, provide less venue for the user to produce innovative use cases, and seem to come (at least for me) with an unconscious sense of unease with using them. It's like UX but at a more fundamental level.


> the idea that the data representation of a UI should match the shape of the UI

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


you do still need to differentiate between the data as presented to the renderer, and the data storage format. For example, you may have a hierarchical UI that wants hierarchical data, but there's no reason you can't serialize that data to a relational data store.


depends. if you need to expose your data trough api your api will likely follow the relational model. it's then more convenient for the interpretation to happen in the presentation layer.

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 had a similar intuition and remember also reading somewhere that eventually your underlying data structure will shine through into the user interface, and if it doesn't make sense the whole application feels off.

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?


I would say if you look into systemic games, you will find similar characteristics. I don't think it's so much that the data structure is tied with the interface that is the root cause of the emergent beauty, but the fact that the representation of the concept is accurate and true with minimal compromises. This is a very hard thing to do well. So from end to end it's more like the interface represents the data & logic which represents the design which represents the concept.

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.


On the game side of things, also check out Spelunky.

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


Did anyone else catch how time travel work from a player perspective in a multiplayer arena shooter?

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.


Whenever you die, your 'focus' shifts and you go back to the beginning of the level. Other players stay when they are.

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.


The post mentioned “waves” that propagate changes in time. I suspect the implementation of time travel is similar in how it works to Achron (https://store.steampowered.com/app/109700/Achron/). In Achron, there are constantly “waves” moving through the timeline that propagate changes that have been committed earlier in it, such that those changes become “real” when that wave hits the present. So units will be removed or made, etc. I don’t know if it’s the exact same implementation, but likely similar. (And also less complex on the code side, because apparently to make Achron took many years of math research, and the CEO of Achron’s company has a PhD in math)


It's the same basic idea, but the specifics of time travel in Achron are very different.

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.


Can you go into more detail about specific situations, like the gun shooting people in the future, or door opening in the past? The idea is very intriguing and I'm curious to learn more. I'm also wondering how to ensure that there's always a way to outplay your opponent, and not end up with degenerate strategies, like constantly killing your opponent at the start?

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?


I'm playing with a number of different game modes, but the big multiplayer place where I want to end up is escape-room puzzles.

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.


Is this playable yet? The website and this article don't actually have a 'play now' or 'buy it here' link, and it's not clear whether it exists or is still in development.


No, it's still in very active development. I'm planning to do a public demo of some single-player puzzles in September.

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.


Does your site by any chance have an RSS/Atom feed hidden somewhere that I missed? Would like to follow this.


I've been meaning to set one up, but haven't gotten around to it yet (I'm not using actual blogging software, everything is just a hacked together series of AsciiDoctor files[0]).

I just need to find a free weekend to add a step into the build process where I spit out the XML.

[0]: https://gitlab.com/danShumway/site


https://danshumway.com/rss.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.


Thank you, subscribed! Works fine.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: