Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Post-comp thoughts on "Rover's Day Out"

13 views
Skip to first unread message

Ben Collins-Sussman

unread,
Nov 17, 2009, 11:24:10 AM11/17/09
to
Following in the footsteps of the Interface discussion, here are my
own thoughts on Rover's Day Out. Perhaps "lessons learned" is a best
way to frame the whole experience.


1. The methodology of "write the transcript first" really works.

Emily mentioned this technique on her blog, and I'm here to testify.
As a programmer, I'm always tempted to start fiddling in I7 in
technical ways, wondering if I can implement some clever algorithm --
and then later trying to figure out a way to justify its use. This is
not the way to write a good game. Instead, come up with a GOOD STORY
first (or partner yourself with a great writer like Jack), and write
out the entire hypothetical transcript first. Think of it like a
screenplay: first conceive the whole experience from the user's point
of view, and decide if it's a good script. If it is, *then* worry
about the implementation. (For the curious, the original transcript
Jack wrote -- before a single line of code existed -- is at
http://rovers-day-out.googlecode.com/hg/rover_transcript.html).


2. Keep the player captivated at all times!

We goofed by requiring too much repetition of mundane routine for the
first half of the game. IF geeks and programmers generally had the
patience to muddle through (or noticed the status bar changing, and
were intrigued about the double-meaning of things). But at least half
of the players out there -- including some beta-testers -- rightfully
had no patience for such a thing. "Just let me do something
INTERESTING already!" Many people simply weren't able to delay
gratification (or keep faith) as long as we'd hoped. Especially when
you have 20 other games standing by, ready to test. Given the blog
reviews, we were convinced we were headed right for the Banana of
Discord. Emily's review and Jim Aikin's reaction were the canonical
example of this. We've learned our lesson here.


3. Avoid linearity.

This was my fear all along, when I first read Jack's
transcript... particularly in the second half of the game. I liked
the story enough to overlook it, but reviewers correctly called us
out. Killing invading bots may be fun, but this still ain't no
Photopia. In the future, we need to really construct some non-linear
mid-game plot flow.


4. Write a hint system.

This seems to be the most requested feature, and I was surprised. I
grew up playing Infocom games, when games were supposed to take weeks
to solve and 'walkthroughs' were expensive InvisiClues you had to mail
away for. Ordering the walkthrough was a badge of shame, an
admission of defeat. These days, the culture seems to have changed
quite a bit. People not only expect every game to have a walkthrough,
but they check it after being stuck for 10 minutes (!) Maybe that's
just the environment of the Comp (when people are in a rush to "get
through" quickly and judge), but clearly an in-game hints would make
the game much more accessible to a wider audience. Perhaps fewer
people would have run screaming from the repetition. :-)

Roger

unread,
Nov 17, 2009, 1:32:01 PM11/17/09
to
On Nov 17, 11:24 am, Ben Collins-Sussman <suss...@gmail.com> wrote:
> Following in the footsteps of the Interface discussion, here are my
> own thoughts on Rover's Day Out.   Perhaps "lessons learned" is a best
> way to frame the whole experience.
>
> 1. The methodology of "write the transcript first" really works.
>
> Emily mentioned this technique on her blog, and I'm here to testify.
> As a programmer, I'm always tempted to start fiddling in I7 in
> technical ways, wondering if I can implement some clever algorithm --
> and then later trying to figure out a way to justify its use.  This is
> not the way to write a good game.  Instead, come up with a GOOD STORY
> first (or partner yourself with a great writer like Jack), and write
> out the entire hypothetical transcript first.  Think of it like a
> screenplay: first conceive the whole experience from the user's point
> of view, and decide if it's a good script.  If it is, *then* worry
> about the implementation.  (For the curious, the original transcript
> Jack wrote -- before a single line of code existed -- is athttp://rovers-day-out.googlecode.com/hg/rover_transcript.html).

Unfortunately I haven't had time to play Rover yet except for a few
minutes (though I will, perhaps on the bus ride home tonight) but I
tend to agree with your sentiments surrounding point four. Personally,
I prefer if hints are seamlessly integrated into a game without them
actually seeming like hints, without veterans feeling like they are
being gypped (I hate that word but I can't think of a better one at
present) out of a challenge, or newbies feling like they are swimming
forever out of their depth. Something like Violet is, to me, ideal, in
the way it nudges you along. Of course these nudges are contextually
sensible given the narrative.

Not everything needs to be hinted at, in my opinion. If a player just
cannot think of a certain verb or noun that any person would be
reasonably expected to eventually come to, then that's what a
walkthrough is for. Hints can only go so far.

Obviously the ability to integrate hints and nudges that way depends
on two things - the type of game being designed and the skill of the
programmer. The second can be overcome with research but as to the
former, I admit that not every game is conducive to the Violet style
of nudging the player along.

Suspension of disbelief is a great thing. Taking the player away from
that, even with an optional appendage, just reminds the player that it
is a game, so I have mixed views on integrated hint systems. Then
again, giving the player difficulty options is not necessarily a bad
thing. I'd personally like to see a puzzle-heavy IF game (someday)
that employs something like Monkey Island 2 or Tex Murphy: Under A
Killing Moon and The Pandora Directive. You have two different
difficulty levels and the harder one just has more puzzles with more
obscure or more difficult solutions. A few of the Silent Hill games
also had something of this nature but I think the Silent Hill games
didn't use it in such a great way. That would be interesting, though
it would be a lot of extra work.

Personally, and maybe this is just a selfish preference and nothing
more: I would prefer if only some games, but not every game, had an in-
game hint interface. I don't know why, but I think it can potentially
cheapen a game if not handled in a certain way.

0 new messages