NOTE: Yes, I do know that this is in the Writing for Games forum. But I also think that this is important information, since you are a new designer and may not know exactly what path to take yet. If you're specifically looking for writing advice (which I think would be a mistake at this point in your education) you will probably ignore this post. But if you're looking toward a future in game design, you'd be well off to take some of this to heart.

----------------

The first thing I usually recommend is to ignore story and focus on making good games. Most newbie designers get lost in their own Final Fantasy driven dreamworlds and forget that the difference between designing a game and writing a story is the interactivity.

The easiest way to avoid this is to minimize (or eliminate) any non-interactive element from your designs. You can start working with stories and characters later, when you're more comfortable with designing games.

Secondly, you want to prototype. Without programming, you may want to design some board/card games to get a real feel for how your concept would play. For actual video games, you'll want to find a quick way to prototype, I recommend Python or Flash.

Finally, realize that you will get more knowledge from designing gameplay systems than by designing content. As fun as it is to write stories, draw pictures of monsters and map out levels, creating good gameplay and balancing stats is far more valuable. Remember that a concept is not a design.

A concept is something like "Different shaped pieces fall from the top of the screen. You rotate and stack them to create lines, which are destroyed" or "A simulated city where you zone residential/commercial areas and create the transportation, utilities, school, and police systems to keep your citizens happy".

A design is the inner workings of these systems. What happens when a line is destroyed? How does the player win? What happens when you can't create a line? What happens when the box fills up? How quickly do these blocks move? How will the player learn how to play? What kind of user interface does this game require? What will people NOT like about it, and how can you solve these problems? In Sim City, what are the inner workings of the simulation? (Note: This type of game is very complex, but you'd get so much out of it. Especially designing the user interface.)

Also consider taking a pre-existing game (such as Sim City) and study its interface/controls, figure out why they did things they way that they did, and see if you can design a better interface without losing any of the functionality.

Try doing the same thing with your microwave oven. Is the interface hard to use? And why? This sounds ridiculous, but 90% of game design is making it intuitive and enjoyable for the end user.

Good luck!

[Edited by - JBourrie on April 19, 2007 7:03:49 PM]

(Double post)

Taking this back into stories:

Once you have a good understanding of game mechanics, you can go back and start considering how to improve it with story and characters. Consider Final Fantasy XII. They redesigned the whole battle system, which is the majority of the games interactive portion, and if you strip away all story and characters the game is still fun. Damn fun. Add in the well written story and unique characters, and it makes for one of the most engaging games I've ever played.

Contrast that with previous games in the series (lets say IX), where if you stripped it down to pure gameplay it would be a fairly dull and lifeless experience. The characters and story overpowered the gameplay, something that worked back then but people are starting to expect more.

Get comfortable designing game mechanics first, then bring in your storytelling talents. Hopefully we'll see some excellent games from you.

[Edited by - JBourrie on April 19, 2007 9:49:40 PM]

Personally I like to develop the story and the game mechanics together. Because the story can inspire innovative game elements, and the meaning of the story has to be supported by the shape of the game, yet it does ultimately have to work as a game, not just a story.

So more specifically, I would start with a description of what the player is doing while they are playing: both what story meaning this has and how it is satisfying and fun to the player, and also what gameplay the player is doing and how this is fun too. Imagine yourself playing the game and describe what you are doing and how you feel about it.

Quote:Original post by perroza
Thanks for all the sugestions. I was talking about the story as well as the mechanics of the game play.

I know, just thought I'd try and convert another newbie to the purer side of games :)

Quote:The story itself is pretty much done ( on a broad way), and im working on the mechanics right now ( player movements, skills, interactions, enviroments, layout, physics...).

In that case, don't consider your story "locked", be willing to change it anytime you think it might improve the gameplay mechanics.

Quote:I guess what Im trying to get at if there is like a format or something like that that I should follow.

Not really, but a few that I wrote at DigiPen are Rumble Box and Thelema, they might be able to give you some ideas.

Quote:For people who have turned in ideas in for games, or have done presentations of their ideas, what do you focuss on? (player movements, interactions, other?) Like Imention, Im a newbie ( just started game dev. school)

Ah, now this is something I think I can help with :)

I see you're in Florida. Full Sail? I finished DigiPen a few years ago, and here's what I learned about game design and pitching:

- Focus on the broader picture. The little intricate details of the gameplay aren't interesting or relevant when trying to sell somebody on your idea.

- If you're pitching to a class, they will have pre-concieved notions of what your game will be like. Therefore, don't start the pitch with "It's like Tomb Raider, but..." unless you're making a Tomb Raider clone. As soon as you say something like that, everybody listening will tune the rest of the pitch out.

- If you aren't having fun pitching, the listeners won't think the game sounds any fun to play. You have to love your game before others will.

- Be loud, be confident, and be excited about what you do. Probably 80% of DigiPen pitches were quiet mousy people mumbling their idea out with no feeling. This doesn't sell a game. If you have an introvert on your team, have him running the Powerpoint slideshow. Just don't let him talk :)

- Talking about a powerpoint show, you need some sort of visuals to go along with your pitch. If it's not a demo, it should be a slideshow or... something else. Nuclear Monkey (the team that did Narbacular Drop and are now making Portal for Valve), third year, gave a "pitch" for their racing-combat game where they walked up to the front of the room and said "Our game goes something like this". Then two of them sat in rolling chairs and made engine sounds, and the other two pushed them around the room while pretending to shoot each other. It really was pretty brilliant.

- You don't want to hear this, but it needs to be said. Of the seven years of DigiPen game's I am familiar with, not ONE "story driven" game was ever successful (they rarely even get finished). The closest thing I can think of was "Eskimo Kisses", which was an Animal Crossing style communications game... not much story.

The reason for this is because story requires content, lots of images and dialogue and characters and such. Students just don't have time to create all of that on top of making the engine, levels, gameplay code, UI, and still do their classwork.

I think you should save your stories for when you can do them justice, and focus on gameplay. But then again my senior project involved little box people kicking the shit out of each other... not exactly story driven :)

Now I'll stop trying to convert you, you can make the decision for yourself. Just know that I have done exactly what you are doing and you are better off focusing completely on the "game".

Quote:Ive just been taking notes, ideas and brainstorming on a game for a couple of years, and Im finally putting it all on paper, so when Im ready to start the programing stage, Ive got some solid start material to go from.

How big is this design? If you've been thinking on it for years, it's probably based on the games that you know and love. I will warn you that this, in the past, has been a Very Bad Idea (TM). I might be wrong, but I've seen it often enough to be confident that this advice will help.

- You will not make a game that is even 1/100th as good as the commercial games that inspired you. You're better off making something that nobody has seen before. Right now there is no risk involved by experimenting with game ideas. Once you're out in the real world, when money is on the line, you will never have the freedom that you have right now. Use it.

- If this idea is Really Really Good (TM pending), you should save it until you can do it justice. While you are learning to program is not the best time to make your Awesomely Awesome Game. Your first few games will suck, I guarantee it.

Quote:Not everything is set on stone (Ill probably shot from the hip with a couple of ideas), but Im kind of an organisation freak, and i like to prepare for the future, so Im doing little by little.

The more organized you are, the better off you will be, especially if you are also a good team leader.

Quote:General information on the game: Its actually an RPG/Racing game mixture, so where the card/board game mock up is actually a pretty clever idea, Im not sure if the racing effect would be represented correctly, but I got some other ideas where it would work just great.

An interesting and new idea, but the letters "RPG" scare the crap out of me. If you haven't realized why yet, you haven't been reading close enough [grin]

Remember: Nobody will play your game for more than 10 minutes. It's a student game, you HAVE to realize that you're not making anything close to what is out there on the store shelves. So make that the best damn 10 minutes you can.

Quote:There will be an open world enviroment plus tracks/racing areas as well; plus some minigames along the way.

If this is a student project, you will not have time for all of this. If it's an open world, build the tracks into that world (so you don't have to design new areas for racing). If it needs race tracks, turn your "open world" into a UI hub. And don't worry about minigames. Minigames are added to commercial games to cover up for shallow gameplay (if a person is playing the same game for 20 hours they need to break it up every once in a while). Again, nobody will play your game for more than 10 minutes.

Quote:Im thinking of making it a platformer game. Should I mention control layout, or should that wait to after the design/programing starts.

You certainly want to consider possible control schemes up front, and feel free to be creative with them. But also make sure to focus test your controls once the game is playable and change them when necessary. Finally, every once in a while do something random (double the speed of the character, figure out a way to remove one button while keeping it playable) and you may realize that it's better than it was before. With Rumble Box, we never realized that our character moved too slow until we just randomly doubled his speed one day.

I'm hoping you mean a platformer "instead" of a racer/RPG. Adding platforming to those other two will just further confuse and complicate things. Also remember that if you don't have an artist and animator, don't make your main character humanoid. Make him a ball with eyes or something. You don't want to waste your time animating unless that's actually the job/degree you're going for.

Quote:Should I go into detail part by part of each level, or should I give a brief description of each? Should I include maps of each level?

If it's a racing game, you certainly want to map out your tracks before building. Double if you are building the tracks into the open world, because you will find ways to make the same intersection work for multiple tracks, further shrinking the actual amount of content that has to be created.

Quote:Ill probably think of other stuff as I go. Thanks for all the help.
Perroza

No problem. Once again, I know that this is the Writing for Games forum, and the advice I'm giving is far more game design than writing. But as a former student going through the same thing you are, I try my damnedest to steer other students down a path where they will succeed. I watched too many good students burn themselves out on too-big projects.

Good luck!

Good luck, I hope it all works out.

By the way, feel free to PM or email me if you have any questions about the docs I linked or anything else (I don't want to post my address due to spambots, but I'm sure you can find it [grin]). I'm always up for helping student projects get off the ground.


One more thing you might want to consider is designing the game in layers.

- Design a good racing game that could stand on its own without the RPG aspects
- Design the RPG aspects in a way that they could be implemented using a UI instead of the open world.
- Design the open-world wrapper for the game, and how it will tie in with the RPG aspects.

Then complete each layer before moving on to the next. In this way, if you don't have time to "finish" everything before your classes end, you will still have a good game that feels complete.