
The Design is the Implementation - danShumway
https://danshumway.com/blog/design-is-implementation/
======
beaconstudios
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.

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

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

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

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

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

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

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

~~~
danShumway
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://gitlab.com/danShumway/site)

~~~
danShumway
[https://danshumway.com/rss.xml](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.

~~~
detaro
Thank you, subscribed! Works fine.

