[Guide] Simple Mana Leveling System (Custom Currencies)


Blizzards most disappointed fan
Apr 12, 2020
Reaction score
First Language
Primarily Uses
Hello everyone.

Some of you may have noticed that I have been helping @Elliott404 with her leveling system during the past week. This is the Thread

Unfortunately, we could not get it to work on her end and was thus abandoned.
I did put considerable work and time into getting it to work (considering the circumstances) ,
with no avail sadly.

And in order to not waste the effort, I would like to share my primitive system with all of you.
(Also on behalf of @ShadowDragon, who requested a demo)

Main Content of this guide:
-Introducing custom currencies into your game and manipulating them to create a gameplay-mechanic for your game using basic functionalities of the engine.
-As an example, this guide deals with introducing an alternative "EXP" currency for leveling up
-A little bit about common events (How to use)
-A little bit about building "Save Points" for players using only eventing
-In "Part IV - The Aftermath" you will find bonus information and some of my ranting

The goal is that you can easily adapt this system and extend and upgrade it to your personal needs.

Note: Please excuse the occasional typos and grammatical mistakes. Bear in mind that English is not my first language. So even though I am pretty confident in my written English abilites, there might be some errors left in here. I just hope everyone can understand the essence of what I am saying in this guide.

Here are the Features you will achieve with this simple system:
- Creating alternative currencies that can be used in your game as a gameplay mechanic
-> This Guide will show you how to create a custom currency as an alternative to regular EXP
-> Can still be combined with regular EXP

- completely independent system (No need for plugins or editing of any code)
-> Can still be modified and improved with plugins

- Creating common events for "Save Points" and "Level up systems".

- Since we use variables, these custom currencies can be modified on whichever occasion you see fit
-> for example: as a reward for battles, Chests, Quests or exploration

- Obviously, it does not need to be called " Mana", it can also be called... i don't know
"Bananas" (<-- @Trihan *wink* ) or something

- If you use more variables, you can potentially add unlimited custom currencies
-> 2 Variables per currency
-> one general variable for gaining custom currencies
-> one optional variable to calculate the amount of the custom currency left until you have enough to
do the stuff you want to do (Like in this guide "leveling up")

This system can NOT ONLY be used for alternative "EXP" currencies,
but rather for any kind of custom currency in your game,
like collectibles, resources, crafting material etc.

In this guide however we will use this system as an alternative EXP resource.
So, how do you do that? It is very simple, really. Here is a guide for a basic system.
First, we need to set up the variables we need. We will need 2 variables for each "custom currency" we use. Furthermore, we need 2 more variables overall to control the flow of our currency and for general user comfort. ATTENTION: If you want multiple party members to have their own Mana reservoirs, you will need one variable for each party member. And probably one more variable to configure individual Leveling costs. I will touch on that on a later part of this guide.
Assuming we use "Mana" as our one and only custom currency, we need these 4 variables:​

- Mana Currently -> This variable stores the Mana your party currently has​
- Mana Cost -> This variable stores the amount of Mana the next Level Up costs.​
- Mana Needed -> This variable is optional, you can use it to calculate how much more Mana the player needs to gather until he can level up.​
- Mana Gain -> This is a dynamic variable you use every time you gain Mana. You put the amount of Mana you would gain into this variable and add it onto "Mana Currently". Note: The main purpose of this variable is that you can display to the player how much Mana was gained
(e.g. "You gained \V[4] Mana!")
- As mentioned before, you will need a "Mana Currently" and "Mana Cost" for each currency you introduce.​
--> "Mana Needed" and "Mana Gain" don't need to be duplicated, they can be used for every currency you end up making​
When you are done, it should look something like this:
ATTENTION: It is extremely important that you initialize your variables somewhere at the very beginning of your game. This mostly applies to variable 2 (Mana Cost). But it cannot hurt to do them all. This is an example of a "Initialization Event":
You will also need to set up a way to spend your "custom currency", in this case our Mana.​
I am sure that there are a dozen of plugins that allow you to spend currency in some way, even using variables as currency.​
However, this guide is aimed to work with the base engine and without external modification.​
One idea would be to make a "Save Point" event, sort of like a safe haven for the player where they can heal, save and most importantly; spend their accumulated Mana.​
Here is an Example on how you could set up such an event:​
Note: As you can see in the picture, the "Spend Mana" option calls a common event, I will talk about that later, this merely shows how you could set up a mechanic to spend your EXP currency
Note: You could put the entire content of that event as shown in the picture above into its own separate common event, which I would even advise to do. I did not do this in this example for the sake of clarity.
Now, in this particular guide, the heart of the system lies within the common event that lets you spend your accumulated Mana. Everything else is really simple.

This is how the basic "Spend Mana" common event could look like:


So let's go through this common event in detail. This will happen when we use the "Spend Mana" option from our Save Point event:
(Green is explainations for what the commands are for)

◆If:Mana Currently ≥ Mana Cost <-- The conditional branch checks if we have enough Mana for a level up. Remember to put the variables at the right spot. In this case Variable 1 >= Variable 2
◆Control Variables:#0001 Mana Currently -= Mana Next Level <-- If we have enough Mana, we subtract the Mana Cost (Var 2) from our Mana Currently (Var 1) because we paid our Mana to level.
◆Text:None, Window, Bottom
: Text:You spent \V[2] Mana to level up!

:Text:You have \V[1] Mana left. <-- We can use the variable values to display dynamic messages to the player, to also make him aware of said values
◆Change Level:Harold, + 1 <-- This is the spot in the common event where you put all the things that happen because you leveled up, in this case we give our friend Harold a simple +1 Level
◆Control Variables:#0002 Mana Cost += 20 (*1)
◆Script:$gameVariables.setValue(2, Math.floor($gameVariables.value(2) * 1.5)); (*2)
^ This is the Spot where we adjust the Mana Cost (Var 2) for the next Level Up. You may use the basic "Control Variable" command to adjust the Cost if you want a simple "EXP curve" (*1). However, using a script call (*2), we can also put more complex EXP curve formulas into place. The one you see here simple increases the Mana Cost by 50% each time you level up.
I will talk some more about this in Part IV

<-- Needless to say, the Else-Branch comes into play whenever we do not have enough Mana for a level up. If you are feeling generous, you can provide useful information to the player using the optional variable "Mana Needed" (Var 3).
◆Control Variables:#0003 Mana Needed = 0
◆Control Variables:#0003 Mana Needed += Mana Cost
◆Control Variables:#0003 Mana Needed -= Mana Currently

^ This is how we calculate the amount of Mana the player needs for the next level up. First we initialize Variable 3 to 0 to have a starting point. We then add the cost of the next level up and subtract the amount of Mana we currently have. Et Voila, you have the difference, or - in this case - the amount needed for leveling up.
◆Text:None, Window, Bottom
:Text:Not enough Mana to level up!
:Text:Mana: \V[1]/\V[2] (You need \V[3] more to level up!)

^ Using Variable 3, we can now play a message with everything the player needs to know concerning his Mana. It displays how much mana he has, how much the level up costs and how much more Mana they need to get there.

Now we can spend our Mana at a Save Point and we control the rate at​
which the Mana costs increase.​
But how do you spend Mana when you don't have any?​

Luckily for you, that is the easiest part of the entire system.​

Since we store our Mana in "Mana Currently" (Var 1) we just need to modify that variable whenever the player should gain Mana (or even lose Mana...?)​

Even though it is not strictly necessary, I would advise using the fourth variable (Mana Gain) to​
control the amounts of Mana you gain. You could just add the Mana gained
directly onto "Mana Currently" (Var 1), but in my opinion, that is a lot less clean and unorderly.

The main advantage of using a "middle man" is that we can use this variable to​
display messages to the player on how much Mana was gained. This is especially​
helpful when you gain random amounts of Mana (like in the example that is coming up).

This is what I mean by that (This is a snippet from a treasure chest event):​

◆Control Variables:#0004 Mana Gain = Random 60..80
◆Control Variables:#0001 Mana Currently += Mana Gain
◆Text:None, Window, Bottom
:Text:You found \V[4] Mana!
:Text:However that works...

As you can see, we set the amount of Mana we gain in Variable 4 and only then do we add this amount directly from Variable 4 (Mana Gain) to Variable 1 (Mana Currently).​
This gives us the opportunity to display a message using Variable 4 as a text code to display the amount we gained.​

With this principle in mind, you can give your player Mana whenever and wherever you see fit.​
Some examples could be Treasure Chests, Battles, Bosses, Quests, Exploration etc.​
Here are a few things you need to watch out for when attempting to replicate this system:​

- Make sure you initialized Variable 2 to set the base Mana Cost for the first level up​

- Make sure all the variables are correct and at the right places. This is pivotal because one misplaced or falsely referenced variable will likely "corrupt" the whole system.
--> It is really easy to overlook one small mistake, so make sure to meticulously check all events that handle variables (often times conditional-branches are overlooked)​

- Make sure the event-commands are in the right order​
--> When working with a lot of variables, you must make sure that all operations​
happen in the right order​

- When maniplulating "Mana Needed" (Var 3) and "Mana Gain" (Var 4), you should make sure that
the values of these Variables are first "re-initialized" before you do anything with them.
By that I mean: Set them back to 0 OR make sure to use the "=" operator when manipulating them
--> Example: if "Mana Gain" has a pre-existing value of 75 (because you forgot to reset it) and then you defeat an enemy which would give you 25 Mana, you would actually gain 100 Mana because the 25 you were supposed to get were added onto the pre-existing 75 Mana.​
--> One solution is to make sure to set "Mana Gain" to 0 before adding values to it.​
--> The better solution would be so just set "Mana Gain" to 25 outright because that overwrites the previous amount of 75.​

NOTE: Theoretically, you could merge Variable 3 and 4 (Mana Needed and Mana Gain) into a single variable, because they both serve similar purposes as "Use & Throw away" variables. However, I personally would advise against it as using 2 variables is a lot more clearer for the developer
and prevents possible mishandling of or confusion with these variables.
You may have multiple currencies, in which case you just need to make replicas of Variable 1 and 2.
Basically, you will need one "Currently" and "Cost" for each currency.

For example:
[Mana Currently / Mana Cost]
[Shards Currently / Shards Cost]
[Bananas Currently / Bananas Cost]

You can still use Variable 3 and 4 to control all of these other variables, that is because the variables Mana Needed and Mana Gain are "use it and throw away" variables. Abuse these whenever you can.

If you have multiple characters with independent Mana reservoirs, you will likely need to make two variables for each character.

For example:
[Mana Currently - Harold / Mana Cost - Harold]
[Mana Currently - Lucius / Mana Cost - Lucius]
You will then need to create a way to reference which character at the save point is trying to spend their currency. This is most easily done by just using a "Show Choices" command to ask the player which character attempts to spend their currency.

If you combine both of these (Multiple Currencies and each character having their own reservoir),
it will be a bit more complex, but still doable.
As said before, if the basic "Control Variable" command is not sufficient in altering the Mana Cost variable in a way you want, you could use this script call:

$gameVariables.setValue(X, FORMULA);
X = The ID of your "Mana Cost" variable (in this case 2)
FORMULA = the mathematical formula which changes the Mana Cost.

You will likely use this format to start your formula:
This will first reference your Variable X (Mana Cost) and afterwards you can put any mathematical operations you wish.

Here is what you can do for example:
$gameVariables.setValue(2, Math.floor($gameVariables.value(2) * 1.5));
// Increase by 50% each time -> this one is very good for a steady but scaling growth
$gameVariables.setValue(2, Math.floor($gameVariables.value(2) ** 1.1));
// Increase by the power of 1.1 -> this one is very good for an exponential growth
$gameVariables.setValue(2, Math.floor($gameVariables.value(2) + Math.floor($gameVariables.value(X)));
^ Increase the Mana Cost by the amount of Variable X. You will have to figure out what
to do with this one yourself

As I am not too familiar with other possibilities, I will leave it at that. You should contact people who are more familiar with JS and the MV engine for more intricate EXP curves.
Since this system as it is deals exclusively with variables, the possibilites with plugins are endless.
Of course, I won't talk about each and every plugin.

However, a great way to utilize plugins is to display your currencies
somewhere the player can see easily.
For example, a HUD on the screen. Or maybe in the menu.

I believe there are also plugins for "Variable shops" where you can
configure shops where you can modify variables if you buy something there.
This would be useful if you use custom currencies for crafting materials for example.

I myself have custom currencies in my game and I am using SRD_GoldWindowCustomizer and SRD_MenuStatusCustomizer to display my custom currency to the player.
In "Part I - Preparation" I made a Note saying that you could put the content of the "Save Point" into a common event of its own. This is how it would look like in my system:


This way, if I need to make any changes to my save points, I can do this handily in the​
common event tab. And once I am done, ALL of my save points will have the changes I made.​

I advise using Common Events generously in your project.​
Basically, any event or block of event-commands you find yourself copy pasting multiple times is probably worth putting into their own common event.​
This is true especially for events and blocks of commands that are prone to change later on.​

Common events are very useful, because if you need to edit the event later on, you don't have to look for the event in question, because it is right there in your database and the other thing is that editing the common event will affect every instance in your map where said common event is called.​

Example: you have decided to make a treasure chest with random loot. So far so good. You put these chests everywhere in all of your maps. But then.... you notice an error... or you want to change something after all. Now you have to hunt down every single treasure chest in your game.​
That sucks. If you used a common event for that chest instead, you would only need to edit this one common event because EVERY chest is connected to it. No event-hunting needed.​

This principle of common events can be applied to not only treasure chests, but any event or​
event-commands that occur more than once in your game.​

However, under certain circumstances, using common events can become quite tricky if the common event in question has a lot of references to outside-variables, switches and other data. You will know what I mean when you eventually hit a wall like that aswell.​

Common events work best with internal variables, switches and static commands
Note: This is mostly a rant about design philosophies concerning the "save point" mechanic

Save Points are utilized in many RPGs and even some FPS.​
These games usually trade the ability to save anywhere with static "save points" which​
have to be reached by the player in order to save their game.​

Often times, these save points have additional options besides saving your game.​
Examples of that could be healing your group, spending skill points (like Mana?),​
accessing fast travel, crafting equipment, maybe even buying items and so and so forth​

This comes with advantages and disadvantages.​
Generally speaking, using save points gives the developer more design space as they​
can choose when the player can save their game.​

As a result, the developer can prevent the player from effectively "soft locking" themselves.​
Imagine an FPS like Half-Life. If you saved your game in the moment you fell down from a bridge, you would die and when you load... well you die again. You would be forced to load an even older save file, or in the worst case scenario, start the game over or use cheats.​

However, using save points is not without disadvantages either.​
The developer is responsible to place the save points in a logical and fair manner.​

If they put too many save points everywhere, they remove any kind of tension or​
sense of risk from the player and they might aswell let the player save manually.​

If they put too few save points, the game can become very frustrating to play,​
as game over can mean losing a lot of progress and in consequence, time.​
They will also be forced to play until they find a save point or abandon their progress,​
should they wish to stop playing.

Here are some pictures of the demo included in Part V:
pic 1.png
pic 2.png
pic 3.png
pic 4.png
pic 5.png
Picture 7.png
Picture 8.png
Picture 9.png
And finally, this is where the demo is at:
Check out this demo to test the system out and find out how it works exactly.
All events are explained with comments. Also make sure to inspect the common events and troops in the database.
DOWNLOAD (Mediafire)
I am aware that this system is very basic, but maybe some people can draw inspiration from it or extend it for their own purposes. Thank you for your time reading this tutorial.
I hope I could help some of you out.
Last edited:


MSD Strong
Global Mod
Jul 22, 2014
Reaction score
First Language
Primarily Uses
Looks good! Thanks for fixing the formatting on your very detailed guide.


Oct 8, 2018
Reaction score
First Language
Primarily Uses
alot to read, might do that when I got time, But I got the demo and see if i can figure out.

Thank you for creating the demo and the huge explanation, this can come in handy.
Also I need to change some stuff, but most will be similair, so I can learn alot from it :)


Blizzards most disappointed fan
Apr 12, 2020
Reaction score
First Language
Primarily Uses
Well its not too much actually.

Only Parts I to III are essential. Everything else is optional help and bonus information.

As for the amount of text, I just wanted to make sure to describe all the steps in as much detail as possible so that everyone understands what I mean as I am not too good in explaining technical stuff.
Last edited:


Blizzards most disappointed fan
Apr 12, 2020
Reaction score
First Language
Primarily Uses
Here is a little update since I was not too happy with the current demo.

Demo: Look into my original thread for the updated Demo in "Part V - The Demo"
-Further cut down the file size (down to 34MB ) B)
-Added some more functionalities to the demo
-updated the readme file to not be so disgustingly ugly
-Added a little bit of humor
-Stronger Monsters
-Void (and possible death...? No, not really)

Tutorial Thread:
-Updated the demo preview pictures
-Cleaned up some formatting issues
-Added some more details here and there
-fixed some typos and grammatical errors (there are probably still some left lol)
Last edited:

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Posts

Latest Profile Posts

My only regret is the portal mirror effect is too subtle to show up in these GIFs. It probably just needs more sparkles. :LZSwink:
Microsoft: Hey, let's waste money advertising the Xbox Series X when nobody has any in stock, we don't seem to be making more, we aren't taking preorders and you can't get on a waiting list. BEST. IDEA. EVER.
So I'm practicing ITC with a spirit box, and decide to try to contact my deceased soulmate. It actually gave me multiple identifiers. Me, still a bit skeptical, asked aloud "Fine but does he still love me?" and the box spoke and printed the word "Forever" at the same time. Been a mess of tears since. :kaocry:
Been scratching away at my game and making progress, but just had a revelation. I'm working in full screen and adjusting all my pictures accordingly, but will they resize if someone's screen is smaller?? I hope this doesn't turn out to be a problem later.

Forum statistics

Latest member