«Foreword« »Where to start.»

VERGE C, System VC, and Map VC

VERGE C, otherwise known as vc, is the scripting language you use to make your games do what you want. VC comes in two different flavors, "system vc" which your entire game has access to, and "map vc", which exists on a 1-to-1 basis with each map. If you're not familiar with the difference, check out Rysen's Tutorial, and then read this section of the Manual by vecna.

Most of the System VC that was created for Sully lives in the vc folder. The exceptions to this rule at present are system.vc (which always has to be in the base directory), flags.vc (which I left in the basedir since it is very closely tied to the mapcode), and effects.vc, (which is where I presently put the functions that define item use). All the other vc files in the base directory have a corresponding mapfile.

VERGE-style libraries

VERGE C is not a high-level language that goes out of it's way to hold your hand. There is no allowance for packages or libraries or private variables as such. However, since reusing code is a very good thing, we've attempted to impose some order on the libraries here. Some of them, like the v1_rpg effects library, are exceptionally portable. Some, like the V1_Menu library, have strong interdependancies to other libraries (in this case, the Simpletype_RPG library) and are generally only good as an example rather than something you can easily adapt.

All of the libraries have listed in their documentation sections all of the global variables and function names they contain, and a list of all of the functions from other libraries that they use. As a point of design, I suggest that anytime you make something in a new library that you want other code to get, set, or otherwise access, that you do it via a function rather than a public variable, just as a point of making it easier to integrate and change 'politely' with other systems.

It's always better to use someone else's library, provided it's not a piece of utter crap, either in whole or as a base to modify from. The reason for this is simple: Why reinvent? Sure, you may want to do something yourself, and by all means go and implement things by yourself (it's a great way to learn), but once you're comfortable with programming concepts, you'll find that it's quite a time-saver to use pre-existing code. And trust me, saving time in a gamemaking project is quite a boon.

I actively encourage people to improve the libraries here, to suggest ways to improve them be it in code or in examples, and to make their own new libraries either to interface with the Sully Simpletype codebase. I only ask that when you make a library, you try to document the interface and use clearly, and always note what other functions/libraries your library has dependancies on.

The includes

Near the top of system.vc is #included includes.vc which serves as a master include file to clear up the clutter that would otherwise go at the top of system.vc. In the vc/Util folder are a bunch of single-serving general-purpose collections of functions. Any of these files can pretty much be of use to anyone, IMO. Here's a list of them with breif descriptions:

There are also three special-effect files, in the vc/Special_effects folder.

In addition, there are three complete libraries. Each one has it's own subsection in this document:

«Foreword« »Where to start.»