how to plan game?

[ZOAG]

Hi everyone! First time poster here, I apologize in advance for this wall of text...

 

I experienced something like an opposite of a writer's block (writer's fountain?): I kept getting more and more ideas for a game that is intended to be a horror rpg game, sort of like a mix between Corpse Party in terms of story, and Ib and Witch House in terms of being somewhat scary. I kept shaping and fleshing out the ideas for the world, setting, plot, characters, dialogs, gameplay aspects, etc.

 

The only problem at the moment is that those are all in the form of notes, which are scattered all over the place and unfocused (as notes tend to be, sort of). I'm struggling a little with structuring them all... we're talking about 200+ pages here, font-size 10, and it's still going (I make notes daily for a few months now). I also haven't made a (finished) game yet.

 

Therefore, I wanted to ask for some tips on how I would go about structuring all those notes and bringing them to one coherent document (or multiple documents if necessary), so I can more easily "connect" all my ideas together and fill in the gaps. Basically I need some template for some sort of "screenplay" for my game, where I can see what sort of "sections" my document would need (characters, plot, etc) for me to describe my game properly, so it's actually readable for people other than me.

 

My questions are mainly:

- What kind of documents do I need to produce to describe the entirety of the game? Which documents do I have to start with before I start with any other? Are there any templates for the type of game I want to create?

- What exactly goes into each of those documents and what guidelines do I need to keep in mind? What do I need to start with first?

 

For me, it's important to be able to easily edit it anytime when I want to make changes in the story or add more stuff to it, so I could keep "duplicate" stuff to a minimum (mentioning the same stuff in two different docs for example). What is also important for me is to be able to use part of the documentation (made to give the reader the same info a player would receive in a playthrough) and give it to other people for easy reading, so they can judge my work and give me feedback based on it.

 

Any help would be appreciated.

 

 

 

P.S.: Before any of you start saying "you should try something smaller for your first game", don't worry: It wont actually be my first game, it's just a bigger project that I'm working on on the side (planning only). I just want to be ready once I want to start with the project some day. And yes, it will be a bit large in scope, but I'm taking my time with it, as you can see, and collecting experience in other projects in the meantime.

 

[sabao]

From another sort of related thread,

Write it all down.


Don't worry about the page count and just scatch at it little by little.


I've learned from experience that the most essential document you have to have is a GDD (Game Design Document). It's a simple document of not more than 2-5 pages covering what kind of game you want to make storywise, aesthetically and mechanically.


I'd start with mechanics first to see if the core idea is actually viable and enjoyable before proceeding with the art and story. Nothing sucks more than getting all the graphics and story done only to realize you can't get Awesome Battle System X which your game leans heavily on to work.


Planning for aesthetics can be as simple as googling for reference images of how you want the game to look and feel like. This should be fairly simple.


Story, you'll probably only need a few paragraphs to summarize. The formal script itself you can work on in a separate document to avoid clutter. You may choose to write that first before producing the game. I chose to make an outline of events, big and small and write actual dialogue on the fly so I can test and have a better feel of the scene while testing the game.


Unless you can remember absolutely everything that you've planned at the beginning, I strongly recommend having a GDD. Actually, no. Have it anyway. Especially when working with a team. Having concrete guidelines of what you plan to do helps keep the team goal-oriented and you get a better feel for progress as you get more done.

To add to keeping a neat list of your plan early on, having a tangible list of what you had planned makes feature creep (or as you refer to it, writer's fountain)easier to fight off: "Ooh, I think idea X would be awesome! But wait, does it fit with the original plan? Can I afford to add more dev time to put it together? No? I should probably stick to the plan then." Keeping all the ideas in your head makes it difficult to map everything out, or assemble the bigger picture when putting all the tiny ideas together. When working with a team, a lack of documentation may produce discrepancies in the overall vision for the project since some people may have imagined something else entirely.

 

[CzarSquid]

I personally divide my game into sections. Tiny mirco-chunks of game that the play will complete. In a way it takes the 'make a simple game' to the second level because essentially you are making a bunch of tiny games into one huge experience. My suggestion would be to organize your notes based on sections of your game. 3 should be the absolute minimum of dividing your game: Intro, mid-game, ending. I recommend more chunks for your project.

Try to outline your game by labeling key points in your plot. Make each key plot point it's own chunk and make a folder of it's own. Put notes that best related to those key points in the game in the folders they belong the most. If you have overlapping ideas, breaking that note up into smaller notes will help a ton.

Then take each folder of notes and try to summarize all those notes in each chunk into one short document. Keep the summary document clear and simple to follow. Once you do that for each chunk try to connect your individual summaries together so that it all flows. Then make a summery out of all the summaries chunks you've made. This super summery is the outline of your entire game. The other summaries of the individual chunks will help you be consistent as you make your game. For example, if you have someone die late in the game but you are working on chunk B all you need to look at is the super summery to find out that this NPC dies in chunk D's. In which you can read chunk D's summary to get quick information on how he dies in detail. Instead of rummaging through all your notes, you can quickly refer to the summary that you need and be able to locate the information you need fast.

I really hope this fixes the organization. You actually are in a pretty sweet spot because you have all your ideas. I just be careful with ideas. They are heavy weights of game design the more you have the more burdensome they can become. Don't be afraid to take out ideas too.

 

[corwinKB]

I am also new to RPG Maker but i found this post to be very interesting. I think I might devise some sort of outline and break things into chunks so I have something else to work on if i get stuck on something.

From another sort of related thread,


To add to keeping a neat list of your plan early on, having a tangible list of what you had planned makes feature creep (or as you refer to it, writer's fountain)easier to fight off: "Ooh, I think idea X would be awesome! But wait, does it fit with the original plan? Can I afford to add more dev time to put it together? No? I should probably stick to the plan then." Keeping all the ideas in your head makes it difficult to map everything out, or assemble the bigger picture when putting all the tiny ideas together. When working with a team, a lack of documentation may produce discrepancies in the overall vision for the project since some people may have imagined something else entirely.

 

[Dragnfly]

For actual software I use yEd Graph Editor for flow charts (you'll want those, especially for puzzles and if you have multiple endings) and an HTML document for the other sorting (though stuff like Excel and Word are much better. I just don't have them and haven't gotten around to re-installing Open Office). It's important to have the right software right from the get-go so you don't run into formatting problems later. Develop a coding system for the importance and order of your ideas, like stuff you absolutely must keep and stuff you can do without. If you have mountains of ideas and can't do without any of them then you're in for some heartbreak. The coding for ordering your ideas is really important for quick referencing or tagging (I just use links, but cell-jumps or reference links work if you're using Excel or Word). I find it important that the GDD has the same info in multiple places (provided you keep it up-to-date in all places) because it saves jumping all over your document and potentially missing stuff.

My documents are basically divided up by the stages of game design. Before even getting to that I make sure to standardize my terminology and link system. It sucks to be unable to find something because you called it a World Map in one part and an Overworld in another. The scene/industry have enough inconsistency already. Also note that these aren't in an order and don't need filled out in this order. I jump all over the place as I run into different sources (like looking for inspiration on vehicles and seeing a really cool map)

Overview (do this first): Explains generally what your game is going to accomplish. Just a few sentences is fine.

Technical Overview: A mechanical overview. It didn't come first with my current project just because it's so old but for the RPG Maker version it does now. This tells you the most important part first: Is RPG Maker the right system for your game. Sabao mentioning "Awesome Combat System X" made me cry a bit inside because I had to ditch exactly that. Since you're doing a horror I'd say "yes" to start with since I've argued a few times that RPG Maker makes better horror games and interactive fiction than it does RPGs. But there may be functions you want that are either impossible or just not worth the effort. It will tell you if you need to scale down or move elsewhere. You're likely fine here, since you quoted 3 of my favourites that would have no mechanical problems being in RPG Maker. In this part you'll also note in what ways the player will overcome challenges. Sounds like puzzles, maybe some chases (be sure to document if there's puzzles while being chased) and maybe some time-restricted events. For example I have puzzles, minor stealth, exploration, battles.

RPG Maker Notes: Things like your resolution, number of tiles per screen and if you'll have anything crazy you want to try and do.
 

Story: The "overall mandatory story" (stuff the player learns before the game is over), broken into tiny sections in the order that they're presented in game. The tiniest sections possible. Note that it's fine if the story includes tidbits about the characters. Have your coding system ready here because you'll no-doubt have sub-events, any tidbits the player might miss on the way through to the ending. You know how these games often give you a key or something after you read a diary or research document? That's to make info mandatory. I played some RPGM horror game while blitzing them on Halloween where most of the story (including the entire reason for being there and the entire reason for the haunt) were on completely optional papers, some of which out-of-the-way. That info should've been required.

Locations: All the locations in the game, starting with the start and fanning out from there. This tells me if I have a workable size for everything I want to fit in and the general flow. It'll also help a lot when you hit the map-making stage. It's useful to tag tilesets, effects and any inspiration pics or real-world locations.

Story fluff: Anything story-relevant that might be missed in a playthrough, like the contents of those buckets all around the school. Be sure to reference at what stage you find the info. For example, the Android game Alphadia Genesis contains a few bits where completely optional info can be found before you get that far in the story, one part even being read by a character you haven't met yet, artwork and all. Referencing minimal parts of the story to see the fluff will help avoid that.

Characters: Mandatory character info. This is the stuff that's directly related to the mandatory story and should be cross-tagged with it. If you're using custom art for them, break down all versions of that art (facial expressions, poses, etc).

Character fluff: Story fluff, but for characters. Did Tim accidentally see Alicia changing one day? Does that matter to the story? Nope? Then it goes here.
 

Visual requirements: Listing and making notes about tilesets and other graphics. I've found this advice is really important: Keep the page, file (if they're ok with it or if you don't care) and the direct link to where you found whatever. Not only does it help with crediting your sources later (including thanking your inspiration sources) but I've run into a lot of cases where people have gone "I've stored my things on Megaupload because Megaupload will be around forever." or "My boyfriend of 3 weeks who I loved broke up with me so I deleted EVERYTHING!" It's not nearly as bad as the 3D modelling scene but it still happens a lot. Actually, in that breakup example you can wait a few months and tell them you have a copy or log of whatever and they might be overjoyed that the stuff they deleted in an impulsive fit wasn't gone for good.

Audio requirements: Same deal.

Script requirements: Same deal. I also reference any good tutorials and problems people had in case I run into the same.
 

Challenge ideas: Puzzles, solutions, timings and potential problems. For me I also put enemies and multi-route dungeon notes here. Might not be so relevant to you.

To me the most important parts of a GDD are to organize and standardize. I hope that helps somewhat and I hope I didn't leave anything out.

Good luck with your project. I'm always looking for (good) horror games.

 

[ZOAG]

Thank you all for the great answers! (and sorry for not answering straight away, had trouble with internet...) This will already help me a lot in getting structure into my game project. It's going to take a while, but I'll get there with time.

 

@sabao: Thanks for your tip regarding "fighting off feature creep". I don't think that it will actually be that big of a problem for me, as the main focus of my game is really "just" the story and the scares inbetween, but I do have certain mechanics I want to implement near the end of the game (like zelda style fighting system). Thankfully, those mechanics are just a nice bonus and not essential for my game, so it's more about getting the story together.

 

@CzarSquid: That would certainly make it easier to structure the entire story. Maybe in my position, I would need at least 15 sections to cover my entire game: intro, middle and ending, times 5 because of how my game will probably have five chapters in total. I'll try out your method and see if it works for me.

 

@Dragnfly: The most detailed out of all XD. It will help me a lot to get started with the documents themselves (tnx also for the program suggestion "yEd Graph Editor"). I like your use of examples, especially on making sure important info is actually aquired (I cry everytime I play a game that easily makes me skip essential knowledge by accident).

"If you have mountains of ideas and can't do without any of them then you're in for some heartbreak." I thankfully don't have much of a problem with that. I was actually surprised at how easy it is for me to get rid of some ideas or transform them into something more useful later (i still keep "useless" ideas around in a separate document, you never know when you can suddenly use them). I found out I can play a lot with the story by changing little things, like combining two characters into one or splitting one character into two characters (the latter being very useful seeing how this is a horror rpg game and I would naturally need some characters to...*ahem*..."get rid of").

 

Again, thank you all for the suggestions!

 

[Dragnfly]

If you're adding a Zelda-style combat at the end I can suggest playing Afterlife - The Second Dimension. Not only is it a great game but a major part of it features such a system done... strangely. Even if you don't play and don't mind spoilers, check a let's play of the end part. The native language is French and it has a pretty bad English translation, so pick your poison.

 

[ZOAG]

@Dragnfly: Tnx, I'll definitely check that out! (although the language barrier could be a problem :/ not too much though, I can tolerate a bad translation somewhat)