Clean Cinema System

[Chaosy]

I was toying around with methods of how to make a cinema as easily as possible.
I came up with the following

system

//! zinc
    library Cinema
    {
        public type callback extends function(integer);
        integer count = 0;
      
        public function Transmission(unit u, string name, string msg, real dur, callback cb) {
            TransmissionFromUnitWithNameBJ(GetPlayersAll(), u, name, null, msg, bj_TIMETYPE_SET, dur, true);
            count += 1;
            cb.evaluate(count);
        }
      
        public function Default(integer i) {
            debug BJDebugMsg(I2S(i));
        }
    }
//! endzinc

//! zinc
    library DEMO requires Cinema{
  
        callback scene[];
  
        unit u;
  
        function onInit() {
            u = CreateUnit(Player(0), 'hfoo', 0, 0, 0);
      
            // function needs to take an integer
            scene[0] = function(integer i) {
                ShowUnit(u, false);
            };
      
            Transmission(u, "Footman", "Hallo", 5, Default);
            Transmission(u, "Footman", "My name is", 5, scene[0]);
            Transmission(u, "Footman", "John Cena", 5, Default);
        }
    }
//! endzinc

The demo will make the footman say three messages, each lasting for 5 seconds and when the John Cena message is displayed the unit disappears.

Using this method you can make all your dialog neatly stacked at one place while putting camerawork and movement elsewhere.

This is obviously not a final product but I think the concept is worth exploring, thoughts?

 

[Zwiebelchen]

TransmissionFromUnitWithNameBJ is terrible as it uses waits. You should rewrite it using proper timers. Also I'm not a big fan of Zinc, but I like the concept!

 

[Chaosy]

The main reason to use zinc in this case is that you can use anonymous functions. But it is not a requirement.
I will look into rewriting this eventually.

 

[Dr Super Good]

TransmissionFromUnitWithNameBJ
is terrible as it uses waits. You should rewrite it using proper timers. Also I'm not a big fan of Zinc, but I like the concept!

When dealing with cinematics one either has to normalise game speed and use timers, or use waits. Cinematics have to run using real time and not game time.

My concern with this approach is the JASS overhead. Features such as anonymous functions are often implemented by placing the code in a function and binding it to a trigger using the add condition or action functions. For any reasonably complex cinematic you might end up with hundreds or thousands of such triggers and a really bloated map script.

 

[Chaosy]

anonymous functions are not required, I just use it because it seems cleaner to me on the front end.

 

[Zwiebelchen]

When dealing with cinematics one either has to normalise game speed and use timers, or use waits. Cinematics have to run using real time and not game time.

Why would you want that? You want game time, everything else makes no sense. As soon as you have units walking around they would end up at different places depending on game speed otherwise.

My concern with this approach is the JASS overhead. Features such as anonymous functions are often implemented by placing the code in a function and binding it to a trigger using the add condition or action functions. For any reasonably complex cinematic you might end up with hundreds or thousands of such triggers and a really bloated map script.

I see that argument a lot lately. Don't use struct extends, don't use this, don't use that...
What's the big deal about triggers? It's 2017, we aren't running this game on the toasters it was designed for originally. Spamming triggers is fine.

Clean code trumphs speed 99% of the time. And the 1% are basic fundamentals like unit indexers, damage detection, etc.

 

[Dr Super Good]

Why would you want that? You want game time, everything else makes no sense. As soon as you have units walking around they would end up at different places depending on game speed otherwise.

So that people can hear the voice overs and read the text...

What's the big deal about triggers? It's 2017, we aren't running this game on the toasters it was designed for originally. Spamming triggers is fine.

Computers are not that much faster in 2017 as they were in 2010 as they were in 2004... Especially doing single threaded x86 (32 bit) stuff not compiled for them.

Well maybe they are 1/3 faster, seeing how it took 15 years to advance 1 GHz...