Dome Project?

LilWendy Thu, Oct 22, 2009 at 9:29 AM

 

To: Emeraldcity

 

Is this the Dome Project?  This game?

 

This taken from an ebook about constructing an ARG

Let’s talk about project management. A couple of
things need to happen before a collaborative project is started
in earnest. A conceptual framework for the core story, the
main characters and the basic methodologies for story delivery
should be fleshed out before you begin deployment
• A simple set of tools should be evaluated and chosen
• A schedule should be drafted and all known elements
should be plotted, with milestones and
deliverables marked inside of this
schedule
• A core team should already be pre-qualified and selected
• Someone should be chosen to be the leader or leaders,
which I always refer to as ‘central command’
• It helps for projects larger in scope to have teams and
therefore team leaders that report to
‘central command’
These are general bullet points and you may add or subtract
to fit the particular idiosyncrasies of your own particular
group working. I will now take each one of those bulleted
items and expand on them a bit. A conceptual framework for
the core story, the main characters and the basic methodologies
for story delivery should already be fleshed out
This stage of planning is analogous to the draft state of a
283
novel*. It can be as simple as an outline, a set of index cards
or as complex as a Labyrinth storyboard [http://www.habitualindolence.
net/labyrinth/] or a Brain
[http://www.thebrain.com/]. This can be drawn up by one
person or several, and it can be taken from a pre-existing
body of work, as we recently did with El Centro or it can be
created from scratch. The important thing is that you have a
map, even a crude one, before you invite too many people to
join your party. The barebones framework includes:
• Starting point (how does this thing begin)
• Body (what are the points that the story is trying to get
across and how do we get there)
• Resolution (how does this thing end)
Next, a listing of main characters, their psychology profiles
and motivations should be listed. Then, once that is done I
always like to plot the characters within the storyline framework.
I also like to make rough outlines of places, secondary
characters, and any groups or organizations that may play a
key role in the story. Personally, I like using The Brain
[http://www.thebrain.com/] for this outlining because it
allows me to link people, places and things together in
arrangements of importance (casual to critical) and in a nonhierarchical
fashion, much the way real life works, in a social
sense. To address cross platform issues with other team
members I have only recently began to experiment with other
tools like StorySprawl [http://www.storysprawl.com/ or
Labyrinth [http://www.habitualindolence.net/labyrinth/] Wiki
[http://wiki.org/] has been immensely useful in the recent
past for collaborative story development and I can highly recommend
it as a simple and useful tool. Other tools are as
varied as your imagination, even including the trusty old private
web board scenario. A nice open source solution is the
ArsDigita Community System
[http://philip.greenspun.com/wtr/using-the-acs.html]. If
you’re really ambitious and have a budget you may want to
look into Groove [http://www.groove.net] or Vignette (formerly
StoryServer) [http://www.vignette.com/contentmanagement/
0,2097,1-1-1928-4149-1966-4150,00.html].
284
This is also as good a place as any to, at least arbitrarily,
come up with the mechanics of your ‘belief engine’. What
media are utilized and how, timing, manpower needed to
actualize it, etc. It’s best to leave this looser than your storyline
because the mechanics of your ground game need to be
fluid so you can easily adapt and adjust to the dynamic landscape
of ‘playtime’. Good planning also recognizes the cost of
over planning. Remember, you can’t know it all, nor can you
take into account all the circumstances that will arise once
you have actual humans interacting with the abstracted user
interface of your story/game. That brings me to an important
point; this level is for all intents and purposes, although
abstracted, the user interface to your story/game. Remember
that. Good sources of information on approaches to this part
of the process include, but are not limited to:
• Video game story line and movie script writing
resources- stay away from ‘how to get
your script greenlighted” types of guides.
Look to structural guides instead.
• Multimedia story development tools and guides
• Storyboard development resources
• Human Interface, design and theory [See the earlier
parts of this book and
http://www.immersivegaming.com/tools.htm for a list of
resources
*As in El Centro, ARGs can also be useful to float ideas for
new novels
in front of a diverse audience to observe their reaction to
story lines and elements. If you write and publish under various
‘Nome de Plumes’ like I do the anonymity factor of the
PM role also comes in handy.. A simple set of tools should be
evaluated and chosen It is always easier to decide on standards
before you get started. This will help you avoid a lot of
snags and pitfalls during the actual development and deployment
processes. When at all possible, choose tools that allow
for some flexibility should you wish to add more team members
along the way. Lean away from proprietary or skewed
solutions unless functionality absolutely dictates those propri-
285
etary solutions are the only available option. Cross platform
solutions and ease of use should always be kept in mind
when choosing tools for group use.
A schedule should be drafted and all known elements
should be plotted, with milestones and deliverables marked
inside of this schedule Ok, so this element will change as
things progress but it still doesn’t hurt to have a rough idea
of what it will take, time-wise, to pull off your idea. When trying
to fit things into a timeline you will often times put your
ideas into a concrete enough form to be able to recognize
‘feature creep’ or in some cases, feature absence. It’s really
simple. Ask yourself: “How long do I want to do this and can I
do everything I’ve planned on doing within that timeframe”.
You may find that your scope is too ambitious or that you
really don’t have the time and energy to execute all the ideas
that you threw into the early planning stages. You can then
adjust the timeframe or trim the ‘features’ to keep your project
within the boundaries of sanity and completion. Treat
your product as just that, a product. This will help with focus
and staying on point. A core team should already be prequalified
and selected. There are many ways to do this. One
way is to simply hang around places like Unfiction’s forums
[http://forums.unfiction.com/forums/] and quietly watch to
see who rises up as cream during the course of game play in
other ARGS. Or you can simply recruit a few identified PMs
when another game has concluded. In the case of El Centro,
we were looking for some crack PMs to have as resources during
the coming year so we actually set up an ARG-like interface
that was not really an ARG. Basically El Centro was a
multi-pronged interface to further several causes. One of
which was to set up a multi-leveled puzzle scenario that
would serve as a ‘survival of fittest’ course so that we could
find candidates that had the unique qualities that we desired
in a PM. You are also free to simply use your friends.
It will of course be impossible to have your entire team
built before hand, in fact you should leave enough flex room
so you can add candidates along the way as gameplay itself
will produce ‘superusers’. I wonder if that what happened to people who were getting too close…. getting bumped off of MJHD
.
Leaving yourself a little wiggle
room will allow unforeseen circumstances like PMs dropping
out, being voted out, or proving to be incapable, to occur
286
without creating a cascading failure effect in your project
once it is up and going. Someone should be chosen to be the
leader or leaders, which I always refer to as ‘central command’
You will always have people who will object to this principle
and I’m the first to admit that a decentralized approach
can work, but more often than not, it doesn’t. This will also
derail any power struggles that may arise later during the critical
period of gameplay. Get it out of the way early. This is
often simple because the original storyline is usually the product
of one or several minds. Pick one or several flag bearers
of the vision and allocate final approval or veto power to
these people. There’s nothing wrong with taking a democratic
approach such as voting or debate but remember that there
will always be times when a quick decision is needed and
when that time arises, someone must be mandated to make
those decisions. I am reminded of a feature film I crewed on.
Feature film production is somewhat similar in nature to an
ARG project, actually. The director was asked if this wasn’t in
fact a democracy, with all of the crew, from the grips to the
production designer, to the actors to the director having
some say in how things get done. He replied: “Sure, I’m open
to suggestions. I guess this is a democracy up until the point
that I have to say no to something.” Yes, I laughed too. Later
when I went on to direct some music video projects on my
own, I really understood what he was saying. A film project or
an ARG is more like running an aircraft carrier than it is like
living on a commune.
It helps for projects larger in scope to have teams and
therefore team leaders that report to ‘central command’
Depending on the size and scope of your project, a hierarchical
structure may be appropriate. Keep in mind that groups
will naturally fall into pyramidical structures, with some taking
lead, others taking more of a follow posture. Those that float
to the top of these natural settlings may be useful as mid-tier
leaders and can even be useful as agents to recruit later during
play. The command structure does not have to be rigid or
cut off. It often helps to have an ‘ear to the ground’ so to
speak, so keep mid-tier recruitment in mind as an option. If
you ever played any of the Steve Jackson games or Flying
287
Buffalo games, you already understand this
principle.
In summation, I cannot stress enough that planning a
framework for true and open collaboration may seem like a
contradiction in terms, but it clearly is not. Some preliminary
planning and construction of a workflow environment is integral
to having a productive collaborative experience. Don’t be
afraid to plan but also keep in mind that as you progress and
learn you will need to adjust and adapt. Building a framework
allows for both while also providing a working space from
which to launch a killer user experience. When faced with a
challenge or dilemma, just remember: “Something’s staring
you straight in the face”
This MUST be why the Jackson’s got together…. to discuss the final roles, and plans before MJ left.

Advertisements

~ by lilwendy on November 4, 2009.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: