Forum for the creative side of the game development process: art, music, storyline, gameplay, concepts, etc. Any sort of relevant discussion is welcome here.
After I finish my next YouTube video, I think I might focus on cutscenes. I've never done anything with cutscenes, but I wanted to throw out my ideas and see what you guys think.
So here's my plan:
- Each cutscene will have its own Lua script.
- A cutscene will be driven by a "timeline" object. A timeline is a list of "events" (Lua methods) and their corresponding time to be invoked.
- Lua will build the timeline and define the methods that will be invoked by the engine per the given timeline.
For example, let's say we wanted a cutscene of the player walking up to a castle:
Notice that the time defined by Lua is the time since the last event. This way one event's running time doesn't impact the rest of the timeline. Each of the methods, such as "ShowCastle", "ApproachCastle", etc., are methods that are defined in the cutscene's Lua file.
What do you guys think? Am I over thinking this, under thinking this - or just plain retarded? Feel free to comment / ridicule as needed.
Wow, that actually sounds like a great idea. I hadn't actually "thought" about this--okay, that's a complete lie. All programmers who think of a problem, if only for a second, come up with some sort of rough outline for how to approach the issue. I hadn't put considerable thought into it is what I'm trying to say.
The rough outline in my head was to give each cutscene its own heartbeat that executes its own logic rather than the engine. But your approach is much more sophisticated, intelligent, pretty, and has nicer boobs than mine.
GyroVorbis wrote:Wow, that actually sounds like a great idea. I hadn't actually "thought" about this--okay, that's a complete lie. All programmers who think of a problem, if only for a second, come up with some sort of rough outline for how to approach the issue. I hadn't put considerable thought into it is what I'm trying to say.
The rough outline in my head was to give each cutscene its own heartbeat that executes its own logic rather than the engine. But your approach is much more sophisticated, intelligent, pretty, and has nicer boobs than mine.
I hope you don't mind me warezing it? Haha.
Hmmmmm... Well now you've got me thinking. Maybe I'm overthinking this.
I kinda like the idea of keeping it simple and just giving the cutscene script a heartbeat. Then the script itself can worry about timing, etc. My timeline system may be too rigid.
I won't get started on this for a few weeks, so I'll keep thinking. But hey, if you wanna try it, go for it. :P
Huh. I was always under the impression that each script would control their own respective 'cutscenes' by frame counting or something...
But I must say, I like your idea. In the long run, that would make development alot faster. And likely help to keep it concise on both the DC and PC builds...
No, i don't think we've given it a great deal of thought. This is quite an interesting topic. Honestly, I'd like to see your idea implemented. ;P
You never answered Gyro's question...How'd you feel about having it warzed? Cheated? XD
<qpHalcy0n> decided to paint the office, now i'm high and my hands hurt
So why don't you just have it so that the script plays "pass the peace pipe"? When one action is complete, it lets the engine know to proceed to the next one. Basing things off a timer / timeline might be bad if the computer playing the game lags. Falco was saying in another post that Lua scripts being ran per frame on the DC was impacting performance. What would happen if the specified time for an action passed by? If every action had a heartbeat, wouldn't that slow things? This way it's simple and less prone to timing issues. Waht do you think?
timer / timeline might be bad if the computer playing the game lags.
'Timer' could (and often does) could refer to a frame-count of some sort. In which case lag would also lag the timer accordingly, so no issue.
Also, the glory of devving for a console is that they've all got the same specs. Lag from on one means lag-free on all. Unless you fucked your shit in the ass. ;P
When one action is complete, it lets the engine know to proceed to the next one.
We're not multi-threading here...Nor does the engine cease to work as a lua script is called. Chances are high I've misinterpreted your post (I'm pretty tired atm. ;P) but I'm getting the impression that you're suggesting
Which wouldn't work, as each script occupies many frames and must yield to engine periodically.
Falco was saying in another post that Lua scripts being ran per frame on the DC was impacting performance.
Yes, but not significantly. Calling lua every frame shows on the stress-bar on the DC, but that's nothing we can't work with/around. Benefits outweigh the performance impact. Last I heard, he is calling the level.lua every frame; I highly doubt he's about to change that fact for the sake of a more usable (but unnecessary) cut scene engine.
Again, sorry if it sounds like I'm speaking out my asshole. Tired, and without enough caffeine. ;(
edit: In the end, i honestly do think we're all over thinking the cut-scene thing...The idea behind a timeline and addition to the engine entirely for the sake of cutscenes is pretty neat in theory, but in practice it may end up limiting, or pointless...We could already do frame-based cutscenes from the standard frame-by-frame level.lua...Then again, the trade-off is that it could probably get messy...I'm sure we'll give it more thought when we're further along.
Last edited by Arce on Wed Nov 26, 2008 10:37 pm, edited 1 time in total.
<qpHalcy0n> decided to paint the office, now i'm high and my hands hurt
mllarson wrote:So why don't you just have it so that the script plays "pass the peace pipe"? When one action is complete, it lets the engine know to proceed to the next one. Basing things off a timer / timeline might be bad if the computer playing the game lags. Falco was saying in another post that Lua scripts being ran per frame on the DC was impacting performance. What would happen if the specified time for an action passed by? If every action had a heartbeat, wouldn't that slow things? This way it's simple and less prone to timing issues. Waht do you think?
Yeah, I hear what you're saying. Since the cutscene events are going to happen in series, why not just have Lua tell the engine when to fire off the next event.
But, I've given this some thought, and I really like the simple approach. My game already calls Lua ever frame, and there's virtually no impact on performance. The heartbeat approach lets the cutscene do it's thing for as long as it wants, and it will let the engine know when it's done.
Falco wins this round.
EDIT: Marcel wins this round as well, thanks for your help guys.
Actually I meant more along the lines of objects than scripts. Lets say that we have three objects: Billy Ray Bob, Bubba Joe Butthead, and the cameraman. We are making a riveting cutscene for that new drama-based game "Backwash Nights". Billy starts the cutscene by spewing out some drivel about how he towed his fat gramma to the store behind his Chevy pickup. Once he is done, he lets the game engine know that he's done, and then the engine lets Bubba know that it's his turn. The cameraman is just there to focus on the speaking person for now. So now Billy and Bubba are having a coversation, each passing the "peace pipe" (a.k.a. talking stick). Now this could be done in a frame by frame solution as well. Now, however, we want a third speaking character to be inserted into the scene (say we thought of something funnier to say). So along comes Lil' Mac, the town's midget pimp. He wants to tell Bubba that his sister made Mac some money last night, but now we have a problem. In a frame by frame script based on an absolute timeline, you'd have a hell of a time adding anything. In the way I'm talking about, the third character could be inserted easily. Once each entity is done doing what it needs to do, it yields to the next thing. Now lets complicate things a bit. Cameraman is being told to walk around Bubba's yard to get a better shot. Now cameraman has to call a pathfinding routine which could take an indeterminate amount of time (say the hound has impeded his progress, and he must find an alternate route). For a camera this seems kinda strange, but I'm just trying to illustrate the fact that certain actions may take an unknown amount of time. Also a cutscene might not take place in an exact point on a map. It could be called anywhere (like "catching the greased pig" minigame), so characters may need to find their way around obstacles.
Basically, if each character is an object (C++ is object oriented) that can be told what to do, do it it's own way, and then yield, it seems a lot easier than a frame-by-frame "move player up 1 pixel". Maybe I misunderstood the "frame by frame" meaning, but I'm just throwing out what I think.
-Matt
EDIT:
I'd like to elaborate a bit further on this. Let's say that we have a female character that is being told to move to a certain point on a map via a cutscene script. So she then must find a way to get to that point. As a land-based character, she has to find a path to that location, and then follow the path around trees, rocks, etc. You could hard-code her path in the script, as well, but now I'll throw a monkey at that wrench. Suddenly you have a brilliant idea. You decide to give the girl a pair of wings (like Nina in Breath of Fire). Now the girl could walk to the point, or if she deems it quicker, could fly to that point. The time it takes her to relocate can be unknown and still not mess up the flow. If you hard-coded her path in the script, then you'd have to change the script to get her to fly. In my approach, SHE decides how best to proceed without having to change the script, or other scripts, one iota, since the implementation on how to move, jump, fly, etc. is with the character herself, not in the script. Just call a function like moveTo(x coord, y coord) and wait until it returns. My point? Hard-coding is bad, simplicity is key...
