How to use a script

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,942
Reaction score
7,459
First Language
German
Primarily Uses
RMMV
How to use a script

A summary and explanation to advanced users


(Please note: as a result of the forum update, the code sections have lost the correct line breaks)

Introduction:
Scripts are neccessary if you want to add new game mechanics or modify the engine's behaviour. However, that always includes the risk of damaging the engine and creating bugs in your game, especially if you do not understand how to use scripts.
Unfortunately, these risks cannot be prevented - which is one reason why we always suggest to make your first game without scripts, and use scripts only when you absolutely have to.
It is also the reason why I wrote that this tutorial is for advanced users and not for beginners, because you can reduce the risk if you understand what you plan to do, and that requires understanding how the engine handles everything before you start to use scripts.


One additional point you have to understand before using scripts:
You will have to read a lot to use scripts, because there is no way to give instructions for every script. The specifics of a script are usually in it's description part, and you have to read that to understand what you have to do in order to use that script. Only in very rare cases there are videos available for a script, and even in those cases the videos either skip details or are several hours long for the more complex scripts.

You cannot "copy and ignore" a script, you always need to check its configuration and adapt it to your project.


And now let's start on what steps you have to do in order to use scripts



1) Decide on which script to use
The master script list (http://rmvxace.wikia.com/wiki/RPG_Maker_VX_Ace_Master_Script_List) contains over 1000 scripts made by hundreds of different scripters, and if you check those scripts then you'll see that for quite a lot of game mechanics, there are multiple scripts that offer the same functions.
There are several reasons for this, but you only need to concern yourself with the two main ones: Compatibility and Details.

The biggest problem with scripts is the compatibility. Every scripter has his or her own way to handle data and functions, and as a result no one can guarantee that every script works with every other one. On the contrary, we know very well that there are scripts that cannot be used together, no matter what you try to do. Every script works with the default engine, but as soon as you add two or more scripts to the engine there can be additional bugs.

How to find and correct those additional bugs is something I'll write about later, but one of the solution is to switch to a different script that has similiar functions but is written by a different scripter.
As a general guideline two scripts can usually work together if they are both written by the same scripter, and often don't work together if they're both part of different scripter's engines. So this is one of the keys to decide which script to use when you have different scripts with the same function: Use scripts from as few different scripters as possible.


The details are the second reason - even if people write scripts for the same idea, their details are often different. For example there are several equipment manager scripts to add new equipment slots - Tsukihime alone wrote three different ones (the oldest are no longer available), there is one from Yanfly and half a dozen smaller variants that only add a few more equpment slots.
In all cases, those script have different details (one of Tsukihime's allows for dynamic equip slots, yanfly's can only handle static slots. Both yanfly's and Tsukihime's allow for new equip types - the smaller scripts from several other scripters only give more slots but keep the original equip types only).
As a general rule more details always mean more complexity - the small scripts adding slots only can be placed in the engine without configuration, but to use the new equipment types in Yanfly's and Tsukihime's scripts, you'll need to know enough of scripting yourself to edit those script's configurations.


As a new script user, it's better to limit yourself to the work of only a few scripters for a project - for example it's no problem to place all the scripts of Yanfly's Engine ACE into a project, or to place all of Victor's script into another project. But combining a few of Yanfly's scripts with a few of Victor's can cause a lot of compatibility problems.



2) READ the script
Each script usually has three different parts (some of them might be omitted on smaller scripts): The description, the setup/configuration and the code itself.
Usually the text files begin with comments that contain the description and tell you how to use the script. This may be missing for small scriptlets, but is usually present in any script from an experienced scripter.
You can identify the description by the fact that you can read it - it's not some mathematical programming code, but complete sentences. In most cases it can also be identified by the # at the beginning of all lines.

After the comments there may be a configuration section, usually a combination of CONSTANTS (usually in capital letters to show that those are not part of the usual code) and arrays/hashes -lists of numbers or names divided by , and defined by [ and ] or { and }.
If a script does not need a configuration, then it might skip directly to the code - but if it needs configuration, that is the most important part for the script user. And if there is a configuration part, usually each of those configuration lines has a few comment lines explaining what that configuration is for.

The last part is the code itself, usually unreadable to most non-scripters.


While reading the script's description, there are a few things that you have to watch for, and take note of them - that's why you need to read it.

- Some scripts require "core" scripts or are add-on-scripts to other scripts. In each of those cases, the other scripts are usually mentioned in the description. And in all those cases, you need to install the required scripts before you can install the one you're reading about. So stop at that point and proceed with the required scripts before entering that one.

- Script order is very important. Some scripts work only when after or before other scripts, and if the other scripts are from the same scripter there is usually a comment about that order in the description. Follow those comments, that is extremely important.

- In some cases, part of the configuration and description follows after part of the coding. This is most notable in Modern Algebra's Quest Script, where the most important data is entered into the middle of the script. In all such cases, the additional configuration area is marked by comments. Even if you cannot understand the code, you have to read the entire script to find those other editable areas if they exist.



3) WARNING: every symbol and letter counts
You need to be very carefull when editing scripts or even only copying them into the script editor.
A single missing or extra space at the wrong line can break a script, so you need to make sure that everything is copyied (no excluding of any line, even if it looks unimportant to you) and when editing the configuration, be careful as well.



4) Download and install the script
Scripts are always text files that can be opened in any editor program - most ending on the regular TXT, but a few scripters save them with the RB extension (for Ruby). They're still text files if you do not have a Ruby IDE.

So when you have selected which script to enter, first make yourself a bookmark to that scripts website. Preferably to the exact point where it is explained, NOT to the download file itself. And sort or mark it as "used" somehow to differ from script pages you just bookmarked for later reading.
That way you will always be able to link us to its description if you have problems, and can check there for updates and whether or not others had similiar problems and solved them.

After that, download the textfile of the script and store it on your computer.
In some cases, the script is not provided as a text file but inside a demo project. In such a case, you have to download and install the demo, open it in the editor and copy the script from the script editor into a textfile to store.


Then open both the script editor in your game project and the scriptfile in the editor.


Scroll the script list to the place where you have to add the script. This is usually below the slot "Materials" and above the slot "Main", but as said before you might have to check for its exact position on that list.

Press the [insert] key at that position to make a new slot.
Click on the "Name" box below the script list and enter the name for the script. Something that will tell you what you will place there and to identify the script later in error messages.

Click into the editor with the script, press [Ctrl]-[A] to select everything and [Ctrl]-[C] to copy it to clipboard.

Click into the text window of the selected slot in the script editor and press [Ctrl]-[V] to paste everything there.

Hint: if you want to prevent errors due to edits, click OK, save the project and reopen the script editor again before continuing.

IMPORTANT: Always copy everything, even the description and comment lines of the script.
When there are bugs, the error messages will report the line number of your script. But if you're asking for help, we'll be checking the line number on the master copy where you downloaded it. If those are not identical, that will cause problems in bughunting.
And if you need to read this, you don't have enough experience to understand which lines are comments and which are code - there have been hundreds of cases where scripts failed because important command lines were not copied with the script.



5) Configure the script: general info
The next seven steps describe the different methods to configure a script. I don't know of any single script that will require all those steps, and a number of smaller scripts require no configuration - but each of the described configuration methods has been used by some scripts, and you need to know how to handle them.
One reason for step 2: reading the script was so that you'll know which of those steps you have to follow, and which don't exist for the script you want to use.
The examples for the configuration options are taken from the following scripts:
Yanfly' message System: https://yanflychannel.wordpress.com/rmvxa/core-scripts/ace-message-system/
Modern Algebra's Quest Journal: http://rmrk.net/index.php?topic=45127.0




6) Configure the script: CONSTANTS inside the script
A lot of scripts use constants to allow for easier configuration, because the constants can be defined in the setup area and then used wherever needed through the script.
They are usually in capital letters and accompanied by a description of what they affect.
Example:


# This button is the button used to make message windows instantly skip # forward. Hold down for the effect. Note that when held down, this will # speed up the messages, but still wait for the pauses. However, it will # automatically go to the next page when prompted. TEXT_SKIP = :A # Input::A is the shift button on keyboard.


Please note that this constant needs a button name and NOT a letter/key as the option. You as the script user and developer are responsible for always setting correct options.

Constants cannot be changed during gameplay, your decisions will remain for the entire game.



7) Configure the script: VARIABLES and SWITCHES inside the script
Sometimes you need to change the script's behaviour during gameplay. This is often done by deciding on game variables and game switches and checking them during play time.
In such a case the developer can change the script result by using a control variable or control switch event command - and he can get a lot of strange bugs if he forgets to configure those variables and switches correctly.
Example:


# This variable adjusts the number of visible rows shown in the message # window. If you do not wish to use this feature, set this constant to 0. # If the row value is 0 or below, it will automatically default to 4 rows. VARIABLE_ROWS = 21


As you can see this looks exactly like a constant definition - and it basically is, but the script uses this constant differently. By the way - this example is famous for the many cases where someone ignored this configuration and later reported that the text windows in the game were shrinking or exploding.

The number behind the constant is the ID number for the switch that will be configured (similiar for switches, I'll only describe variables from now on as switches are handled the same).
So what to do with this information?

i) open any event and add a control variable command to it.
ii) in the control variable window, click on the dots to the right of the variable selection to open the variable list window
iii) Scroll to the variable with the given number, in this case 21, and check if that variable is named/used.
If it is unused, name it by putting "Message Rows" into the name field and click on OK - cancel the control variable window as you don't want to add that command itself.
If the variable is already named, select a still unnamed/unused variable, name it and then change the script configuration in the editor to the number of the other variable you just named.

The naming of the variables not only will tell you what this variable does when used (together with yanfly's message system, it allows you bigger or smaller show text windows) but it will also prevent you from using variables or switches on different functions.




8) Configure the script: Data inside the script
In some cases, especially like most quest scripts, you'll have to add a lot of data for descriptions, rewards and so on. That can cause a lot of problems, because as I said above: every symbol and letter counts, and they need to be exactly where they are required. Additionall, () is not the same as [], and {} is still something else for a programming language. That is why most video tutorials about scripting fail: the watcher usually cannot differ between (), [] and {} on a small resolution video. Use the wrong sign, set the wrong comma, miss a space and nothing will work.

Additionally, whenever a description tells you to use a (text) string, that is something enclosed in '' or in "".


'This is a string'"This is a string"This is NOT a string


Unfortunately some scripters also use the word string to refer to a code string, and that is a mathematical sequence or condition without '' around it.
I won't go into these examples here, because if you can write a code string then you won't need this tutorial anymore (that is already scripting itself)

Additionally there are so-called keys that are beginning with a :
This is especially for input buttons. The key :A stands NOT for the letter A when pressing buttons...

Now let's check an example.


Example:

Spoiler




This example is from Modern Algebra's Quest journal. That script also contains a description of what the following lines are used for. This description is about 170 lines long, and you HAVE TO READ and understand it if you want to use that quest journal. Sorry - no other way. It is the reason why this quest script is as powerful as it is, but also the reason why a lot of people fail to use it correctly.



when 1 # Quest 1 - SAMPLE QUEST q[:name] = "Runaway Bride" q[:level] = 3 q[:icon_index] = 7 q[:description] = "A local woman was abducted by bandits on the night of her wedding." q[:objectives][0] = "Talk to Boris" q[:objectives][1] = "Search the Haunted Woods for Boris' wife, Ladia" q[:objectives][2] = "Slay the Bandits" q[:objectives][3] = "Escort Ladia back to Boris" q[:prime_objectives] = [1, 2] q[:custom_categories] = [] q[:banner] = "" q[:banner_hue] = 0 q[:client] = "Boris" q[:location] = "The Haunted Woods" q[:common_event_id] = 0 q[:rewards] = [ [:item, 1, 3], [:gold, 500], ] q[:layout] = false


Modern Algebra gave a template to copy for creating more quests. Use that, and in all lines never change anything before the =
The data is always to the right side of the equal symbol, and if it is enclosed in "" then that usually means it's a name or description for display on the screen - those can usually be rewritten as you want for your quests.
Whenever there are number however, that can either be a real number (like gold reward) or an ID (like item ID) or an index (like icon index) and you have to be very carefull on what to write there. A wrong index or ID number can either result in something wrong happening, or even a crash if the index doesn't exist.

Whenever you see [], that stands for a type of lists - and they can be nested inside another as long as the matching brackets are there. Unfortunately that can quickly be overlooked, especially if the lines are formatted in the wrong way like the reward lines above.
It would have been much better if Modern Algebra had written it like this:


q[:rewards] = [ [:item, 1, 3], [:gold, 500], ]


Try to nest and indent it like this whenever possible, because this way it's a lot easier to see which part of the data belongs where and where the data ends.



9) Configure the script: Noteboxes in the database
Writing data into scripts is always problematical, not only because of mispelling or other errors. It's also requires additional steps to get into the script editor, and most importantly it doesn't make any assignments of the data into the game visible.
To solves these problems, most scripts use notetags to get their data: coded text sequences written inside the note boxes scattered through the database.

The first thing to learn about these is: Noteboxes do absolutely nothing by themselves. Originally they were intended for developer comments to help in game developing only, and had absolutely no function in the game. Only because they were also saved into the database, scripters learned to read and use them.

And that is the second point to learn: every script can only work with its own notetags and ignores everything that it cannot identify - including notetags that were misspelled. You need to follow the script's description on how the notetags need to be written for them to work.

Example:


<max level: 20>


In Yanfly's Enemy level script, that notetag can be used to tell the engine not to level an enemy beyond level 20.

Please try to make all notetags exactly as given, including upper case/no upper case, no space between level and : but a space between : and the number and so on.
Sometimes the script can detect wrong cases, but most of the time most of the spelling errors result in the script not working.
Also remember the differences between strings and no strings as described above, that can also cause problems here.



10) Configure the script: Comment Commands in Eventing
Oh, but there are no noteboxes on troops or on events - how do I set data there?

You aren't the first to see that, and the solution has been found years ago: comment boxes.
Both troop events and map events can use the comment command (first page bottom left) to keep notes there, and that also has been used for data transfer.
Simply use the comment command, but otherwise follow the description of 9) above.




11) Configure the script: Additional Resources
Some scripts need additional resources - pictures, text files, sounds or other things. This is especially true for HUD-scripts, but also for a lot of battlescripts and others.
In all such cases, the required resources are either linked on the script's website or inside a downloadable demo.
Make a list of these resources, copy them from their downloads and place them exactly as required in your project.

Attention: be sure to check the latest descriptions. I know of at least one script (a bust script) where the description for version 1.0 required the bust pictures in the picture folder, but a later script version changed that to the faces folder of the resource manager.



12) Configure the script: External Data
In some cases, the scripts might require external files for data. That is especially true for several multilanguage scripts, where the translations for all game texts are placed in different language files and the game loads them from there instead of using the internal fields.

Again there can be no general rules as how those files look, but you have to read and follow the script instruction on how to write those external files.


13) Implement the script: Script calls
Some scripts work automatically when you have added them, but other scripts need script calls to work. This is especially true for a lot of quest scripts.
Basically that means that you need to use the script command inside an event to trigger the script - and some scripts need dozens of script calls at different events.

Which script call is needed when depends on the script itself - you need to read that for specific instructions.
However, all those script calls will happen inside events and they will use the script command from the third page of the event command list window.



So now you have the script inside your project, believe it to be configured correctly - what's next?
Testing?
...

Not exactly...


14) Save and Test: New Game
Yes, you should save your current work and then start a test of the new script (single - I hope you didn't install several scripts before testing them). But there is one tiny little thing that can cause a lot of errors: Loading a saved game.

A savegame contains some of the script data from last save. If you add a new script that needs its own data, this data may be missing. And depending on where that script needs the data, it might be that you can even load a saved game and play for a while - but sooner or later the script will require its data, and then it will crash.
If you get an error reading like "undefined (whatever) for NIL-Class", then in 80% of all cases that error is caused by loading an old savefile after adding a script that needs the new game function to set itself up properly.


So whenever you installed a new script, you have to start a new game for testing.
That is one reason why a lot of people suggest to get your scripts together before entering maps or story, because you have to start even testplays again if you added a complex script since the last test play.




Unfortunately the most frequent common visitor to all game development is a Mr. Murphy. Unless you know exactly what you do (and you wouldn't be reading this if you do), then sooner or later there will be crashes or error messages or the game won't do what it's expected to do.
That gets us to the bughunt. There are a lot of methods to use in bughunting, but each can usually only find one type of error and you'll have to check them all until you found the problem(s).

Hint: Make a backup before bughunting - several methods require changes in the project, and you need something to come back when the change didn't work.



15) Bughunting: Clean Project
The first step is to make a new, clean project and enter the problematic script there. And then try to get it to work in the clean project.

This method is the only way to make sure that your configuration and use of the script is correct.
If you can't get the script to work in a clean project, then in 99.9% of all cases YOU have made an error.
There might have been bugs remaining if that script is new, but if it already has several pages of answers without mentioning your problem and is months or years old, then you should check if you made a mistake when following the scripts instructions if it doesn't work in a clean project.

If it works in a clean project but not when the same settings are used in your full project, then that is most probably a script compatibility problem.



16) Bughunting: identifying crashing scripts
This option only works if you get a crash with an error message. Very often the error message won't help directly unless it's an obvious direct error - that is because the error message displays the line where the computer found the error, NOT the line where it actually happened.
But the true cause is still stored - it just isn't displayed with the default error message.

Go to http://himeworks.com/2013/06/custom-main-full-error-backtrace/ and install that script, then activate the console and playtest again until you got the crash.
The console now lists all scripts and functions involved in the crash - and one of those scripts contains the bug.
Write that list down - you'll need it until the bug is found and the error resolved.

First, check any non-default scripts if you configured them correctly and if they work.
Second, check any default scripts if you ever changed any of them - that might have been the cause.

If that doesn't help to solve the problem, proceed to number 18


17) Bughunting: Identifying problem scripts without crash
If you don't get an error message and the script simply don't work, then you'll have to identify the cause the hard way.
This is another reason why the script itself needs to be correctly configured by 15 - you need to have a way to identify as soon as it works correctly.

Go to the script editor, select the first of your added custom scripts and press [Crtl]-[A] (now everything of that script should be selected) and then [Ctrl]-[Q]. Now the entire script should be commented out and disabled.
Confirm, save and playtest: does the script work now?

If not, return to the script editor and disable the next script (without enabling the first).
If yes, mark the last disabled script as one possible problem cause, enable all but the problematic script(s) and test again.

Sometimes several scripts can block another - that is why you have to test until you identified all of them.

As soon as you have the list of involved scripts and checked them for possible configuration errors, enable all scripts again and proceed to the next step (18).



18) Bughunting: Script order
The easiest solution (one that solves about half of the compatibility problems) is changing the script order.
It makes a difference to the computer in which order the scripts are installed, and sometimes specific scripts can only work together if one of them is installed before the other.

Simply copy&paste the script slots around until each order was tested once (hope that the bug involves only two or three scripts or this might take a while).
If the scripts work together in a specific order, be happy the problem was solved that easily and continue with game development.



19) Bughunting: Request patches
If script ordering doesn't solve the problem, then you're approaching real incompatibilities and the point where true scripting/programming knowledge is needed to solve the problem.

Post an error description here on the forums in Script Support: http://forums.rpgmakerweb.com/index.php?/forum/47-rgssx-script-support/
Make sure to include:
- Links to all scripts that you identified as part of the bug (LINKs, not the scripts themselves and preferably to the original page with description and updates, not to direct downloads)
- Screenshot of the error message (if any, and screenshot is better than retyping)
- description of what happens in game (error description)
- description of what you want it to do (wish for solution description)


Depending on the complexity of the scripts involved, you might get a script patch within minutes or might have to wait for months if you get a solution at all.




20) Bughunting: Removing Scripts
Unfortunately not all incompatibilities can be solved. It can happen that no one can find a solution, and that might cause you to remove some of the conflicting scripts to get the rest of the game operational again.

That is why I mentioned the first point as to decide which script to use - perhaps there is a different script with similiar functions out there that you can use. If so, remove the failed script and try again with the other.



21) Request new script if everything fails
Alternatively you might request a new script if none of the existing works for you.
If that is the case, make sure to mention in the request what scripts you tried and why you couldn't get them to work - by default you'll be redirected to exiting scriptsunless everyone knows why that doesn't work.
 
Last edited by a moderator:

tearsofthenight

Evil Sorcerer/Mystic Key Stealer
Veteran
Joined
Feb 3, 2014
Messages
1,451
Reaction score
167
First Language
English
Primarily Uses
Good tutorial/Advice!
 

??????

Diabolical Codemaster
Veteran
Joined
May 11, 2012
Messages
6,477
Reaction score
3,049
First Language
Binary
Primarily Uses
RMMZ
Much agreed:)
 

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,949
Reaction score
3,039
First Language
French
Primarily Uses
RMMV
I don't read the whole tutorial because I can't read much walls of text in english without getting lost.

but yeah thanks for this tutorial it's would help a lots of user and give a little break to us script maker who have to deal with people who always ask for bug fixing when this not a bug but a error from the user of the script who provoke this!
 

Seriel

Veteran
Veteran
Joined
Aug 16, 2014
Messages
3,013
Reaction score
504
First Language
English
Primarily Uses
Other
Ah, another great Andar tutorial. Nice one! :)
 

JaiCrimson

Veteran
Veteran
Joined
May 30, 2015
Messages
44
Reaction score
13
First Language
English
Primarily Uses
That was terrifyingly informative.
 

DangDut

Narratell Studios
Veteran
Joined
Jun 1, 2015
Messages
37
Reaction score
6
First Language
Indonesian
Primarily Uses
Thanks, great tutorial about scripting.
 

_Shadow_

Tech Magician Level:
Moderator
Joined
Mar 2, 2014
Messages
4,077
Reaction score
2,654
First Language
Greek
Primarily Uses
RMMZ
Bughunting advices are extra helpful and the whole tutorial is fantastic.
 

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,942
Reaction score
7,459
First Language
German
Primarily Uses
RMMV
added a forgotten point about script calls to start some scripts ingame.
 

BlackestSoul

Veteran
Veteran
Joined
Nov 22, 2015
Messages
33
Reaction score
2
First Language
English
Primarily Uses
Wow, although i have just started with VX Ace, and have no knowledge of scripting at all, your explanations here have helped answer a lot of questions that had been on my mind. It was surprisingly simple when explained properly. Thankyou.
 

Negi-Mox

My hand got fractured!!
Veteran
Joined
Jun 19, 2017
Messages
140
Reaction score
33
First Language
English
Primarily Uses
RMVXA
WHo write this MUCH?:dizzy::dizzy::dizzy::o:o
I did not even readed the whole can you explain me in simple??
 

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,942
Reaction score
7,459
First Language
German
Primarily Uses
RMMV
@Negi-Mox that IS the simple explanation.

Sorry, but there is a reason why scripts are considered for the advanced users only, and if you have problems with scripts your best chance of solving them is to follow the tutorial here step by step.

"script" and "scripting" are words that come from describing written things, and reading is part of writing.
There is no shortcut to this - there are some other tutorials using videos, but it has been proven that those usually miss part of the data here despite being several hours long. And yes, you'll need to watch several hours of videos to get the same information and tips that I placed here.
And it has also been proven that several of those videos resulted in errors due to video quality on top of that - in scripting there is a massive difference between () [] and {}, but on some videos it is impossible to see the difference when the video creator writes them - you need to take a good look on the different letters even when written in a text, and a low-res-video that shows them only for a few second won't help.

So short answer: you have to read all that if you really want to use scripts with all their options, or you have to stop using scripts.
 
Joined
Nov 9, 2017
Messages
2
Reaction score
0
First Language
English
Primarily Uses
RMVXA
So...question. It's about the legality of changing the base script, the ones that are there already when you make a project.

Is it legal to change that? An example of this would be if I want to remove the menu that shows how much gold you have by erasing it from the code.
 

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,942
Reaction score
7,459
First Language
German
Primarily Uses
RMMV
As said in the EULA, you can edit all resources that come with the engine as long as you follow the EULAs specifications. That not only includes the art and music but also the scripts openly available in the script editor.
It does NOT include those functions that are closed source inside the ace DLL, because reverse engineering for them is forbidden.

In fact, editing and adding to the scripts in the script editor is what this tutorial is about, so of course that part is legal and how everyone does it.
 
Joined
Nov 9, 2017
Messages
2
Reaction score
0
First Language
English
Primarily Uses
RMVXA
Oh okay. I read the EULA, but wasn't 100% sure what the reverse engineering part was about. Thank you.
 

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

Latest Threads

Latest Posts

Latest Profile Posts

Ami
Castle is my Biggest Fear :kaodes:. I just Managed make Part by Part (like the Entrance only),not the Entire Castle like in the RM Sample...
This video really speaks to me...

Stream will be live shortly with a session of the interactive text adenture! Feel free to drop by!
I worked a lot more today and I am thinking about Youtube videos to make to my channel, but I am still looking for some content :D

But I am happy to be back at work :D

Forum statistics

Threads
104,365
Messages
1,005,866
Members
135,887
Latest member
YamiiJudaii
Top