Hey guys,
Ok, I figure that it's about time for a Lightning Wheels-Ultimate Roller Coaster Simulator update! Now this topic was released a few weeks ago to the VIPs, but here it is for everyone to see. It's quite a LOOOOOOOONNNNGGG post, I think it came out to be around 6 pages in Microsoft Word, but it's packed to the brim with information. If that newsletter thing ever worked out, this would be the king of all newsletters.[:p]
Plans for the immediate future:
Lightning Wheels-Ultimate Roller Coaster Simulator will be RELEASED quite soon! Yes, you read that right! The full version will soon be avaliable for purchase, and of course a free demo with some features removed. One last time, just for good measure, the full version of Lightning Wheels will soon be released.
Ok, now that you're over the shock of that, let me explain. Lightning Wheels will soon be released, yet it is not totally done yet. However before I may explain that, let me explain the versioning system Lightning Wheels uses. It is a three number system (e.g. V.1.5.2). The very first number is the "release" number. This is like the difference between SM1 and SM2. Every time the release number increases (VERY VERY rare), the user will be required to repurchase Lightning Wheels (again, EXTREMELY rare. Like going from NL1 to NL2). The second number is the "version" number. Updates to that are basically major changes to the game. Like going from NL 1.3 to NL 1.5. These updates are free, but require a complete reinstall of the game (however you will NOT lose all your files and tracks and everything). The final number is the "patch" number. These are minor changes to the game, usually bugfixes or such. Obviously they will be free, and downloadable as a tiny little patch that will not require a reinstall of the game.
Ok so back to the upcoming release. Lightning Wheels is currently on V.0.4.0. The 0 for the release number means pre-release. Basically, the current version of Lightning Wheels is a COMPLETE PROTOTYPE (with every single feature, identical to the complete game) of the complete game. It has every feature, EVERYTHING that you will see in the first release of V.1.x.x. So why exactly is this a "prototype"? The entire thing has been programmed in what is called BlitzBasic. BlitzBasic is a 3D programming language with a BASIC syntax. Basically that means that I can program the game and not worry AT ALL about the complicated techniques of 3D programming. For example, instead of wasting over an hour trying to render a single 3D model to the screen like I would have to do with C++, I can simply say "ShowModel()". This allows me to concentrate on the GAME, and not the PROGRAMMING.
So we've very quickly created a mock-up of the full game. However, now I've decided to take it a step further and just finish the game in Blitz. However, because it is in Blitz, I have no real choice over the system requirements. V.0.x.x runs on DirectX 7, meaning that it will require DirectX 7 or higher and only run on PC (due to the requirements for DirectX). That is the only main difference between V.0.x.x and V.1.x.x.
Once V.0.4.0 is totally finished, it will go up for sale with the same information I've given you here. Users will be able to purchase V.0.4.0 for $34.99 (the price of Lightning Wheels). Now you may be wondering, if the COMPLETE version will be EXACTLY the same, and they'll have to pay all over again, what's the point?!? Well, we've decided to make the upgrade from V.0.x.x to V.1.x.x completely free. This is a one time thing, and will not be offered again. So basically the adantage is that you get Lightning Wheels... now! Again, though, it's PC only.
Plans for the future:
So once V.0.4.0 is released, work will immediatly begin on V.1.0.0. This version will be programmed in C++, so I'll be concentrating on PROGRAMMING this time, instead of the GAME (the game will stay EXACTLY the same). Also, the game will use OpenGL 1.5 (or maybe 2.0). This will allow us to release the game on PC, Mac, Linux, and possibly Solaris if we find the time and the userbase seems worth it. However, Lightning Wheels was started using DirectX, so to stay true to its roots, PC users will have the option to use DirectX 9.0c instead. They will be entitled to slightly better graphics, better shader effects, and basically most of the other advantages DirectX 9 offers over OpenGL 1.5. But point is, Mac and Linux users will no longer be totally left out.
(Also, Lightning Wheels uses ALL internal file formats, so a track or object or CScript or ANYTHING created on Windows will be totally compatible with the Mac version).
Now on to the actual game. The style of Lightning Wheels has been COMPLETELY REVAMPED, setting it 100% apart from any coaster sim you have ever seen. I'm sure you are mostly familar with the CESL system previously introduced. Well the CESL (Coaster Effect Scripting Language) has been totally overhauled and the entire game is now based off of this.
The Lightning Wheels editor is actually divided into three different parts. Editor3D, Editor2D, and EditorCESL. Editor3D is rendered entirely in 3D with very little GUI. You'll use it mainly as a preview option for your track, and to edit terrain and the environment. You can also use it to edit the X, Y, and Z position of a CScript or a track position. However it is not recommended to actually create your track(s) in Editor3D.
Editor2D is like what it sounds. A 2D editor, sporting 5 different views (Top, Front, Back, Left, Right) and a nice GUI. You only change positions on two planes at a time (XY, XZ, YZ), making it much easier to create your tracks accuretly. If you've ever tried to edit a track in 3D, you'll know it's very difficult. Editing your track in Editor2D will be almost exactly like editing it in NL. Again, the only things you may do in Editor2D is edit/create your track and position CScripts.
Now before I get to EditorCESL, let me explain the newly revamped CESL system. This could take a while. CESL is a flexible, EXTREMELY-LOW-LEVEL programming language used exclusively in Lightning Wheels. The CESL language contains 7 commands (off the top of my head). They relate to creating variables and functions, executing functions, overriding CScripts, and controlling CESLScript flow. Now you'll have noticed the terms CScript and CESLScript. What's the difference? A CESLScript contains actual CESL code, but it itself is never actually executed. A CESLScript is composed of three main parts: Header, Code, Functions. The Header defines the variables that will be defined upon creating a CScript, along with other variables relating to the identification of that CESLScript. The Code is simply CESL code that will be executed whenever the CESLScripts trigger (defined in the header) is met. Finally the functions are simply blocks of code that are not executed until they are actually called from within the code of the current or another CESLScript.
A CScript is basically an instance of a CESLScript. You can drag and drop any number of the same (or different) CESLScripts from the CESLScript Library (a window on the right hand side of the screen that simply has a list of all the avaliable CESLScripts) into your environment to create a CScript. Again, you can have an unlimited number of CScripts per CESLScript. Each CScript also has it's own set of variables that you can set that are local to that CScript. The variables that you can set like this are defined in the CESLScript's header. For example, let's say you had a CESLScript that creates a tree object where you position the CScript in your environment. You simply find the script #LW_Tree (all CESLScripts start with #, and any premades start with #LW_... more on that later) in the CESLScript Library, drag it from the library into your environment, whereever you want the tree to be. A window would then open, asking you to set... say a texture for the tree and a height. You would enter these values, and then when you took it into the simulator, you would see a tree with your texture and height! Obviously, if you dragged the #LW_Tree CESLScript from the library into your environment 100 times (a different position every time), you would create 100 CScripts for a tree, and then 100 trees, all with different textures and heights (if you made them all different upon placing them) in the simulator.
Sorry if that was really confusing. It will make much more sense when you see it in action. Now the last editor, EditorCESL. This is basically where you'll edit your CESLScripts. Pretty self explanatory. You pick the scripts you want to edit, choose to edit the Header, Code, or Functions, then you edit in a text box! Couldn't be simpler. Also, there will be some kind of test-compile option, however I'm not sure on the specifics of that yet. And some functions built into it to help make your coding faster, but no specifics on those yet either. Work on EditorCESL has not actually been started yet, but work will not take more then a week to maybe three weeks at the most.
Because of the new CESL system, NOTHING will be programmed into the game. No physics, no model viewing (including trains), NOTHING. The only things are: track editing (there will be an option for bezier, spline, or one other option that is yet to have a name), terrain editing, track rendering, and I think that's about it. Not even physics will be there.
Now you may be worried about this for the following reason: "you're telling me, in order to make a roller coaster in Lightning Wheels, I have to learn a programming language, and have to put in HOURS of work, just to display my train and get it to move, with proper physics (that I have to program myself)?!?!?" No no! This is where the beauty of "Premades" comes in. Premades are CESLScripts packaged with the game that you can simply drag and drop and use! No programming required. There are currently over 500 premades planned to ship with the initial release, including a PERFECT physics script (and you release the breath I'm sure you've been holding ). All Premades are what we call "reserved", meaning you cannot view or edit their code (however you CAN see a complete list of all the functions the contain, just not the code within each function). There will be a premade for physics, a premade for trees, a premade for 3D objects, a premade for trains, a premade for lights, you get the point. All premade CESLScript's names are prefixed with #LW_. For example, #LW_Tree, #LW_Physics, #LW_Object, etc. Now there is one CESL Command called Override. If you call Override from within any CESLScript and pass it the name of a CScript, that CScript (that you gave to Override) will be "turned off" until you call the Return CESL Command on the same CScript, or until the current CScript is finished executing. This is useful say, for if you are using the #LW_Physics premade, and say once the train passes a certain point you want it to start slowing down (like the weighted trains on Top Thrill Dragster). You would simply create a CESLScript and then a CScript on the position where you want the slow down, then inside the CESLScript, simply Override the #LW_Physics script, set the trains speed lower, Restore the #LW_Physics script. Again, it'll make much more sense once you see it in action.
Now you may have one other concern. "I don't want to mess with this programming or CScript or CESLScript stuff at all! And even if I did, it would still take quite a few CScripts to get my coaster working properly!" Well there is one more beautiful CESL feature I've yet to tell you about. The #LW_NormalOperation premade. This magical (literally) CESLScript isn't really a CESLScript at all. There is NO CESL code behind it, it's all actually programmed into Lightning Wheels. All you must do is drag #LW_NormalOperation from the Library (conviently placed right on top) ANYWHERE in your environment. All by itself, #LW_NormalOperation will make intelligent decisions and create CScripts that will get you up and running properly, just as if you were making your track in NL and hit save then opened the simulator. #LW_NormalOperation will load the appropriate train based on your track, create a station and control panel, accurately initialize physics, create proper lighting, etc. I'd say about 90% of the time, you won't even have to worry about anything except dragging #LW_NormalOperation into the environment. Now the #LW_NormalOperation CScript may only be created once per file (duh). However, when you drag it into the environment, it doesn't just cause your track to operate normally. It actually creates all the other CScripts (out of premades) necesary for your track to operate normally. Therefore, if you need to, say change the train, you can simply open the train CScript created by #LW_NormalOperation and change the train! So in reality, you can build your track out of beziers (possible NL or SM import function? no decision on that yet), drag the #LW_NormalOperation script in, then just drag a few #LW_Tree's and #LW_Object's in, and hit run! You're set to go!
Well I think that's about it. If you have ANY questions or concerns or confusions (which I'm sure you do), please post em. I'm sure there's stuff I've forgotten to mention too, so if I remember any more I'll let you know. No release dates on any of this, we all know how well those have gone for us in the past. [;)] However you will see some screenshots... well soon.
Thanks guys, enjoy!
Nick Small