GAMING DEVELOPING AND WHERE TO BEGIN.

If it's your first game, you probably don't really even know what to plan, though. I mean I tried to do this in my first game but the planning amounted to a list of characters, a list of spells for each character, and a plot overview including dungeons and bosses. Oh, and about ten pages of jokes.

Know what it didn't have? An overview of when you get access to elemental and status resistance gear. A general indication of when in the game each of those spells actually becomes available. A correlation of which bosses will require or benefit from said gear and spells. Anything at all about enemy mechanics beyond describing my bosses as "a fire-elemental dragon" and "a golem with a lot of HP." A timeline of teaching the game's mechanics to the player - not that it had any mechanics to learn. An overview of what I would and wouldn't need in my tilesets, since I only got five tilesets for the whole game. A realization that RM95 only has 256 switches and I needed to ration them out ahead of time, or that buff spells don't work for players in RM95 and I needed a different way of differentiating characters.

But shit man, I had like ten pages of jokes planned out. What could possibly go wrong?

author=LockeZ
If it's your first game, you probably don't really even know what to plan, though. I mean I tried to do this in my first game but the planning amounted to a list of characters, a list of spells for each character, and a plot overview including dungeons and bosses. Oh, and about ten pages of jokes.

Know what it didn't have? An overview of when you get access to elemental and status resistance gear. A general indication of when in the game each of those spells actually becomes available. A correlation of which bosses will require or benefit from said gear and spells. Anything at all about enemy mechanics beyond describing my bosses as "a fire-elemental dragon" and "a golem with a lot of HP." A timeline of teaching the game's mechanics to the player - not that it had any mechanics to learn. An overview of what I would and wouldn't need in my tilesets, since I only got five tilesets for the whole game. A realization that RM95 only has 256 switches and I needed to ration them out ahead of time, or that buff spells don't work for players in RM95 and I needed a different way of differentiating characters.

But shit man, I had like ten pages of jokes planned out. What could possibly go wrong?

lol! My first game suffered from some organizational problems as well; in addition to there being a fair number of glitches due to my not organizing the maps properly, players complained that the difficulty curve was too high later in the game, and that some of the playable characters were far superior to others.

What I've learned to do since then is to work 'big to small' when organizing a game's various details. I start with one document that breaks down the game into sections (chapters, essentially, which cover the areas in sequence). Each section is then further broken down into two categories of areas; towns and dungeons. Each location is then further broken down into lists of NPCs, items, monsters, rooms and puzzles. Doing this allows the designer to have a quick 'fact sheet' for each location.

What I do next is then make a new document for each location, copy and pasting the information from the fact sheet, where I flesh out all the other details; the location of treasures and enemies, relevant plot points, the number of switches and events required, enemy and boss strategies etc. I find that the more complex the location, the more helpful a detailed outline will be in bringing it to life. I usually then make a new folder for each area, with more detailed information in separate documents (item stats, puzzle solutions, character dialogue, etc.)

As for characters, the same basic approach applies; I start with each character's class (assuming I am using classes), then I put down their skill lists, their usable equipment, their basic stat progression, etc. After I have done that, I have a pretty good idea of how the various party members will look at given points in the game, and I can go back to the areas and jot down things like what the intended level for the party will be in a given dungeon, and revise the area data accordingly.

Above all else, I try to follow the KISS principle ("Keep it simple, stupid"); things will get complex on their own, so I find games work best if the designer tries to keep things as basic and straightforward as possible when laying down the framework. Once the game starts to come together and you know that the foundations are sound, you can get more creative and add more content.