Repository for editions and examples of the Warcraft III Version of scCS

On another thread, I discuss the beginnings of my development of a new cinematic system which I am writing for Warcraft III in terms that are as general as possible so that it can quickly carry over the Starcraft II once that editor is available. I am posting as an attachment a map that gives a very rudimentary example of what the script does. Over the next few days, I will post updates to this map.

The system is called Starcraft Cinematic System (scCS). It is a C program that runs on the command line and produces code in Blizzard JASS that can be imported into maps.

I encourage people to download and look at the map. The custom script code that scCS produces for maps in general can be found in the map Custom Script section. Shortly, I will make the facility in scCS to read user input files containing lists of actions and compile them into fully customized, high optimized Blizzard JASS to be imported into their own triggers that will run user-scripted cinematics.

But, for now, you can start up the map in WC3 and simply type "Start" as a chat message. It's not very impressive to look at, the little Blood Elf Spellbreaker just moves to a point 1/4 of the way up and across the screen and then back. But, he also turns his facing around as he does so, as if he were a wind-up top or something. That's not possible with the standard editor, and the smooth acceleration that he makes in all these variables (X, Y, and facing) is not in fact possible with the existing WC3 cinematic system.

There are some obvious problems with the movement, however. If you type start repeatedly (let the motion finish each time, please), you'll note that his starting position migrates bit by bit down and to the left. This is because of numerical instability in the integrator. I think the best (and most efficient during gameplay) method to mitigate this is to have the C program part of scCS walk through each movement virtually as it's writing the custom script and tweak the accelerations slightly so that N discrete steps approximating a continuous movement will take you, as closely as is possible given the numerical precision of the WC3 engine, to the same spot you'd be if the movement truly were continuous. That's the next thing to fix.

In its more advanced stages, I'll make it possible to create very complex effects involving a few parameters and otherwise highly random motion, like big explosions with piece of debris flying around in parabolic arcs (or, in space, straight lines away from the origin of the blast). With a single line in a human-readable script file, a user will be able to order scCS to create a large explosion that radiates with a particular speed, number of particles, and persists for a given length of time. scCS will then diligently write hundreds of lines of Blizzard JASS to make it happen in the cinematic.

Later I'll be adding more examples to this map of the types of movements you can do, and making it possible to order unit animations from within the scCS environment, so we could animate our Blood Elf as he dances around (or, make him appear to "walk" as the engine pushes him around the map). But, for now, I welcome comments on this system and ideas for things you'd like to see.

 

A little progress to report here. The following map contains similar triggers and the same old sliding Spellbreaker, but this time he slides four times, some of them very quickly (that's when the integrator messes up the most), and his final position is reported at the end of the slides. It should come to (-694.25, 227.0), which it nearly does thanks to some in-game corrections. I think that I may have actually not got ALL of the integration steps going, rather I may have n-1 when I want n steps, so that may be another source of error (I will check). But, things are looking good--you can position units with very little error even after fairly lengthy, roundabout movements with this system.

By the way, the code in the trigger "Cinematic Backstage" was generated almost entirely by scCS given the following input file:

The input files are case insensitive (joy!), have many optional arguments (scCS will tell you if you forgot to tell it something critical), and the order in which you set the arguments does not matter.

The next things to do will be to make a "map" in scCS memory tables of when and where all the movements are occuring so that scCS can decide which hotlist numbers to assign each unit to. I will include other features soon, like the ability to type custom script into the input file for execution at a particular time, which should cover just about any functionality that general scCS functions like "slide" shown above do not.

 

You know what Picard, this is what is awesome about you, you post stuff most of us don't know anything at all about and I think that's just cool.

Same with the fact that we are so used to excellence from you that no one has seen fit to comment the obvious positive things that accompany your posts.

owerup:

hell even the thread name confuses me

I was considering power ups for many of your other threads but was skeptical, its long over due here.

 

Thank you for the owerup:, Watcher!

I hope I can get the point of this tool across once I've developed it more fully. I've now implemented an "event" struct that nicely compacts the time stamp, duration, type of event, and associated event script (as a very long string) so that I can easily make sense of an otherwise disordered list of events in scCS. What comes out does not look pretty at the moment, because the indentation is all off, but that shouldn't be hard to fix.

The trigger that initiates the events in each cinematic (I call it the "backstage" trigger) will be as compact as I can make it, and run fairly quickly--I think I can totally eliminate local variables, particularly local non-elemental variables, within that trigger, so that should save some execution time.

The real point of all this is that I'm using C as a "compiler" for Starcraft game, to write highly optimized Starcraft script code that isn't really meant to be understood by humans. You are required to make a human-readable list of events that you want to happen, but then scCS takes it and produces something that you just cut-N-paste which then executes very quickly during gameplay.

 

OK, much progress to report.

I've overcome what I was at first afraid would become a real coding nightmare, that is keeping the hotlists tidy while at the same time figuring out which slot in the hotlists to assign units to. I was also afraid that the "backstage" triggers that initiate the unit movements and such would become very crowded, possibly even too long to make some of the depthier cinematics.

But, no more! I've dramatically compacted the "backstage" code and taken care of hotlist placement issues. The updated system will still run very efficiently and makes use of a couple more custom-script functions, to have some of the list generation happen in game. Because this will only have to happen a few hundred times per cinematic, the added cost will be negligible.

The current example shows how the system can correctly move numerous units according to the user's input, which in this case was:

Next on the list is to streamline the system's ability to find the right actions inside the "backstage" trigger without doing N*P if-then evaluations (where N is the number of steps in the cinematic and P is the number of actions the cinematic has). I can cut that down to something like 2 log P operations--very small indeed!

Soon, I'll have the basic system running smoothly, and will then be able to add new functionality rapidly.

 

Boy, I can't believe how much time I've spent on this, but I'm on a roll and I'll just be thinking about how to work out bugs in the code if I don't get it to a stopping point.

We're closing in on that, in fact.

This latest commit now has the ability to merge actions that are to happen at the same time point to create even more compact script code. But, that's a fairly minor improvement. The major improvement is that this version of scCS (which I am uploading now) has the ability to bifurcate a list of events using if-then statements so that the resulting list of actions can be searched in O(log P) operations rather than in P operations. Next will be another major improvement which will put the "backstage" trigger into idle mode for the numerous timesteps in between the times it's actually supposed to do something. That is not a difficult thing to do at all, and it will save considerable computation time involved in the action searches in the "backstage" trigger.

So, what you've got in this post IS the basic version of scCS, albeit without a bit of streamlining, a lot of scripting options (to be added soon), and perhaps in need of some updates to the -help output.

The "Cinematic Backstage" trigger in the attached map was generated using scCS. Compile the code as scCS*, and then do:

 

OK, the movement precision has been greatly improved thanks to a predictor-corrector I added in scCS. With each spline it computes, it will integrate it over the requested number of timesteps and then compute a small (imperceptible) correction to the initial velocity to get the movement as close as possible to the correct value.

Seven movements now generates a position error of less than 0.5 map units, or about 1/100th the height of a sorceress in WC3--again, imperceptible. And, if any of those movements is an absolute point-to-point movement rather than a relative point-to-point move, the error will be essentially reset to zero on that move.

I am now thinking that Blizzard's numerical precision is 0.001 in WC3, but I'm still not sure. Either way, this level of precision is high enough that I don't think I have to worry about other issues with numerical error.

 

Cameras are working, all aspects of the Warcraft III camera can now be manipulated with high precision using scCS.

Next up, an example of a more complex function in scCS, which will make the camera seem to rotate about a fixed position, as if the observer were turning round and round (WC3 has a function to rotate the camera about a fixed target, but not a fixed source). scCS should be able to code this up in JASS with ease.

Then, unit facings and flying heights--shouldn't be too hard, really a re-hash of things I've already done.

 

OK, with this latest version of the code, you can manipulate units' flying heights and facings. I think I'll make the unit coordinates (there are eight available):

Index Coordinate
0 X
1 Y
2 Z (flying height)
3 Facing angle
4 Pitch (reserved)
5 Roll (reserved)
6 Size
7 Transparency

The unit animation speed is something that doesn't need to be varied too smoothly, so we'll just leave that to a more general event to accomplish.

Next, I will program a "custom script" function that permits users to place custom script directly in their cinematic as an event, which will open up another large swatch of functionality. Then it'll be on to sound effects.

 

OK, here we go! Time for a new code commit, and this time I've got the custom script parser / event producer in there. You can now type stuff like:

and scCS will take that custom script and make it fire, in your cinematic, at time -t (0.5 seconds in this case). This engine is now pretty darn powerful! Not so useful as Anitarf and iNfraNe's system, yet, but it's well on its way.

 

Things are moving along nicely; I've decided that the unit coordinates should in fact have 16 dimensions, not just 8--they now stand at:


Index Coordinate
0 X
1 Y
2 Z (flying height)
3 Facing angle
4 Pitch (reserved)
5 Roll (reserved)
6 Size X
7 Size Y
8 Size Z
9 Red vertex shading
10 Green vertex shading
11 Blue vertex shading
12 Transparency
13 TO BE DETERMINED
14 TO BE DETERMINED
15 TO BE DETERMINED


The overhead for determining, at each step, whether sizing and vertex shading is to be done is minor, because these operations are coupled in their individual components.

This larger coordinate set means that in WC3 you'd be limited to 512 actors and 512 particles (but can any computer handle 1024 units on the screen at once anyway?). In Starcraft 2, I am betting that the arrays will be larger, but we'll see.

The really neat thing to report is that I've just realized how to give an impressive (and I mean IMPRESSIVE) new level of versatility to scCS which will allow you to have multiple systems going at once, as well as the ability to loop cinematics. So, the idea would be that if you have some sequence of events that you want to be constanly going on as your cinematic unfolds, there's no reason to script endless iterations of that sequence, simply script another cinematic to control those events and specify some "-loop" option when you run scCS on the command line. Then, when you first call the cinematic (which, through custom script, you can do within another cinematic) it comes on as usual and runs on an independent timing counter. When the second cinematic finishes, though, it doesn't just turn itself off as usual, it resets its own counter variable and begins anew--it loops! To turn off the second, looping cinematic, a user might specify some more custom script within the main cinematic to turn off the triggers for the second one, and voila--precisely timed engagement and shutdown of auxiliary cinematics. All cinematics will still use the same global arrays for units, and of course you only get one camera, so it will be possible for them to interefere with each other, yes, but then again it will also be very convenient to have them both seeing the same sets of actors.

 

OK, new example map, this one showing the new script code that scCS writes, and demonstrating its ability to smoothly re-scale units and change unit colors and transparencies.

So, with all of the code in this map, you have most of scCS, but I've been making improvements to the script generator which you don't have yet, but I do intend to release at some point.

Next up, as I said, is to make it so that multiple cinematics can run simultaneously.

Happy modding!

Capt. Picard

 

OK, here 'tis, code for the new and ever-improving scCS.

This version has something even more powerful than I had intended to make at first: the ability to run, inparallel, multiple threads of cinematics. And, to loop cinematic threads. So, if you want to make a storm of units flying in a set, circular pattern, you can make a looping cinematic thread to do that. If you want there to be some variation on the pattern each time, a judicious use of the custom script capability will make that possible.

I still intend to add lots more functionality to this cinematic system, but for now it's already quite powerful.

To run the program, just compile it as scCS:

>> gcc scCS scCS.c -lm

and then run it on the command line:

>> scCS

Capt. Picard

 

Well, not too much new to report, but I verify that scCS can work with multiple cinematic threads in precisely the way that I wanted. So, it's now easy to add looping effects to your cinematics, and you can have practially as many as you want!

I also added a special effects system, so special effects can be made to take place at any point in the map, attached to a particle unit. Thus, if you want to have the special effect occur in motion, you can create the special effect and then move the particle you've attached it to using the standard ParticleSlide / ParticleField commands.

Next, fade filters! Something I've been wanting to try for awhile...

 

This dude have brains... I respect how he's posting continously, and don't give up that nobody discuss with him, because most forum people don't understand what he's talking about. His writing style makes his posts very interesting to read, I'll be glad to see how this whole story ends owerup:

 

Yes, it's stuff like this that keeps me going. :good:

The "story" will end when I produce a Starcraft cinematic using the Warcraft engine. I'll start this weekend.

I'd LOVE to have some of the Project Revolution models for this cinematic--that'd just be over the top.

This will be a good means of building more into the cinematic engine as well as testing it--I'm bound to find some things I'd like to automate as I create the cinematic, beyond what I've already come up with.

 

OK, not anywhere finished with this yet, but the next big thing is going to be a system for dealing with terrain and flying thingies. Warcraft III had this huge problem, where the fyling height of units was all that could be controlled. So, if you wanted to make a unit travel in a parabolic trajectory like a cannonball, you needed to have level terrain underneath it, or otherwise some way of compensating for the absolute height of the terrain in your scripts. This problem was compounded by the fact that the height of the terrain directly underneath the unit wasn't all that mattered--the height of terrain within a circle of radius 192 or so around the unit is what mattered. So, if you wanted to do the terrain adjustments, you needed to compute a lot of terrain heights, which meant a lot of extra function calls that could create lag.

My way of dealing with this is going to be to have scCS read in a grid with the terrain heights at all its vertices (though I'm not yet sure how to create that grid conveniently). With the grid read, height adjustment functions will incorporate adjustments for the height of the terrain so that movement is controlled in an absolute sense.

Starcraft II may well be able to deal with this sort of problem more conveniently, but it very well may not, and it would sure be nice to have this sort of control from the get-go.

 

Progress! scCS can now read a grid in what approaches "free format." You list comments on lines beginning with "#", "$", or "%" symbols. Within the comments, somewhere, you must list the fields

CELLX: the number of grid cells in X
CELLY: the number of grid cells in Y
ORIGX: the grid X origin
ORIGY: the grid Y origin
SPCX: the grid X spacing (optional)
SPCY: the grid Z spacing (optional)

All other lines are treated as if they contain data for the grid (e.g. numbers representing the terrain height at some grid point (X,Y) ). The lines of comments (and, therefore, the grid dimension data) may be interspersed with the lines data, and you may specify as many data points per line as you like, so long as you don't exceed 8191 characters, so your file could even be something like:

and scCS will read it as:

Grid = [
0.102 10.020 1.920 0.309
2.509 20.110 4.590 6.002
3.000 2.440 5.021 7.022
8.001 9.032 6.453 3.210
];


Edit: yuck, that was a lot of coding, but at least it's to the point where the new code in scCS compiles. I've also gone ahead and made scCS use multiple libraries and several more data structures so it's easier for me to keep track of everything. I'll release a demonstration of the new capabilities soon. My goal is to be able to put a big, ugly mountain (cliffs and all) in the middle of some objects flight path, and still be able to lob a ballistic unit over the thing in a parabolic flight plan.

 

OK, got it working. You can even specify to kill the particle units to create whatever missile hit effects there may be when the particles reach the ground.

I've attached a file with a cinematic generated from the following input:

(Edit: nix that input, you don't need to see that. Here, instead, are some pictures just in case you don't have WC3 handy.)

All you need to do is play the map to start the cinematic this time.

Notice, in the cinematic, how the particles shoot up fast but quickly lose speed and then drift back to the ground. This is because I've specified a "-drag" parameter. The default "-grav" parameter (the gravity force) is only 100.0, so I might increase the default in future versions.

But, to summarize, these are some very realistic pyrotechnic effects that you just can't get without some serious help like scCS provides. In the near future I intend to code similar functions to automate the creation of even more complex particle movements, to create whirlwinds of psionic energy or other cool effects.

I'm not yet demonstrating the full power of this system, because I haven't tested this far yet, but the code is all written to accomodate terrain that isn't flat and still give you that nice projectile motion, like I said in my post above. I have a system now for extracting the topography of a map quickly and then reading it into scCS (I discuss the reading part above, but the extraction system will be a trigger that you can cut-N-paste into your map, run it once, and then rummage through the game cache to find the topography--hopefully I can take advantage of some better system in SC2).

(Edit: I meant to add, in the future, the 48 lines of input used to create this explosion will be streamlined by a single "StarBurst" command, which will create a pyrotechnic display of particles with user-specified gravity, drag coefficient, and other parameters for variation in particle size, lifetime, velocity, and spread. Michael Bay, eat your heart out!)

 

I'm about 1/4 done with the Battlecruiser model, and I've started some wireframe work with the Wraith, but it's slow going with so much school work.

I haven't even started on the texturing yet.