Excel as a Game Design tool

S

steve.breslin

I have heard that "Excel is to game designers what Microsoft Visual
Studio is to programmers" -- and as a relative newbie, I'd like to
learn howso.

One common thing in game design is branching and recombining plots (or
story elements). I can break up the plot into least-units, and put
each unit in a cell. But beyond that, how can Excel help with this? My
problem is that sure, I know what I know, but I can't imagine what I
don't know.

So for example, I know I can color the "key plot element" cells, then
sort them by color so I can see all the "key plot element" cells
together. But I don't know how to use Excel as a plot-analysis tool.
"How will a given design play?" and "where are the stubs in the
story?"

Should I somehow flag certain cells with a set of keywords, then write
a macro which automatically re-orders the cells in an instructive way?
Is this the sort of thing that "Excel is to game designers" means? I
think maybe I'm missing something simpler.

Another problem: inventory being a primary way of solving puzzles, the
idea apparently would be to use Excel to track the puzzle-solutions a
player may have available (pick-up-able) and ready (in inventory).

Can I associate plot points with game-objects which become available
at that point? Then, can I pick a plot point and get a list of all the
game-objects available at that point? (Corollary: can a plot point
remove an item from the list of available objects?)

I'm sort of wandering in the dark here. Not sure what questions to
ask. Of course I looked all over online, but discovered nothing
apparently interesting. If you have any general pointers on this
topic, I'd love to hear!
 
J

Joel

Excel is good as a tool to visualize what data is in an array. Instead of
storing data in arrays you can put the data into excel.

In a game you move from one location to another location and you have
objects that you collect as you move from location to location.



So you can set up a spread sheet where each row is a location. For example,
the columns can be one of the following

1) Ways of leaving a location
2) Next Location you can go to
3) Objects found in a Location
4) Object Required to perform a task
5) Tasks to perform in a location
 
S

steve.breslin

Joel said:
Excel is good as a tool to visualize what data is in an array. Instead of
storing data in arrays you can put the data into excel.

Understood! However, I feel like I'm still missing something. I was
under the impression that it would be useful to harness sorting and
perhaps functions, to evaluate a design and discover problems.

I don't think it's possible to use sorting with arrays. (I mean, where
we have a list of items in a single cell, sorting only really
considers the first item, right?) Would the idea then be to write a
macro which analyzes somehow the elements of arrays?

Again, my apologies for being so vague. My main problem here is that I
don't understand the idea, so I'm basically just wandering in the
dark.
 
J

Joel

With excel you don't have to werite sorts or Finds. the worksheet already
have these features. so if you can put your database into a spreadsheet you
can use these features. You can also use worksheet functions to count the
number of times an item or event occurs.

If you think harder enough you can find good reasons to use Excel. You just
seem to be fighting the idea rather than going along with the flow. Start
Simple. Find one reson to use Excel, then more ideas will come.
 
A

ai864

I have heard that "Excel is to game designers what Microsoft Visual
Studio is to programmers" -- and as a relative newbie, I'd like to
learn howso.

One common thing in game design is branching and recombining plots (or
story elements). I can break up the plot into least-units, and put
each unit in a cell. But beyond that, how can Excel help with this? My
problem is that sure, I know what I know, but I can't imagine what I
don't know.

So for example, I know I can color the "key plot element" cells, then
sort them by color so I can see all the "key plot element" cells
together. But I don't know how to use Excel as a plot-analysis tool.
"How will a given design play?" and "where are the stubs in the
story?"

Should I somehow flag certain cells with a set of keywords, then write
a macro which automatically re-orders the cells in an instructive way?
Is this the sort of thing that "Excel is to game designers" means? I
think maybe I'm missing something simpler.

Another problem: inventory being a primary way of solving puzzles, the
idea apparently would be to use Excel to track the puzzle-solutions a
player may have available (pick-up-able) and ready (in inventory).

Can I associate plot points with game-objects which become available
at that point? Then, can I pick a plot point and get a list of all the
game-objects available at that point? (Corollary: can a plot point
remove an item from the list of available objects?)

I'm sort of wandering in the dark here. Not sure what questions to
ask. Of course I looked all over online, but discovered nothing
apparently interesting. If you have any general pointers on this
topic, I'd love to hear!

Broaden your view of game design; it's more than just story writing
and puzzle creation.

Consider an RPG like Final Fantasy. What are the elements that a game
designer must deal with here?
* Yes, there's a storyline. As you mention, this is probably better
done in plain text, or (in the case of a branching storyline) in a
flowchart tool like Visio or even Powerpoint. Excel is of limited use
in story writing. However...
* Excel is great at making lists. If you want to link your plot points
to other game elements (puzzles, dungeons, bosses, locations, items,
whatever), you can easily create a matrix in Excel that shows these
relationships.

But the combat system is where Excel really shines. Think of all the
areas where you need lists and formulas to balance the game:
* Formulas for combat damage based on player and monster stats. You
can create a combat damage calculator in a single cell, which takes
data from other cells whose values you set, in order to play around
with the numbers in the formula so you can get them to feel right. You
can also create combat simulators that assume multiple combat rounds
to figure out things like, how much total damage do you expect the
player party to take when in combat with a particular set of monsters?
Or even, how much damage do you take over an entire dungeon, assuming
a certain number of combats?
* Likewise, progression of player abilities as they gain level.
Calculating how many monsters you need to kill at each point in the
game in order to gain a level, and comparing that with how difficult
those monsters are to defeat in combat, and how much additional power
the player gets on level-up are all things you can do in Excel.
* Ditto with items. Each new weapon that you find (or buy) can go into
the simulation to figure out how fast you expect the player to go
through the game. How does it affect the pacing of a dungeon if you
remove the sword in this treasure chest halfway through? What if the
sword is still there, but you change its combat power? What if you
have the player encounter it earlier or later in the dungeon? There's
no substitute for actual playtesting, but a good Excel simulation can
give you a pretty good starting point.

Then there are the production-oriented uses of Excel:
* Create a list of all monsters in the game. And all locations. And
all items. And all characters. And so on, each on its own worksheet.
For each, give its stats and text description (as necessary).
Programmers can take this data directly (it might be easier if you
save as CSV) and dump it directly into the game; if your programmers
are REALLY good, they'll allow you to change your data in Excel and
reload the data at runtime so that you don't even have to exit the
game before trying out some new values.
* Add columns next to each item for number of polygons allowed in the
art, or total amount of game data required. Also add a column for the
level where each element is found. Now you have a total memory budget
for the game data in each level, which lets the programmers know how
much is left over for other things (like, say, music and voice). It
also tells you which level(s) are the most memory-intensive, letting
you solve problems ahead of time by adding stricter poly budgets for
enemies in larger levels.
* Add columns next to each item for various stages of completion (art
placeholder, art complete, implemented in game, etc.) with a sum/
percentage at the bottom. Next time your producer asks for a task
status, you can actually give a percentage complete right from the
Excel sheet.

During playtesting, you can put all kinds of metrics in Excel to do
some quick-and-dirty number crunching: average play session times,
number of player defeats, number of random encounters per hour, and so
on. This allows you to intelligently tweak some variables if they seem
off in reality (and maybe even improve your simulations, if you can
figure out where the discrepancy is).

Excel is also great for random-number simulations. Suppose you're
working on a card game. You can use RAND() to generate random values,
and using it together with RANK() and VLOOKUP() you can effectively
shuffle a deck and look at a random shuffle. Copy/paste to have your
screen FILLED with random shuffles, and (in Windows, at least) you can
press F9 to re-shuffle. This can give you a pretty good idea of things
like the optimal ratio of basic land to spells in a Magic deck.

Generally, Excel is great at helping you to balance a game. If you
could use Excel as a *player* to analyze a game and find the optimal
strategy, then you can use it as a game designer in exactly the same
way to find the exploits and fix them before your players find them.

And this is just one example. There are all kinds of others. In a
sports game, where you've got tons of stats on each player and each
team to begin with, dumping the whole thing into Excel to balance the
teams is an obvious design task. In an FPS, you can give the total
amount of ammo and weapons given to the player in a level and compare
it to how many enemies there are and how much total damage they need
to do, assuming that the player misses some percentage of the time
when they're shooting with each weapon. In an RTS, you can use this to
balance the costs of various unit types to make sure that no single
unit is too weak or too cost-effective. In a street-fighting game, you
can balance the various strengths, weaknesses and vulnerabilities of
individual moves and entire characters with respect to one another. In
a sim game, you can balance the various items available for purchase
and the skills your Sims need to learn versus the amount of time it
all takes.

Does that all make more sense?
 
S

steve.breslin

Thanks, ai864! That's a great explanation! Totally clears everything
up for me. I really appreciate it!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top