Design.

.

 

I know this is off topic but do you have a recipe for mango pork? it sounds as though it will be pretty tasty.

 

Its not a difficult process, but quite important.

If you're following an object-oriented approach, think of all the possible entities and data they would require to function, states they could be in and methods.

http://en.wikipedia.org/wiki/Object-oriented_design
http://en.wikipedia.org/wiki/Relational_data_model

 

I've never heard of that being some kind of law of game design. It sounds pretty bizarre, in fact. Even if this would be of any use it would just be classic abuse of a spreadsheet for holding data, as done by offices all over the world. This is what a database is for. About the best you could do is outline your intended data structures, or the most obvious variables that will be required. All of them? Wow.

If you really want to do it, create a spreadsheet and then put all of your variables in it. Once you realise that this isn't possible until you've already programmed the game, you'll see the problems inherent in the idea. You could certainly export out a list of all variables and data structures for a program for documentation reasons, but expecting somebody to be able to do this as part of the design process is ludicrous. Maybe I'm just out of touch, who knows. If somebody asked me for this I'd print one out and then wipe my ass with it.

Mango + pork.

 

I don't use it, so I'm not sure if this is the same. The process I know off involves putting gameplay element stats; e.g. monster health, firepower etc. into an excel spreadsheet that you give to your designer. They can tweak it to their heart's content, and there's a button that automagically exports the proper cells in your spreadsheet into a format that your game reads.

You'll need to write your own office exporter to export the data your designer generate into something your game reads in.

IMO, if you're using Unity, it's probably cheaper in the long run to write your own run-time editor using reflection if you're going to have separate designers doing lots of tweaking.

 

Graaaaaargh! This is not what spreadsheets are for!

If you want to do this, use XML or a database of some kind.

 

I think this is called a desk check, and its taught in colleges and universities to ensure your expected data output matches your inputs. Its fine for application development and banking but for unity just ad lib.

 

@xomg

This workflow is partly used by Boomzap if IIRC.

The excel file does not go into the game nor is it read directly by the game; it's only an interface presented to designers, and the end output is normally XML or some other easy to parse format.

When working directly with a database or XML datastore, someone will still need to write a front-end for the designers to use to enter data; you don't want them hand formatting xml or going through phpMyAdmin to set variables.

That's what some game companies do; they use formatted spreadsheets as the front-end for data entry, then add a button to export the data into an XML file for their game. Why write an editor when you don't have to, especially when the editor you can use lets your designers write ad-hoc formulas and labeling?

 

My bad, they don't export to XML, they export to Lua, but the point stands.
Note that Boomzap is not a Unity shop, so their workflow needed to adapt to the fact that their tools are not as designer-friendly as ours.

Here's the article:

http://www.gamasutra.com/view/feature/4314/quick_and_dirty_prototyping_a_.php?print=1

 

Maybe that works for them, and that's all that really matters. I've never heard of them, so I can't comment. I'm sure their games are great, but I suspect I'm too old and male to be in their target demographic...

Most games I've worked with (or on) have had a level or game editor, and that's where variables are exposed to the level designers. The thought of having to load up an Excel spreadsheet to tweak the health of enemies just makes my balls ache, even if it is just a front-end to export to a game-friendly format. There are plenty of very simple XML editors that could be used that will display this sort of information in a nested tree format if you really don't have any kind of in-house level/game editor.

Getting back to the point, it is a good idea to write down the data structures for things such as your player, enemies, levels, and that sort of thing. You'll obviously want to document things like networking or how the renderer works as they're unlikely to change during development and many other aspects will depend on them being stable, but variables and game features are going to change.

The reality is that game development is not the same as business application development unless you're some soulless drone working at EA, making a game at University, or churning out "casual" games with a 3 month dev cycle. Games tend to be flexible, with new technology or optimisations only becoming apparent after the design stage, often during playtesting. Development may take several years, and some features will be cut while others will be added depending on time and real-life engine performance. What's important to have in your design document is the key gameplay elements, level design, and things that you're 100% sure are requirements.

It would be great (even ideal) to be able to document every last detail of the game during design, but it's not the law. It's definitely not something that people should be worrying about just because they've read about it somewhere. I suppose if you're just writing a simple puzzle game then you could potentially list out every single variable and object in the game, but I would argue that the time would be better spent just writing the damned code.

 

A spreadsheet typically has an option to export to tab-separated text. This can be read by Unity (perhaps in an editor script) and used to generate the equivalent data for the game. Another often overlooked option is to use a script written in Perl or whatever to generate source code from this data.

However, with Unity it is very convenient simply to set public variables directly in the inspector. Maybe one option is to turn the process on its head - use Unity for data entry and have an editor script to generate tab-separated text from it. You can then import that into a spreadsheet to make a concise design document.

 

In what way? Don't get me wrong, I know this attitude is pervasive in game development, and not to pick on you specifically, but since you feel strongly about this, do explain how $100K (ok, chump indie change in reality, let's talk real game dev $5-50MM) is in any tangible way different from similar investments made in business development (and just to get a closer comparison, let's narrow business development down to retail targetted software).

If I understand your arguement, code execution dymanics, application design patterns, User interface design principals and user experience factors, base system constraints, memory utilization, System sub-components and processors, storage, database design, networking considerations, threading models, and best practices are all uniquely handled in game development making "seat of the pants" development necessary in game development as opposed to retail application development. Did I capture that right?

I would argue that new technology integration (and up front decisions about technolgies to be targetted/used, that are not lightly altered mid-stream) and optomization considerations are functions of design (refined in mid and final stage testing phases), not after thoughts. If you can't tell me how to design a .Net program (any field) to better leverage the targetted implementation of .Net runtime environment, then frankly you simply can't tell me if Unity or XNA .Net extensions are better at a given task. Now... you want 7 figure budgets put at your disposal based on the promise that you are good enough to build the next great game without the need for "all that overhead" (and you still haven't had the audacity to lay claim to "Agile" development - which despite popular developer claims "doesn't require documentation" actually produces more documentation), is that right?

There's nothing new in these claims, business app development was treated the same way in the mid-late nineties by too many. Turns out, the vast majority of those projects/businesses failed. Not to draw unnecessary conclusions, but frankly... the game industry hasa tremendous failure rate (of both projects and businesses). Better structure to game design/development may not create "inspired" gameplay, but it sure as H*LL will eliminate many of the stupid bugs and gameplay oddities that leak into the market today.

Pouncing on someone for asking to use a sound application development practice, because the notion of it seems to contradict your personal philosophy, is neither helpful nor warrented.

Game design documentation is used by many more than EA and college students.

@Mangopork - unfortunately I don't have an example spreadsheet handy, I'll poke around my drive tonight and see if I can find one.

Cheers,

Galen

 

I understand your point, and yeah - I'm mostly just being awkward for the sake of it. It often brings out some good discussion on a topic, in this case from you.

The monetary investment for a game might be the same as writing a business application, if not more, but the product you're building and designing isn't always comparable. I'm not hailing a "seat of the pants" approach as being the best or only answer, and it's monstrously risky in today's screwed-up game market, but despite the best intentions of designers you're often going to be forced into some level of flexibility during development simply because you can't quantify the "enjoyment" or "fun" of a game in the same way that you can design an application to satisfy the requirements of a client or a set of input/output data. That means that your design document and "variable spreadsheet" no longer matches the game you're making 6 or 12 months in once you're able to properly playtest it and rethink or improve elements.

I'm not a fan of buzzwords or rigid development ideologies such as this either, but again that's just a personal opinion. People seem to cling to them without good reason a lot of the time, just because they've read about them in a book. Often they'll suit your team and working environment, but I've also seen them forced on a team by a "business strategist" when they simply aren't suitable for the task at hand. Each business, team, and project is going to require a different approach depending on what you're making, the size of the team, and lots of other variables. Trying to bash a square "agile" peg into a round hole isn't the answer.

Perhaps what I'm describing/whining about fits into one of these methodologies, I don't know, but documentation is vital. Any methodology that argues against this is questionable at best, bullshit at worst. Getting bogged down in documentation and design documents is just as risky as having no documentation at all, though, especially for the relatively simple games and small "inexperienced" teams that we're talking about with Unity development. With experience comes the ability to better plan your future games, but for people making their first game you're often going to benefit more from just getting stuck in and seeing what works and what doesn't, then starting from scratch and planning based on what you've learned is possible in Unity and within your team/self/budget/timescale.

Agreed. You'll get a game that functions exactly as planned, and your game will be considered a success when measured against the design document. For an application that's very important, because producing anything else will mean that you've ignored the requirements. For a game it will often result in a product that ignores the results of early playtesting or was unable to adapt to make use of (for example) a new version of the engine or some new rendering or AI techniques that became available during development. You'll get a game that your market research tells you should be a success, but will receive average reviews at best and be forgotten about quickly. It will still turn a profit in most cases, so you could argue that it doesn't matter...

Again I'm putting opinion ahead of logic, but I'd rather see an industry producing interesting and unique games than churning out "products" in a lab or factory environment fuelled by huge spreadsheets and rigid designs. It is surely safer to produce games like this, but you just get a flooded market full of painfully average games where nobody is willing to take risks or experiment. Inflated budgets are mostly to blame for this instead of design methods, in my opinion, just like the stale movie industry.

I'd like to see the next generation of game developers take inspiration from the old-school "seat of the pants" programmers and designers that lead to breakthroughs in technology and gameplay instead of trying to emulate what massive sequel-factory publishers such as EA or Activision are doing. The reality is that those days are gone, for better or worse, but you still see diamonds appear amid the turd-swamp of modern games. This is from a combination of an innovative design and a dynamic team that can adapt to what their market wants without compromising the core of the design. A lot of these diamonds have changed dramatically from their initial design goal, and come out of the process better than ever. Some have taken this approach too far and never made it to market or have lost their way through having no clear design at all. Duke Nukem Forever, I'm looking at you.

Perhaps not, but it's lead to a more interesting discussion than if I'd just said "Open a spreadsheet and put your variables in it", and the guy had gone away thinking this was really going to help him or that it was the only way to work. Proper design and a clear goal is vital, no doubt, but in this case it felt like the guy was running into a brick wall while trying to design his first game because of this specific step that he felt was required.

 

Having just dipped my toes into the Custom Editor waters, I'll just make a plug for doing that instead of using some sort of spreadsheet -- Data structures are often more than 2D, which is all a spreadsheet can show. Why not just aggregate everything a level designer needs to edit into an editor panel and save it to the objects that need to be updated.

Much easier to maintain, much easier for the level designer to actually design the level, and much less likely to have things get lost in the pipeline.

And with 3.0, writing a custom editor is not that hard (if I can do it, then it's not hard).

 

Ah ha! An instigator! My kind of people

First, @Mangopork - i wasn't able to find an example for you. I'll keep looking.

now, back to the general discussion that urrupted

I think there's room for creativity in a well documented game design. First, I still think it's crazy to stuff a whole game design into a single document! Some of the worst business development environments I've ever been in just can't seem to separate information and processes into associated terms. Game design (in my humble opinion) isn't a technology discussion (or document, necessarily.). Ok, that was loaded, let me clarify, while certain technology decisions are often key to core gameplay and game design (iPhone touch interface vs console for example), the vast majority of what the game is (or is envisioned to be) has little to do with HOW the game is made real. Yes, technical limitations often change the end result, but no computer application (or plan in general) survives contact with the enemy (MS I'm lookin' at you ).

Let's look at the most generic business application process, and see if it can line up with game development...

basically you have 4 phases (generic remember ).

1) requirements
2) planning / design
3) development
4) test

Usually followed by deployment (well... that's the story anyway ).

Game design docs, to me, seem like a great fit for requirements. It's the "What do we want" document.

Design documentation, in traditional generic dev, breaks up into functional and technical requirements. Again, the game design document could easily capture functions, or a gameplay document perhaps? We're still in creative land to this point.

Ok technology (Mangopork's original request), this could take many forms. I would say you need to follow the same logic that any other technology field uses:
1) do enough design to articulate the ideas
2) the amount of design required is directly related to the savings/benefit/risk factors - ie .. a quick web site that's static only isn't going to be hard to fix if something needs adjusting (and usually no one gets hurt ), now, the space shuttle... give that one about 10-20 yrs worth of design phase (cause even at that, when things go wrong... ).
3) Don't forget you need to support this thing - ok, now this is one place where game development deviates significantly from other computer related fields. Business apps are supported ... well... for a disturbingly long time (Have you had your Cobol fix today? ). Games... well, historically, they make their most money quickly and support vanishes by the 3rd quarter from release (some companies don't get that far... you know who you are).

Point 3 is, I think, one of the major driving factors in the state of game design. In a business application (internal), operations costs typically run 76% of the total cost of an application. for retail, the costs can be dramatically higher for the maker of the software (if it doesn't work well it could put an end to your business creditability and well... your business). Games.. hmm, I can say there have been some AAA titles that struggle to, ahhh, how to put this? INSTALL!!! much less run (sometimes I wonder if the cry engine was named more for consumer experience, than developer pain... )

That, however, may change. WoW (or any other online based game), have tremendous support costs. Not to mention, hacks that break down customer confidence, player monitoring, etc... NOW, how many creative risks can you really afford to take? If the client side is slow, people leave, if the server side crashes, people leave, if your server side is poorly designed and consumes too much resources, your hosting costs alone may drive you out of business, and so on.

On the up side, online games have hit the holy financial grail ... people not only buy the game... but they actually pay (every month!!!) to keep playing! Ye gods! Can you imagine the uproar if MS used the same pricing model for MS Word (ok, no need to imagine, they've pitched the idea before, just google around a bit - no, the response wasn't pretty).

[back to the initial 4 generic phases]As for the rest of development process, it actuall runs very similar (develop it and test it and subject parents to another "must have" they can't afford - the only difference being if it's for them or their kids ).

Now... "seat of the pants" development, should be (again, in my humble opinion) be more like Research and Development (test your ideas BEFORE you just throw them into a new product). And don't do the technophile thing, and always jump on the newest coolest thing ...

Now, for my disclaimer: the above thoughts are purely taken from a business (game or otherwise) profit driven point of view. Doing game development for pleasure can benefit from structure, but... it's only as necessary as you want it to be

Oh, and you're right, it is a "better" discussion ... for us. @Mangopork if you want your thread back please let us know, so we can throw ourselves out and "get our own place"

Cheers,

Galen

 

Using spreadsheets to document the variables in your software design is rather uncommon. A typical approach is to use UML. That language and related tools are... better suited to OOP designs than a spreadsheet... and your local bookseller's sure to have at least one book on it. As you get to know UML better, you'll realize it can do quite a bit more than express the variables in your design.

 

Ok, time for a terminology check... when you say variables, are you talking about game play elements? As in, I want to document and plan the various dynamic elements of my game, not, I want to document (or store) programming variables? I suspect, based on your last comment that many of us jumped to conclusions based on the language you used. Variables in programming refer to a symbolic name that represents some data in memory, which gets persisted in some file format (in many of these responses the authors are answering your question as though you intend to use a MS office excel spreadsheet as the storage format, and are offering XML as a better structured flat file format).

Now, I and some others are pitching our responses more toward structured code design, but I think that may not be correct either.

Two things make me think we're off in our responses, 1 you said you aren't technical (at least not strong in coding), and 2 you got advice from some senior industry game designers (who may not be coders). I suspect their advice would be geared more toward actually doing more detailed and structured game design, gameplay design, and game element design, rather than creating what amounts to a variable "data dictionary".

Am I way off here?

Cheers,

Galen