DEVELOPMENT METHODS:WHICH ONES ARE YOUR FAVORITES?

Here are three things I always do.

1. Common Events

Common Events are the most important thing to me. One of my games, the Halloween Board Game, is pretty much 100% common events. There is only one event on the game's map (outside of moveable graphics) and all it does is call the common event.

I stick common events within common events. My common events have common events. I save rows and rows of things as common events. An example of some things I'll use it for:

Item-Get Sound Effect: This is always Common Event #1 because I use it so much. Got a new item? Use this common event before the text. Don't like the sound and want to tweak it game-wide? Instead of going inside each and every event and changing it, I simply change the common event. It's also good to have another common event dedicated to "Key Item Get" with its own unique sound to help the player differentiate between the two.

You got a Potion: This is a pretty standard, and easy to adjust, common event. I'll dedicate dozens of Common Event slots to the most common items my players will encounter. Is there a potion in a dungeon? There's a CE for that. Do you know how someone earlier mentioned to leave frequently used events in a hidden map? I'll do that for my potions, and I'll fill it with common events. So every time the player gets a potion, I just use that specific common event. The common event itself will usually call another couple common events. It has to...

• Call a common event for the item-get sound effect.

• Call a common event to change the message box settings, because I like to change the display (I usually shrink it to 2 rows).

• The actual "You found a potion" text the player reads, and the adding of that item to the player's inventory.

• The turning on of the self-switch, which doesn't apply globally, but to the event on the map the CE is attached to.

• Another common event to change the message box settings back to default.

Its gotten to the point where, outside of transfers and other things, every event on my map tends to have some kind of common event. Shopkeepers are great to common event as well, as you can make them all have a general opening statement, an inventory relevant to the player's level - if you do that - and anything else I want to be standard for the flow of the game. Innkeepers as well.

I'll create cutscenes for door animations, instead of using the default. I'll have the door open, have the players walk through it, gather the party, fade the player graphics out, then close the door, fade the screen. I'll use this in my template door events. Then I'll use a second common event dedicated to fading the screen back in after the transfer command.

I'll even put cutscene text in common events if they are significant to the plot. It aids me in changing it later. Sometimes I'll sit and read through it and tweak the conversations a little, here and there. Very smooth, especially if you have move the cutscene trigger event to a different position throughout the world. Also, if you're using the method I talk about in point 3, this is very handy for later.

Common Events for life.


2. Templates for everything.

Everything has a template. Everything in the database has slots for adding additional items in their respective category. If I'm making skills particular to a character, I'll leave a bunch of empty spaces after. If I'm making healing items, I'll leave a bunch of spaces for that. I'll create empty skills that simply act as "Folders," leave about 20 slots after it, and create a new Folder.

Then I'll create templates for every spell, every item, every enemy type. My physical attack formula, if I'm dealing with low numbers, tends to be something like a.atk - b.def. My magic tends to be a.mat - b.mdf. My heals tend to be a.mat + b.mdf + (b.luk * 0.75).

I'll template my classes. I'll make a general standard and apply it to everything, then tweak it from there.

That magic formula above? Some people may see it as underwhelming. I can change these templates after I test it. Perhaps I want to make it 15 + a.mat * 2 - b.mdf. Maybe I want to keep it a.mat - b.mdf and make everyone's magic attack stat higher than everything else, a'la Pokemon's stat system. Wouldn't it be nice if there were common formulas that functioned like common events?



3. Create your entire game with filler, then build it.

Yanfly has made this method more popular recently, and it's something I also do, and I greatly recommend. This is known as "how to actually know if your game is fun", or as I like to call it, "finish your game first, then make it".

Basically his comic - click here to check it out - details his method. You're creating filler for everything.

If you're an artist like I am, you probably like making the graphics for the game. You may be bummed about using filler RTP for your graphics and world. It's tough, because you want to see results up front, but I strongly recommend either 1. having custom graphics ready before you begin, or 2. creating them all at the end. Sure, it may be underwhelming throughout the process, but it's much better than, you know, getting partway through making a game and throwing the whole thing out because it isn't fun.

This method, popularized by Yanfly, is great. You lay out the game, you use fillers, you play it to see if it's fun, and you craft the plot. Basically, throw down filler, get your game mapped out, then go back and built it up in parts over time. His method of using maps as Folders is helpful as well.

It's a great method, and it's pretty much how I built most of my games when I released a bunch last year. It will help you see what's fun with your game, and what's not enjoyable. You're stripping the gameplay to the bare basics and seeing if it's still an enjoyable game. It's also good for letting you know if you've got a good thing going that's enjoyable to play, or if you should spend some more time working with the concept (or perhaps, toss it all together). Plot-wise, it makes you lay down the essentials of your story so you don't get to the part where you say "okay, what do I do next?" Highly recommend this method.

It's more a category than a distinct method, but I guess I favor a narrative-first approach to games. Like, the idea of starting up a game project thinking "I want to create an epic-length adventure with a high-stakes plot, lots of characters, plot twists, etc." but not knowing specifically what the end product is supposed to be like seems absurd to me, but the idea of coming up with a gameplay concept or structure, working out what the play experience should be like and how to implement that, and then trying to figure out how the story should go seems pretty weird to me as well.

Not that I necessarily chart out the entire story in advance, but I always want to know what the story is going to be like, and what the key events are, first, otherwise I don't feel like I have a sense of what kind of gameplay and structure lends itself to the experience I want to create. Once I've figured that out, I don't feel the need to keep going back and adding features, changing mechanics, etc. because those elements were all consequences of my decision about what elements would best convey the experience of the narrative.

In a sense, it's the opposite of the method suggested in the Yanfly comic, which advocates making the game's story follow the structure rather than the other way around. But the way I see it, it's another approach to the same basic idea; start with the foundation which determines what everything else in the game should be like, and work up from there. To me, the narrative is the foundation, the gameplay structure is the implementation.

I've been following these suggestions without even knowing it! My game's foundation is pretty solid... but I will have to add filler into story mode when that time comes.

I use common events EVERYWHERE... seriously I've got about 400 common events that do all sorts of weird repeatable things.