VM Construction

VM Construction

GAD! I am SUCH a genius!

Unidentified animated character

CHAPTER 5: VM Contruction

Virtual Mektons are built using a personal editor. These editors can be bought (relatively) cheaply at any VMA-affilited arcade, and are designed to take advantage of the Virtual Mekton Programming Language (VMPL). VMPL allows easy modifications to existing constructs, and built-in comression utilities let the final product fit on a standard data disk. Technical staffs at the VMA are trying to overcome one of the perennial problems of using the data catridges: The fuller the cartridge, the slower the program runs (called "Lag time"). So far there has not been much luck, and the pods are not built to accept other (more expensive) media formats.

The first step in the construction process is to design out the VM you want. This will take the player CP/50 in days. NOTE: this cuts design time from what the normal rules state. What you are designing is just a computer simulation, after all; much easier than designing a REAL giant robot. This allows a PC to design a VM in half the time it would normally take - allowing them to make real progress even with a poor schedule.

Here is a sample chart for VM design:

VM CP Time Range Design
difficulty Programming
difficulty

0 - 150
0-3 days
10 10

151 - 350
3-7 days
15 15

351 - 550
7-11 days
20 20

551 - 750
11 - 15 days
25 25

751 - 1000
15 - 20 days
30 30

1001- 1440
20 - 30 days
35 35

Designing a VM requires a VM Design roll (INT + VM Design + 1D10). This roll is made once the needed time to design the VM is finished, the GM is NOT to tell the player the result..it is far better to roleplay the result, see also the Flaws Table for some interesting results when things don't go exactly right.

Once the design has been completed, the player moves on to the next step: Programming the monster they have created.

Once the design phase is finished the player starts to program. Programming time is equal to the design time, but unlike the design time programming time can be reduced.

The first way to reduce programming time is to come up with a clever way of coding a complex item in the VM, this is represented by making a TECH + VM Programming roll vs 1.5 times the Design diff, made by the GM. For every point over the target number, programming time is reduced by 10%, if you BOTCH the roll with an unmodified 1 (one), then the GM gets to have a field day with your design....

The second way to reduce programming time is to get friends to help you, but they also give a slightly larger chance for things to get screwed up. The designer will split up the design and give parts of it out to those helping, and everyone has to make a VM Programming roll. The benefit is that programming time is reduced to 30% of what is needed (minimum 1 day per Ranking level the VM fits in (REG: 3 days)), plus a day for intergration. The down side is if the programming roll is blown by anyone on the team, then the "missed by" number is DOUBLED for determining the flaws (Miss by 3, look at 6). The difficulty can be modified by things. Taking your time may add +1 to +3 to the roll, but rushing can take away a like amount. If you have friends helping then all may use the highest values available and you may add 1 to the roll. per person helping.

Please remember that the home compiler is fairly stupid, it will tell you that there are errors, but won't be able to specify what they are. Finding those bugs may require many hours of thorough playtesting which CAN be done at home...but some errors won't show until the VM interacts with a full scale networked arena environment. Where the home compiler won't tell you what the problem(s) is, the arcade simulator will - with everyone looking (or trying to) at your new secret weapon.

The MTSAC

VIRTUAL MEKTON offers your players umparalelled flexibility at the time of designing their own walking monstruosites. So, sooner or later, YOU, the GM, are bound to run into some glaring rules abuse.

OK. So your players just fielded a VM as monstruous that could defeat the entire array of VMs presented on this book with one hand tied to th eback through th euse of some rules lophole. You have two options. You can try on your own, on the spot, to find how to neutralize the rules abuse before it ruins your game. Or, you can take usage of the MTSAC.

The Mekton technical System Abuse Catalogue is the result of countless discussions on the Mekton Z and Virtual Mekton mailing lists, as long with oficial RTG explanations, about what are the most outragoeus ways of abusing the MTS that WE, the designers, ever found as game masters, and how we did deal with them.

Read these notes. Remember them. Use the deterrants we offer. Even laugh with them!. You don't need to apply the corrective measures ALL the time. There's nothing bad into designing a VM using these incredibly abusive rules jyust for fun. But if one, or all, of your players try to use them to dominate the game,

NOW YOU ARE READY FOR THEM!!

If the Programming roll is missed, it means that there is some undetected error(s) on what you thought it was a finished design. To find exactly what the error is, the GM will apply standard MZ+ construction rules, but for substituding the following table for the Tech Construction Table of MZ+ pag 7.

**VM PROGRAM BUG TABLE**
FAIL	WEAPONS	SENSORS	CODE
15	Beams improperly coded, damage & range are at -2	All sensors (except visual) go offline after 1d6 turns	Improper compiling: you lose after 10 turns
10	Rapid-fire weapons de-rezz after 1d6 turns	Flawed coding: ranged weapons	Bad data transmission: lose 1 from MV
6	All beam weapons shut off for 1d6 turns	Targeting Misalignment: ranged weapons at -3 to hit	Readouts all show "Imminent System Failure" after 1d6 turns of operation
3	All missiles/rockets "Jam" after 1d6 turns	Bad Shielding: you get signal noise for 1d10 turns, no communications	Not enough power allocated, MA drops by 1/2 D6 and immediate landing needed.
1	Faulty guidance routines, Missiles /rockets are at -4 WA	Lose commo for 1 turn every 1d6 turns	"Spaghetti Code": drops 1 random multiplier system until recoded
FAIL	ARMOR	MOVEMENT SYSTEMS	AVATAR
15	Poor coding: ALL Armor SP is 1/2, with NO DC/RAM capabilities	Movement systems cut out after 1d10 turns. Happy landings!	VM will lock up after 1d10 turns
10	Armor is "gapped": -1 SP from 2 random locations.	Slow System response: move at 1/2 MA for all motive systems (includes walking)	Poor polygon structure: 2 random sections De-Rezz after 1/2 D6 turns
6	Armor is mapped wrong, -1 SP from 1 location	Jammed Throttle: move full or don't move at all.	Poor polygon structure: 1 random location De-rezzes after 1/2 D6 turns.
3	Refractive coating flawed, -2 sp VS beam weapons	Directional control systems not responsive: increase turn radius by one	Poor "camera" placement, add 2 to all rolls needing sensors (targeting, detecting etc etc)
1	Density flawed: -2 sp vs all ballistic weapons	System misalignment: -1 to MA	Weak limbs: -2 kills from melee/fighting damage.

NOTE: If there is a result that is not relevant, such as "rapid fire weapons de-rezz
after 1D6 turns" and the VM has no rapid fire weapons, find the nearest sensible result.

The PC can roll vs INT to find the errors, but the greater the error, the harder it is to find.

"And what is the Time Lag of VMs which cost more than 1440 CP?",

asked the Anonimous Gearhead. Not a good question, for there are NO VMs costing more than 1440 CP. Remember, this is a hard limit impossed by the actual maximum capacity of the game disks. You can argue with your GM about if he's willing to acept larger designs, but go and try to argue with a full data disk about if it's willing to acept more data. Best of lucks.

"But why you can't fit that 1656 CP VM? It takes only 1440 MB, after al!"

Good question, unlike the former one. But remember that, to compress a design, you NEED to have it finished before starting to work on it! The uncompressed design simply wouldn't fit.

"And why can't I simply design it on my hard drive, then compress it, and finally copy it into the data disk?"

Good question. GOOD question! That question proves that you are willing to go and try alternate solutions to the aparently unsolvable problems. Sadly, it still wouldn't work; to compile a VM, it needs to be stored into a VM Data Disk. And they have a kimit of 1440 CP worth of space, period.

Rules Modifications

VM provides some rule suggestions and options that alter portions of the construction process. Some are setting-specific limitations, other are just optional rules. If the GM does not want to use any of the optional rules, it will not take away from the setting or from player enjoyment.

Maximum Cost

All designs on Virtual Mekton are limited to a maximum cost of 1440 CP. This cost represents the actual capacity of the data disk on which the VM code is stored, measured on Data Blocks (the "computer" name; also called Size Units by the people using programming-free compilers). For one of these incredible coincidences that do happen on RPGs, a Data Block / Size Unit is table to hold the information of exactly one CP worth of code. Ain't be the GM great? :-)

All VMs need to be stored into a 1440 CP data disk in order to be used on a game pod. Even more, in order to compile a design, the design needs to be stored intoi a data disk, since the compiler needs both to read the ROM internal chip of the data disk (which contains several copyrighted and encrypted routines) and to write the VM directly on the same disk it uses for reading. This is a failsafe measure willingli installed by the VM company. You can safely store designs on any data storage system, but you can only use or modify them on their own (but rather cheap, anyway) VM Data Disks.

Lag Time

The nuts and bolts number crunching for VM construction is , for the most part, identical to MZ+ (or Mekton II + MTS); The main difference is in the MV of the unit. MA will be based on the tonnage of the unit as per standard rules, MV (called "Lag Time") will be modified by the CP of the unit.

To modify the effects of lag time the programmer will have to apply Code Compression (x0.05 per level, this additonal cost does NOT add to the lag time penalty). Please not that this table augments the existing, weight-based, MZ MV table (so a VM with a MV of -3 and a Time Lag of -1 will have a total MV of -4).

LAG TIME TABLE
CP Time Lag Cost multiplier to cancel

0 - 120
+1 NA

121 - 300
0 NA

301 - 600
-1 0.05

601 - 900
-2 0.10

901 - 1440
-3 0.15

NOTE: A positive Time Lag CAN raise a unit's MV above zero.

Time to go through the code and actually do the compression is 1 day per 25 CP of compression cost. This time is in ADDITION to the coding time to build the VM.

Another advantage of code compression is that it frees space on the data disk equal to its cost (instead of adding it). This means that a compressed 900 CP VM, which raises its efective cost to 990, would take only 820 space units of the data disk, as opossed to 990. It should also be specifically noted that, even with compression, the hard 1440 CP limit CAN'T be exceeded; you can't compress a 1656 CP VM so it wouyld take 1440 size units! This means that the only efect of the smaller data size of compressed mecha (other than their inferior Time Lag) is that you can stuff more extra VMs and/or optional weaponry on your data disk.

Internal Memo for the Tech staff of the VMA:ALCON, lately there has been a debate on the ability for players to code Ship / Orbital class (x10 / x100) scale weaponry into a VM for tourn-ament use. We all know of the theoretical possibilities that this can be done (especially with the Gun Transform option available). The Official (and current State of the Art) Word is that this cannot be done. Even so, there is the chance that it can be done and policy must be set. The policy is as follows: Use of Out-Of-Scale (OOS) ranged weaponry is authorized, but not encouraged. Independant VMA franchises may allow or dis-allow OOS ranged weaponry if it appears. The VMA franchise owner will, upon discovering the use of OOS ranged weaponry, foward a copy of that VM to the tech staff for anal-ysis. Please include the creators (not users) name and Lweb ID so that our tech staff may communicate with them. If the owner / user / creator object use the VM template stored in / Vm / prvious / (pod id) / (VM ID) / temp / initialized. The VMA will be most willing to discuss terms of settlement for use of this coding and information. Please note that for this offer to applicable there must be a OOS ranged weapon in use BEFORE the relevant VM transforms into a Gun model (if there is a Gun mode for that VM). The Gun mode enhancement alone does NOT qualify. <original signed> T. Izumi

This section on nukes brings up another dark possibility: Virtual Nuclear Theft. What would happen if some terrorist organization actually stole plans for building nukes and hid thatdata on the VM game net? It is an excellent place to hide such data as there is so much"fantasy" based weaponry that is based on real world models there, that an information setlike that (Nukes) would hardly seem remarkable.

Design Restrictions and Ban Equipment List

There are a few limitations to VM construction. Other than the following limitations, all systems, even te more high-tech ones, are available.

There are some things NOT ALLOWED under any circumstance (Notice that most of these are rather obviously of no use on a computer game, anyway):

Dimensional teleport
Lightspeed
'OIDS
Esper Lenses
Techno-organics
Bioenergy powerplants
and the following SMTs:
- Merge with mecha
- Expanding plasma (see note below)
- Self duplication
- Summon mecha

SMTs not listed above are allowed, but some need GM's approval (and a dose of sense for the setting). To wit,

Super Deformed mecha needs also RIVAL's approval (either explicit or implicit, such as entering a SD-using Arena or Game Channel);
Piracy might be OK, only if the GM approves the concept of control (this shouldn't happen often Character concept or no.)
Expanding Plasma is a thing that is technically POSSIBLE to code (it resembles the function of some powerups), but is strictly ILEGAL on the game -code it and the sysop will kick you out REAL fast!
Gun Transformers are allowed, but they don't get a damage increase (they get all other bonuses, though).
also see below for SMTs that fall on the controlled items definition

Thought Control is technically possible, but it needs a spetial control VR headset, prized at $3,000 at a minimum!

Also, Combiners are possible in a limited way. The combined VM has to fit on one of the players' disk - in addition to the players' individual VM.

Nukes do exist, but are subject to spetially strict limitations. See below for details.

Things that ARE allowed but are STRONGLY suggested to be highly controlled are:

E-Pools with a Portfolio of more than 3
Out-of-Scale ranged weapons
standard teleport
Any scale item above / below standard x1 scale
x10 scale EMWs without limited shots of no more than 5
Some SMTs: Tunelling, Material absorption, and Morphable mecha.
All reactive shields should have ONE weakness as well; having Reset:X does count as a weakness for this purposes ONLY (but that does not stop anyone from buying several reactive shields with seperate weaknesses to cover each other).

When designing a VM, there are also several gidelines regarding weaponry and armor that you are encouraged (but only encouraged) to follow. These are:

The average weapon damage should be on the 5-7K range.
"Heavy Weapons" damage should be on the 10-12K range
Whould the armor be Gamma, it should be at most HS on level (SP 5)
Servo and Armor level should be around Striker to Medium Heavy

These above sugestions are to create VMs which are balanced each other and can have a fair fight betwen them. Most of the "of-the-rack" VMs that you can buy on the stores are built on these lines. Of course, most VMs that are custom-built won't strictly follow all these guidelines....

Sharp observers would notice that both the strongly controlled items list and the damages / armor guidelines list includes the things that are possible to code / outdo but that are banned/mandatory on the OVMR (Oficial Virtual Mekton Regulation). A VM built outside these gidelines will be perfectly compiled, but unless playing under a Regulation that allows these items (see the Regulations chapter), the designer will find its VM downgraded to the "allowed" parameters.

A word about Nukes

Please note that on Nukes, while they do exist on the game, there is no code available for this. While the gross effects and requirements are known, trigger mechanisms and such have NEVER, EVER been released to the public, so coding for Nukes is/should be extremely hard, with the possibility of code errors (see above table) doubled AT A MINIMUM. Game Nukes (scenary nukes or those provided by power-ups in arenas) are a special effect provided by the base game system and are not duplicateable by any home system regardless of how wired the home console is (security features in the Main system will disable any duplication of this arena function, and no amount of tweaking or recoding at home or on the mainframe system will disable this)

Mackie eased the Zephyr out of the starting alcove of The Core's upper level, immediately using her high-powered sensors to spot the BMBM on the far side of the chamber.

She lined up a shot on the advancing m00se-mek, then blew it away. "You Win! Total match time under 30 seconds! Double Score!" The glowing golden letters marched across her main veiwscreen, but all Mackie felt was a vague dissatisfaction and the sense that she'd wasted her playing fee.

"Maybe this thing wasn't such a great idea." she thought glumly as the pod opened. She looked across the ranks of pods to see Mustard already heading back to the veiwing area. 'That's odd, he almost always wants to talk about the fight after... but there wasn't much of a fight to talk about, I guess. I guess it's a good thing I kept a copy of the old Zephyr on this same cartridge."

She went after him to apologize. a note for gms on the use of oos ranged weapons.

This is discouraged under any but the trying of conditions. And bloody hard to to do as well when allowed. Special care MUST be made to keep these from showing, and when they show, to keep them minimized. To do otherwise will cause these weapons to start a cycle of higher damage levels that makes the game most unfun for lower level player (high level players being the starting point for the basic CAPABILITY of creating an OOS weapon of ANY type). The baseline requirement for OOS construction is VM prog +8, Masters standing, and a LOT of time to program VS a design and coding roll (that is 2 seperate checks) Vs 25. NO LUCK ALLOWED. "Sport" characters like Jaired are possible but only with GM approval and strict controls and monitoring. In addition, the mech that uses an OOS ranged weapon will be auto- matically considered two full grades higher than it actually is (I.E. a 375 CP Regular would be considered a Master level VM for purposes of Rep gain/loss)

In order to discourage players from using OOS weaponry, we suggest that the manager of the local VM center have an established set of rules that would allow or disallow their use, along with a set of penalties for breaking the rules. Remember EVERY VM is checked before allowing its use in the VM network every time a player wants to use that particular disk. In God we trust, all others get virus-checked and compatability scanned.

Suggested penalties inlcude, but are not limited to: Loss of 75% of Rep for unjustified use of an OOS on an overmatched opponant, revokation of VM priviliges (gets kicked out of league and loses all standing), permanant gain of bad Rep for unsportsmanlike conduct, rejection by all friends (social priority goes into the toilet and gets flushed noisily. Repeatedly). The point of all of this about OOS weapons is that most folks would like a balanced game world to run around in. It is not fun to build the Ultimate Fighting Machine if nobody will go up against it.

One final word on OOS and SuperVM construction: Just because these rules allow for the creation of VMs that will be undefeatable does not mean the GM should allow such creations to run around in his game. This is an anime based game at its heart and more often than not Our Hero is not invulnerable or unstoppable (there are some anime out there that do have this, but we are not considering those Over the Top shows, good as they may be). Anime is based on conflict, soap-opera and adventure. If your players are capable of stopping everything thrown at them with out significant effort (and the occasional defeat) then what is the purpose of playing? Cut straight to the closing scene and find something else to do because we are interested in enetertaining you with a new world and its possibilities, not wasting you or your players time.

We now return you to your regularly scheduled VM Construction.

As an example of control layout, A good friend, Jaired Grey recently let me look at his cockpit-in-progress for the "Mistwalker", his current VM in design.

Once he decided on the standard dual-joystick congfigura-tion, he decided to keep the multi-function-displays (MFD) a simple as possible. The joysticks control overall movement, shift both left, the unit slides left and so forth.

Arm movement is activated with the thumb buttons. Primary weapon is set to the right trigger, and primary defensive is set to the right. Drone launch/ recovery is on the secondary right thumb with drone target designation on the secondary right thumb. Thruster controls are set to both pinky triggers.

The MFDs are set as follows: Center MFD, game radar (variable ranges are set with on screen buttons). Left screen,commo and damage display (self or target) Right MFD, electronics (he refused to set this with anybody around).

Please keep in mind that he is using one of the simplest control sticks available on the market. (I suspect that this was meant more for a demo on how to set up controls than what he actually uses - he always takes a bag into his pod right before a match).

A matter of good forms

One of the strengths of the VMP Language was the ability to embed vehicular and biomorphic capabilities into the VM code without having to resort to continuous self-referencing of a VMs code for capabilities (thus avoiding exessive code bloat). Instead the VMPL uses Lightweb hyperlinks to the information on the current form, and when needed, an alternate set of forms.

What that means in plain english is that VMPL uses a new referance system for Transformation of a VM. Wih that referance system you can create a completely new form with entirely new capabilities by referencing the appropriate part. Want your arm servo to morph into a bats wing? No problem, simply refer in the code structure "Metaform arms into Bat wings". Of course it is better to reference the specie (for biologics) or model/part (for mechanicals). Enclosed on the Optional Rules Appendix: Custom Transformations is a sample set of reference commanands and the system cost for inclusion. Enjoy.

CONTROLS

After the VM is designed and built, the player defines his control systems. This is a simple but crucial task. Due to the amazing number of supplemental control systems available, the controls have to be specifically defined for the system to recognize and utilize their capabilities. If the control system is lost (IE you can't find your VR helmet) then you will have to come up with a replacement or redefine the controls to work with the default controls that come with the Pods. If you don't redifine, then either your VM will do nothing in the arena environment, or your VM will do very strange things that are not likely to be helpful.

The pods come with a default control set that most players utilize: four visual screens that provide a 180 degree visual panorama, there are also 2 4 button joysticks and 3 programmable function touchscreens (similar to ST:NG), and a Game Radar. The Game Radar will provide a 360 view for visual range only, this is not the same as buying the sensor version of radar. Only one of the joysticks are fixed, the other can be removed and a supplemental system can be installed. Installation is simple, all that needs to be done is to plug the control runs into the pod. For the players that DO manage to get ahold of some of the more expensive systems (see Equipment) there are problems with the Virtual Reality systems. The VR systems provide sharper clarity and better refined targeting, but they do have a tendency to "go on the fritz" very easily in the middle of a battle. This is due to information overload for the helmets control computer. When designing the VM the programmer defines what (s)he wants the visual displays show and how they show it, this is done by hooking up the editor to the family holo-sim, and then selecting/defining the controls to match the VM and the pilot. The controls are completly designed by the player...if the player wants an Evil Laugh every time the SUUPPAAA Laasserr! is fired then that is exactly what happens.

Communications between opposing units is provided via a voice activated open channel. Team freqs are preset before the match and can't be intercepted and decrypted without the proper equipment (ECM).

Combat notes

If there is a cockpit hit, the computer will judge the impairment of the pilot. ALL pilots, regardless of their BOD stat, will be treated as if their BOD is a five (5).

Power and Endurance of the VM will depend on the energy source selected. see the table below

Type Endurance Spare power allowed?

standard unlimited NA

power cell 4 hours (game time) yes, per std rules

combustion 3 hours (game time) yes, but needs to be payed for

bioenergy NOT ALLOWED

other GM discretion GM discretion (think REAL hard on this)

Screen controls are considered standard - that is what the VM pods were designed to use so there are no plusses or minuses with this.

Manual controls (- 0.05) these were the only to be found on the first two generation pods (San Diego area). There are no shortcuts, no action commands or programmable features. - 2 on initiative. +1 for piloting (better control feedback) Modern pods CAN be tweaked to reproduce these controls for retro-compatibility of nostalgics. It also spares a bit of code size...

Virtual controls: (+ x0.05) need VR kit (see equipment) to use this, standard bonuses with the danger of control overload and the fact that you can't use you VM if your VR kit is damaged IN ANY WAY

Thought controls (x.5) are STRICTLY GM's choice. They are NOT USED in any setting but the darkest. Cutting edge to boot. Available only from weapon manufacturers and usually (read: ALWAYS) has some severe side effects... Oh, well, on lighter settings they also do exist on the open market, but even on lighter settings kids don't usually have enough money to buy a toy that is more expensive than a car... and the side efects still do exist. On VM, you won't get directly damaged by a TC VR kit (Bonk damage, remember?), but you would feel really dizzy... nah, the printed documentation says that this efect is just temporal... it does say that, right?

Back to the Index

Back to Chapter 4Go to Chapter 6