Virtual Reality Studio 2.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ Virtual Reality on your desktop  Neil O'Rourke   <> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <>   Introduction ~~~~~~~~~~~~  Virtual Reality should be nothing new to most readers - basically, it is a name given to software that lets the user interact with (in real time) objects that populate a 3D world inside a computer. Such programs include F19 Stealth Fighter, Falcon, StarGlider II, Driller and Castle Master. The last two games mentioned (Driller and Castle Master) have at their heart a system developed by Incentive, Inc a couple of years ago when 8 bit computers (ZX Spectrum, C= 64, CPC 464 etc) were all the rage, and the 16 bit systems were making their debut. FreeScape is the name of their system, and a darn good one it was, too (If you've ever owned a Sinclair ZX Spectrum and saw Driller running on it, you too would be impressed!). This system was ported over to the Amiga, and used to create the Castle Master and Driller games, however the Freescape novelty was beginning to wear off. Incentive released the FreeScape system for the public to play with under the guise of 3D Construction Kit. Last year, an update was 3D Construction Kit 2, a piece of software now unobtainable in Australia. I tried to get it from one place in Sydney (I won't say who they are, but those slack peoples know who I'm talking about, don't you, Mate?),and after FOUR weeks of promises ("Yes, its in stock. I'll send it to you on Comet", "Sorry, it wasn't in stock after all.", unreturned phone calls, "It was shipped to us a few days ago, but hasn't turned up yet", until finally "We cannot get this product at all.") I got very sick of them, and cancelled the order. The other place I called said to me: "Never heard of 3D Construction Kit 2. Are you sure it isn't Virtual Reality Studio 2?". Well, it was. Thanks, Karl, and to all the guys at Egghead for putting up with me and my near dead Visa card.  The Software ~~~~~~~~~~~~  VRS2 came in a box with a manual, a clip art catalogue, two disks and a tutorial videotape (NTSC/60Hz, unfortunately. I've had it dubbed to a PAL/50Hz tape, the cost normally around $40). The inclusion of a tape was a good move. Having read the manual (a bit) and playing with the system (a lot), the tape provided some inspiration to actually DO something. The advantage of the tape was also to see the program (abeit the IBM version) running, and the ease with which objects can be created and animated. The main disk has a hard disk install program, which is one of the best I've ever used. Installation on to my drive was a breeze. Double clicking on the main program icon brought about a software failure requester. My system consists of an Amiga 2000 rev 4.4, a SCRAM 2000 SCSI Hard disk controller with 8 meg of RAM, and a MicroBotics VXL-30/25MHz '030/FPU accelerator with 2 meg 32 Bit ram. I have the ROM mapped into 32 bit RAM with the FastROM option. After this crash, I fell back to the 68000, and the program worked. I soon found that the program was allergic to having the ROM mapped into 32 bit RAM (methinks the fault lies in the 68EC030 chip and the FastROM, but with no documentation I can't really be sure). Disabling the FastROM option, the program now works well. VRS2 is a realtime 3D animation package. It is primarily designed to be a games creator, but has some more depth than that. Because it is realtime, speed is of the essence, so the program runs in 16 colour lowres (although it has hundreds of dither options available as well), giving finished projects a Videoscape look (if you've seen Driller or Castle Master you'll know exactly what I mean). Running on my '030/68881 system, the calculations fly and the screen redraws fast, on a stock system is is a bit clunky (but still useable). The program doesn't make use of the math libraries (and hence an FPU), so the speed of your completed projects (note I didn't say games) depends totally on you CPU speed.  Productions ~~~~~~~~~~~  The first project anyone probably wants to try is a 3D shoot-em-up set in space, but this is but a fraction of the programs potential. Although the users input is limited to moving around, activating and shooting things, games of some depth can be created IF you can imagine it. The use of sensors (proximity devices), hidden objects, teleports etc can make for a varied adventure game, for example. Other examples of 3D polygon games are Robocop 3 and the stunningly beautiful but supreamely difficult Virus. Midwinter is a game of massive depth, also done in 3D polygons, so there is heaps of potential there. Again, to use this product effectively you must have the time and imagination to realise it. Another potential use is walkthroughs of proposed buildings, house renovations, gardens etc. Because the system is realtime, the builder is not limited to a single predefined view or animation. Rather, any aspect of the structure can be examined at any time.  The Manual ~~~~~~~~~~  Previous reviews of mine have taken every opportunity to knock the so-called user manuals than came with them. For example, a program as costly as Imagine 2.0 came with a tome filled with the stuff that mushrooms thrive on. Happily, VRS2's manual is an entirely different kettle of fish (and NOT another bucket of mushroom food). For a start, although lacking an index and a bit brief in places, the manual is well laid out. Five tutorials kick off the manual, after a brief introduction to the concept of 3D, then every control panel and menu item is summarised and shown in the menu reference section. Then there is an FCL (Freescape Control Language, more on this later) tutorial and FCL reference section, taking up half the book. This is good, because FCL has over 300 commands available. A couple of appendicies round out the manual, consisting of hard drive installation, some common questions and a keyboard shortcut reference. The style of the manual is quite up beat and never patronising. The authors have a quirky sense of humor, and their prose had me actually laughing in places. For example, in the section about how to make objects react when shot (titled "Holy Exploding Cubes, Batman!!"), the first paragraph reads thus: "By now, you will have noticed that when you have the arrow (mouse cursor) on the view window and you click the left button, four flashing lines appear from the corners and converge at the arrow. To the more violent among us, this will be immediately recognisable as shooting. New Age pacifists can take this to be sending out rays of love to pacify and remould the negativity of the location, but the program calls it shooting." Rays of love? Now there's a notion! That is the style of the manual throughout, and this, coupled with the fact that the tutorials are happening in real time, make following the tutorials an absolute pleasure. Contrast this with the massive tutorial in the Imagine manual, which was not only a chore but a slow chore at that. There are some amusing typos (try "diskovery") but these do not detract from the flow of the manual. The manual does appear incomplete, however. The tutorial on FCL (don't worry about this for now) mentions an advanced section that doesn't appear. Oh, well.  3D Object Creation ~~~~~~~~~~~~~~~~~~  All objects in VRS2 are formed from ten basic primitives: Cube, Pyramid, FlexiCube, Line, Square, Pentagon, Hexagon, Triangle, Sphere and Quad. From these simple (and not so simple) bits, complex objects are formed. Bear in mind that the more complex an object is, the longer it takes to calculate and render (even on an '030!). The object creation process in unique. Firstly, you call up a primitive from the menu, colour and stretch it, and move it into place along with the other primitives you have created, all in the 3D window (no tri-views here!). If you can't see what you're doing, then simply zoom around the object until you can. After the object has been assembled, simply call it a group and then FCL can treat it just like an ordinary object. This process has its pros and cons. Although you can see exactly how an object is going to look, even as you create it, doing fine work is difficult and I've had to resort to hand editing the object coordinates on a number of occasions. Some of the primitives that you use to build your objects need no explanation, but others do: A FlexiCube is almost like a cube, but the corners don't need to remain at 90° to each other. Also, a Quad is like a square, but the corner angles can be almost anything (keeping Euclid in mind). A Sphere is simply that: a sphere. You can't distort the basic shape of it, but it can be resized. A sphere is an unusual shape to find in a 3D animation program, but quite useful. Those objects who are obviously flat (square, triangle etc) are required to "dress up" objects - a square is good for a window, for instance, whereas a black rectangle makes a convincing doorway. The different faces of an object can be coloured, of course, but if you give a face the colour 0, then that face is not rendered. This can save much time in a large object when calculating new views of it. It can also prevent some funny "show through" effects that sometimes occur when an object is being drawn. Objects can have as many (or as few) faces as you like, but bear in mind that this thing is going to be animated. My personal best record for an object was 158 objects (some animated) all on screen at once. Unfortunately, the screen refreshed at one frame a second, which is not a terrific frame rate. I've found that up to 60 visible objects to be a safe maximun to work to in any one area. Detail on objects is one area that I have second thoughts about after I design an object. Too much detail slows the system down, while too little detail makes it unclear exactly what you're looking at. Generally, I try to make the object guessable as to what it is, then try to provide clues to establish the object. This has its drawbacks, however. What would you think of a small cube chasing you down a corridor, shouting "Exterminate!"?  Object Attributes ~~~~~~~~~~~~~~~~~  Now we have a basic object, we obviously want to give it some properties. Some of the properties it can have are: * Visibility, or Invisibility * Wireframe or Solid rendering * Tangibility (is it there or does it look like its there?) * Movable * Colourable We can also make the object a: * Sensor (proximity) * Transporter (as in Star Trek) Some options are obvious, others are not. A "tangible" object is there. If you run into it, you stop (and maybe lose some hit points). An "intangible" object only looks as if it is there, for example a hidden doorway. A transporter does, as the name implies, transports the user to another place in the current area, or to a new area (areas will be explained later). Wireframe rendering has uses, but it most notably speeds up the entire system. Wireframes are drawn in the object's colours. I've used this to make a quick telephone booth. "Visibility" is different than just being colour 0. An invisible object is there, it just isn't rendered. You can still bump into it. An object of colour 0 just doesn't exist, as far as the Freescape system is concerned. A Sensor senses objects (obviously), but can react two different ways. It can be a shooter, and shoot you, or it can detect you. A shooter is somewhat limited in its actions, but a detector gives quite a deal of scope for interesting effects. Automatic sliding doors are a snap, large heavy objects that fall out of the sky are no problem, but one use I've found is to animate a Dalek! If it doesn't see you, it follows a simple program, but if it catches sight of you, well just don't hang around long. The range of the sensor can de determined by you (a short-sighted Dalek is interesting), as can the direction of sense. A Dalek can only see out of its eye-stalk, and the sensor is located there. It can only sense "in front" of it, so the direction of sense is limited to the front only. I'm working on a way to sneak up behind it to plant a bomb. Not only can a sensor have a limited range of sense, but it can also have a delay incorporated into it. By this, if a sensor senses you, it could wait for a minute or two before opening fire, for example.  Freescape Control Language (FCL) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  Having lots of pretty objects just hanging in space does not make for a very exciting game. FCL is the heart of the animation control system. FCL operates on several different levels. These are: GLOBAL: Things that must happen all the time, for example updating a clock on the screen. Global scripts affect the entire Freescape world. LOCAL: A local FCL script is almost like a global script, but only controls things in the current area. I'll discuss the difference between Worlds and Areas later. CONDITIONAL: A conditional script is attached to an object or group. Whenever some interaction takes place between the player and the object (for example, the object is shot), then this script is executed. The script can choose to ignore this interaction. PROCEDURAL: A procedure is a chunk of Freescape code that is useful almost anywhere, for example updating the score on the players' control panel when something happens. A procedure can be called from anywhere. ANIMATOR: An animator is a seperate script to control the animation of an object or group. It is the only way to have things moving of their own accord in the game system. The language resembles AMOS in many respects, but is much more specialised into making 3D things happen. Also, there isn't a single, large program to deal with. You simply select the object or group you wish to program, and enter its control script. If you delete that object, you also delete all its commands too. The control statements are: * For ... Next loops * Loop ... Again loops (same as Repeat ... Until) * If ... Then ... Else ... conditional statements Although a small number of conditional structures, the possibilities are endless. A set of global variables can act as a trigger for other objects, but the whole system doesn't bog down into massive scripts (well ... it can if you let it). Each object has its own script to follow, and all this can completly ignore the user is desired. Of course, the ubiquitous GOTO is included in the language, although it is called Jump (Goto is used to tellan object where to go). As an example, suppose object two is going to react when it is shot. Suppose that it will fade out. To enable this to happen, we attach the following script to object two: if shot? then fadeout(2) Now, this object could be following some global actions, but still have this little script attached to it. So, if its is shot, it fades out! Simple, and then we could have extra statements in out little script that modify some global variables to cause another effect now we've shot this object. FCL also has a full complement of drawing commands, but these use absolute screen coordinates. You can draw circles (filled or hollow), plot lines, draw rectangles (also filled or hollow). Also, disk commands are included for full file handling. The files are sequential files, but the ability to have off line files is unique in this sort of program.  Virtual Worlds ~~~~~~~~~~~~~~  In Virtual Reality Studio, Worlds are constructed of linked areas. Now, an area is quite small (only 8192 by 8192 by 8192 units), but big enough to create a room, a view of a house and yard, etc. The number of worlds you can have seems to be limited by available RAM (but I wouldn't be surprised it you can only have 8192 areas). You link areas by the use of Entrances and Transports. An entrance is where you enter an area, a transport is where you leave it. Doors make a good point for a transport, and if you place an entrance just in front of it then the effect of leaving and entering through a doorway can be quite realistic. Areas can have their own colour schenes. As an example, suppose you are exploring a space station, and find the teleport room. You could select which planet to teleport down to, which would be a different area. This new area could have purple grass, pink sky and a blue sun (if desired), reinforcing to the player that they have left the safety of the space station. An area can also have its own scale. The smaller the scale, the bigger the apparent area is. By setting the scale to the maximum value, you get an effect like Gulliver in Gulliver's travels. This can be changed by an FCL script, so a shooter that shoots you needn't kill you. It could just shrink you, or cause you to grow so you can't fit back into the teleport.  Sound ~~~~~  Sound in VRS2 is limited to playing back prestored samples. The samples are stored in a bank, and the bank is edited with a supplied utility, 3D Sound. Sounds are limited to raw samples (IFF don't appear to be supported), and can have a number of special effects applied to them. These sounds are saved out of Sound as a bank, and loaded into VRS2 upon request. The effects you can apply to are a sound are pretty basic, and I've heard much better out of Audio Engineer, but its better than nothing. The effects you can apply are * Echo - echos a marked range * Metal - "heavy metal" distortion * Reverb - applies reverb * Chorus - adds a chorus effect * Treble - treble boost * Bass - bass boost Slider controls affect the level and duration of the effect. To be rather blunt, these "effects" are pretty, umm, "naff" (as the British mags tend to say). Stick with your sampling software's effects, and use 3D Sound to build a sample bank. Back in VRS2, you load the sample bank, and do some fine editing within the sound requester panel. There is no documentation as to the sound requester panel, so I've had to guess as to its functions. It is possible to set the pitch and volume, but so far I've had no luck in setting a looping sample. Stereo panning is possible, but the method to do this is a real pain, plus syncronising it all is a hassel, too. Samples can be played on predetermined channels, and can be activated anywhere within the program's world (currently, I've got my Dalek to shout "Exterminate!!!" if you stray into its field of view). I'm disappointed that the program doesn't support soundtracker modules. I hacked the runtime module to load and play a soundtracker module, but this is not a nice solution. It isn't a solution that most users would be able to effect, either.  Other Things ~~~~~~~~~~~~  You can't have IFF pictures as a backdrop, unfortunatly. However, you can have IFF's as a forground picture, as a control panel, status panel etc. Here yoo can have instruments such as gauges, dials and digital readouts. You can also set up any command buttons you require (Foward, back, turn left or right). You can also include bitmapped graphics in the games. The program supports the concept of Animbrushes, although you can't import direct from DPaint. These brushes cannot be interacted with in the usual way, but can be triggered as the need arises (for example, a bitmapped explosion). They also make great backdrops (like a planet turning slowly beneath a space station or a moon orbiting a remote planet). You place the bitmap at absolute screen coordinates, so bitmap scaling isn't possible. The input routines can be configured to suit your needs. By default, pressing the LMB gives a shooting sound and four lines from the sides of the screen. I've a lovely sound from Aliens, where Ripley loading and firing a gernade from her rifle, but remember that there is a time delay between loading and firing, a factor that you have to consider if you decide not to use the default firing routine. Attention to detail such as this can make the difference between an OK game to a great game, however. Speaking of firing routines, the system maintains a list including how many shots have been fired. Useful if the gernade launcher can only fire five shots. If the shot count reaches five, then you can disable shooting until you find more ammo. Other system variables include * Viewpoint X,Y,Z and rotation * Number of times shot, crushed, sensed * Mouse x and Y * Last mouse button pressed These are mostly Read/Write variables, and can change the whole status of the game if you wish. The colours used in the game can be set from within a game. This could be used to simulate lighting. As an example, suppose you appear on a darkened space station. Find the light switch, and have an FCL script run the colours up to maximum brightness.  Creating Games ~~~~~~~~~~~~~~  This section is deserving an article in its own right, but for now: Plan Your Games. Make maps before you turn on the Amiga. Work out what will happen in each area, and what requirements are needed to complete it. Use the game constructions wisely. Remember, if a game is frustrating because there is no logic to it, things just happen, then this is a game that will not be played for very long. Give the player every chance to live. In fact, some of the better adventure games around today make it very, very difficult for the player to be killed or kill him/her self. Dead ends are a definite no-no, especially if it isn't obvious as to why there is a dead end there in the first place. Don't make every game the same, as VRS2 can be anything. Although all my examples are based on science fiction, this is by no means the limit. I doubt that anyone could bring a Barbra Cartland novel to life as a Virtual Reality game (the mind does boggle a bit), but the senerios are almost endless. How about a gothic horror, set in Sydney, where the player must venture into the dark dungeons that make up Central Railway Station to discover the reason that trains seldom seem to run on time? Or searching the bowels of State Parliment in Melbourne, searching for a creature of mythical proprotions and nature, the Balanced Budget! Above all, plan a game that *you* would enjoy playing. If you don't like it, who else will?  Problems ~~~~~~~~  No piece of software is perfect, and VRS2 is no exception to the rule. Although it can be a very nippy piece of code (considering it is running in 3D), at times its performance is downright sluggish. For example, all the control panels are beautifully rendered, with the buttons having a sculptured 3D look to them. Unfortunately, they give no feedback whatsoever as to whether they've been pressed or not. The program has locked up and crashed on four occasions so far (not counting the FastROM problems). To its credit, there are no real bugs that I've been able to find. The program open on a 320 by 200 screen, with no option to change it to PAL, or at least make it an NTSC screen. Trying to perform an operation on the floor, like resizing it, usually hangs the program. You can delete the floor, but nothing else. Pity... The system is very much a closed loop. It has no AREXX port and no cli command function. Since it only supports its own samples, music is impossible with VRS2. An AREXX port would have made life much easier. Although heaps of objects and worlds are included with VRS2, there is no complete game to see working and experiment with.  The future ~~~~~~~~~~  The next generation Virtual Reality system is coming, and is called Superscape. Although not yet released on the Amiga, the system features: * Texture mapping * Massive world size * Realtime lighting * Multiple screen resolutions * Networking This sounds very good, and as soon as I can find it AND have the cash, I'll get it.  The bottom line ~~~~~~~~~~~~~~~  Virtual Reality Studio 2 is a massive program, the results of which can only be determined by your imagination, patience and skill. It is NOT a game creator along the lines of SEUCK, because although the games created will look like a VRS2 game, the depth and playability of these games can be tremendously varied. Any successeful game made with this utility will take long hours of planning and much patience to test, but the results will truly be worth it. I'm told that AMOS 3D produces similar style graphics, and can generate better games, than VRS2. That could well be true, but I only own the original AMOS, and dislike it so much that I've never bothered updating it or purchasing extensions for it. From what I can gather, VRS2 will not replace completly AMOS 3D as a 3D games creator, but VRS2 is a much more user-friendly system that gives immediate results, rather than the myriad of line of BASIC code needed to get AMOS up and running. If all you want is to write 3D adventure style games, then VRS2 is for you. Before going out and buying this program, take the time to assess your needs in a 3D system. You can't make 3D demos along the line of various Euro demos, nor will you be writing StarGlider III. If you need complex character action of your objects, then implementing this in VRS2 is quite difficult. If your coding skills are limited, though, then this could easily be an answer to a frustrated game creator's prayers. Do I like VRS2? Yes, I do. It has its place on my hard drive, and I'm currently writing a game based around Doctor Who. Can I reccomend it? Yes, but with reservations. Plan to spend time with the package, and plan to use it. But don't expect much better than CastleMaster or Driller. Virtual Reality Studio 2 costs $169. It requires 1 meg of ram, and is compatible with all Amigas. I bought mine from Egghead in Sydney, phone (02) 415 3383.  <> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <%> 34 <>