A Cinematic Breakdown news - Dark Messiah: Co-op mod for Dark Messiah of Might and Magic

Happy November everyone, and welcome back to another exciting article where I breakdown some component of Dark Messiah that took me upwards of a few months to fix because it was extremely well hidden within all the code! Hurray!! For this article we're going to be looking at the cinematics that exist in Dark Messiah, how they were fixed for co-operative play, and what my plans are for the future.

---

The Scene System

Before we get into any of the specific cinematic types, we need to lay the ground work for how they are performed within the source engine and specifically within Dark Messiah, because while it does USE the source engine as a foundation it handles each of it's cinematics a little differently. However, the best place to start is always the ground floor, then working your way up.

The easiest way to think about this is like a movie, and fittingly the main driver for every cinematic in some way is the Scene System. With a movie you have a set of actors that are given a script with directions, lines, etc, which are then followed by the actor split apart by different scenes and locations. This is basically the same concept with the Source Engine's scene system, where these scripts are given as .VCD files and refer to each actor by their entity name.

The entity names are usually given by the map maker, but there are few consistent ones such as !Player for the player or !PlayerFirst for their view model. We'll get into the viewmodel one later, as that is specific to Dark Messiah and certain cinematic types, but you can see from the VCD readout that dialogue, facing, moving, even gestures are all dictated by this system.

The Combat Move System

Specific to Dark Messiah, a very important system for pretty much everything is the Combat Move System. If you're familiar with any sort of state system, it's keeping track of the currently performing activity of the player is. Going up a ladder? Swinging your sword on the third succession? Standing still? All are states being tracked and cycled through with an internal variable.

Because there are so many different Combat Moves, they are naturally extremely important during cinematics. These states can dictate anything from what actions you can perform next, to the animation that is playing on the model, to even whether or not you can open your pause menu. Functions are often re-used and only the combat state will dictate the difference between what if statement it follows.

Understanding both of these systems are crucial in now identifying each type of cinematic and talking about how they work.

---

The Cinematic Types

Now that we understand the two most important building blocks of cinematics, let's start talking about them!

BIK Cinematics

BIK Cinematics are the simplest because they are completely pre-rendered. The name comes from the file extension that they use, and you literally can't avoid these cinematics because.. well.. you see them when you launch the game! That "Ten centuries shall the fortress stand.." introduction video at the start of the game is a BIK cinematic. The dream sequences with Xana, Arantir, those are also BIKs!

How they work is also extremely simple. Basically a function is run when the player has triggered something that opens up one of the .BIK files in your movies folder and plays them on screen. Since these are entirely pre-rendered, you can easily change what cinematic plays at any point by just going into the movies folder and replacing any of the BIK files with your own. In co-operative play, fixing this was as easy as changing what is originally just a function that points at the host and make it point to every player on the server. Skipping a cinematic isn't a problem because the connection won't be initiated until all players have confirmed the cutscene has ended, though the host can still change to the next map and the other plays may connect late!

At the end of the day however, my goal is to recreate these cinematics to be entirely done in-game. I'm a big fan of the way Half-life 2 handles it's cinematic conversations of just "let the actors play the scene out and you can care if you want to", which actually lends itself very well to co-operative play. There are some effects that may not be clearly achievable without getting into the rendering engine, but as these are all pre-rendered they must have been recorded in-game, which means the assets are SOMEWHERE. Actually, if you look at the animations present on character models, you will find cinematic animations are still there, meaning all that needs recreating are the levels and that is easily done, especially given all the texture and model assets already exist within the game.

Ride Along Cinematics

Ride Along cinematics are in no way the official name, but one that I think really gets the point across. It happens in every game, where your player is attached to some vehicle or vessel and you are at the mercy of their direction. You don't have any meaningful controls except for looking around, and you're usually passing some set pieces or world building. In Dark Messiah, these are pivotal to setting the stage for your current journey. The Stonehelm horse ride is the easiest example of them, but they happen even with Leanna's siege on the island or your escape with her from the same.

These cinematics are a little more complicated behind their function, but can be simplified by basically taking the player that activated a trigger, forcing them to enter a vehicle (or seat, based on your perspective), and then letting the vessel run it's path. The CombatMove variable of the player is set to prevent them from using any controls, inventory, really anything but looking around with their mouse and keeping their animation relevant to whatever vehicle they are on.

Fixing this in co-op was not the easiest task because there is only one vehicle, and it's not possible to mount every player onto the same vehicle. The current fix for this is to, unfortunately, take every player's camera and assign it to the person in the vehicle. This was important because a lot of expository dialogue is also usually delivered during these cinematics, and they are always limited by the player's auditory range. This means players could miss important dialogue or become desynced during their own gameplay.

Originally, the only person locked into a vehicle was the person who activated the trigger, which meant every player was left to roam around completely unrestricted. This was a really cool concept on the earlier missions like the Stonehelm gate, as it meant players were walking on the journey next to the person on the horse much like the couple you see pass by you. In the final product, I would really like to give each player their own vehicle to ride alongside each other. It would be really awesome to have a horde of boats with players assault the island or a cavalry of horses arrive at Stonehelm. Plus I think it really would enhance the atmosphere of the adventure.

Fly-By Cinematics

These are another extremely simple set of cinematics but are dictated a little differently than expected. Fly-bys are basically anything that takes full control of your view and flies through an area. This is another extremely common type, and is most notably used during the Prologue to display the Shantiri crystal, but it is also used when you slay the undead cyclops after the siege of Stonehelm.

The function behind this cinematic is actually mostly controlled through the design of the level. The player has function called "SetViewEntity" which basically allows a player to have the perspective of another entity in the game. The mapper can then add a custom view entity and then have it run along a track, taking and relinquishing control once the cinematic is done. To fix this in co-op, you simply have to force this entity onto every player, not just the one that activated the trigger. However, this needs to be done carefully, as sometimes these view entities are only MEANT to be activated by one player. An easy example is the ballista turrets which utilize view entities to put your camera between their sights!

I believe this is the one cinematic that won't really get changed by the end of development. At best, it will be refined to know exactly what flags to use for global vs individual view entity application. It is currently using the cinematic boolean, which works fairly reliably, but for map makers it might be better to give them some more to work with.

Focus / Look-At Cinematics

Yet another common industry cinematic, this type is always used to show the player what they should be paying attention to. Boulder flying above you? Crucial objective at this location? You focus on it. In the case of Dark Messiah, these are mostly used when someone is talking, but the previous applications still find their usage occasionally. The running example I always test is the first conversation you have with Leanna.

This is a little tricky because functionally it is extremely simple, just set the angles of the player towards whatever is talking. In reality, this is done by three different systems. To start, we're going to return to the scene system. The direction that a player should be looking uses the !PlayerFirst actor, which again is their viewmodel, because a player does not dictate it's viewing angles based on their model but rather their view model's orientation. The main model is used for physical body presence, and it's one of the reasons why you can pivot your arms before your body follows! Once that's done, it sets another variable called the CombatMove_Entity, which is used to tell the player what entity it should be locking it's camera to. Finally, it sets a CombatMove to tell the client that they currently have no controls active and they should STAND STILL.

Fixing this in co-operative play was following my implementation of the Ride Along fix. Whenever the triggers are initiated by a player, all other players now share the view of this player. The extra tick of this view however, was making sure that it was intrusive to the player's current actions. You don't want to be climbing up a ladder when suddenly you have to view something and then you fall down, so a lot of CombatMove manipulation needed to be done. At the end of the day, re-implementing source's spectating system was the best move, using it's variables to mimic a combat state and then reset it back to the player's old combat state. Then all angles are followed without ruining anything else! I haven't really thought much about the final implementation, as I'm going to need to get feedback what people prefer. I would however like to allow map makers to choose specific targets instead of blanket application of this focus camera.

Player Acted Cinematics

Following our previous type, sometimes the player needs to be more involved in their performance. Simply looking is not enough, it's time to act! These are cinematics where the player has an animation played on them and all camera movement or player control is dictated by that animation. Bigger examples include the horse knocking you off in the Stonehelm siege but it can go as small as getting up from the water or just getting out of bed!

Functionally this uses the scene system, but on the !Player actor instead, as it does involve the player's full body animations. It then uses the CombatMove state to affirm the animation and change the camera following mode to the eye attachment of the model. Finally, if there's any focusing entity, it uses the CombatMove_Entity variable to keep your player model's angle relative to them.

This is the one cinematic I haven't fully fixed in co-op (up to your perspective perhaps?) mostly because there are so many use cases for it. While the horse collapse and bed cinematic are the easiest to fix, simply carrying the player view, some cinematics are completely destructive to the game. When you are caught trying to steal the Shantiri crystal, Arantir will choke the player, causing the game to go into a deathstate. Making all players see that camera doesn't makes sense because only THAT player got caught, but it also would risk putting them into a death state which doesn't make any sense.

The stance I've taken is to hand select the levels where these animations need to be shared and keep them as such, everything else is simply acted by the triggering player and pushed. Some would say that is a fix, but I think it can be done better. I don't think I want every player getting out of bed when they spawn, but it would be interesting to see how this can be done more fitting for multiple players with the help of some map editing. Time will tell!

---

Closing Remarks

All in all this has been a really interesting experience for me as I love movies and working with cinematics kind of makes you see how much movie logic really does get applied to video games, and with good reason! I mean they aren't called cinematics for no reason.

As I missed Halloween for the blog post Riddick3 was still nice enough to drop by some spooky cheers as school burns through his free time.

It's also tradition for me to drop a developer diary, so here is a little information about reverse engineering and some visual aid to follow this blog post! You're probably pros by now.

And with that, this blog post is over! Thanksgiving is coming up for me so hopefully that'll lead to more free time to continue development at a healthier pace. Until then our Discord is still open if you want to talk with me about anything: Discord.gg ( select Dark Messiah from the #role-assignment channel )

I accept all pings, questions, suggestions, and etc.

I don't know how long twitter is going to last at this point but I'll still keep trying with updates, so if you want to see some of these as I get through it you should definitely follow: Twitter.com

Thanks again to all of you out there keeping the dream alive and those stopping by to read these articles! See you next time