World [70+ Supporters, 98.6%] The Actor System [ Includes Video & Gif Demonstrations ]

Huzzah! Yet another suggestion with more videos!

So before I delve into this, I will say here and now that this suggestion is intended to have the Wynncraft Content Team as its primary audience. Of course, anyone else who is interested in what this is, feel free to read on!

This is also a pretty long read, so pull out your reading glasses.

A very important note: This is NOT meant to be a replacement for the current method of how Wynncraft creates their cutscenes. This is simply another alternative tool they can use to create it. (Brought up by Aarontti)

Now I don’t know how hard it is to make Wynncraft Cutscenes, but I’m assuming it takes a lot of effort, especially for things like the Secret Discoveries (The Wynn Monument discovery cutscene must’ve taken a long time!) I wanted to think of a way to not only improve the “liveliness” of the cutscenes, as it’s kind of obvious when something has a predefined path when they’re moving in a straight line, but to also make the effort of creating epic cutscenes easier.

I would also like to give a little something back to the Wynncraft Content Team (This is basically an “internal” suggestion) as I'm sure that there are a few things that could be changed to make their lives easier.

So, I present to you the fruits of my labor over the course of 4 weekends (I can't work on weekdays really), The Actor System.

Let’s start with a demonstration of what the Actor System can produce, as I know a good portion of people who actually open my threads only come for the demonstration(s) :)


Counting only the total time worked on it and not including a couple of bugs I had to fix along the way, this took ~30 hours to record & edit the scene.
Btw, there’s this super cool mod which will increase how many sounds can be playing at a time that I used in the video: https://www.curseforge.com/minecraft/mc-mods/extendpolyphonylimit

Ok, onto the actual info!

The Actor System was designed to make the job of creating cutscenes much easier. This idea was developed for cinematography in Minecraft and in fact doesn’t have to be just limited to the Wynncraft world.

So the basic goals and premises of this system are as followed:

• Defining “actors” that are controlled by players and recording them walking around and performing actions. These actions include Arm Swings and Hand Item Switches.
• These movements are “recorded” and transcribed into Player NPC movements, which will create near-perfect player recreated movements.
• Using the Editor tool to add and change the looks of the scene. This includes adding Dialogue, Effects (Particles and Sounds), changing properties of Actors, and so on.

There’s so many features of this system that unfortunately I won’t be able to go over them all in this suggestion. So if you have any questions about how this works or what it can do, feel free to comment down below and I will answer them ASAP.

The Recorder

When making a Cutscene, the first part that most people should jump to is the recording.

To record, the editor of the scene needs to define “Actors.” These actors can then be used to record with by assigning players to them. For example, I can create an actor with an ID of “act_mage”, then assign someone like Corpe_ to it via a command.

After assigning players, you can then record the scene. This my friends is where the magic happens. When recording a scene, all movements and actions (Currently arm swings and hand item switches) are recorded into Actor Frames. Then, once you are finished recording and you test/play the scene, all movements done will be shown back to you via Player/Mob NPCs. This means if a player runs around in a circle flailing his arm, the scene will play back to you exactly what he was doing and exactly where he was in a smooth 20 TPS/FPS, the maximum Minecraft can provide. (Any higher via multithreading can cause data corruption to the Minecraft world unfortunately)

Click here to see an HD(er) version


Of course, you can assign multiple actors and recording simultaneously with multiple people performing actions of their own. I find it preferable however to record with just myself as it makes organization and scripting it a bit easier. Collaboration is hard sometimes!

You can also assign “Velocity Tools” to your hotbar keys. These tools allow you to change your velocity mid-recording so you can simulate knockback, launch forwards, and so on. For example, if I define a Velocity Tool to my 2nd Hotbar slot, when I scroll or switch to that hotbar slot, I will be launched based on the parameters I set.

Click here to see an HD(er) version


And finally, you can re-record portions of an actor in case you messed a pathing up. However, keep in mind that if you do this, all actor frames that are ahead of the frame you start at will be deleted, so be careful when re-recording to make sure you don’t mess up. For example: If an Actor has 500 frames, and I begin re-recording at frame 250, Actor Frames 250-500 will be deleted.
I should actually make it so re-recording just overwrites the frames as you record to prevent such things... Maybe another time.

The Editor

The second key feature and primary step in creating the cutscene is the Editor! There are a lot of cool tools for you to play with in order to get your scene looking flashy!

First of all, there’s Preview Mode, a powerful editing tool that allows you to preview the entire scene. How it works is you can play/pause the scene, move to the next scene frame, and move to the previous scene frame. This allows you to see the movements of all the NPCs and where they are, so you can make predictions when creating props and adding effects. You can even add effects and change properties while in editor mode, so you can see the results when you play them after the scene is finished!

Click here to see an HD(er) version


Next are the actual editors themselves. There are two primary editors: The Scene Editor and the Actor Editor, with the Actor Editor being the most powerful with the most tools.

Let’s cover the Scene Editor first. This editor is the easiest one to understand. When you’ve recorded a scene, scene frames are added, and you can open a UI to view all of these frames. When you open a Scene Frame, you can add Dialogue at that specific frame. This allows for easy dialogue creation, and all standard Wynncraft format is handled for you.



Another feature is that you can add is the ability for the scene to perform a command when that scene runs. This allows you to place a redstone block to trigger a door opening, or some sort of block explosion happening.

Click here to see an HD(er) version


Finally, is the Camera feature, which I think is the best part about this editor. How the camera works is you define points in the frame scenes, and set properties such as if the camera will instantly teleport to that location or not, and what direction the player will be looking when they teleport.

But what does the camera look like and how does it work? It’s actually an item drop that the player rides while they’re watching the scene. The “camera” item is moved at a constant velocity between points that is determined by the distance and the frame offset between the two points. This allows for extremely smooth camera movement while also allowing the player to have a full 360 view of the entire scene.

Click here to see an HD(er) version


Of course, a limitation is that the item can still collide with blocks, so it’s important that the camera path does not intersect with a block or it can lead to mishaps.

Oh yeah, and you can have Noteblock music play on certain frames. That’s cool I guess for people like @Corpe _ .

Spoiler: Technical Error with Noteblock Music

While implementing the Noteblock Music feature, there was a bug where due to internal server lag, the Noteblock Music can get off-beat the longer the scene goes on (ex. A scene that is 2+ minutes). This is because the Noteblock Music is running on a separate thread from the main server thread, and since server lag does not affect this separate thread, the music keeps going regardless of lag.

I spent a whole day trying to figure out how to fix this, but to no avail. I did manage to slightly fix it but not a whole bunch, so I had to develop a small BukkitRunnable workaround that allowed the music to be played on beat consistently. However, the tradeoff here is that the music can ominously pause on a beat due to how the tick calculation works.

I went ahead and used the BukkitRunnable workaround because I needed the consistency and was willing to deal with the tradeoff.

Now let’s move onto the best editor: The Actor Editor.

The Actor Editor allows you to add effects and change the properties of the actors themselves. These effects and properties are all contained to the actor that you are editing. I will show why this is the case in a moment.

I don’t want to go over the entire list of features available to the editor in-depth, so here is a rundown of it:

• (Properties) EntityType: Can change the type of entity being shown. This entity must be a Creature-type Entity.
• Name: Change the Actor’s displayed name. (This does not change their Name ID)
• Skin: If the EntityType is a player, can change their skin to a specified one.
• Armor: If the EntityType can wear armor, they will show the armor that you give them. Armor is static throughout the entire scene and cannot be changed frame-by-frame. (I may change this once I decide to not be lazy about it)
• Visible-While-Inactive: A true/false flag that determines whether or not the actor is visible or not when they haven’t reached their starting frame.
• (Frame-By-Frame Effects/Properties) Visibility: A true/neutral/false flag that toggles whether the actor is visible or not. This persists throughout the remainder of the frames until toggled otherwise.
• Held Item(s): Can change the items held in the main and off hand. Items changed at a frame persist until changed again.
• Particle Effects: Can add effects at chosen frames
• Sound: Can add sound at certain frames
• Frame Actions/Animations: Includes Particle Lines & Particle Circles. More stuff can be added via code with ease.
• Animations/Effects: Plays/Removes certain mob/player animations at selected frames. These include:
  • Arm Swings
  • Hurt Animations
  • Death Animations (If this is toggled on, the Actor will not appear for the rest of the scene)

All of these properties and effects are limited to the Actor that you are editing. Why? Well this allows for the player editor to copy and paste the Actors at will! With a couple of commands, the editor can select/copy an actor, and paste them wherever the editor like, with all of their properties and effect still in tact.

You can also have the Actor’s path rotate according to the horizontal direction your looking at. This makes creating parts like clashing NPCs much easier!

Click here to see an HD(er) version


Whew! That’s the basics for the Actor System. Like I said, there’s a lot of things that I wanted to go into more detail about, but if I talked about everything and how everything works, this suggestion would be a 30 page essay.

That said, if you have any questions, feel free to comment and I will answer them ASAP! I will also put them in the “Q&A” post so that way people can check if their question has already been answered. There’s also a couple of technical questions to start off with so feel free to read those if you’re interested in the technical side of things.

Thanks for reading! And as always, feedback is appreciated!

Jesus Christ now I can finally sleep for more than an hour...
Btw did anyone else see the new logo? :monkaS:

________________________________

Q: How do the actors path work internally?

A: When recording an actor, the player’s location and direction is saved to a frame every tick (1 tick is 1/20 of a second, or 0.05s) with the according actions they performed on that tick (ex. Hand Swings). When playing the scene back, the Actors are actually being rapidly teleported to where the player originally was. This is accompanied with a small visual glitch in Minecraft where rapidly teleporting/moving an entity in a direction will cause their avatar to look like they are walking/running.
At first glance, this seems very unnecessary and inefficient. I actually thought the same too when I first made this system. So, I ran a test with the following parameters:

• A running server with 1 GB allocated
• 100 Copied Actors performing the same action(s), which include particle effects and dialogue

This was the result:
https://media.giphy.com/media/fUefWXMUywEtwgZGGc/giphy.gif


Q: How do you save/load a scene?

A: All scenes can be saved by the Scene Editor with “/scene save.” In doing so, they are stored in their own .json file. They have been programmed to save only necessary information, such as non-default variables.
All scenes load automatically on server startup, but you can also manually reload the scene (/scene reload) in case you somehow messed up the scene catastrophically and need to restart from your previous save point.
The size of the .json file is proportionate to the duration and complexity of your scene; The more actors, effects, and the longer the scene is, the more information it saves and the larger the files becomes.
For example, the scene file for the GIF above this question takes up 6 MB, while the actual demonstration scene shown at the very beginning is about 18 MB. All in all, that isn’t a lot of disk space used.

Q: Are any command blocks involved in making a scene?

A: No, everything about the Actor System is handled purely by plugin magic. However, the Frame Editor allows you to run a command in case you need to perform some command block magic during the scene. This is to mainly allow CMDs to place a redstone block somewhere if they need to.

Q: Responding to a major technical concern from @Aarontti

A: I'll start with reliability first. I'm going to assume that this is the question of "How do I know this isn't going to bug out midway into playing a scene?" The answer to that, unfortunately, is I can never know perfectly. Things will break whether we expect them to or not. I've done my best to wring out most of the errors in the code, however the amount of logic that has to go behind everything, specifically the recording portion as I know there are about 10 different cases on how a user can record, may conflict in places where I may not expect it to. However, I've done my best to be sure that nothing breaks mid-scene or mid-creation and everything turns out smoothly. The main thing I worry about right now is the Camera. Since it is basically a moving item drop, it can be destroyed by things like Lava or collide into blocks, offsetting the path. I plan to add more checks to both the camera and more fragile places in the code to make sure errors like these don't happen again.

Performance impact I've addressed somewhat in the post. Yes, performance was something I kept in mind while creating this. The primary thing that could cause some lag is the actor movement.
I'll restate how actor movement works: When recording an actor, your location is saved every 1/20th of a second and when the scene plays back, the actor is teleported to those positions. So approximately every 0.05 seconds, all actors in the scene are teleported. I was and still am slightly concerned about this, but I've come to terms with it more and more that it isn't neccessarily a bad thing.
I even ran a test to make sure of this. In this gif link, there are exactly 104 Actors. The server that it's running on has a total of 1 GB allocated to it. The demo scene was also recorded on 1 GB, although if you wish to test it more I'd be happy to lower the allocation down to even 512MB or smaller.
https://media.giphy.com/media/fUefWXMUywEtwgZGGc/giphy.gif
If you have other performance tests in mind as well, let me know and I'll gladly test and fix stuff in the code if needed.

Next is multiplayer compatibility. Most of the code written does not touch the primary Bukkit API, and if it does, it does so very lightly. All of this code is ran on 1.12. Of course, things like Particle effects and Sound effects may not be saved correctly depending on what Wynncraft's version is running (I don't know for sure if Sound effect names in code change from 1.8 to 1.12 dramatically). Of course, methods to fix this such as reflection exists in case it needs to be compatible between versions.

So different types of lag... I'm going to assume you mean client lag and server lag. For server lag, the scene is still played and when the lag ends, it fasts forward like mobs do in Wynncraft where they're supposed to be when there is a lag spike. For client lag, the scene will still play. If they're is a camera in motion, they will still be riding it while the item camera moves.

 

You made this. I get that this is a suggestion, but this is something you've actually made! This isn't a plugin concept: You've made the plugin. That is AMAZING. Am I missing something? You did spend ~30 hours on this right?

I can only imagine how useful this would've been back in the day when Minecraft cinematics were popular (a certain YouTube channel could've used it well). This is simply spectacular.

Why is this even a suggestion? You should spread this somehow! Even if this is clearly made specifically for Wynn, this could be useful for way more than Wynncraft. (with some generalisation tweaks, I suppose!)

And speaking of Wynncraft. The Content Team, this really is something that'd be useful for them. I just hope it's compatible with whatever they're using right now...!

Keep it up!

 

Thanks!

So I spent about 4 weekends on it since I couldn't work on it during weekdays. So that's about 10 days if you count Fridays as half days.
The actual demo cinematic took ~30 hours. That's my main guess, could've been longer or shorter.

So this is gonna sound very smug and prideful and I don't mean it that way because it's the honest truth: I was actually bored and wanted another side project to do, and I remember first seeing Wynn Monument's Secret Discovery and thought to myself "Damn, how can I make that look x10 cooler and x10 easier to make?" Then I came up with that.

Fingers crossed! I don't know how their code looks though I'd honestly be happy to help integrate it if they are interested in this.

 

Hot damn that’s impressive

 

This is really impressive! And the demonstration video was really cool too, although the camera could have moved less, especially at the beggining when the adventurer asked the fleeing villager what happened to their village.

 

join ct

 

Hot damn my dude stop making cool stuff you're making all of us look bad.

 

what the actual hell this is way too good, it should be illegal to tease us with such features
seriously if we were able to do that i'd just go sicko mode

join ct
no

join dev

 

the only reason to not use this is theyd have to redo most of the cutscenes theyve done before this, and even then this looks like a blast to use!
if this isnt used i will find salteds house and raid his freezer

 

Ty!

I knew I should've reworked the camera movement!!!!! AAAAAA

________________________________

Hmm...

 

i'm down

anyway, while this is outstanding, the files are pretty heavy right? the ultimate discovery takes about 32KBs, and this might be an actual issue if it takes up too much space
but oh well, even if it's something we use for the more "important" cutscenes, that'd be sick

 

Referring from the questionnaire

Q: How do you save/load a scene?

A: All scenes can be saved by the Scene Editor with “/scene save.” In doing so, they are stored in their own .json file. They have been programmed to save only necessary information, such as non-default variables.
All scenes load automatically on server startup, but you can also manually reload the scene (/scene reload) in case you somehow messed up the scene catastrophically and need to restart from your previous save point.
The size of the .json file is proportionate to the duration and complexity of your scene; The more actors, effects, and the longer the scene is, the more information it saves and the larger the files becomes.
For example, the scene file for the GIF above this question takes up 6 MB, while the actual demonstration scene shown at the very beginning is about 18 MB. All in all, that isn’t a lot of disk space used.

So I'm not exactly sure how much space the Wynncraft server has available, but at least in my house, a few MBs isn't a lot.
I actually did at FAT oopsie with the saving which causes the files to take up more space than they should. If I actually got off my butt and fixed that it'd probably be lower.

There's always gonna be a way to reduce the file sizes in code... >:)

 

Amazing as always. Thank you for making the text read at a reasonable speed too.

So I'm just spitballing here, but what if there was a way to smooth out certain segments of an actor's recording into "shapes", to reduce file size? Maybe this is already done - I was surprised at how small the filesizes are.

 

I'm getting mixed signals about this one... :monkaS:

I actually thought about that, splitting actor recordings into "recording segments" so that way if you re-record you can just re-record that segment. But idk, I didn't go with it.

 

I might call it very slightly fast, but eh. Compared to ingame text, it's quite nice to read.

 

As cool as all the demonstration videos have been so far, I can't be the only one who thinks they feel more like marketing instead of suggestions; Using the community to put pressure on Wynn for not using something that's seemingly available to them, whether that's the pre-made plugins or a potentially hireable developer, neither of which are something a suggestion should put focus on.

I'm not saying that any of the concepts are bad by any means, nor saying they couldn't or shouldn't be utilized, since even in my opinion they seem quite polished, externally at least. However, they do seem more like personal show-off projects than actual suggestions. The reason why I'm bothered by this is how the threads can easily invoke impressions such as "There's no reason for Wynn not to utilize it if it's possible" and "Well, it's already been made, so why recreate something that exists". Things such as reliability, performance impact, multiplayer compatibility, and how different types of lag influence the cutscenes for players, are all major things to take into consideration with something of this magnitude on Wynn, yet I see none of them covered on the thread in any capacity. Instead, 90% of the thread's content focuses on giving a tutorial about the particular system that you created; Not the suggestion itself, nor its technical aspects, or how it could function inside of Wynn in particular. Hence, if even one thing prevented it from being implemented, or it wasn't seen to fit the game, Wynn could be met with a negative public outcry from the community for "wasting a valuable asset", or whatever people can come up with. Knowing certain people of the community, I can already hear the "Oh no, Wynn is big bad and can't do something that even an individual person can" and "Lol, Wynn'd rather die out than become better" echoing in my ears. As for the thread itself, I don't like the "this is how I do it" focus of the suggestion, since it's usually the one thing that can hardly be utilized for suggestions in particular.

Note, that this is more of a worry than an accusation, so I hope there's no hard feelings for it, albeit I do admit that I personally dislike how you're continuously posing your own plugin as a definitive solution. If any of this comes off as rude, also note that I'm having a bad day, and much like you and everyone else, I have personal opinions that are based on a limited spectrum of information and observations. The sole concept of being able to record and playback actual player movement and actions is pretty interesting though, and I really like it as an idea.

 

I definitely did not mean for this to be a "market" post. Tbh I can understand where you're coming from. When I was writing this I had the mindset of having to walkthrough the basics of how this idea works and the steps involved into making it.

So all of the 3 suggestions I've made so far that use these types of Demonstrations are the Improved Spell Effects, the Improved Boss Fights, and The Actor System. The reason why I made these in code and not just put them in picture or text is because:

1. I needed to find out if these are actually possible to make in the first place and if they're actually worthwhile to develop. For example, on the Actor System when I first thought of it and during the makings of it, the system was so complex and incredibly frustrating to my logic side that I had no idea if this was actually even worthwhile to suggest or post.
2. Everything is much harder to explain or visualize if only texts and a few picture are used. Sure I can make a psudo Chest UI but the idea can be better examined and criticized if a proper demonstration is given. Some of the best suggestions I've seen are ones where small gif or video demonstrations are given. Of course, I'm not saying that other suggestions that use pictures, math, and straight up facts are also convincing, but I wanted to follow that template.

Of course, I do have to admit that I have made these kinds of things to impress, however I do not have the intention to show off my skills or tell everyone "Hey I can make Wynncraft but better, look at this pretty video of a CoW boss battle!" Wynncraft is on its own level above me that I cannot probably even be able to comprehend unless I actually examined it with a large magnifying glass.

I'm completely sorry that I didn't address this entirely. I should've gone into the more technical side of things about this and instead I ranted off about the externals, not the internals which is the most important part of this.

I'll start with reliability first. I'm going to assume that this is the question of "How do I know this isn't going to bug out midway into playing a scene?" The answer to that, unfortunately, is I can never know perfectly. Things will break whether we expect them to or not. I've done my best to wring out most of the errors in the code, however the amount of logic that has to go behind everything, specifically the recording portion as I know there are about 10 different cases on how a user can record, may conflict in places where I may not expect it to. However, I've done my best to be sure that nothing breaks mid-scene or mid-creation and everything turns out smoothly. The main thing I worry about right now is the Camera. Since it is basically a moving item drop, it can be destroyed by things like Lava or collide into blocks, offsetting the path. I plan to add more checks to both the camera and more fragile places in the code to make sure errors like these don't happen again.

Performance impact I've addressed somewhat in the post. Yes, performance was something I kept in mind while creating this. The primary thing that could cause some lag is the actor movement.
I'll restate how actor movement works: When recording an actor, your location is saved every 1/20th of a second and when the scene plays back, the actor is teleported to those positions. So approximately every 0.05 seconds, all actors in the scene are teleported. I was and still am slightly concerned about this, but I've come to terms with it more and more that it isn't neccessarily a bad thing.
I even ran a test to make sure of this. In this gif link, there are exactly 104 Actors. The server that it's running on has a total of 1 GB allocated to it. The demo scene was also recorded on 1 GB, although if you wish to test it more I'd be happy to lower the allocation down to even 512MB or smaller.
https://media.giphy.com/media/fUefWXMUywEtwgZGGc/giphy.gif
If you have other performance tests in mind as well, let me know and I'll gladly test and fix stuff in the code if needed.

Next is multiplayer compatibility. Most of the code written does not touch the primary Bukkit API, and if it does, it does so very lightly. All of this code is ran on 1.12. Of course, things like Particle effects and Sound effects may not be saved correctly depending on what Wynncraft's version is running (I don't know for sure if Sound effect names in code change from 1.8 to 1.12 dramatically). Of course, methods to fix this such as reflection exists in case it needs to be compatible between versions.

So different types of lag... I'm going to assume you mean client lag and server lag. For server lag, the scene is still played and when the lag ends, it fasts forward like mobs do in Wynncraft where they're supposed to be when there is a lag spike. For client lag, the scene will still play. If they're is a camera in motion, they will still be riding it while the item camera moves.

You're absolutely right on this and I can understand how this may happen. Of course, I've never seen Wynncraft's code so I don't know how it functions. If something went wrong, I'd honestly ask for everyone to put the blame on me instead of Wynncraft. They did not originally develop the system for their own compatibility, so it would not be fair if something broke that my system didn't account for.

Understood, though I don't really know how I could've phrased it in "this is how Wynncraft should do it." As I said, don't know how the code looks and what can fit and what can't.
Now I want to be clear on something: However they're making cutscenes right now, whether it be command blocks or script, I don't think it's a bad system or idea. In fact, I think it's a fantastic system and makes my mind wonder how in the world they made something like that. And I'm not saying either that these systems can't live side-by-side in harmony seeing equal and fair use. This is not a replacement for the current system, as I know there are probably some things that their current system can do that this one cannot (ex. Armor Stand magic).

Looking back now, maybe I have spent less time than I should've working on these suggestions. I didn't mean to propose my plugin as the solution to these problems, and if it has come off of that way I am truly sorry that it has. The plugins were only meant to serve as demonstrations and fun tools and projects that I can use and expand on for my own personal use. None of these plugin suggestions have meant to devalue Wynncraft's technical excellence, in fact I am certain that these are no where near in parallel to Wynncraft's plugin magic right now.

As a final note, I will start posting major systems like these in "Your Work." It probably fits it better and I don't want people to take these suggestions as a show-off or a rewrite of an existing system.

Thanks for pointing all that our Aaron. It was probably well deserved and I'm glad you brought it up, as it had never crossed my mind.

 

this is so hecking cool

join ct

join dev

 

Time for a bump

 

I would still like this to be in general suggestions.
Most of the time you make one of these they are something I want to see in game, though, I be it, I don't know much about the technical side of everything nor their due-ability.
However it isn't my job to know how due-able something is with their systems and servers. At the end of the day, they are the ones that get to deiced what ends up in the game, I'm simply here to say what I would like in the game.