Is it possible to design it 'right' from scratch?

[Digital_Scapegoat]

I currently have an internship on a game-company in Sweden. My main task at the moment is to define a gameplay for a game concept idea that is rather experimental with no obvious similaritys with classic game titles to take inspiration from. The whole game is in a pre-preproduction state at the moment, so everything is kind of abstract.

My task is to work out what you actually DO in the game, how do you interact with the world, how do you use your tools, how do you solve the problems the game presents for you. How do you play the game!

My approach so far has been a trial and error method, picking the pieces that had some substance to them from each trial iteration, developing them and completing them with new design ideas. This slowly reveals a method for playing the game, but at the same time it feels like an ineffective approach since each trial means a lot of new design layouts and programming to give game-play to the new designs.

My question is, how would you/someone else/'an established game designer' approach this challenge with a game at this early state of production? Does designers actually do qualified 'good estimations' of what would be fun to do in a game before trying out the feeling of the design in-game?

Is it possible to create a fun, challenging and entertaining game-play concept in theory and making the whole concept work right from the beginning?


Peace out!
/E

[yaustar]

This is almost a religious argument. Personally, I think it is impossible to get all of it right from the beginning without some element of prototyping and trial and error especially some of the more experimental concepts. The trick is to be able to prototype it at speed.

Having the designer sit with the programmer(s) and develop the prototype iteratively until it 'works' is the why to go. Software practises and paper be damned, the code is more or less going to be thrown out anyway so why bother making it correct? The idea is to make it work, not to write production code.

If need be, get pen and paper, live act the 'game', do anything to try the idea and see if works in practise.

Don't forget to ask for other people's opinions on an idea, they may pick up on something that you hadn't thought of .

[Gshonk]

Originally Posted by yaustar

If need be, get pen and paper, live act the 'game', do anything to try the idea and see if works in practice.

I generally start with a paper or white board prototype just walking through all of the steps that way helps. But I have to agree with yaustar there is nothing better than just sitting down and coding a prototype and seeing how it works.

[Ezion]

The more complex the system is, the more variables you could mess up. Because you're pursuing an experimental design with no previous examples to draw upon, your chances of messing up a few variables is even greater.

From sheer mathematical probability, there is very little chance you will come up with an experimental game design that doesn't require tweaking.

You say that you're working on a way to interact with the world...this has been done extensively in both 2D and 3D worlds. Are you sure you can't draw on any previous titles?

[Adrir]

whiteboard<->prototype<->evaluate<->playtest

[lostgamedev]

"What would Miyamoto do?"



Yeah, prototype the hell out of it, although first you have to have a pretty solid idea in your head (or on paper). And by solid I mean you've already worked out possible kinks way before you try prototyping it. Try chopping down the concept into bite-sized pieces then address these concepts separately, so that one successful part isn't bogged down by a failure on another. If everything works fine, then try merging these pieces and see if you can see 'fun' out of it.

Good luck!

[yaustar]

IIRC, Super Mario Galaxy was in prototyping for 2+ years. Nintendo have different approach to developing games: http://timedoctor.org/2009/03/gdc-iwata/

[Digital_Scapegoat]

Thanks for all the answers! I really appreciate getting some insight in how other people approach the matter. I like the divide and conquer method losgamedev talks about, especially when working on a more complex system thats probably a 'must do' to get an overview of the system.

[Zooch]

This is one of the main reasons why I learned Flash.

Prototyping in Flash is such a valuable communicator - I know I've saved literally months of prototyping over the past year. I hated every minute of learning that god awful program (I don't hate any program more than Flash CS4/AS3). It's just that prototyping with flash saves so much time and frustration on the other end of the spectrum, dealing with the program is worth it.

For me, Flash was my graduation from pen and paper and/or MS Paint.