Skip to main content ↑ ↓
Topic: Scenario 3.8.1 (multithreaded scene manager) (Read 431904 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: Scenario 3.0

Reply #15 –
A comment on your usage of the 'with' keyword. I never really understood ( or was not motivated enough to understand ) why it is evil. In your demo it makes totally sense. But if you want to avoid it, you could have all your scene functions return the scene itself.

Code: (javascript) [Select]


var myScene = new Scenario();
myScene
    .beginFork()  // Forks the timeline
        // We're fading in, so we specify a transparent color (alpha = 0) to fade to
        .fadeTo(CreateColor(0, 0, 0, 0))
    .endFork()
    .movePerson("Katelyn", "north", 100, 2, true)
    .pause(5000)
    .synchronize()  // Pauses until all subforks are finished - we want to wait until the fade-in is finished before she blows up!
    .playSound("BigExplosion.wav")
    .killPerson("Katelyn")
.run()

Re: Scenario 3.0

Reply #16 –
Or the user could tie the $ sign to it:

Code: (javascript) [Select]

var $ = new Scenario();
$.beginFork();  // Forks the timeline
    // We're fading in, so we specify a transparent color (alpha = 0) to fade to
    $.fadeTo(CreateColor(0, 0, 0, 0));
$.endFork();
$.movePerson("Katelyn", "north", 100, 2, true);
$.pause(5000);
$.synchronize();  // Pauses until all subforks are finished - we want to wait until the fade-in is finished before she blows up!
$.playSound("BigExplosion.wav");
$.killPerson("Katelyn");
$.run();


It'll run a bit faster this way, only because cascading function calls can have some overhead for huge cutscenes. Of course this is just style, but you should implement what Metallix wants too, since it can an option that way.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Scenario 3.0

Reply #17 –
Radnen, can you explain the overhead in big scenes to me? If I have function1().function2() isn't function2 executed after function1 returned completely? Or do I got something wrong?  :o

Re: Scenario 3.0

Reply #18 –
Well, in any case I implemented the cascading scene composition to be unveiled with Scenario 3.1. It required a single line of code: return this; at the end of defineCommand(). I wish all features were that easy to implement!

Re: Scenario 3.0

Reply #19 –
Quote from: Metallix – on

Radnen, can you explain the overhead in big scenes to me? If I have function1().function2() isn't function2 executed after function1 returned completely? Or do I got something wrong?  :o


You know what, I don't think there is much overhead with that. I was thinking that because the same reference to Scenario is not being used, that  there might be some overhead with the call stack. I  could see the interpreter doing something like:

Code: (javascript) [Select]

a.func1().func2().func3();

// becomes:

z1 = a.func1();
z2 = z1.func2();
z3 = z2.func3();

//...


Which might be a bit unnecessary. Now, I don't know what optimizations v8 does. So, with that version of JS I don't think it matters.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Scenario 3.0

Reply #20 –
Well then, looks like I'll soon need to update the version of Scenario I've embedded into NShoot :)

Re: Scenario 3.1

Reply #21 –
Scenario 3.1 has been released.  A couple breaking changes in this one, might want to check the changelog before upgrading any existing projects! :)

Re: Scenario 3.5 (general-purpose cutscene engine)

Reply #22 –
Scenario 3.5 is out! This a major upgrade which introduces asynchronous operation (scene.run() returns immediately instead of blocking).  Now multiple scenarios can be run at the same time so you can coordinate stuff other than cutscenes (animations, for example)! ;D

You'll have to call Scenario.initialize at the beginning of your game now, and add Scenario.update() and Scenario.render() to your update/render scripts, respectively.  To determine whether a given scenario is still running or has finished, you can use the new isRunning() method.

Re: Scenario 3.5.1 (general-purpose cutscene engine)

Reply #23 –
So what features would you guys like to see in Scenario 4.0?  I was originally considering doing something with event flags and conditional execution, but now that I think about it that may be overreaching on scope a bit (it's a cutscene coordinator, not a game framework) Besides, persist.js is better for that kind of thing anyway...

Re: Scenario 3.5.2 (general-purpose cutscene engine)

Reply #24 –
Just released Scenario 3.5.2, now with tweening!  See the OP for details, I added an example to illustrate it. :)

Re: Scenario 3.5.3 (general-purpose cutscene engine)

Reply #25 –
Another hotfix to 3.5.3, running a scenario no longer steals the map engine input focus. :)

Re: Scenario 3.6 (scene manager)

Reply #26 –
Just released Scenario 3.6.  This will probably be the last update for a while (barring hotfixes, please test this for me so I don't have to find all the bugs myself! :P) while I think about where to go with Scenario 4.0.  3.6 is an awesome release: It doesn't take over control of the map engine anymore (camera changes and screen fades during a scene aren't reverted at the end, you have to do it yourself), which means you can use it for all kinds of stuff, not just cutscenes.  I'm using it in Spectacles for UI animations now, for example. :)

Also, Scenario doesn't require the map engine to be running anymore (unless you use map commands like 'panTo'!), which means if you need to, you can even use Scenario's scene management functionality for your title screen or whatnot.

Re: Scenario 3.7 (multithreaded scene manager)

Reply #27 –
Just released v3.7, gist updated.

This was originally supposed to be Scenario 4.0, but I decided to release the new conditional execution and looping features as 3.7 instead since it wasn't nearly as much work as I thought it'd be and it should get some testing.  I haven't had a need for these features in Specs yet, so it won't get adequate testing with just me having the code.

For 4.0, my plans now are much more ambitious, including a cutscene language (composing scenes directly in JS is awkward, the queuing behavior makes it so there's a lot of things you can't do the "natural" way) and the ability to load scenelets from other JS files.

Re: Scenario 3.7 (multithreaded scene manager)

Reply #28 –
Quote from: Lord English – on

For 4.0, my plans now are much more ambitious, including a cutscene language (composing scenes directly in JS is awkward, the queuing behavior makes it so there's a lot of things you can't do the "natural" way) and the ability to load scenelets from other JS files.

I'd be more than happy to help you with this, given that I actually have written a cutscene language for Scenario. It probably still needs a bit of work before it's more useful than JS for cutscenes though. Additionally, I don't think it works in Sphere 1.5 (it uses some SpiderMonkey 1.8+ specific syntax) although that should be easy to fix.
Anyway, I'm happy to talk about this in this thread or over PM if you have suggestions for syntax or whatever.
You can see the source for it here. There's no documentation, but you should be able to figure out the syntax from the parser which is easy enough to read (I can't say the same about the compiler).
Warning: if you do choose to go this route, it's a lot of code. IMO it's worth it, but it will at least double if not triple the size of Scenario. You'll be requiring prospective users to learn a whole new language as well - although if the cutscene language is well-designed this may be easier than learning how to use Scenario through JS.

Regarding Scenario 3.7, I can't really see how Scenario variables are more useful than JS ones since they're set before the scene is run instead of during, which makes them equivalent to regular variables, no? Wouldn't
Code: (javascript) [Select]
scene.movePerson('hero', 'north', 5 * GetTileHeight(), 1, true)
     .set('heroX', GetPersonX('hero'))
     .set('heroY', GetPersonY('hero'))
     .panTo(scene.variables.heroX, scene.variables.heroY, 1)
     .run();


move to the location of 'hero' before the movePerson()?
If set() accepted a function instead of a value, then it could call the function at scene run time to produce the value. scene.variables could be a function that accepts the name of a variable and returns a function that returns the value of the variable. Other scenelets could then accept that function and get the variable's value. In code,
Code: (javascript) [Select]
scene.movePerson('hero', 'north', 5 * GetTileHeight(), 1, true)
     .set('heroX', function () { return GetPersonX('hero'); })
     .set('heroY', function () { return GetPersonY('hero'); })
     .panTo(scene.variables('heroX'), scene.variables('heroY'), 1)
     .run();
 

Re: Scenario 3.7 (multithreaded scene manager)

Reply #29 –
Damn it, somehow I broke fork in 3.7, nobody download this yet until I figure it out. :(