Starting Tips

Welcome to the wiki! This is where you can find resources from Yanfly.moe, Ækashics.moe,
VisuStella, Caz Wolf, Fallen Angel Olivia, Atelier Irina, and other affiliated content creators.

Introduction When creating a new project in RPG Maker MV, it can be hard to figure out where to begin. There's so many things that need to be done, so many things that need preparation, so many ideas you have, and it can be a mess to make. These are some tips I have for you all to help start your projects to make it more bearable to handle, especially if you're a solo dev. Keep in mind that these are tips, not absolute rules that you have to follow. Tips Don't Stress Over Titles Yet This is a common trap that a lot of devs tend to have when creating a new project. They tend to try to figure out the best possible title for their game before even continuing into the game dev process. You can change the title of the project at any time so this is nothing that is permanent. You see similar problems with amateur writers, who must begin with a title for their essay, paper, book, etc. before they can write out the content of their work. This is a hindrance and will impede on progress. Instead, give your project a "codename", which could be just about anything. Many AAA game studios do this with their major projects before deciding on a name for their final product. Even non-game companies do this. Microsoft, for example, codenamed Windows 7 as "Vienna" and Windows 10 as "Threshold" before deciding to just go with simpler number naming schemes. You can worry about creating a good title once you have a feel for what your game is going to be about. Turn Off/Remove Initial Plugins Open up the Plugin Manager and either turn these off or remove them from your game completely. The Community_Basic plugin conflicts with a lot of the Yanfly Engine Plugins library and a lot of its functions are already recreated in the Core Engine plugin. The MadeWithMv plugin creates an unskippable splash screen that occurs each time you boot up the game, even for play-testing. It's a huge time waster. Use Your Maps as Directories The Five Maps When starting out, I recommend creating these maps for organization purposes. Debug To Do Work in Progress Finished Cutscenes You can name them whatever you want. I've seen some people name them as "Do, Doing, Done" and it still serves the same function. And what function is that? Read below: To Do, Work in Progress, Finished These maps will serve as directories for other maps in your game. Not only that, they give you an idea of what needs to be done, what is currently being worked on, and what is already finished. Let's take a look below. In the above image, the map listed under "To Do" means that the map still needs to be worked on. There's little to no work being done on it. In a project with multiple devs, this folder can be used to help devs figure out which maps need work on so the workflow can be distributed more thoroughly. Once you've decided to work on a specific map from the "To Do" list, drag it over to "Work in Progress". This way, you have an idea of what's currently being worked on and it will be harder to forget about that map in case you get sidetracked. This is also helpful in group projects with multiple devs, as it will give other devs an idea on which maps are currently being worked on and which maps still have to be done. Once a map is done or in the finishing stages, drag it from "Work in Progress" to "Finished". This will help remind you that these maps are finished and don't require much else work on them. You may still go back to them and change things around, of course. The rules aren't absolute as these folders are just here for organization purposes. In a group project, this tells other devs which maps are already done so they can start play testing them or focus on something else. By having a more visible understanding on where your map progress is, it's easier to determine what still needs to be done. Often at times, when devs finish a small "part" of their game, they end up with Choice Paralysis and could not figure out what to work on next. This "map directory" will help mitigate that by letting you know at all times what still needs to be done and worked on. Debug Room So what is the Debug map for? It's for a debug room. What's that, you might ask? A debug room is typically a map that only the game dev(s) can access. It's usually not the prettiest map, and it usually contains a bunch of events to help the dev in different ways. Such functions include the following: Quick navigation: The event will teleport the dev to a desired location. This can be a different town, start of a chapter, etc. Give items: The event will give the dev a bunch of items. This can be strong items, test items, etc. to help the dev quickly play test their game. Add party members: Add specific party members without having to go through their quest line, the game story, etc. Fight monsters: Have rare monsters? Make them easy to fight here. Have bosses to play test? Put them up here. Setting Flags: Enable or disable certain switches, change variables, alter various settings. So why is the debug room separate from the To Do, Work in Progress, and Finished maps? Well, there's a couple of reasons for that. The first is that this map normally is inaccessible from the main game itself and usually only a place you can access through test play (usually through setting the player's starting location at that specific point). The second reason is so that the map is quickly accessible, allowing the game dev(s) to quickly add the necessary events that need testing. Cutscenes So, why is the Cutscenes folder separate from all the rest and not on the playable maps themselves? A couple of reasons: Cutscenes are better off as separate maps. Why is that? Because inside a cutscene, there's often a mix of events, switches, move routes, etc. that can conflict with NPC's that are already existing on the playable maps themselves. By keeping them separate, you can have the cutscenes be produced in a more controlled environment, without having to worry about a stray "Auto" or "Parallel" event invade the cutscene itself. Less Switches. Making a cutscene on a playable map is going to involve the usage of more switches. Switches have to be turned on to trigger the cutscene, to disable them after they're done, and even more if there's special occurrences during the cutscene itself. If a cutscene is on a separate map, you can already forgo the trigger and disable switches. The switches pertaining special occurrences during the cutscenes themselves can be recycled switches (more on that in a later section). Easy Access for Revision. Sometimes, a revision in a part of the story can happen. It's a part of the writing process. When that happens, if a cutscene is attached to a playable map, a lot more changes have to be made to that playable map than if the cutscene was placed on a separate map. There's less intrusive unpredictable behavior when cutscenes are placed in separate maps. At worst case scenario, you could just scrap the whole cutscene and revise it, but scrapping a playable map just for a cutscene change is too much. Easier to Implement Replay Cutscene feature. Know how some modern RPG's have a "Replay Cutscene" feature? By keeping cutscenes on a separate map, it's easier to implement such a feature. If the cutscenes were a part of the playable maps themselves, you would have to turn off specific switches, make sure that certain triggers won't go off, and have to ensure that the cutscene recreated at that point is completely plausible as if it was made at that point in time during the gameplay. This is far harder to do with a playable map than a separate map dedicated to a cutscene instead. There's a drawback to using a separate map as a cutscene. That drawback is that if you make any changes to the original playable map the cutscene is based off of, you would have to implement the same changes onto the separate cutscene map itself. However, this drawback is a minuscule con compared to the various pros that having cutscenes as separate maps give you. Recycle Switches and Variables Instead of making switches and variables for every single thing, make them reusable. I personally reserve 20 of each to be reusable switches and variables although I don't even use more than half of that amount at times. I also recommend setting them as your first batch of switches and variables, making them the very first page of switches and variables that you see. So, what are the benefits of recycling switches and variables? Easier to Setup. If you keep them towards the front like what I suggested, you can easily pick and choose a switch or variable to change up. These are helpful for on-the-fly one-time-use conditional branches and/or script calls. Making completely new switches and variables for a one-time-use conditional branch is wasteful and makes things extremely disorganized rather fast. If you're using separate maps as cutscenes, then these switches and variables can all be recycled. Special occurrences like making specific NPC's appear/disappear, doors change, etc. in a cutscene can be done using these reusable switches/variables. Assuming that you reset them before and after each cutscene, these switches and variables should never conflict with one another in other cutscenes. Easy to Mass Reset. Reusable switches and variables are easier to mass reset. Making the above common event would let you instantly reset all the switch values to OFF and variables to 0. This is particularly helpful at the start and end of a one-time-use event or cutscene. Prototype Your Game The screenshot you're seeing above is a prototype of the Nintendo game: Splatoon. Not every aspect of your game has to be made as its finalized product from the get go. In fact, it's probably worse for you in the long run if you do that. In Progress This page is still a work in progress! There's more to come!