Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411491 Posts in 69371 Topics- by 58428 Members - Latest Member: shelton786

April 25, 2024, 04:10:03 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Handing In-engine "Cutscene" Movement
Pages: [1]
Print
Author Topic: Handing In-engine "Cutscene" Movement  (Read 1215 times)
RyanHuggins
Level 1
*



View Profile WWW
« on: June 28, 2015, 07:05:59 PM »

I'm not sure where to post this exactly, but because it's a potential design pattern implementation of some sort, I'm going to ask it here! THIS IS A QUESTION FOR A 2D PLATFORMER TYPE OF GAME. Really though, answers from any type of game would be cool too!

I'm just curious how all you fancy game developers go about writing your movement systems in a way that makes it easy to move units through scripting interfaces for in-engine "cutscenes". My definition of cutscene here is pretty broad, but what I essentially mean is I want to move my unit from point A to point B then to point C after displaying dialogue.

I fully understand how I'd go about writing the actual interface for giving those commands, but I'm always interested in how other developers actually handle MOVING the objects and units to those locations. Do you guys use the physics engine and just move the units or is there some sort of magic cutscene/animation system that people use that is different from the in-game physics engine??

I've done it so many ways and I've never really been happy. So, just curious!
Logged

Armageddon
Level 6
*



View Profile
« Reply #1 on: June 28, 2015, 07:48:26 PM »

I'm very curious about this too, especially in third person games where the character can move to position seamlessly. I imagine you'd write the player controller as if it's an AI that your keyboard controls or something and have it act like all the other AI in the game somehow so you can tell it to move into place and face areas and such.
Logged

Hydorah
Level 0
**


Improved Push Movement (Final?)


View Profile
« Reply #2 on: June 29, 2015, 02:00:28 PM »

http://www.cavestory.org/guides/basicmodding/guide/tsc.html

Pixel used a scripting system to set up all his dialogues/cutscenes. It works good.
Logged
Shashwah
Level 0
**


View Profile WWW
« Reply #3 on: July 01, 2015, 02:57:00 AM »

You would no doubt have to use a scripting language with an interface of some sort.
Scripting things like cutscenes is the easiest way to do it, it doesn't even have to be anything big; it can simply be a group of commands that are also in a dictionary. So the command of player.moveUp would be two parts "player" which would obviously be equal to the player object and the "moveUp" which would do your normal movement code for going up.
An example from myself (a swift programmer) it would be something like this:
var objects = [
    "player" : PlayerClass,
    "enemy" : EnemyClass
]
var commands = [
    "moveUp" : Entity.Up,
    "moveDown" : Entity.Down
]

Then you just get what object you are affecting and then apply the variable change or function call or however you normally make them move and it should all work properly.
I hope this helped in some way, good luck with it all.
Logged
oahda
Level 10
*****



View Profile
« Reply #4 on: July 01, 2015, 10:48:20 AM »

I wouldn't rely on AI movement or pathfinding or the like for a cutscene. Too important. Should be hardcoded (but scripted, as suggested by others, so that it's easy to modify) IMO. But of course you can write systems to help you out, like tweening characters between positions in a way that they would move when walking normally and so on.
Logged

ThommyTheThird
Level 0
*


View Profile
« Reply #5 on: July 02, 2015, 02:31:59 AM »

As others have said, a solution that is both elegant (code-wise) and easy to use would be to hook up a script to your regular movement code. Normally you'd listen to key inputs and call a method on a character, now you're using your script to execute the same movements/actions in a controlled environment. (Preventing player input while it happens!)

It could expose flaws in your movement system, but it would also result in real in-game cutscenes. The movements seen in the cutscene can be reenacted one-on-one, and allows you to show off bosses abilities accurately.
Logged
Sqorgar
Level 0
**


View Profile
« Reply #6 on: July 02, 2015, 04:44:11 AM »

My approach was to make the game out of cutscenes, rather than the cutscenes out of game. By that I mean that the characters on screen are a view of the game model, with the cutscene directions being the controller. I use an actor/stage metaphor.

Each actor has a queue of commands that it can follow. Move here. Play this animation. Fade visibility. Stuff like that. The commands set up animations and return immediately, so there's also commands to wait on animations or delay the queue for a few seconds. So the actor's command queue might look like:

MoveTo 64,85
PlayAnimation "Walking_NE"
WaitOnAnimation position
MoveTo 300, 85
PlayAnimation "Walking_E"
Delay 4.5

And so on. Basically, each animating attribute has 7 commands (set, moveTo, moveFromTo, shift, abort, complete, wait).

Above that, I've got a Stage and a queue of stage directions. They are very similar to actor commands, but are more for coordinating multiple actors. So you can send actor commands to any actor, wait on actors, create new actors, and so on.

Ted: MoveTo 64,85
Ted: PlayAnimation "Walking_NE"
Mike: PlayAnimation "ImpatientWobble"
WaitOn Ted
Mike: MoveTo 1,1

So the actor commands control the actors and the stage directions coordinate multiple actors. This system was largely designed for turn based strategy games where you make up complex behaviors involving multiple actors on the fly, but I'm fairly sure it can be used to build adventure games or cutscenes within an action framework. The most important part is the ability to block the queue based on various events. I'm assuming that the most important events are actors finishing behavior (waitOn) and waiting a set amount of time (delay).

I animate the position attributes directly, so if I wanted some sort of complex path to be followed, I'd probably break it down into a series of MoveTo/WaitOn instructions. One way to do this is to use a stack instead of a queue, so a command "PathTo x,y" could be popped off, and the individual commands could then be pushed on in its place.
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic