December 2022

General

Hello! As I announced, I could not publish the dev log of October and November.

Since the 0.4.2 update, I am stuck in a vicious cycle, more work to do and less time to do it.

I improved and corrected little by little and now I am fully operational, ready to start the new yea. I also improve my hardware and production a lot, witch I will speak more of in another log.

v0.4.3 to v0.4.3.4

All updates since the 0.4.2 have been focused mostly on bug squish, coding clean up and deletion of useless codes and IT assets.

Following all the modification and correction I did, I also was about to refactorize, notably when it come to IT assets and Artificial intelligence. All the modifications I did won't change the gameplay experience at the moment, simply because it's all "under the hood" stuff that will help for the future development.

As I explain in the devlog of September, the game is way more modular than it was, by the I mean that some functionalities may now be added or taken away without impacts on other functionalities. Basically, it's now way easier to correct bugs and add new stuff.

I also Partitioned some modules so I may have more control over them undependably.

Before I just had a script that generally took care of the AI, now I have submodules that are taken care of by the main script. One of them manages the memory, another the tasks, the decisions, the environments, etc.

Shoe - Animation

I worked on the animation when Cobble is stuck in Talas shoes, but before that I went on with the idea to make a different animation depending on what position Cobble has when inside the shoe, but I quickly realised that the number of animation work were exponential to the number of situation possible.

It is way better to make one good and well optimised animation depending of when Talas put on and off his shoe and use the procedural modification depending on the context like the position Cobble has inside of it.

I also temporarily deleted the inside view when you are inside the shoe, I will need to refactorized the visual effects of the camera and how they activate/deactivate before I am able to put it back in.

Still in the animations part, I added the possibility to get stuck directly to Talas shoe, similarly, I will make specified animations depending of the situation, like if Talas unstuck Cobble from the shoe and will use procedural modifications depending of the context.

Shoe - Data base

One thing that was hard to manage was the data management from the different position and context possible for when Cobble is attach to Talas.

When I do this, I have to think about the layer of attach, basically, if he is stuck inside or outside the shoe or if he is stuck to Talas Foot. I also have to think about the context of if he is stuck under the foot or glued to it and update all the data in real time inside caches so I may extract the data without having to calculate again and, of course, while thinking of to replicate it in multiplayer.

As I worked on this, I found lots of bugs that I corrected little by little and now, I have something that is stable. What is good is that it is work that I won't have to do again when I will add new macros or new shoes.

Game Master

I normalize the way the Game Master can define some of the in-game data and engage with the environment. I just need to add corposant to my actors and everything is done automatically on the replication level of the interface as well as the interactions linked to it.

Adding new variables or control is now way easier and simpler to debug since the code is not all over the place when it comes to the functionalities that it depends on.

This is all thanks to making the game more modifiable.

I took the opportunity to make a look over all the actions the Game Master has on Talas.

The different actions are way more organised in the interface since it is now possible to interact with it using the keyboard alongside the mouse. I added some variables on the shoe to define the chances for the micro to stay stuck and to unstuck from the sole. I will add other options like the damage multiplicator.

I added some variables on the shoe to define the chances for the micro to stay stuck and to unstuck from the sole. I will add other options like the damage multiplicator.

Modular game stat and world settings

Like I did last month, I made the statistic management, and the level management scripts functionalities modular. This allow me to work way more easily on the different statistic that are replicated on the client and updated by the Game Master.

I also use the Game world setting to put in cache some of the data that may take time to be updated, all of this optimize the game a lot dependant on the utilisations.

Like when the player has to interact with an element, the interaction module will look on all the actors of the scene, then it will filter one by one to see which actors are interactable, all of this take a lot of resources, especially when it comes to calculation each images. But now, all of this is partially calculated, stored in the world settings every 2 seconds et registered inside the cache which will then be used by the interaction module.

AI - Debug

I corrected a lot of bugs with the Artificial Intelligence while also creating a new interface that will help me debug by showing what happens in the AI code.

I also added verification inside the code, if something doesn't work, I will be notified, witch in turn, helps with debugging.

AI - Tasks manager

I partially refactorize my task system used by the AI. I won't extent too much on it on this dev log, but long story shot, the AI can now set a succession of task and under-task starting from a basic order.

If I give it the order to go from A to B but there is a door between those, it will now generate the task to open the door and if the door is locked, it will generate a task to go fetch the key before crossing it.

This works well in situations where Talas is sitting on the couch et has to take a particular situation.

I talk more about it on the channel #wip of my discord.

Before I had this system in place, the structure of data and Artificial Intelligence were generated one by one. But now, the task are dynamic scripts witch may update automatically depending of the context and create its own under-task by itself.

Something else that refactorization allow is to better separate the management of the AI code and of the tasks. Witch is way simpler to debug and organise.

Another thing I upgraded is the way the AI find some occupations and point of interest. This uses the world cache witch avoid freezes each time the AI want to do something new.

AI - Memory manager

Like for the tasks, I refactorized the management of memory. Bricks of memory are not simple date anymore, but dynamic scripts witch may be updated depending on the context. I also took advantage of the refactorization to separate the code of the Artificial Intelligence and of the memory management.

AI - Personality manager

Another thing I did update the decision making table, finished since 0.4.2

UI - Input actions

If you remember, in an old dev log I started using the Common UI plugin of Unreal Engine. Well just before the publication of 0.4.2 I found an annoying bug that would prevent the Game Master from clicking a scene if a menu was open, making selecting item, impossible.

Because I didn't had time to fix the problem, I did a small patch and added a button to close the menu so I could have the possibility of selecting things again.

Since then, I did some research and test that allowed me to understand that the inputs of Common UI go trough all of the game inputs.

When it comes to the Game Master, the right click allowing to hide the menu and the left click allowing to select are both going trough the menu and so, when I right click or left click its the menu that receive the input, not the game. I know that it is a problem that will impact a lot of elements of the game, notably the Photo mode and all QTE

Sadly, this means that I can't use the Common UI inputs and the buttons link to the UI will have to work without it.

The simplest solution, witch is also the most complicated, is to recreate everything the way I want it.

To do this, I created specific interactions that trigger the action buttons depending of their settings when the game receives and input.

I made a date base like in the Common UI plugin where each input has its own image that will than show up on the button for a previsualization. The button will be updated depending on if the user uses a Keyboard/mouse combo or a controller.

I also upgraded the system for my own use so I may trigger only the action buttons of the focused elements. Now, the Game Master works like it did before and the action input works without conflict.

I also bought some icons packs that will be used for the actions inputs. Those inputs are, for now, used in the game alpha. It is possible that they may be changed during development.

Controller Icon Pack: PC Only https://www.unrealengine.com/marketplace/en-US/product/controller-icon-pack-pc-only

Controller Icon Pack: XB Only https://www.unrealengine.com/marketplace/en-US/product/controller-icon-pack-xb-only

UI - Menu domain widget

The interface in MMVS works in very specific ways. I have the HUD script take control of the in game interface globally. The HUD has multiple menus managed by modules like the code and works specifically to they utilisation. Each menu will have a list of pages and under-pages to show.

To manage the list of pages, under-pages, display, transition, focus, etc. I created my own action inputs with 0.4, then, I transitioned on the Common UI plugin in the migration toward UE5 with the 0.4.2, thinking that would simplified the task, but the possibilities are too tight.

So I went back to where I was before with my own system. Like the action input, this demands a lot more work than if I used things that are already available. But, I prefer having the control on what is and is not possible to do with it. I am able to manage the transitions way more easily and am able to do modifications that fits my own needs.

Finally, the Common UI plugin of Unreal Engine will have made me lose a lot more time than it gave me since this project is already pretty advanced and demands a lot more than what is proposed by the plugin.

UI - Customization and Gamepad picker

With all the modification, I kept working on the customisation menu which work with the in-game controller. Notably, I added a pop-up of selection for the colors and added the control of the Color values via the in-game controller.

I also took advantage of this to correct the animation of Cobble inside the customization menu. He can now turn his head and react to the music like before.

UI - File manager and Preset Import/Export

I added on the customization menu, the possibility to import and export your own customization, but for that, I had to create my own file management.

The file management allows to navigate inside your computer files, whether it is Linus of Windows, and to save or read the files. It also work with the in-game controller!

Interact FX UI

I reworked the interaction module, and the icons display in the 3D space, which allows to know where the player may interact.

At the moment, the interaction icons in the 3D environment are managed with simple particles effects which will be updated depending on the data of the interaction module. All of this is accomplished in real time and calculate on the GPU which allows for a low resource consumption.

Before, I used transparent faces with textures and position that were update via the CPU. This is something to avoid. At the moment, the name floating above the players and icons of teleportation that are visible in-game are always managed by the CPU. As I go and update the game, I fix those little problems.

Net code and replication

I globally reworked on the replication, the number of data, the refresh time between sending and the condition to send like the distance.

I also changed the way I approach certain utilisation; I will use less the replicate events and concentrate on the replicate data.

Replicating an event allows, for example, to notify all clients when Talas put on his shoe on the server side. It works well, but when the client has a desynchronization at the same time that it logs onto the server after its execution, it won’t be notified that Talas is supposed to be wearing that shoe and the game will be bugged on their side.

So it is preferable to replicate a simple variable that tell whether or not Talas wear his shoes and let the code execute depending on the server side and client in case of modification.

If the player has a desynchronization or they rejoint after the execution of the variable, the client will be updated anyway when the connexion will allow it and execute the code if need to.

A problem that I encountered on the UE5 is that the native replication of movement will replicate the actor depending on the absolute position in the world and not of its relative position.

If a player is sitting, attached to a chair and the chair is not in the position on the server side and client side, the character on the client side will teleport where the chair position is on the server side.

To solve this problem, I must deactivate the native replication of movement and replace the character depending on the chair from the server and client side.

But this also create another problem where a character does not replicate a movement and is attached, the animation script stops updating itself and freezes the character in its pose which makes it impossible to resolve the issue.

So I have to update the native replication or fix this problem of animated script not updating correctly which is not possible without modifying the source files of the engine and lose a ton of time doing so.

I have to brut force this and make it so that the player position changes with each image. Its far from the most ideal outcome, but it will fix the problem without using too much resources.

Orb light and static mesh.

I also corrected the bug of the orbs render, the light effect is way better and the model is optimised for UE5. I also made the actor fully dynamic to be able to further play with the light effect and avoid the problems of render with Lumen.

When it comes to optimizing the model, UE5 works a lot better with static meshes than skeletal meshes.

So I use an invisible skeleton to manage the animation and use static meshes for the different item parts.

I also use the same technology for Talas house doors and will use this technique for the remoted controlled car.

Lumen map

I updated the Lumen level with more interactable lights and new textures. The whole works in multiplayer.

To be frank, I see this level like a public test, so I have fun adding interaction that would not necessarily be coherent with the game universe.

Toy car

I fixed the toy car with the new physic engine and took advantage of that to improve the experience and feedbacks like the engine sound, the lights, speedometers and the ability to respawn and return the car.

As things stand now, it is not possible to control the vehicle in multiplayer if you are not the host.
The problem comes from the fact that vehicles in Unreal Engine are considered like characters. I would have to make it possible for the player to lose control of Cobble and become the vehicle. So, I would have to update every dependence like the camera control, the visual effects and recreate some code like the management of hands in VR in the vehicle itself.

It's work that would require way too much time for something that is not really indispensable in the game at the moment.

So, I came back with a simple solution. The player entries are copied in the toy car and activated only when the player uses it. This solution allows to control the remote car without problem, but this function is only available in sole or for the host.

Character Scale

I added an option to debug that allows to modify the scale of the character.

In MMVS the scale of the characters is not managed directly in function of the actor scales. I a character has a scale of 20, its actor will keep the scale of 1, and the component of the actor will be updated depending of the situation. It’s the case for the collision collider which will update the size values, but also the values of the character movement, gravity or jump high.

What is really complicated here is to make the size change work in real time. It’s not programed by the base character script, notably because of the values that put in cache and are normally inaccessible.