A new beginning...

Submit your own resources!

Michael Hense   (Sep 11, 2006 at 12:02 GMT)

on the surface, your plan sounds like an excellent one JB...

but i think you've might've left out a few stages...

( *warning * mini rant area ahead * proceed at your own risk* )


for instance, in between stage 5 and 6... the point at which you
suddenly come to the realization that, after weeks of coding and
modeling and texture making, that the initial design goals were
waaayyyy to unworkable, too unrealistic, and must be further
refined and streamlined in order to have a chance of becoming
reality within the framework of the engine or the development tool
that you've chosen from which to make your pride and joy with...

and after stage 6... when nothing seems to be going right in your
development, and you look outside and see that the sun is shining
out there, and 'normal' people are running around, pursuing real
goals in their real lives... enjoying themselves, not a care in the world,
least of all why a single line of code won't compile properly...

that's when the real doubts about what you are doing starts to seriously
seep through the cracks...


the we arrive at stage 7... assuming that you've been persistant and
single minded enough to get that far... when you now must convince
the entities who own the channels of distributions, that your great idea
is the one worthwhile project out of the multitude of projects that pass
before them, that they should gamble on, and invest their precious resources
in... and if you are really bold, if after all this you are willing to risk everything,
you propose the idea that they should consider returning a mere 15% of the monies
that they will undoubtedly make, back to you, the developer... so that
you may have the funds necessary to buy a few necessities of life, and splurge
on one or two indulgences... and license the next great release of the dev
tools necessary to allow you to embark on stage 8...

so that when the dust of the postmortem clears, youcan through all of it again...

and we haven't even touched upon the tons of coke, the packs of smokes, the loss
of what used to be 20/20 vision... better than 20/20, the demise of your position on
the social register ladder of up and coming fast climbers who aren't wasting their time
'playing with the computer'...

i think that these are just a few of the things that you might consider, if not adding, then
definitely factoring in to the game plan above...

( * end of mini rant mode * safe area ahead * blue skies abound * )

:)


hey... what the heck... at least you have taken the time to write down a plan...
maybe that was my mistake from the beginning...

d'ya think :)


all good luck and success with your project...

--Mike

David Montgomery-Blake   (Sep 11, 2006 at 14:54 GMT)

Somewhere in steps 1-3, I would amend it to prototype both the idea, the refined "core" elements of the idea, and such pieces will filter into the "design" phase. This will help you refine your "paper gameplay" by having prototyped the core elements of your gameplay to see if it is actually fun, because sometimes good ideas just aren't that much fun (or else the are non-intuitive).

For example, just recently I had an idea for a game that I was calling "Paper Magic". Basically, you were trapped in a storybook and had to do various things with the pages to solve puzzles. So, you could tear up pieces of the terrain, unfold boxes, cut-and-paste pieces of the world to create bridges, stairs, etc. It sounded like a pretty neat little idea (and I would have enjoyed playing something similar if I could have made it intuitive). Unfortunately, what I discovered was that in "unfolding" geometry, the more complex the geometry (pretty much anything stranger than a cube). It felt like UV mapping, which when you first begin doing it, is irritating to learn and seemingly not intuitive (Modo and BodyPaint (remember Detailer, anyone) have made it easier, but to a beginner, it is often still a problem to figure out where be to have your seams, etc). And since it was a game, albeit a weird niche game, everyone starts as a beginner. And if the core element (tearing up stuff to make other stuff) is non-intuitive, it is not a good start. So I canned it. I had prototyped it in Blitz3D because I had quick and easy access to the underlying geometry. It didn't matter if it was fast or elegant. It just needed to make sense. It did not and therefore would have been a major time sink if I had come up with an elaborate design scheme based around a simple, unintuitive and shockingly cruddy gameplay mechanic that sounded good on paper, moved it into TGE by adding in my own object interaction, optimizing, and then realizing that after all that work...it wasn't any fun...

And, of course, it depends on the type of game that you want to make, but prototyping out how the gameplay mechanics work is an excellent way to determine what needs to be changed before you set it in stone in a design document--and yes, I know that a DD should be a maleable working template, but it seems that many young indie developers or hobbyists begin to trust it as the fact of their thought rather than an implementation of that thought. They see it is a fact->implementation guide rather than as a two-part implementation which can change as the game needs to change. DD's and the programmed game are maleable and should be able to change as needed to create a tight, polished end-product.

This is not to say that design is unimportant, especially for story or character-oriented pieces, but in terms of gameplay components, prototyping is a quick and dirty way of seeing what works, what doesn't, and how (if) it needs to change.

Ethan Groves   (Sep 11, 2006 at 14:59 GMT)

LOL! XD

"when nothing seems to be going right in your
development, and you look outside and see that the sun is shining
out there, and 'normal' people are running around, pursuing real
goals in their real lives... enjoying themselves, not a care in the world,
least of all why a single line of code won't compile properly..."

Then you go the blogs and forums for encouragement and help with you project and all you get is rants...
(I'm teasing.)

You are right JB planning is crucial. "If you fail to plan, you plan to fail." (A quote from someone.)

Jody Byrd   (Sep 11, 2006 at 21:04 GMT)

@Micheal

Quote:

---

after weeks of coding and modeling and texture making, that the initial design goals were
waaayyyy to unworkable, too unrealistic

---

I decided to develop my workflow idea having done exactly that way too many times.

Quote:

---

and you look outside and see that the sun is shining out there

---

And try to have the courage to open the window and smell the fresh air that remind's you of a time when you were a child of the sun and not a creature of the night.

I'll be happy if I can get to stage 7 with this project.

Jody Byrd   (Sep 11, 2006 at 21:50 GMT)

@David

You point about a prototype is exactly right. They are needed to prove concepts.

also, Spoken language, Written language, and Visual language are 3 seperate things, and a prototype/mockup can get a team speaking the same language quick.

But the way i see it, having to do a protoype first is a decision you make based on your designs, and that's an iteration of the agile development cycle. In Stage 4, you make that call. There you should have a design doc, and most likely you can't make the whole game at once anyway. So you'll have to break it up into chunks. Then, in order to code those chuncks, you'll lay down your tech specs for the chunk you need to work on first. If a prototype is required to test a theory before continueing, so be it, that's what being coding this cycle. Then in Stage 8, if it's worth continueing, you add the knowledge gained back into the next cycle.

You must be a member and be logged in to either append comments or rate this resource.

Home | Products | Solutions | Downloads | Support | Search | About Us
Copyright © GarageGames.com 2000 - 2008 All Rights Reserved