OK, I'm making a cinematic scripting system (scCS)

Inspired by iNfraNe and Anitarf over at WC3 Campaigns, I decided to write my version of a cinematic scripting system building on what I think may be some weaknesses in theirs. My system will have much less custom script function code and instead rely on hard-coded trigger actions cut-N-pasted into the editor for each scene. My system will also permit you to script your cinematics in any order (so did theirs, but you ran into performance and function call limit issues if you had many events listed apart from the actual time sequence they were to be called in). Another advantage is that my system will feature much more advanced functions and numerous checks on the user inputs to ensure validity of the code. I think that my way of doing things may be faster, but that depends on whether the sheer amount of trigger code makes a difference during gameplay (my system will have much more), or whether it's solely about the number and complexity of operations that the code calls for (my system will require much less).

So, to whet your palettes, here's a sample of what my program (written in C) does:

And, here's a little tidbit of the sorts of functions I'm planning to have:

So, you'll basically have an input file with a lot of lines that look like command-line program calls, which scCS will then parse to produce a fully organized script for your cinematic. The calls to specific, in-game functions that do things like set unit locations will take place every 0.01 (or 0.02, 0.03, whatever time interval you want) seconds, and there will be a set of nested if-then statements to ensure that each function call is found in O(N log N) steps, where N is the number of time steps in the cinematic scene.

scCS is a command-line C program which will be easy to compile for any architecture. I will provide the code for the program at a later date, when I have it working on actual SC2 maps. Until then, I will be writing functions with the expectation that the mechanics of SC2 will be not altogether different from WC3, and then change a few names at the very end.

 

you are one smart cookie.

once the scripting system is complete, will it be integrated in to a WYSIWYG point-and-click program? an easy way to create powerful cinematics. a 2nd starcraft editor... this one for cinematics!

if whta im saying is gibberish, please excuse me, because i'm not completely sure what all this cinematic talk is about. in wc3, you could create your own cinematics, using the figures in the game?

 

No, no WYSIWYG editor, just the ability to type a text file, parse it with my program, and then cut-N-paste the code that my program generates into your trigger editor. There is a system for WC3 that does similar things, but like I said I'm aiming to make this system more efficient in its execution to keep the overhead of running cinematics down (also, this system will then be useable as something that runs constantly during normal gameplay to control certain unit movements, although I have yet to decide exactly how that might work.

 

ah, ok. thanks a bunch for explaining that...

i wish i could be of some help, but all i can do is html time to go learn C++!

 

Well, I wrote this for WC3, and I will test it soon, but to stimulate discussion here's the "guts" of the cinematic system. This routine is going to be called every 0.01 seconds (or whatever time interval you pick--0.02 seconds should probably work for most purposes). As far as I can tell, this is MUCH lighter on the CPU than the existing cinematic system because it avoids many function calls if they are not needed. Note that the arrays actor and particle could potentially be huge, as many as 1024 units given WC3 scripting limitations. However, in most cases there are only a handful of actors moving around the screen under the control of this system, and I have programmed numerous cinematics using the current script system and never had more than about 16 actors to deal with. In the vast majority of cases, the small number of actors and particles will keep these loops very manageable, particularly in SC2 where the CPUs are going to be stronger and one expects that the scripting system will be more efficient in its execution.

Note that there will be other functions called at particular times to set the various units in motion. So, the mechanics is going to be:

- Call "StartUnitMoving" (or whatever function name I pick when I get around to writing it)
- Computes initial position of the unit (done in-game to prevent error propagation)
- Decides how many steps will be needed to complete the desired motion given the desired velocity constraints
- Sets motion counters to value N so that motion will proceed for N steps
- Sets acceleration and initial velocity values
- Add unit to the list of "hot units" that are currently moving

- Periodic calls to "APCUpdate"
- Detect this new unit movement via a global array and propagate it
- Decrement the unit's motion counters with each step
- When the motion counters reach 0 again, evict this unit from the "hot list" of active units--it will remain in place until ordered to move again

Camera motion works slightly differently--the camera will be moved according to a preset trajectory, but there are again motion counters for the various types of camera movement. I may well re-work this part of the script, and with any luck the SC2 editor will have much better features than simply linear camera interpolation so I won't have to mess with it at all.

 

Oh, one thing to note about the array indexing for the unit position data (ac and pc for actors and particles, respectively) is that there are 8 elements to decribe the position of each unit. Three of these are for the X, Y, and Z (flying height in WC3) positions, the fourth is for the unit facing, and as yet four are empty. So, if SC2 has some more unit controls (like pitch and roll) I can add those and control them separately (that is, I can update them without having to update everything else). I'll be leaving space for extra controls that we may get in SC2, as it's easy to do when you first start to make something.

 

Yes, change of heart. The camera system will now work on a triple-integration scheme, whereby the camera coordinates get updated after velocities and accelerations (there is a jerk term in the camera movement--it's a cubic spline). With the new system (example below), the camera can now move without problems associated with roundoff (the WC3 engine only dealt with reals to a precision of 0.01, and did not use the standard floating precision numbers at all--I'm hoping SC2 will be better, but I won't count on it). So, what will happen is that scCS will anticipate these roundoff problems and pre-compute the camera trajectory. If it's off, scCS will try to compensate by doing two camera manipulations, playing with the jerk term on the second try to get the camera as close as possible to the final desired destination.

 

Yep, works like a charm. To get a camera (or anything) to move a total distance dX in a total time T, with initial velocity Vi and final velocity Vf, all you need to do is solve the linear system:

which solves easily as

Although I wouldn't recommend computing that in the editor if the precision is as low as it is in WC3, it can be computed easily in floating point arithmetic and the results can then be transferred without much trouble in precision to the program:

And, voila, you have the constant jerk and initial acceleration necessary to make the camera at point W move a certain distance in the W parameter (W could be rotation, X coordinate of the target, whatever) with initial velocity Vi to arrive at point W' over a total time of T and have a final velocity of Vf when it gets there.

There is one other (small) problem, and that is the error bound of the integrator. Using the straightforward forward Euler gets us a bit of a mess, but this doesn't really seem to be a huge problem for reasonable camera movement speeds (moving the camera 1000 units in 1 second to achieve a final velocity of only 50, essentially a very quick acceleration and then deceleration) throws us off by 3%, but doubling the time to make this move (which would still correspond to very brisk camera movement in WC3) cuts the error roughly in half and the use of a better integrator should achieve even better results.

Yay!

 

You are clever but i don't exactly understand this thread, what is it exactly about?

 

It serves as a nice way to let others in on what I'm doing, also to organize my thoughts as to how best to assemble this cinematic engine.

Do you have specific questions concerning the engine itself, or was it just the thread?

Have you taken a look over at WC3 campaigns, where they have the original engine designed for WC3? The primary function of that tool is to get around the problems with the "wait" trigger, but it turned out to also help them do a lot of things that aren't otherwise possible (or, at least, not at all convenient) in the WC3 editor. My engine will have most of the functionality of theirs, and will even get around some of the things I thought were cumbersome in their editor (which, to reiterate, was a general improvement over scripting in the WC3 Editor). Primarily, I didn't like the fact that I more or less had to list all events in chronological order. I'd much rather make separate sections of a list for different elements of the cinematic, like the movements of one character, the movements of the camera, etc. This makes it much easier to see what all is going on. You can do this to some extent in their system, but when you call events out of chronological order, the engine wastes a bunch of cycles, eventually running into a thread limit, trying to re-organize your script. So, by having a C program I will not only open up the whole new world of functionality associated with the C math libraries, I'll also be able to produce nicely organized, scripted cinematics based on human-readable input without adding any computational costs to the game. Another thing I'm hoping will improve efficiency is the way my system recognizes new events. I'm not exactly sure how it's done in the WC3 Campaigns engine, but it may involve a lot of triggers generated in the game itself. I'm going to use an O(log P) system, where P is the number of time steps in the cinematic, to ascertain whether there is something to do at a particular time step.

 

Still making progress on this. I've now got the core of the game executable, APCUpdate, working in a WC3 map. All movement is now being done in terms of cubic splines (with parabolic and linear movement of course being possible by setting the higher-order terms to 0).

The driver is also very tidy (read: optimized) in its first working incarnation. If it detects that there aren't any cinematic operations to perform, it goes to sleep. The user will work the cinematic system via a set of control functions that put units, particles, camera variables, etc. on a set of 'hotlists' for the system to deal with for a particular amount of time. Every time a new item goes on a 'hotlist' the cinematic system is woken up (no lag to worry about, it merely toggles between nominal and complete execution of APCUpdate). Thus, with every movement you order up, you will be able to specify the time that movement is to take, the length of that movement, and the initial and final velocities of that movement. scCS will take care of the rest, and I will likely even add features to the command-line executable that compiles cinematic scripts for input into Starcraft to tweak the accelerations and such by minute increments to compensate for numerical error in the integrator--all done with no added cost during game play.

So, I think I'm well on the way to making a very efficient, user-friendly cinematic scripter. If you have any requests or suggestions, feel free to drop 'em in this thread.

 

Well, a little more progress, there are now, across the board, eight coordinates for each unit, particle, and camera, and an identifier plus seven toggles for each unit, particle, and the camera. The first two coordinates are going to be X and Y coordinates of the unit, particle, or target of the camera. The first toggle pertains to the X and Y coordinates simultaneously, because they are almost always changed in tandem. Otherwise, the toggles pertain to the Flying Height (toggle 2), Facing (toggle 3), and four as-yet undetermined characteristics of the unit (could be pitch, roll, size, and transparency). In the future we could foreseeably add toggles and coordinates for other things, but 8 seems to be plenty for now.

The new code again works in the WC3 editor in my test map.

It turns out that anitarf and iNfraNe used a double-linked list to sequence their cinematics, which is slightly more efficient in terms of operations than my proposed O(log P) algorithm. However, I suspect that the operations they had to do to make that work were much more costly--involving the game cache. I'm going to keep this all very simple so that it is portable to SC2, by using data structures and logic operations that are as basic as possible--and that means integers, if/then/else, and so forth. So, I'm sticking with my O(log P) algorithm (P is the number of cinematic actions scripted by the user). For 1024 actions, which believe me is a large number for a long cinematic, there would then be 10 if/then statements required to find the correct action to execute at a particular time T. So that we don't have to do even those conditional operations every 100th of a second (which would still not be a large burden, even in WC3 JASS), I will write my command-line cinematic compiler to set a separate counter variable after each action, denoting the number of time steps before the next action is to be taken. For a 100-second cinematic with 100 scripted actions, at most 1 in 100 of the time intervals would have actions to implement, so the other time steps can just be skipped at the cost of a single if/then statement.

Again, I still think that the O(log P) algorithm can be less computationally costly than the alternatives, and I will certainly have an easier time porting it to SC2 than any of the stuff that's been specialized for WC3.

 

You lost me about 4 posts ago....

I hope I'm gonna be able to keep up with this coding or at least be able to apply it.

What is the first thing you're going to need from me?

(I.E. Battlecruiser model, etc.)

 

Oh, yes, I should probably keep this thread tidier. I'll see about deleting some of my "diary" posting and keeping it to significant updates in the future.

"All this coding" is really nothing more than this:

- A C program that I am writing will do the heavy, high-precision number crunching and thus "compile" a script for the cinematic that is easily executable in the map. This is much like any compiler works--you give a it a set of human-readable code and it does the hard work of translating that into a set of instructions that the machine can read and execute rapidly.

- The "compiled" cinematic script is merely copied into the map, where we will execute it with triggers. Again, this code will be highly optimized so that gameplay and rendering of the cinematic is not hindered by the cinematic system.

- So, you produce a text file with a series of script lines that will look something like:


SLIDE -T 6.07 -A 0 -Xi 105.2 -Yi 1934.2 -Xf 602.4 -Yf 1930.0 -D 4.50 -Vi 100.0 -Vf 300.0
< more lines >

This might mean something like "Move actor 0 at time 6.07 seconds from point (105.2, 1934.2) to (602.4, 1930.0) over 4.50 seconds, with initial speed 100.0 and final speed 300.0"

And scCS will read that file and generate a script for SC2 that does precisely that.

The nice thing about scCS being a C program is that I will have access to all of the power of C libraries, structs, and of course the calculation speed that a compiled computer language has to offer. So, I can tell scCS something like


STARBURST -T 10.02 -Pmin 55 -Pmax 105 -Xf 1049.3 -Yf -6051.2 -Zf 500.0 -Lmin 300.0 -Lmax 500.0 -Tmin 2.0 -Tmax 5.0 -F 0.80


and then scCS will see that and automatically select particles 55 to 105 and use them to create a starburst (explosion) at point (1049.3, -6015.2, 500.0), shooting them off randomly into space over distances of 300.0 to 500.0, over lengths of time ranging from 2.0 to 5.0 seconds, making them fade out 80% into their travel time. scCS will merely look at STARBURST as a call for a bunch of SLIDE actions and script it accordingly. Thus, a task that would be very tedious, not to mention cumbersome to program in the SC2 editor, can be accomplished with ease, repeatedly.

Since you asked, if you wanted to get started on a REALLY nice, detailed Battlecruiser model, that would be AWESOME. Something that could fill the screen and maintain the level of poly detail that the other models have. Do you know how to animate things in this 3D tool of yours? If not, don't worry--just to have the detailed model sitting there during cinematics would probably be OK--we could even conceivably have multiple models superimposed on each other using scCS to drive them all as if they were one. That way, you could make multiple models for the Battlecruiser base, its turrets and missile launchers, and hangars. Very cool!

 

I'll start working on a base Battlecruiser model ASAP and we'll go from there with regard to detail, etc.

 

Great! Take your time if you've got tests and things coming up. I'm trying to engineer all of this so that we can do it "a little bit here, a little bit there..." and not have to deeply involve ourselves for some tremendously difficult problem like constant tweaking of a particular cinematic element or new model animation. With Terran vehicles and ships, the models are pretty easy to construct bit-by-bit.

Do you also do textures?

 

I really couldn't say. I'm relatively new to using Maya, but I do know how to at the very least design a full model although it probably takes me more time than a better designer would.

I'll consult ArchLimit on anything I don't know, but since textures is just replacing surfaces with images, it shouldn't be a big thing.

 

Moreover, textures are images and the 3D model's faces project onto those images. So, one face (a triangle) of a 3D model will have three vertices corresponding to different points in the 2D grid of the image. In WC3, and I think generally, the vertices are stored as fractional coordinates, so you can substitute a 512 x 512 image for a 256 x 256 image and obtain higher resolution, or go the other way and reduce the size of the map download. Texturing is easy once you have a suitable map. I would expect that Maya has at least some rudimentary texturing features.

One place I'm worried you may get hung up (at least for a little while) is the conversion of Maya output to a format that Blizzard's editor will accept. For WC3 this was .mdx format, and a script was written to convert .mdl files output by Gmax (a free version of 3D Studio Max) into the appropriate format. This may or may not work with Maya output and the demands of the new editor, I don't know.

But, there is at least the promise of many dedicated people who will make conversion scripts quickly should they be needed. There are lots of people out there doing 3D models, now, so they won't take long to make a shoe-in for their talents in the world of SC2.

 

I agree. The #1 thing I'm worried about is the conversion into something you can actually use. But I think that's secondary to actually creating the model.

I understand the way texturing works, and I should be able to produce something that will be very similar to what is actually going to look like the Battlecruiser. I'll do some pretty high-res models and make textures that can be varied, including variations in lighting.

 

i was wondering what you use to make do the programming?