Cutscenes, dialogs, etc

[Vincent]

Allright, I will.

[bluemonkmn]

Have you had a chance to try it yet.  I've added SpriteRecorder to source control as a code object in the source code library, but I want to make any corrections that may be necessary.

[Vincent]

Hi!  Well, finally, I decided not to use it.  I'll explain why:

Using this record/playback feature allows me to make the movements in the cutscene for the character that the player uses, but it limits me in certain aspects.  The player can move the character around, etc.  But some animations are not available to the player by pressing the buttons.  So, for example, when the character dies, he is tranformed in a cloud of bats.  But I also want the character to move around (although not available to the player) in this bat form.  So I can't record inputs to accomplish that.

Also, I cannot use this to move around NPCs, like enemies and friends that are not controlled by the player.  I don't know if you remember, but my character is sort of split in a couple sprites: a hit-zone (invisible, contains most of the code for the player), the character (visible, contains animation but no code), etc.  So, when I switch to a cut scene, I freeze the hitzone, so the player cannot interact, and I make the character move around, play his animations, etc.  When the cutscene ends, I am sure to resume the game at the right position, since the hitzone that dictates everything hasn't moved at all.  The character is moved by to the hitzone location and everything is well.

The only thing that makes it tedious, is that I cannot record what I want to happen, so I have to figure it out frame by frame.  But, since I don't plan making some very difficult cutscenes, I guess I'll be okay.

I'm very sorry if I had you work on this for nothing... 

Anyway, I'm sure it will be a great addition to SGDK2, I will probably use it in my future projects, or even in this one later on.

I hope you're not too mad at me... 

Thanks for your time bluemonkmn!  I really appreciate it.

[durnurd]

You know, you could use this to record NPC sprites as well.  Just for the duration of recording, map the player inputs to whatever sprite you want to control, then when you're done recording, go back to the normal inputs.  Then, during playback, map the inputs to another playback object that has the data for that sprite.

[Vincent]

Yes, I know I could, but I would have to define a set of rules specifically for that moving the NPCs around, and well, I thing it's still a little more trouble than to just move them according to frame numbers.  I would probably do it if the cutscenes were long or complex, but since they are not (for the moment)...

Anyway, you will be able to get a more precise idea when you see the cutscenes for yourself. 

[durnurd]

You may not have built your sprites to work with it, but there's a reason that there's a separation between the player and the player sprite.  The inputs should be allowed to be mapped from anywhere, and that's a good way to design a sprite: map it's inputs from source (x) then do actions based on current inputs, including moving the sprite and performing the special abilities that a sprite can do based on the state of buttons 1-4.

If I'm explaining something you're already doing, forgive me.  But for example, it's easier to set the Right input bit then call AccelerateByInputs, than it is to manually set the dx and dy.

[Vincent]

I absolutely agree with you! 

But I would still have to map some abilities to the buttons, and those sprites are not designed to receive any inputs.  So I had a choice: either I mapped some abilities to the buttons and then record the proper actions or I could manage a timeline by counting frames and set all movements and animations by code rather than by a play back.  I opted for the second option.