A starting point for new users (V1.2)

Discussion in 'RMVX Ace Tutorials' started by Andar, Jun 28, 2013.

  1. Andar

    Andar Veteran Veteran

    Likes Received:
    First Language:
    Primarily Uses:
    Hello and a welcome to all beginners in the RPGM-community

    EDIT: The forum update has destroyed the original links in this topic. I'll repair it when I have time, but unfortunately this may take a week or two...

    Note to RMMV users: While this tutorial was written for VX Ace, everything above scripting/plugin level is identical in RMMV and RMVXA. There are a few wording differences and you can't open VXA games with MV, but otherwise just work yourself through these tutorials.

    The purpose of this topic is to provide a starting point for all beginners by explaining how some things are handled in these forums, providing links to important topics and explaining those strange abbreviations you might read while making your game. This intentionally goes beyond RPGM/program handling and includes general points that any game developer has to keep in mind, and I'm more concerned with pointing into the correct direction than with creating complete link lists (which will change anyway when new games or tutorials become available).
    Let's start with a basic sentence:

    1) Creating games is fun and work.
    A lot of people stop reading that sentence at the word "fun", and there is no problem with that.
    For myself I developed several story/world settings knowing (before I put down the first word in the first notebook) that I'll never play in those worlds with anyone else - simply because it's fun to think out and develop new stories. However if you want others to play in your world and distribute it, then it takes more to create the game - that is where the "work" part becomes important.

    If you think you can purchase a RPG-Maker today, learn how to use it tomorrow, create your game next weekend and have it played by half the world next week: Please think again, because that is absolutely impossible.
    This topic intends to help you make your game as fast as possible, but no one can work miracles ;-)

    There is one more reason why I began this topic with comments on how much work creating a game can be:
    You don't have do put in all that work yourself.

    This community is one of the most helpful communities that exists - there are several request forums here where you can ask others to make pictures (sprites, logos, tileset,...) or scripts or events for you for free, and those request are often answered within a few days.
    But they cannot make your game for you - you need to show and prove that you put your own work into your game as well. If you do this, then the request are usually solved fast - otherwise they might be ignored. But more on that at a later point, we're still at the beginning.

    2) What is the first thing to do after installing the RPG-Maker (or better, even before that)?
    Download the sample game Crysalis (for VX Ace) or Knight Blade (for XP) and play it for a minimum of one or two hours. If you have not yet installed the full editor or the trial, you will need to install the RTP before you can play. The RTP is available at the download area as well.

    There is no official sample game for RMVX, but several can be found on the list of unencrypted games (link below)

    There are two reasons why you should do this.
    First, Crysalis uses the default VX Ace engine - no scripts have been added to the game. You can learn what is possible without big problems in RPGM-Games by playing this sample game.
    Second, that game still contains all project data and can be opened in the editor. If you want to know how something is done, you can open the Crysalis game in the editor and check all events and maps and how they work.

    Many other games are encrypted and can't be opened in the editor any longer, but there is a list of other unencrypted games that can be checked in the editor, allowing you to learn from them:

    3) Doing the tutorials
    There are a lot of tutorials available to help you to learn how to make your game.

    The most important advice about them is: Do not simply read them, but make your own project to completely do the tutorials.
    On one side of your computer's screen you open the RPG-Maker and start a new project "Tutorial", on the other side you open the browser or the PDF with the tutorial. And every step the tutorial talks about, you do for yourself in that tutorial project.
    Do not try to get away with simply reading the tutorial, because in a lot of cases that would be a waste of your time. There are a lot of tiny details that can't be explained or learned just by reading a tutorial, you have to see what happens if you use the tools or options described.
    If you have any problems with any tutorial, simply ask in the forum and someone will answer – but that only works with specific questions of where you’re stuck. Asking general questions without trying to work through the basics first usually becomes obvious fast, and it’s difficult to answer such general questions…

    The official tutorials cover most of the basics, and additional tutorials are also available on the blog:

    Unfortunately those tutorials don't cover everything, but you should still work through the parts one to nine as a minimum.

    <EDIT March 25th 2016: I should point out that the tutorial 3.5 with it's extra script is outdated as the community has found a way to add similiar effects without using scripts. You can read more about that in


    End of Edit>

    Additional tutorials have been made by several users on the forums. You can find them in the forum area, but I would like to point out several links and topics in that area as important:

    Do not be concerned about the fact that a lot of those tutorials are unconnected and only for very specific cases. There are a lot of different games that can be made by the RM engine, and you do not need to work through every tutorial. After you have gone through the basics, you only need a tutorial if you want that function in your game. If you do not want that, then you can ignore that specific tutorial.

    However, there is one thing I want to add to this part about working through the tutorials, and you really need to understand that.

    By my estimate (and confirmed by several users) it will take you about one month of time to work through these tutorials to get the basics.

    Of course that estimate depends on how many hours you can place into the tutorials each day and how much background in game development you already have from other programs, but it's absolutely impossible to understand the basics in one or two days or by simply reading through this.

    But taking this time will speed up your later game development. If you read on, you'll get to another estimate - the one about development time for a game. There I explain that on average, you'll need at minimum 100 hours of development for every hour of gameplay.

    This average assumes that you already have the basics and know what you're doing - if you try to make a game without that knowledge, the numbers will look very different. Most probably for each hour of gameplay developed without knowing how to use the program, you'll need 200 work hours of trial and error, plus another 400 hours of waiting for answers to your questions here on the forum.

    That last part is because we simply can't answer every question directly (especially if you don't know enough to give us the details we need) and because you'll be referred to the tutorials anyway in a lot of cases.

    Developing a game takes time - if you ever want to complete your game, then accept that you have to take that time, and that includes taking the time to learn the editor and the engine correctly instead of blindly bungling ahead.

    4) Explore the editor program
    RPG-Maker has a lot of options to help the game developer to make his game, but some of them aren't visible at first.
    As an example in the area of events (one of the most important aspects when implementing your story into the game), please do the following:

    Open the Editor, hit F6 to switch to eventing mode and double click anywhere on the map to open an event screen.
    Doubleclick into the content area to open the event command window and click on the button "control variables" (first page, left half, middle area) to open the "control variable" window.
    Most of that window should be obvious as it deals with mathematics on how to set or calculate a value. However there is one innocent looking line "Game Data" near the bottom. Click on the selector in front of it and then click on the dots to the right of that field ...
    A new window appears that has a lot of different selections and list on what part of the game's data you want to set into the variable for further operations.

    There are too many options and additional windows to explain everything in tutorials - especially since a lot of them are easy once you've seen them. You need to learn those options on your own.
    So, after you've done enough of the tutorials to be familiar with the basic options, go and use several hours simply for exploring the editor and experimenting with what you found.
    Make a new project to protect your other works and doubleclick and right-click on areas and lists to see what other options and windows might appear, click on menu options and database-tabs to see what can be set there and so on.
    Especially the right-click/context menu contains a lot of options like sample maps, quick events, find in scripts and so on.

    With a lot of possible problems just remembering that a certain option exists (and possible even where you found it) is half the way to the solution, and the few hours you spent exploring the program will help to speed up your later game development a lot.

    5) Do not make your first project your "dream game"
    Everyone has a learning curve, and your first maps and events will not be the best possible (which is a nice way of saying the first project has a high chance of being the worst you'll ever do ;-)).
    Your first questing event will probably involve a dozen switches and variables on two dozen event pages, and only one or two months later you'll look at it thinking "what a crap - with my current knowledge I could do the same with half the number of switches and only four or five event pages".
    It's a rare case that the first game project started ever sees the end as a finished game. Usually it's scrapped halfway and the developer (who learned a lot making that scrapped project) starts a new (and much better organized) game project.

    Your "dream game" is usually your best shot at getting a good game out, simply because you're pouring your best ideas into it. Risking that dream to be damaged by the frustration of scrapping the first project is usually a bad move.
    It's much better in the long term to admit that you have to learn something and that your first project will not be your best - so use a secondary idea for that first game and preserve your best idea, your "dream game", for a later project.

    6) Select what to do yourself and what to request/commission
    Maps, Quests, Events, NPC conversations, Art, Music, Scripts,... - a game has a lot of different components, and there is no way any one person can be competent in all of these areas.
    The first step of a game developer should be to decide what parts of the game he/she has the skills to do him/herself, what part might be available somewhere else (RTP, free resources, purchased packs from the shop) and what part he/she has to request or commission from others.
    When posting a request it's important to follow the forum rules for those requests and provide all information needed to do the request. Read the pinned rule topics as well as some past requests from others to learn how to post a good request - this will increase your chances of getting a result fast.

    However, a lot of the rules set for requests come down to one basic fact:
    Respect the worktime of those that fulfill the request.

    When requesting something, you basically ask someone else (usually an unknown someone) to do your work for your game for free.

    • That someone has to get food on the table - so any free work can only start after the bills are paid. Do not rush people with requests, there is a forum rule that you have to wait three days before bumping any topic.

    • The people doing request have limited time available - don't make them waste that time for something you could do to prepare the request.
      Don't ask for something "like game XY" and make them search the internet for a game that they never played - make a good description and provide links and pictures for the request wherever possible.

    • Structure your request - large walls of texts or descriptions that mix half a dozen different requests are bad in those cases.

    • And always look if the answer to your request might already exist - if there is something similiar available, you'll only be pointed there instead of having your request fulfilled. And if you need something else, it'll be easier for you to point to the existing resource and only describe what changes you need instead of making a new description...

    7) Remember that you are not the first (human, game developer, player, artist, scripter,...)
    In any large and old enough community all kind of general bugs and problems have occurred and been asked before. That is especially true for beginner's questions on RPGM.
    As a result it's usually faster and better to search for older questions than to post the question a fourth time and wait hours until someone answers.
    However, you have to know the best way to search for these answers - and an internet search like google is often the worst way for questions specific to the RPG-Makers. You'll find the answers on Google, but unless you do a very specific search those answers are buried beneath thousands of other answers containing the same words.
    It is better to use the forum's search engine (top left) for this, as all answers will be automatically about RPGM.
    But you need to use the regular nomenclature of the RM's to find those answers. Some of those abbreviations and words can be found farther down in this topic.

    Two additional links might help you when looking for something:
    a ) Master Script List: http://rmvxace.wikia.com/wiki/RPG_Maker_VX_Ace_Master_Script_List
    The master script list contains a lot of already completed scripts. Many of those scripts can simply be added to the script editor to provide that function, but some need to be configured and others might be incompatible to each other.
    The description in comments on top of the scripts usually explains how they are handled.
    Unfortunately, the master script list contains only VX Ace scripts - there is no such list for the other makers.

    b ) Resource Staff Releases: http://forums.rpgmakerweb.com/index.php?/topic/4683-restaff-release-index/
    Over the years, a lot of free resources (tiles, sprites, music, scripts) have been created and distributed by the forum staff. You can find those resource collections at the linked index.
    However, please check the Terms-of-use included - you need to credit the contributers anyway, and some of them made those resources only for free games, requiring payment if you want to use them in commercial games.

    8) T.E.A.M. – what does this mean?
    At several points I already mentioned that you don’t have to do all the work for yourself, you can request help with the things you don’t know or can’t do yourself. And one of the most effective ways to reduce the workload might be to gather a team of people to work on the project.
    However, there is a german saying that is – unfortunately – not entirely joking about this.
    It goes “T.E.A.M. is short for Toll, Ein Anderer Macht’s”. That can be translated as “Great, Somebody Else Works”…

    Your project won’t get far if you don’t work yourself on it – if it is your idea, then you need to proof to others that you can work on it before they approach you to help. That is because no helper wants his/her worktime wasted on a project that is advertised big and then crumbles because the lead designer doesn’t work on it himself/herself.

    That is why we suggest that any recruitment topic needs to show work examples and what has been done before the recruitment started. And basically it’s the same behind any request: All requests should be teamwork, with the artist/scripter working on the requested part and YOU working on the description of what you need for your game. That is why short, general and unspecific requests usually aren’t worked on, but good and complete description get the request fulfilled fast.

    The more work you put into your project, the better are your chances of finding help or getting requests fulfilled. Requesting a lot of help without having something to show from yourself will not get you far, because you are (and have to be) the main developer (and main worker) on your own project.

    In my personal opinion you should expect to do at minimum half the total work on your project for yourself and expect all random helper to do no more than 10% of the work per person (unless you’re well-known and already have personal friends willing to help). More often the random helper can’t do more than 1% of the work of your project for free.
    That changes of course if you are able to pay people to do the work – if you’re willing to pay, you’ll get a lot of good people to work a lot on your game, as long as you can pay them reasonable rates. But game development that way often costs several thousand dollars per game.

    9) Decide early if you want to go commercial or not
    From a developer’s point of view the difference between commercial and non-commercial are the licences needed for the resources. Some of the resources available on the internet are free for both commercial and non-commercial uses, but a lot are not – they either require payment for commercial use or are ripped and cannot be used at all. You’ll need full documentation on what you used and what you have to pay or provide (some artists ask only for a free copy as compensation).
    Getting this organized is only possible if you keep your documentation correct from the beginning – it’s three or four times as much work if you collected resources without documentation and then need to retrace your steps for the specific resources you used.
    For that reason it’s easier to change from commercial plans to free than the other way around. So if you're in doubt, better prepare everything in the way for a commercial release - if that is too much additional work and cost, you'll know why you'll decide to go free later...

    10) Requirements for going commercial
    This forum contains an area for commercial discussions where you can read tutorials about going commercial and ask your own questions.
    Please read all topics there if you want more info.

    However, there is a very short list of requirements that you cannot skip when trying to go commercial:

    a - Experience
    Please ask yourself a question: "Is this my first game project?"
    If the answer is yes, then scrap any idea of going commercial (see also point 5 about the "dream game"). You may still keep your documentation for a later game, but the first one should not be commercial.
    To have any chance of even minimal success at selling a game, that game needs a minimum quality that is impossible to achieve if you're still learning how to use RM.
    Make one complete game (can be small one, no need for an epos) including bughunting before even considering going commercial, because only after completing the bughunt you'll know what kind of work you have to expect for a commercial game.

    b - Minimum seed money ($100 to $200)
    This isn't about a shopping spree for resources or similiar things - it's about keeping you out of prison.
    Almost all countries require a business licence and tax sheets before you are allowed to sell or work commercially, and that licence costs money. Additionally you'll need entry fees for getting to special sale platforms like Steam Greenlight or to host your own website for that game you want to sell.
    If you do not have the money to pay for that, then you simply can't go commercial without risking a lot of trouble depending on your countries laws. And really? It usually takes one or two years of development time to complete your game. If you cannot scrape together those fees in that time, then you don't have any chance of going commercial...
    Save your next birthday money, ask if you can do some work in your neighbourhood or simply work three or four days as a minimum wage helper at a company - all that should go far towards those fees you have to pay, because you only need to make that payment before selling anything and not when you start game development.

    c - keep all credits and terms-of-service for whatever you use
    Organise the art, music and scripts you're about to use in a way that you can always find the original source and artist.
    Make Screenshots of the artist page for the licenses and terms-of-service. And I'm talking about screenshots here that you'll never edit, because texts can be easily changed - sometimes the artist may change the terms of service, and then you'll need the original to solve problems.
    NEVER use any ripped resource - if an artist is even suspected of having ripped and edited other material, you cannot use that material.

    d - work efficienty
    Sometimes I read about users searching weeks for a free script or workarounds because the existing and perfectly fitting other script requires a commercial fee of 20$. That is your decision of course, but also consider this:
    Do you want to waste fifty working hours of your time for a suboptimal solution if you working somewhere else for minimum wage for five hours will get you the money to pay for that licence and more?
    Working commercially is not only about getting money at the end - it's also about thinking how to work efficiently. A lot depends on what you can do in your country, and how much "seed money" from point b above you can get. But you won't get far with either your game or your commercial plans if you can't concentrate on the best way to solve a problem. And discarding a game mechanism because the script for it is too expensive is a valid solution if the alternative requires you to waste much time on suboptimal results.

    Aside from those requirements, here are a few points to consider for your game when going commercial:

    You'll need a "selling point" to get your game to players.
    This might be a good story - but to convince someone your story is good needs a lot of examples (demos or previous games). It's much better if you have something else as an additional selling point.
    That "something else" is often a custom graphics set - but unless you're an artist yourself, you'll need to pay an artist to provide you with the artwork. You don't need a complete set, but it has to be enough artwork to make a difference compared to pure RTP. The main reason for this is to show potential customers that you put something behind your game - either worktime or money for other artists.
    If you're using only free resources you'll have it more difficult to convince others to pay for your game, especially since there are a lot of free games using RTP only...

    A titanic list of features is usually the surest way to go titanic (down to the bottom of the sea) with your game.
    First, because a big list of features also needs a lot of work to implement - a half-finished game helps no one.
    Second, because it's a lot more difficult to integrate and balance a large feature list - a bug-infested game destroys your credibility and if it's your first commercial game it needs to be as bug-free as possible if you want to sell it. It's much better to use complementing features that make a good game fit.

    Plan your game!
    Heading on to make the first maps and story segments before you know how to end the story usually creates a lot of problems. You can only do this and have a good result if you have some experience in creating games - it won't work that way if this is your first game.

    11) Where/How to start a project
    Any project needs to have a lot of components done before it can be tested, and most people want to be able to test their project as soon as possible, just to see the results of what they had done so far.
    Luckily the defaults on a new project contain everything needed to make a game playable, from predefined Actors, Classes, Enemies and Items in the database to quick generation events (Right-Click on the map) and sample maps (Right-click in the map window). Probably the only thing missing for a quick setup of a game is a story, and that you usually have before buying RM (otherwise you probably wouldn't be interested in it).

    Do not delete those defaults until you have something to replace them with - you can't do balance testing of your game with the default data, but you can try to test single game components with them - you need an actor for the party if you want to go around your first map for example, so you should not erase the default actors until you can replace them with your stories' characters.

    What part of your project to start with depends a lot on what you want, so you should think about your story and its structure first. Depending on your story concept, there are three things that might be chosen as a project start: Storywriting, Mapping OR Scripting. Each of that has its own advantages and disadvantages.

    If you plan a complex, multi-branching story instead of a simple linear story, then you should probably close the RM-Editor and write down a flowchart of your storyflow with all branching and secondary stories first. This is especially important if you plan to recollect storylines into a few endings later - if you simply branch and never touch the other storybranches again, then you don't need much pre-planning and can start with mapping the first maps.

    If you plan to add features that require a lot of scripts to implement, then you should start with getting those scripts implemented and working together, using sample maps and default actors/enemies to test the script functions. That is because changing scripts requires you to start a new game - if you add a new script later in the game, you invalidate all testing saves and have to play from the beginning to test other things (like combat balances) again.
    And you don't want to plan for a script if you don't know that it will work.

    If neither the story nor the scripting require much planning, your best option is to start with the maps for your game, as this is the most important part of the work, which will be seen by the player most of the times - and creating new tilesets or specific map effects requires experience and experimenting.

    After that, follow the flow of your story to implement structures - it doesn't help to have the map for the last boss ready if your actor's can't go there to test it for several month of other work.

    12) How big to plan your project
    If it is your first real project, plan it small - one or two playing hours are enough for starters.

    That has a lot of reasons, not only that your first real project (after your scrapped learning project, see point 5 about "dream games") will be for gaining experience - it also needs to be completed if you want to have a good chance of continue working.

    The best cure for demotivation or other similiar problems is if you can point yourself to a completed project - "see, I have finished something". If you continue to scrap or abandon project, that will cause damage to your future motivation. In the long term it's much better if you make your second project as something that you can finish. That will be a lot more than 90% of the hobby developers will ever achieve, and it will also give you a reference for future project (especially if you do want to go commercial). Because if you can point people to a completed free game when trying to sell your first commercial game, it'll give you a lot better chances as if you tell them "this is my first ever made game, please purchase it".

    Additionally this will give you a much better picture of the scale needed for games.
    Search around the forum - every three or four months there is someone asking "how to exceed the 500x500 tile limit on maps" or "how to make more than 999 maps in a game". And in all those cases, the person asking usually has only a few posts because it's a newby who lacks that experience about how much content a game really needs.

    Here are two ways for you to understand what we're talking about:

    a - development time to playing time (~100x)
    You can consider for your calculations that every hour of playing time needs one hundred hours of development time. Of course this is only a very rough average that depends on what exactly your game is about, how much experience you have in game development and much more. For complex games this can easily exceed 300 working hours for the first playing hour, or if you use randomized maps then it may drop to let's say fifty hours work for a single playing hour.

    But read the rules for the IGMC: http://blog.gamedevfort.com/indie-game-maker-contest-rules-and-dates/
    The contestants have one month to make their game, and they should keep it at one hour play time for the judges.

    Those numbers weren't chosen at random, even if there are other reasons than just the development times. But no one expects a single developer to get more than one hour of playing time together in one month of development, especially if the contestant is not a full-time game developer but needs to work for his food at the same time. Full time working is considered 40 hours a week, which means that fulltime one month is 160 working hours for a single person. And they know that a lot of contestants will only be able to work part-time on the game and expect around one hour of playing time after that month...

    b - walking on a large map
    Please make the following test:
    Open RM Ace (Lite if you don't own Ace) with a new project, right-click on the map list bottom left and select "Load Sample Map".
    Select "Field 1" (OK), then right-click on one of the snow beaches to place the player starting position there, and rightclick to place the ship starting position on the ocean next to it (no cheating by using airship).
    Then playtest and travel around every continent and area of that sample map.

    That sample-map is 140x140 - how much time did you need to really travel around everywhere? Without distracting enemy encounters, without towns to explore and with the ship already available?
    A maximum map is twelve times as much tiles, so it will need twelve times as much wandering time - not to mention 12x as much mapping for the main map only, and you'll want a lot of towns and dungeons to fill that map...

    So - start small, get your first experience - and then ask us again if you really need more maps and bigger maps. There are solutions that allow to bypass those limits, but we don't bother to point newbies to them because they won't need them anyway.
    Most commercial RM games have less than 300 maps and most of those maps are less than 100x100 in size.

    13) How to make cutscenes
    There are a lot of tutorials to tell you how to make the components of a cutscene - how to move NPC-Events, how to control the player, how to select actors for messages and more.

    I won't repeat that here - but I will talk about the most important mistake in making cutscenes: spreading the commands is the shortest way to failure whenever you try to make a cutscene.

    In any motion picture there is only one director telling the actor what to do - and it should be the same for a cutscene in RM: you have ONE event controlling the cutscene, the rest of the events should not have any content/command in them.
    That way you can be sure what will happen at any point in the cutscene, without wasting effort on coordinating autonomous movement by dozens of events.

    There is a blog that explains it in a bit more details:

    14) Backup, Backup and Backup … Did I mention backups already?
    When Windows crashes while you’re working on your game project, there is a high chance of your project files becoming damaged. That has nothing to do with RPG Maker, it’s simply a technical result of how computers work, and it can’t be prevented.
    As a result every other month or so we’ll see a desperate post on the forums “how can I repair my game project”. There are a few things you can try to do when that happens, but very often some part of the work is lost as a result – sometimes many months of work if the user had no backups.
    You can do backups manually by copying the project folder, but there are also scripts that automatically backup every time you start a playtest of your game. If you’re using one of the following backup scripts (choose one of them you like best), remember to remove that script before you distribute the finished game:

    15) To script or not to script
    Basically you can say that you should use as few scripts as possible but as much scripts as necessary.
    Scripts are there to add functions that are missing in the default engine of the RPG Makers. But that exactly is a key that a lot of users do not understand: They ADD – but the RPGMaker does NOT NEED scripts to make a game.
    And scripting (especially if you’re adding a lot of scripts) can add a lot of bugs and problems into your game if you don’t know how to read and use scripts. And that is something not everyone can do, because what is called scripting in the RM Community is in reality full capacity programming in Ruby.
    If you’re new to the makers, try to make your first project without scripts – the sample game Crysalis is a perfect example to show what can be done without scripting. Only after you know the basics you can start selecting some scripts that will help you make a better game.
    The master script list was one of the first links given in this tutorial (several points above). Go there to check and choose if you want to add an existing script.
    Always read the script instructions at the beginning of the script, and always check the script for configuration options that you need to specify for the script to work. This is especially the case when the script uses game variables to be controlled from your game events – if that is the case, always check if the configured game variables are still unused (if not, change the variable number) and if they are unused, reserve the variable by naming it in the event commands.
    And remember: if that script is from one of the well-known scripters and had been used by thousands of other developers, then it usually is bug free and almost all problems with it are either compatibility problems with another script you’re using or because you didn’t configure or enter the commands correctly.

    For those who wish to learn more about using scripts, I wrote another tutorial for that:

    16) Bug Hunting
    When you work on your game, then sooner or later you will encounter problems and bugs. That is completely normal, as well as you coming here to make a topic about your problem, asking for help.
    And this is a very helpful community, we all really want to help you to make your game - but you have to allow us to help you, and that's where some of the real problems start...

    The rules about this forum aren't there to make your life difficult, they're there to help get everything sorted out as fast as possible.
    We neither have a magic crystal to allow us to see what is on your computer's screen, nor can we read your mind. That is why we are asking for detailed descriptions and screenshots.
    I know, I know, it's unreasonable - but we have problems with mail ordering magic crystals - if you can get us one, then we might be able to help you without screenshots. Perhaps you can get us in contact with Wizard's R US?

    OK - joking aside

    When you have a problem and can't solve it yourself, that is usually because it's in an area that you don't know about. Because if you would know about it, you would be able to solve it yourself most of the time.
    But when you only make short descriptions, you keep them to the areas you know - which usually results in that you tell us what you have done correctly, but not about the areas where the bug is located.
    A screenshot is the fastest way to show us everything, including the settings you don't understand yet - which is where the bug is located in 80% of all cases.

    Similiar reasons are for scripts - we are asking for LINKs to the original pages where you got the script, because that's where most of the other users have reported their problems, might have seen patches and where additional manuals and descriptions are located.
    Copying the script into this forum will usually only bloat up your posts and rarely help, it should only be done if the specific script configuration is important (like in quest systems where you have to add a lot of data into the script) or if the original page is no longer active on the internet.
    And if you link, please link to the script's description page if possible - the downloadlinks for the scripts themselves are usually not sufficient for the additional info.

    17) Where to continue?
    As said in the title, this is a starting point for your learning. If you worked through the tutorials listed above, you have everything needed to make a regular game project with RPG Maker.
    However, one of the strong points of the RMs is their versatility - XP, VX and VX Ace use Ruby-Scripting to allow the user to replace most of the game engine with his or her own programming (called scripting in this community), and the next RPG Maker MV will use Javascript and allow replacing of everything (no more blocked parts).

    But to go into scripting or use the other, more advanced options and tricks, you'll have to continue learning how to use the programs. That cannot be handled in any single tutorial.

    In the two posts below you'll find some additional info and tricks about the RM series and especially Ace, but for further tutorials I made a site-blog where I post links to forum tutorials and smaller articles that don't deserve their own tutorials:

    Andar's Tutorials, Tips and Links

    This tutorial is now complete - for further help follow the blog
    However, I will continue updating the descriptions in the two posts below
    Last edited: Feb 3, 2017
  2. Andar

    Andar Veteran Veteran

    Likes Received:
    First Language:
    Primarily Uses:
    Terms and Explanations within RPG Maker Programs

    Program abbreviations:

    RPGM, RM: Short for RPG-Makers, all versions (XP, VX, VX Ace)

    RM2K: RPG Maker 2000 (very old version recently translated due to user demand)

    RM2K3: RPG-Maker 2003 (very old version recently translated due to user demand)
    RMXP: RPG-Maker XP (oldest version)
    RMVX: RPG-Maker VX (second version)
    RMVXA: RPG-Maker VX Ace (newest version)

    RMMV: RPG-Maker MV (next maker, should be available winter 2015 according to latest info - no exact date given)

    GCH: Game Character Hub, an independent editor for Faces and Sprites usable in the RM series

    RM95: An old PC RPG Maker that has no legal English version (only pirated translations) and is not supported by Degica or on these boards
    IGM: Indie Game Maker, a program distributed by Degica that has nothing to do with the RM series

    GGM: Good Game Maker, a program distributed by Degica that has nothing to do with the RM series
    MM: Manga Maker, a comic creation program distributed by Degica that again has nothing to do with RM

    Patches for older RPG Makers (RM2K3 currently, probably RM2K later): Because the older RMs have no scripting system, the only way to add new functions is by reverse-engineering the program and patching it. This process is breaking the original EULA, but has been done with the pirated versions for decades. A new Patch-EULA gives limited legality to people using or making those patches, but any use of any patch voids access to official support because Degica Support cannot know what the patches do.

    RTP: Short for Run-Time-Package - can be downloaded for each maker separately and contains all resources (graphic, audio, animations) included with that maker. Is sometimes needed to run games made with that maker on a computer without the maker.

    Battle System Types:

    FBS: Front View Battle System (default for Ace)
    FTB: Free Turn Battle
    CTB: Charge Turn Battle
    ATB: Active Time Battle
    ABS: Action Battle system (real time on-maps)
    TBS: Tactical Battle System (turn based on maps)
    SBS: Sideview Battle System

    Developing/editor descriptions:

    These are the skills to create the maps in the editor - usually static maps, since all changes and most animations require events.

    The use of events to create dynamic maps and quests, NPCs, Map-functions and more.
    Events use a limited set of commands that can't be changed - what is called eventing in RMs is often called scripting in many other game makers, but in RM this term is restricted to the use of the existing event commands.
    There are Map-event (placed on the map in eventmode F6), Common Events (in the database, Common Event Tab, runnning on all maps) and Battle Events (in the database, Troops Tab, running only during battles with that specific troop).

    Script Calls
    This is a limited form of scripting using script call command in events, the damage formula field in skill definitions or as a script line in control variables/conditional branches.
    This is mostly a form of accessing data that isn't available otherwise or calling up true scripting functions.

    Creating and using full scripts in the script editor - this is a full programming language and not a simple form like eventing or what a lot of other games call scripting.
    You can completely reprogram RM using scripting, and there are some scripts on the master script list that can be used to turn RM into a system for action games, tactical games and more - even a lot of different minigames are available because of this.
    Scripting usually provides additional abilities to the RM engine, and those abilities are called and configured by either notetags or script calls or settings in the scripts themselves.

    Notebox and Notetags
    When you go to the database pages, you'll see that a lot of the pages have a box called "Note" somewhere in the lower right area. This box was originally intended for developer notes what to do with that specific object - similiar to the notes automatically placed there for Skills #1 and #2.
    However, because this box can easily be read by scripts it also has been used to transfer data to scripts. This script data is commonly known as "Notetags".
    Because the notebox has absolutely no function without scripts, there are no rules on how notetags should look like and what they might be used for. When you add a script, you need to check that script on what it requires to be used as notetags, and different scripters and different scripts can use different structures as notetags.

    Mapping Terms:

    Shift-click-Mapping: Autotiles will be copied and placed in different ways if you hold the shift button while copying or placing - four different behaviours are created this way.

    Parallax-Mapping: An advanced form of mapping where the map is made as a background picture in GIMP or Photoshop or similiar programs, and then the editor is only used to set passability by adding invisible tiles above that background. The results usually look much better than regular mapping, but it is also a lot more work and should only be tried after some experience is gained with regular mapping.

    Overlay Mapping: Similar to parallax mapping, the maps for overlay mapping are usually created outside of the editor by image programs. But while parallax mapping usually needs only two layers (below and above player), the overlay mapping adds layers for shadows, for lights and sometimes even additional map layers to simulate height.
    Last edited by a moderator: Aug 17, 2015
  3. Andar

    Andar Veteran Veteran

    Likes Received:
    First Language:
    Primarily Uses:
    Important tips and tricks


    1) Checking Tileset Tile B for passability

    2) Erase Event is only temporary

    3) Sprite format, $ and ! in sprite-filenames

    4) Moving Events

    5) Control Variable is more than a simple way to set a variable

    6) There are different types of tileset resources

    7) A4 Wall Passability: the two-level-dungeon on a single map

    8) Boat and Ship: Special (and inverse) Passability

    9) Antilag scripts stop events

    10) Always NAME your switches and variables

    This list will not contain any number of tricks, but only those who are really important to know. If it gets longer than 10 tips, I'll start deleting the less important ones to make sure that the list stays small.

    1) Checking Tileset Tile B for passability

    If you have any problems with passing on a map made with your own tileset, you'll have to check the passability of the tiles in the database.

    But what isn't said in the help file is that there is one special setting for the first tile on the Tile-B-set:

    That first tile always needs to be empty (no picture), and it needs to be set to "Star" passability.

    If that is not the case, then all other passabilities on that tileset will be broken or have other problems.

    2) Erase Event is only temporary

    That command is badly named because it will erase the event only until the map is reloaded. When the player reenters the map, the event will run again.

    If you want to disable an event, set it to an empty page conditioned to one of the self-switches. The command to turn on the self switch has to be in the line where the erase event was planned.

    One correct use of "erase event" would be an autorun map event that sets or updates some map data (like time, tints or so) whenever the player enters the map.

    3) Sprite format, $ and ! in sprite-filenames

    VXA accepts any picturesize as a sprite file and calculates the resulting sprite based on a few assumptions. If you do not know that, the resulting sprite will not fit into the game.

    A single sprite picture needs 12 cells with the sprite - four rows high (the four directions) and three columns wide (for a 3-frame-animation).

    The regular sprite file is assumed to have eight sprites in it - two lines of four sprites each. You can see an example if you select the graphic of an event within the editor and then select any line without $ or ! in the name - Actor1 for example.

    When you import such a picture, VXA will assume that a single sprite-size is 1/12th the width and 1/8th the height of the imported picture.

    To change that, the $ sign can be added in the front of the filename. An example from the RTP would be $BigMonster1, which contains only a single sprite group of 12 monster pictures. You can also see that this sprite contains four different monsters instead of a single monster from four sides - if you use such a sprite in an event, make sure to check "directional fix" to prevent the graphic from changing depending on which direction the event turns.

    If the $ is in fron of the file name, the spritesize will be calculated as 1/3rd the width and 1/4th the height of the imported picture.

    You can also see some sprites that have a ! in front of them, for example the door-sprites.

    That doesn't effect the spritesize, but the display of the sprite. Regular sprites are moved 4 pixels up to appear to be walking in the middle of a tile.

    This is disabled by the ! in front of the filename - a door should always go to the bottom of the tile, not end with a opening at the lowest part.

    4) Moving Events

    When moving events, you should use autonomous movement whenever possible.

    Placing move route commands in the content of a parallel process page of an event should only be done in special cases where it's absolutely neccessary to combine the move with other commands, as this will increase the lag of the map.

    Any Movement that does not require player interaction or coordination with other events should be done with the options under "autonomous movement", an area to the right of the sprite graphic and the left of the content/command area.

    This area contains option for random movement as well as custom move routes, and they're automatically on a form of parallel process that is a lot more effective than a move route on parallel process.

    5) Control Variable is more than a simple way to set a variable

    The event command "Control Variables..." (first page, left side, middle block) is commonly used to set a variable for quest control - for example the chapter number or the number of people visited. However that is only a tiny part of this really powerfull command.

    It's also the randomizer of RM (control variable : random : number-range) and can be used to read data from all parts of the engine (control variable : script), or it can be used to access a lot of different game data.

    To use any of the more advanced options, you usually have to make it a two-step-conditional branch.

    The first step would be control variable to the data you want to check - for example Control Variable : Game Data : Actor : Level

    The second step would be a conditional branch on that variable - for example Conditional Branch : Variable : Greater than : Value

    The example used together would be a way to check that the player can only pass if the actor's level is beyond a minimum number to make sure that he doesn't fails on the first random encounter beyond that door. It could also be used to check for current HP and trigger healing or how many pieces of a specific item are in inventory (without the variable, the conditional branch can only check for 1 or more).

    6) There are different types of Tileset Resources (VX Ace)

    When you go to the tileset tab in the database of VX Ace, you'll see a number of slots for tileset resources/pictures on the left side.

    The naming and sorting of those slots is NOT random or for random use - if you put a tileset picture into the wrong slot, then the results will be less than satisfactory...

    In the first group, the A stands for Autotile. There are five different forms of autotile pictures, and each picture can only be used in the correct slot type. In most cases that slot-type (one of A1, A2, A3, A4 or A5) is indicated as part of the file name. You might also see pictures for Autotile-slots that are missing some of those tiles - that is because even within a slot, the exact position of the tile changes its function. The entire file definition can be found in the help file.

    The second group with the slots B to E is intended for regular tiles. These slots are interchangable, it doesn't matter if a regular tile picture is placed in slot B or in slot D.

    The following guide helpt with importing tilesets into your projects:


    7) A4 Wall Passability: the two-level-dungeon on a single map

    If you go into the database to the tileset definitions, you'll see that it's impossible to set directional passability for those "walls", and that there are in effect two different forms of wall-tiles in there: the top wall and the side wall.

    The reason for this is a special passability programmed in to allow the game to simulate a two-level-dungeon within a single map - misunderstanding that is one of the possible reasons for "my player walks on walls" - the other reason is described in tip #1 (star passability on B1).

    When you map any area with the top wall tiles of A4, then the directional passability is set in a way that the player can move on those tiles - but not leave them to get to regular ground floor tiles from A1 or A2. That way you can map a labyrinth where the player can either move on A1/2 ground tiles ("Level 1") or on A4 Top-wall-tiles ("level 2"), but not move from the one type to the other.

    To move between those levels, the developer needs to override the A4-passability - usually by placing one of the "ladder"-Tiles from B on top of a sidewall-tile. That's what those tiles are intended for (in the default, interior and dungeon tilesets have them at top, next to the stair tiles): to provide the player with a hint where he can "climb" to the top of those walls.

    However, no program is perfect - and the editor can't know if you're placing an overriding tile to intentionally allow the player to move on the topwall, or if you accidentially place it without knowing that the player can use it to move on top of the walls. So if you suddenly find out that the player can move on a wall he isn't intended to be able, then you have to look where on the map such a movement override was placed (usually B-tiles to be placed on walls should be set to non-passable, only B-Tiles to be placed on the floor need passability). An override is either a passable B-Tile on the sidewall (like a latter) or a passable tile on the edge of the top-wall (overriding the directional non-passability with a general passability, like a flower at the edge of a cliff)

    But if you know how to use that level-2-passability, you can not only use it for better mazes but also to create places for NPCs where the player can't get to and those NPCs can't leave even when set to random movement - or a few other special uses depending on your game's story.

    8) Boat and Ship: Special (and inverse) Passability

    Boat and Ship have a special form of passability, that does not conform to what you're using for regular player passability. Some of that passability is described in the resource standard in the help file, but unfortunately not everything.

    Basically Boat and Ship can only move on some of the tiles in the A1 Tilesheet, but not on everyone - the animated obstacles like the waterfalls or water cliffs are impassable to boats and ships. Additionally, the deep water tile (tile 2) is only passable to the ship, not for the boat.

    However, there is one additional restriction not mentioned in that part of the help file: The water tile needs to be IMPASSABLE to the player for the boat and ship to move through it.

    Just think of it this way: if the water is shallow enough to let the player walk through it, then it is too shallow to allow a ship or boat to travel through it.

    9) Antilag scripts stop events

    One of the problems of the RM engine is that a large number of events can cause a lot of lag, especially if these events contain poorly designed parallel processes. To help solving those problems some users have written so-called antilag scripts to speed up game processing.

    However, using them without knowing what they do often causes more bugs than are solved.

    First, unless you know exactly what you’re doing, don’t use multiple antilag-scripts. In 99% of all cases this will not help at all.

    Second, most antilag scripts reduce processing time by stopping events from being processed. This usually means that any event farther away than a set distance is being stopped, usually when the player won’t see it anyway.

    This will create problems if that specific event is needed for the map to function (puzzle events for example), or if the player increased the screen size without increasing the stop distance. But that is why the better antilag-scripts allow for exceptions by comments or configuration.

    Please make sure that you understand how to configure the antilag and how to set exceptions for vital events, and only use antilag scripts AFTER you detect lag, not as an unnecessary precaution.

    It’s a lot better to prevent lag by making sure that there is only the minimum needed on parallel processes and that those parallel process events are correctly written with a good number of wait frames.

    10) Always NAME your switches and variables

    When you open the control switches and/or the control variable event command window, there is a button with dots on the switch/variable selection part that will take you to the list of switches or variables of your game project.

    This list not only shows the numbers of the switches and variables (those are used internally for identification), but it also has a name field where you can place a name for any variable or switch.

    These names are NOT used anywhere in the game, but they are displayed in the editor wherever a switch or variable is used.

    As soon as you use a variable or a switch, name them there – and give them a name that will tell you exactly what you plan to use that for. That way if you see a variable with a name you’ll know what it is intended for, and if it has no name then you’ll know that it hasn’t been used before.

    The reason for this is that nothing is as difficult to find as a bug as something that is caused by a double used variable – and that can happen faster than you think, because the control commands are not the only parts where switches and variables are used.

    Whenever you add a script, read through its configuration and setup parts to check if it uses switches and/or variables. If yes, change the default numbers to variables and switches that are still unused in your game, and name them at once to prevent later use of those variables and switches in other game parts.

    Regularly check the common events if you defined a switch for activating a parallel process or autorun event. By default these special events are triggered by switch #1, which is why you might keep that switch unused through your game.
    Last edited by a moderator: Jun 19, 2015
  4. Silent Darkness

    Silent Darkness Robomage Veteran

    Likes Received:
    Dark Realms
    First Language:
    @Andar The link to Chrysalis seems to be throwing a 404.
    Last edited by a moderator: Nov 30, 2013
    Seriel likes this.
  5. Andar

    Andar Veteran Veteran

    Likes Received:
    First Language:
    Primarily Uses:
    Corrected - the links to sample games were on the previous site's structure, now there is a single link to both official sample games.
    Nightblade50 likes this.
  6. 100LittleDreams

    100LittleDreams HueHue Veteran

    Likes Received:
    First Language:
    Is there anyway to change the overall battle system type?
  7. Andar

    Andar Veteran Veteran

    Likes Received:
    First Language:
    Primarily Uses:
    Please start a new topic for your questions, do not post them on random other topics
    You can change anything in the game with scripts, and there are about a dozen different battlescrips available on the master script list (which is also linked in the tutorial above)
  8. 100LittleDreams

    100LittleDreams HueHue Veteran

    Likes Received:
    First Language:
    Sorry I am new to these forums so I didn't know. I'll make sure to post questions in a topic. But thank you for replying.
    Ronpa likes this.
  9. Secretplot45

    Secretplot45 Warper Member

    Likes Received:
    First Language:
    Thanks for this info :)
  10. CrypticCuddler

    CrypticCuddler Free Hugs Member

    Likes Received:
    First Language:
    *bows* THANK YOU! This information is just what the doctor ordered! Thank you very much for taking the time to compose and post this information for us floundering newbies.
    Engr. Adiktuzmiko likes this.
  11. Engr. Adiktuzmiko

    Engr. Adiktuzmiko Chemical Engineer, Game Developer, Using BlinkBoy' Veteran

    Likes Received:
    First Language:
    Since I was a little bored while waiting for work to finish, I decided to read it up... really nice work man... XD
  12. Dandydan

    Dandydan Veteran Veteran

    Likes Received:
    Somewhere out there beneath the pale moonlight
    First Language:
    Thanks for this post because as a newbie I dislike jumping into any project. Rather, I need to see the big picture first. Your post helps me in some respects (I am attracted to the idea of saving one's best ideas for down the road) but does not in other respects.

    First, I find myself overwhelmed with jargon. Sometimes Google is useful and sometimes it is not. For example, I keep reading about "parallax" gaming but even after Googling the term I still don't understand how it applies to RPG Maker. So one thing I sorely need is a good dictionary so I can comprehend the lingo.

    The second issue I am having is one of integration. So much of what is presented in this forum is disconnected blobs to me. Most of the tutorials are designed for the inexperienced to get a feel for RPG Ace as a tool. So they are mostly step-by-step guides. I feel, however, that they are guides leading me down a road that goes nowhere. There is little effort made to discuss how all the parts fit together abstractly. Another way to express this is to say that there is a great emphasis on /how/ to do things without really helping the new person understand what is going on behind the scenes. So I find myself wandering from detail to detail without any understanding on the bigger picture.
    Last edited by a moderator: Jan 15, 2014
  13. Andar

    Andar Veteran Veteran

    Likes Received:
    First Language:
    Primarily Uses:
    Google is a very bad search engine for small, specific areas like RM - you're better off with using the search engine of this forum, as that automatically filters out any use of a word that is not RM-jargon.
    In this specific case, it's parallax mapping, not parallax gaming - and that is an advanced mapping technique that basically creates the maps outside the editor (by GIMP or Photoshop) and uses the editor only to set game-relevant map data later. In my opinion you need to know how regular mapping works before you can start with parallax mapping, and then you'll need about three or four times as many work to make a parallax map compared to a normal map (the parallax map will probably look better, but it is a lot more work)

    There is no way around that, because there are too many different games. Each of the "disconnected blobs" is probably used in less than 20% of all games, and it's the decision of the game maker to see if that mechanism is wanted in that specific game or not.
    We cannot tell you what to include in your game - and only after you made that decision it's even possible to look for which parts and tutorials you'll need.

    For example, some users are making a harvest moon-type farming game and there are a lot of tutorials and questions on how to do that - if you're planning on a diablo-type action RPG, then those tutorials won't help you but you need to look up on the tutorials for one of the action-battle-systems to make on-map-battles.
  14. deadahead

    deadahead Villager Member

    Likes Received:
    Williamsburg, VA
    First Language:
    When will the part 10 tutorial be posted? I am really enjoying them.
  15. Andar

    Andar Veteran Veteran

    Likes Received:
    First Language:
    Primarily Uses:
    I don't know - the official tutorials are handled by Degica Staff, the tutorials on the forum (like this one) are by users.
  16. Caustic

    Caustic Hopped Up on Goofballs Member

    Likes Received:
    Right behind you
    First Language:
    *sees point #5*

    But-- but-- but...... I've already started on my "dream project" T-T *angst*

    Oh well, that plot isn't going anywhere fast. Been stuck in my head for well over a year now...

    All the better to develop rather than rush.

    Maybe I'll try my hand at the smaller-scale ideas I have.
    AddictedCreator likes this.
  17. Andar

    Andar Veteran Veteran

    Likes Received:
    First Language:
    Primarily Uses:
    For those who haven't checked this lately: in the last few weeks I continued adding several more explanations and tips, today the tip how to make a two-layer-dungeon on a single map by default. You might want to check this again if you haven't done so in the last few weeks...
    tjaether likes this.
  18. MMO

    MMO ℱα☂αʟ Member

    Likes Received:
    First Language:
    Sarcasm (ಠ⌣ಠ)
    Excellent guide for new creators, even I learned a few things from this(the abbreviations xD).
    tjaether likes this.
  19. Cadh20000

    Cadh20000 Veteran Veteran

    Likes Received:
    First Language:
    It is not just for new users, it also helps those who haven't worked with RM in a while and need a refresher! :p
    eigwayne likes this.
  20. tmacaula

    tmacaula Warper Member

    Likes Received:
    Salmon Arm, BC
    First Language:
    Has there been any word or indication as to when or if they will finish the VX Ace official tutorial set? I have recently found the Beginner's guide to VX Ace by Vesper, and that looks very thorough, but also very long. I was hoping for a shorter tutorial set that walks through making a simple sample game for my students. The current VX Ace set is unusable - the format is hard for them to follow, and it references many things that you are not shown how to do - so it's useless as is. I am thinking of using the old set of tutorials for VX, but I am not sure if they will be missing out on any great new features in VX Ace if I do so. Any thoughts? 

Share This Page