![](https://media.discordapp.net/attachments/517010400860962831/1088287410657439814/image.png?width=1440&height=611)

Turn based game where both players act at the same time.

Codename Prototype

Exanite

RoboZero

It's been a *while* since I've last done a showoff post and an *even longer while* since I've posted about Codename Prototype.
Despite that, I've actually been working on Codename Prototype for the past few months!

Most of that time was spent refactoring and overhauling existing code, but I've recently started working on a 2D in 3D game world for the game.
I've also added dynamic music and some animations.

I've been working on a bunch of scattered tasks for the past few days in Codename Prototype.

Today, I worked on automatically adding localization entries. Previously, the localization key had to be added manually and was very tedious.
This is done by adding an attribute and using some custom editor code to draw a button if the localization key was missing (Odin Inspector made adding the editor code fairly easy).

Today I implemented a InMemoryTransport that allows for simulating a local network connection, mostly for fun, but I might use it for CodeName Prototype.

---

I also wrote up a plan for how to reduce code duplication in CodeName.

One of the problems was due to treating singleplayer and multiplayer code separately. Simulating a server in singleplayer removes the need to program singleplayer and multiplayer separately.

Another problem was that I had two state machines that needed to always be synced with each other. Because the two state machines represent the same states and always need to be in sync, combining them reduces code duplication.

This was originally due to my incorrect decision to have the game simulation and game UI track the game state separately, as a way to separate game logic and game rendering (separation of concerns/single responsibility principle). However, the UI state machine contained important game logic and arguably doesn't do any rendering at all. Despite the naming, this makes the UI state machine fit better into the game logic layer than the game rendering layer.

Today I finished implementing the network channel system I was working on and updated Codename Prototype to use it.
Overall, the code is a lot easier to write and understand now.

Here's a high level overview of how the channel system works along with the rest of the networking library I am working on.
Data travels from one end of the diagram to the other through 3 different layers before being reversed on the other side.

Today I worked on networking again, focusing on refactoring my existing networking code and adding a confirmation process to the protocol.
Only after the protocol has been confirmed can messages be sent through each channel.

It's again been a while since I've written a showoff post 😅.

I've been working on a lot of different features in Codename Prototype recently, but the current feature I'm working on is for improving the game's networking system.

For context, the networking system I'm using is completely custom (self enforced restriction) and that means I have to implement almost everything myself.
It's *almost* everything because I don't implement the RUDP layer. I use LiteNetLib and Unity Transport for that. Everything related to serializing and sending packets is on my end though.

One of the issues of my networking system is that I'm, for the most part, sending raw byte arrays around.
The issue with raw byte arrays is that they require a decent amount of boilerplate to read and write, leading to very verbose code.

In order to fix this and to make it easier to implement networked features, I'm adding a network channel system where developers can register packet types and assign them a ID.
On the developer's end, a string ID is used. This is to reduce collision chances. *However*, this is bad for bandwidth. Ideally an integer is used to reduce the amount of data sent.

To optimize bandwidth usage, I first send list of channels used by both the server and client. This is to verify that the server's and client's channel lists are compatible.
The next step is to swap out the string IDs with integer IDs. I do this by having the server determine the integer IDs then sending them to the client.

This last step is what I implemented today, and the result can be seen below in the image. You'll see that the server and client ids match and are in the same order.

Yo I heard you like Unity UI Layout groups.
Today I put a Horizontal in a Vertical in a Grid in a Horizontal layout group. 
(For Codename Prototype UI update before more extensive playtesting)

It's been a while since I've written a showoff post. Let's get back to it.

One of the problems I've been facing in Codename Prototype is how to properly generate IDs.
It's an interesting problem since the server and client has generate the same IDs while keeping each ID unique.
My original implementation used an incrementing counter. For example, the first ID generated by the server and client will always be 1, then 2, then 3, etc.

I can do this since Codename Prototype uses a deterministic simulation. The server and client are guaranteed to have the same output given the same input. This means the same IDs will always be generated.

This is fine for the most part, but runs into a problem with serialized data. Serialized data can bypass this system by specifying an ID that has already been generated OR will be generated in the future.
This is bad. Id collisions means that one ID will refer to multiple entities.

For some context, typical ID generation systems focus on preventing ID collisions, usually by using a multi part ID consisting of a timestamp and process ID (Eg: Discord/Twitter snowflake ids). With networked games, typically the server generates the IDs and tells the client what IDs to use. This allows the IDs to be unique, but also be consistent between the server and client.

Previously, I couldn't use either of these because using RNG in a deterministic simulation would cause the simulation to be non-deterministic. Additionally, I designed Codename Prototype to not require dedicated networking code, so passing messages between the server and client wasn't an option.

However, I now have a snapshotting system in place where the client simply uses the result generated by the server. To prevent collisions from serialization, I can now use C#'s Guids. This solves both of the problems I had with IDs (consistency and collision prevention).

Alright! Today I checked off two major items off of my todo list AND also did a major refactor of the Codename Prototype codebase.

The first major item is updating Abilities and AbilityEffects to use the standardized EntityAsset (behavior), EntityInstance (id), EntityInstanceData (data) system. As shown in the parentheses, these represent the three major parts of an object. In Codename Prototype, I separated these out to ensure that each can be treated and used independently.

The major refactor of the codebase was also related to the Asset/Instance/Data system, focusing on making it easier to add new Entity types in the future.

The second major item off my todo list was to add priorities to the different Entity type's event handlers. This priority is used to decide the order of when different entities in the game will be notified of events.
For example, if GameRule A had higher priority than GameRule B, GameRule A will always be notified first.

For this system, I decided to snapshot the list of entities at the start of the event, sort the list, then notify each sequentially.
This is because entities can create new entities while the first event is being processed. Without snapshotting, the entity list would be modified and the foreach loop will break (since C# does not allow modification of a list while it is being iterated). This does mean that new entities will miss the current event, but I think it's a minor issue because it's only the current event. Removed entities will also be notified of the current event, but also a minor issue, at least when compared with alternative solutions (constant diffing of the entity list... which is very performance intensive).

An additional requirement of this priority system is ensuring that the client AND server have the same priority list. This is done by sorting by an integer priority, then tie breaking with the asset key.

Since the async-rewrite of the codebase is now mostly complete, I switched over to focusing on a different task today.

One possible task I could have worked on is adding a way to defined GameEvent handler priority. This, for example, allows developers to declare that a certain StatusEffect should always handle events before another StatusEffect so that it can intercept and prevent the event.
GameEvent handler priority is something I've been thinking of implementing for a while, but it's a bit difficult to do in practice because of all of the possible edge cases.

Instead of that, I focused on GameEvent matchers. I implemented 3 matchers: MatchOn, CausedBy, and PrecededBy.
MatchOn is the base matcher that other matchers will use.
The names are fairly self explanatory. CausedBy checks if an event was caused by another event, PrecededBy checks if an event is preceded by another.

Here's an example query that checks if a Magister unit was attacked:

Since I completed my custom async-await StateTask implementation yesterday, I started to update the codebase to use it today.

Currently I have updated all of the gameplay related code, but the simulation related code still needs a bit of work.
To my surprise, the Generative simulation was fairly easy to implement, requiring much less code compared to before to implement.
Unfortunately, I can't say the same for the Regenerative simulation. I'm still working on that right now 😅.

For a quick comparison on how the simulation works with async-await and without async-await.

The previous simulation implementation (without async-await) used what I called Deferred Events. With this simulation, each GameEvent was treated as a separate unit.
This is what allowed for pausing between each events. This also meant that GameEvents were executed in a LIFO/Queue style.
This however, is a slightly unintuitive way of writing code because Raising an Event does not mean that it has completed yet. This is because Raising an Event simply queues it.

With async-await, I can still pause execution of events while keeping a more intuitive FIFO/Stack style execution model.
One of the traditional advantages of async-await is that you can write asynchronous code in the same style as synchronous code by awaiting asynchronous parts of the code.
This is the same advantage I sought for during the implementation of my custom task system.
With this system, Raising an Event is much more intuitive since you can use `await` to wait until the Raised Event has completed executing.

A bunch of experimentation and tweaking later, I think I got a working custom Task implementation.
It's basically the same as Task or UniTask, but does not do threading or scheduling. The remaining functionality left behind is the only part I need: the ability to pause execution of methods.

You might notice that I started with GameStateTrackerTask yesterday. I also had a EventRaisedTask.
I found that just implementing the tasks as generics was simpler and more flexible so that's what I have now.

In the image, StateTaskCompletionSource is like a remote control. By calling Complete, I can continue the execution of code (otherwise it remains paused).
In this case, I'm calling it immediately, but in theory, the CompletionSource can be passed anywhere.
I plan to use this with the UI to step through each game event one by one while playing animations for each. Without some way to pause the execution of the code, the game will just calculate everything in a single frame, which doesn't work for animations.

Not me at 5 AM writing custom async code.

Worst part is that I'm planning to use this async code synchronously. The main benefit is that async-await allows execution of a method to be split into multiple parts and paused.
This is mostly an experiment, but I'm very interested in seeing if it actually works the way I want it to.

IEnumerator/iterator/generator functions would probably be easier. They do have a different execution model though.

It's also interesting seeing how everything connects together.
One of the rules with async-await is that you always need to `await` an async method. 
Without awaiting, you'll have silent failures when exceptions are thrown. That's very bad when debugging.

The reason the await is required is because `await` calls `Awaiter.GetResult()`. `GetResult()` is what throws the exception. Without `await`, the exception is not thrown.
`task.GetAwaiter().GetResult()` is the synchronous and manual way of getting the result. In my implementation I just return null, but C#'s implementation will call `spinWait.SpinOnce(-1)` until the task completes (if it's on the same thread, it will never complete).

Today I fixed a serialization bug that I didn't notice until earlier today and updated the replay system for Codename Prototype to use GameEvents instead of PlayerCommands.

Apparently, with Json.Net for Unity, the JsonIgnore attribute is ignored when used with Unity's SerializeField. Fortunately StackOverflow had an easy fix.

With the replay system, the reason I switched over to storing GameEvents is because GameEvents are more generalized and can be used to represent more than just player input. One such example of this is the GameStartedEvent. This allows any important event that occurs in Codename Prototype to be saved and replayed.

Additionally, GameEvents can be serialized as either only the root event, or as an entire tree structure.

For some context, Codename Prototype's data engine can be ran in two different modes:
1. Regenerative (Replay) - The event tree is strictly followed and each event is replayed in sequence.
2. Generative (Core) - Only the root event is stored and additionally events are raised in response to the root event.

Both of these should produce the same output, but the Regenerative mode will be important for the server code in the future.
This is because this allows data to be hidden from the client, as a way to prevent players from accessing data that they aren't supposed to (eg, the other player's hidden goal cards).
Because data is hidden, using the Generative mode is higher risk and can lead to more desyncs. Using the Regenerative mode decreases that risk.
Additionally, the Regenerative mode also allows for server-only logic to be ran without the client being desynced. This is because all relevant events are included, rather than only the root event.

Today I implemented the TypePropertyCollection I designed a few days ago (see <https://discord.com/channels/1016463705011134465/1016463705401200705/1102419327984083054>), now called "InstanceDataCollection" to better reflect its usage.

I also converted everything over to use the new data system, which honestly took longer than the implementation of the new system, which was just a dictionary and serializer.

Today I added a quick mod to Codename Prototype to verify that the new modding and GameRule system works as intended.
There were a few things I had to fix during the process, such as the code not generating properly, but overall it works! 😄

Not so much programming today compared to yesterday, but I worked on designing a different part of Codename Prototype's codebase today.

One of the problems Alex and I noticed was that it was difficult to generically apply a feature to every StatusEffect in the game.
One such example is making it so that a StatusEffect has a duration.

This is because in order to implement a duration for a StatusEffect, both data and functionality is involved.
Functionality is easy to do generically because Codename Prototype has a concept of GameRules that can iterate through each object.
But in order to define data, an interface has to be implemented *separately* on each StatusEffect's InstanceData class*. This is because I use inheritance to define InstanceData.
This also shows that data cannot be implemented generically.

* I separate objects in Codename Prototype into two parts: behavior and data. Behavior = the ScriptableObject asset. Data = Instance and InstanceData. This is basically the flyweight pattern. This same pattern is also used in Minecraft, which is where I got the original idea.

To fix this, I'm considering adding a way to generically *compose* data together. In other words, I'm using composition over inheritance.
I've written a similar system before, but this one is specially designed for Codename Prototype's data requirements. At this point, it's not complete and I still see a few potential problems, but it should be more flexible than before.

Pseudocode for how the API might work below:

I started working on some code generation today so that it is possible to refer to Codename Prototype's assets in a type safe way:

Today I worked on being able to automatically add assets to Codename Prototype's GameResources dictionary.

You might notice that the type of the ScriptableObject is "ModInfo". This is because I also plan on using this as a mod system where assets can be added or replaced by adding additional mods.
I'm also looking into Unity's Addressables system. I don't envision myself using it in the near future, but I'm trying to get more familiar with the system so that my modding system can eventually work with it.

I finally found out why these desyncs were happening in the first place. Apparently my Core and Replay simulations had the events being called in a slightly different order.
This caused the state snapshots to be taken at different points in the game's simulation and be ever so slightly off. For example, a counter being at 1 instead of 0.

I also started working on making GameEvents be serializable. This will be important later on when I start streaming GameEvents from the server instead of just providing the initial input.

One of the issues with my desync/drift detection system was that it was inconvenient to tell *what* exactly is different.
This is because diffing the game states required manually copying the serialized game data to JsonEditorOnline.

I made it so that it now automatically generates a link that loads up the game state in JsonEditorOnline, so it's now a 3 click operation instead of involving multiple window switches and copy pastes.
I did experiment with showing the diffs directly in the log message, but I didn't find an easy way to diff json files in C# (other than writing my own library). There is JsonDiffPatch, but it doesn't work well with arrays of objects.

Today, I added a way to intercept events and prevent them from happening.
This allows effects to, for example, prevent a unit from dying and restore their health.

Yup, looks like I hit the effective MTU for Unity's `FragmentationPipelineStage`. The default is set to 4096 which matches what I'm seeing from my testing (3968 can be sent, but 4096 fails. Not sure of the exact number, but that doesn't matter.).
I *can* set it higher, but I'd rather not because I have to also tweak the `ReliableSequencedPipelineStage` to allow more packets to be queued. It's also not a good idea to use a game networking library to send extremely large amounts of information since the libraries aren't designed for it and it leads to high latency.

Today I took a short break from working on event related code and worked on compressing the data that I was sending over the network.

Currently, the way I'm sending the game state is by serializing the entire game state as JSON and directly sending that.
However, that is a bit inefficient and leads to a lot of data being sent.

To improve this, I added a compression step using Brotli compression to reduce the amount of data sent.
This reduced the amount of data sent by a pretty drastic amount (for example, from 4706 bytes to 598 bytes).

Overall, this is a great optimization, but I'm actually not doing this for the optimization.
With networking, there's a concept known as a Max Transmission Unit (MTU). That's the max size a packet can be.
That value is usually around 1000 to 1500 bytes. As you can see, my data is a lot higher than that.

The usual way to get around this is to either reduce the size of the data or to split the data into separate packets.
I'm currently doing both, but I'm not sure if I'm properly using Unity's UTP packet splitting feature correctly so I'm doing the compression as a band aid fix.
It also doesn't help that Unity silent fails instead of throwing an exception when the data fails to send.

I mostly did refactoring and cleanup work on Codename Prototype today, mostly focusing on the game's event system.

The first area I focused on was to convert code from the old event system to use the new event system. However, the new system is a bit more verbose so I'll need to revisit this in the near future. I mainly wanted to remove deprecated code instead of making things pretty here.

The second area I worked on was to clean up the event tree and other event tracking code. For this, I added a GameEventTracker class that simplified the creation of the event tree. This took a bit of time since the Core and Replay simulations had their own implementations, but condensing the two implementations into one was very much worth it. The result is that both the Core and Replay simulation code is simpler and much easier to read.

Taking a look at the logs and checking the diff between the expected and current states, the only differences between the two states are the IDs.
This is because the IDs are randomly generated. This is good if you want every ID to be unique and generated independently of each other, but with a deterministic simulation, everything should be replicable. Non-deterministic randomness prevents that.

To fix this, I added a simple ID system where IDs are generated based on a counter stored in the GameState. Each time a new entity is created in the game, the counter is incremented and the current value is used as the entity's ID.

Interestingly, since IDs are now a simple incrementing integer, it is now possible to see the order that entities were created in the game by examining their IDs. Higher numbers means that the entity was created later.

With this system in place, I haven't seen any other divergences between the Core and Replay simulations (no warnings in the console 😄). There might be a few left, but with the safeguards I put in place, they should be very easy to debug.

Alright, just added an initial implementation of the event deferring system I talked about yesterday. It's just a queue that enqueues all child events and runs all of the child events in a for loop after the parent event is done executing. Unfortunately, this simple implementation isn't enough to have everything work together just yet (it flattens the event tree when it shouldn't), but it is a good start.

I also added a drift detection system between the core and replay simulations.
Here's how it looks after the event deferring system was added (only 2 mismatches left):

As it turns out, fulfilling those requirements I mentioned yesterday turns out to be very difficult. I had long known that these requirements are going to be difficult to fulfill, but there were a few additional issues that I did not foresee.

Under a deterministic system, same inputs should equal same outputs. However, as you can see in the diff below, the states are different. This one fortunately is easy to fix, but there's some harder to fix issues that I uncovered today.

The two simulations that I run of my game: Core and Replay, run by very different rules. Core is synchronous, and because of that, I realized that there was another issue I needed to address: child events can run during the execution of the parent event. This is because synchronous function calls naturally block the caller until the function completes. This is fairly obvious behavior, but the not so obvious part was that I have to imitate this behavior in Replay, otherwise Core and Replay will function differently.

Fortunately, I think I have a potential solution figured out: instead of imitating the synchronous behavior of the Core simulation, I'm planning to make Core defer event calls so that no child event can run during the execution of the parent event. This will match the behavior of the Replay simulation, thus preventing the two simulations from diverging.

I've been rewriting Codename Prototype's event system for the past few days. Today, I focused on making sure that the Replay/UI event tree was properly recreated based on the Core event tree.
As a quick summary, each turn in Codename Prototype is actually simulated twice. Once synchronously in the core simulation and another time asynchronously in the replay simulation.
The first simulation finishes instantly, but provides additional information for the replay simulation, which is shown in real time in the game UI.

It's a bit of a weird design, but it separates a lot of concerns between game logic, but so far it's been extremely helpful with implementing UI animations, multiplayer, and replay functionality into the game.

Here's some scratch work I used when implementing the Replay/UI event tree code:

I finally got automatic versioning to work with my automated build pipeline!

It was supposed to be fairly easy to implement, but apparently there was a security fix to Git that affected how my code works during the build.
Because the builds run on Github Actions and not on my computer, debugging what was going on took forever.

Today I worked on a versioning system for Codename Prototype so that the builds of the game are easier to identify. 
Currently they show as confusing incrementing numbers in itch.io. They also aren't synchronized across different platforms so Mac version 6 might be the same as PC version 7.

Currently the version can be seen in the build directory and as a menu item in the Unity Editor.
However, my main goal is to integrate it into itch.io. Specifically, you'll be able to see the versions in the itch.io launcher when you switch between different versions of the game.
It's almost done, but it's unfortunately almost 12 so I want to get my showoff point for the day 😛.

In addition to the lobby list in the main menu, I've also added a copy button next to the join code when you are waiting for players.
With both the lobby list and the copy join code button, it should be a lot easier to join games in Codename: Prototype. 😄

Today I added a lobby list on the side of the main menu to make it easier to join existing games (the UI is temporary 😅).

I set up an automatic build and publishing system for Codename Prototype today.
Each time a commit is made on main, a new build will be built and uploaded to Itch.io automatically!

The Itch.io page for Codename Prototype is still not public yet though. We're still working on polishing up the page 😄

Created Atrophy, Gale, and Counter abilities for CODENAME: Prototype! Tested them with William 😄

I forgot to showoff yesterday, but I finished adding the logs and notes tab. Both of the tabs are useful for planning.
I also rewrote a decent chunk of the code related to abilities and events today.

I did a bit of game architecture design today for Codename Prototype. This tree based event log design has been on my mind for a while, but today I made the design more concrete by writing it down and figuring out how to begin implementing it.

Our current event log is completely flat and linear instead of a tree like above.
While the tree like log structure will be applied in the same way as a linear log, having a tree provides a bit more information — namely tracking parent-child relationships between triggers and triggered effects.

Since Codename Prototype requires planning and keeping track of what your opponent does, I've started adding a notes and logs window to the game.

The ability tooltip system is almost complete! Today I added some code that will hide the tooltip after the cursor leaves the ability element.

The system still has a few issues though, mainly a flicker that occurs when the tooltip first displays. This is because the height of the tooltip isn't known when the tooltip is first created.
The issue also occurs in a few other areas, but I've fixed most of those.

I keep making these random utilities for my UI code 😅
This converts the pixel based offsets into percentage based anchors. This makes the elements scale with the parent by stretching rather than displacing.

Today I added the data syncing part of the tooltip system and added descriptions to each of the effects.
I also wrote a bit of custom layout code to make sure that the tooltip resizes correctly for longer descriptions.

You'll notice that for one of the abilities, the effects don't have icons. This is because that icon is actually a GameObject instead of a simple sprite. The tooltip also doesn't automatically hide yet.
I'm going to work on fixing these two issues next.

I worked on Codename Prototype's tooltip system today and designed an ability tooltip. 🔎 
The tooltip doesn't have any actual data connected to it just yet though. I'm probably going to work on it tomorrow or on Friday.

**Watch your step**

Added a Caltrops ability in Codename Prototype. Place it on a tile as a trap, then 
pressure your enemies to move onto it to save their allies.

*Design wise:*
*1. CP is prediction based. Negative punishment -> more predictable enemy*
*2. 'Pops' the Divine Shield effect on the enemy Knight, preventing damage.*
*3. Source of passive damage much like the Ninja's Deathmark (tm)*

First of many environment effects, supported by William 😎 
The symbol is a bit small right now, so I'll show it tomorrow <:thonk:1017485648019603456>

I wrote some custom layouting and animation code for the goal cards in Codename Prototype today

Today I improved the existing status effect bar and added icons for the new effects that @Alex G. (RoboZero) added.

Only a bit past midnight 😅, but I began to add in a more full featured status effect system to Codename Prototype today!
Previously I simply stored the (singular) status effect I had as a bool.

The DeathMark status effect was created by @Alex G. (RoboZero)!

While @Alex G. (RoboZero) and I were testing out Codename Prototype yesterday, we discovered a bug where if one of the players couldn't take an action during a turn (due to being down a few units or having their units disabled), the game wouldn't render any of the actions taken by the other player.

It turned out to be a bug in my state machine code. The player was stuck in the select ability state and because of that, it couldn't go into the turn replay state.
I added a check to select ability state and it now exits if the player does not have any available actions to take.

It's been a while since I've shown off, but here's one of the projects that I'm working on.
It's a multiplayer turn based game where both players move at the same time.

I added in voice lines that play when you select a character today and also cleaned up some of the UI code so you can't select other player's characters, etc.

I got the new targeting system working with the existing ability system today, but I still have a few things I need to implement before it fully works.

Beginning to prototype a new targeting system for the TurnBasedTacticsGame. Here's a sneak peek:

After spending a good chunk of the day working on this project, I now have the ability system in a decently working shape.
Each unit can now be given specific abilities and the player can select from them when it is that unit's turn.

I also worked on the UI, rendering, and a bunch of other miscellaneous things.

Finally getting some gameplay working with the Turn Based Tactics Game project.

For the last few days, I've been refactoring the map editor code and rewriting basically all of the input code for the game. This was a break from that and honestly was pretty quick because I had most of the systems in place already.

I got unit health bars working and the unit event system simply works when I go back to my other scene 😄
Units are cleaned up properly along with any UI elements that were created.

Starting to add a proper event system to my game 😄

I implemented a basic auto battler and organized my code today.

Currently each unit has a basic attack that deals damage based on how far the enemy is, the closer the more damage.
Here, the units take turns attacking each other, using damage prediction to determine which enemy is the best option to attack.

At the end, the units don't attack because they are too far away to deal damage.

Not much to show for today, but I organized the code that I wrote this week and tried out git subrepo for including one of my shared libraries into the tactics game.

Today I added an actual laser vfx in my game and a multi laser ability:

I decided to try out Unity's VFX graph today in order to make a laser effect
Little did I know that it would look more like a flamethrower effect when I was done 😅

I finally finished one of the projects that I was working for a summer class and now I'm back to working on the tactics game.

I improved the ability system that I was working on and this is a video of it in action.
Currently it doesn't do much, but new abilities shouldn't be too hard to add now that I have the core of it set up.

A big focus of my design is to make it so AI and UI can easily interact with the system, in addition to the goal of making it easily expandable.
This way, both players and AI enemies can use the same abilities and the UI can show what an effect is going to do.

I worked on my PropertyCollection class a bit more today and added a few more features on top of the core functionality, mainly validation and events.
In addition, I expanded the number of unit tests that I'm using to test the functionality.

Main idea of the PropertyCollection is to act as a more type safe `Dictionary<string, object>` that lets you access properties of varying types by name.
By using PropertyDefinitions, string based access and type casting is avoided.
```cs
var name = collection.GetProperty(nameDefinition); // nameDefinition = new PropertyDefinition<string>("base-game:name", "Default value");
Debug.Log(name.Value);
```

I did a bit of work on the ability system and added a way to store data in a generic fashion (PropertyCollection).
For the PropertyCollection, I also wrote a few tests to make sure everything was working.

I'm currently prototyping how the ability system is going to work for Alex and I's tactics game, mostly focusing on the structure and how data is going to be passed around than anything else. Each ability represents a slightly different use case and I'm trying to make sure that the usage of each is consistent.

Not much to show for today, but I wanted to get my showoff points for today 😛 . I spent the last few hours organizing the Unity project for Alex and I's tactics game and going over my old code.

This Scriptable Object Creator was part of the old code that I dug up from one of my older projects:

The map editor I'm working on now also has a debug pathfinding tool!
Everything is starting to come together 😄

Saving and loading!
Technically I had this working a few days ago, but I've rewritten the save system like 3-4 times since then because I was trying to find a decent way to serialize the data.

Main difficulty were that I was trying to do the serialization without instantiating MonoBehaviours (since Unity doesn't let you call MonoBehaviour constructors) while keeping all of the references intact.
I ended up creating a valid version of the grid first and then serializing the data into each tile based off of the position specified in the json.

Still working on serialization for Alex and I's tactics game, but since yesterday I've written quite a bit of serialization code and I have also rewritten the ReactivePropertyConverter I wrote yesterday.

The big changes were that I realized I didn't need to make an intermediate JObject for holding the Json and that JsonSerializer supports deserialization by Type object in additional to the usual generic overload of the Deserialize method. This removed most of the ugly reflection and shortened the code to a very acceptable amount.

I also experimented with C# nullables, which can be enabled with the `#nullable enable` preprocessor. Since it analyzes your code for possible null reference exceptions, code written with it on should be much safer.

Currently trying to write a custom JsonConverter (Json.NET) for UniRx's ReactiveProperties.
Ended up in the land of reflection and hard to read code 😅 

The WriteJson method works as expected, but I'm still ironing out the issues with the ReadJson method.

Currently attempting to serialize and compress my grid data
Apparently brotli compression reduces my data size by 26x

I spent the last few hours identifying and fixing different edge cases in my pathfinding code
I think I fixed most of them, but if not, I'll probably just fix them as I go

Here are a few that I fixed:

Welcome to the testing grounds

Technically my second showoff post today, but I think I finally finished my wall and height pathfinding logic

The MapEditor now will automatically update tile walkability when the grid is edited, along with a few other calculations
I also implemented walkability calculations in the case of walls, but there are a few cases that I haven't fully implemented yet (should not be able to vault uphill over a half wall)

The white "arrows" indicate that the connection is walkable
The purple "arrows" indicate that the connection is vaultable

Since this is updating the walkability of each connection, the pathfinding system will simply work with these new changes

Separated most of the ability functionality into a class which can be used on multiple units + general refactoring. Still unsure of why box gizmo exploded https://images-ext-2.discordapp.net/external/BQfTGmnm9_rerT1Vk8F4eSNWrN6R6Ui1cpN__nKK3TU/https/i.imgur.com/4zwVhq1.mp4

Not much new to show today, but I spent a bit of time restructuring the code I currently have for the grid

This image here shows the new grid builder component I'm writing and I plan on using it with the map editor that I'm also working on
Idea is to run the RunOnCreation processors once on startup and then use the RunOnEdit processors to update tile connections and other data as needed

Today, I cleaned up my map editor related code and implemented the wall editing tool
Next step for me will be to integrate the walls into pathfinding and possibly generate animation data so that characters will visually vault over walls and other obstacles.

Almost @ admin-ed. Added / fixed undo system on top of ability controlling by using a double stack approach. Also for some reason box gizmo exploded https://i.imgur.com/3SDsgIw.mp4

I added edge support to the tactics game grid I'm working on. (The mesh is only for debugging)
No map editor support yet though, but that should be fairly easy. Currently just generating random edges and that makes it look crazy.

The lower sections of wooden planks represent half walls that you can vault over.
The higher sections of wooden planks represent full walls that provide more cover than half walls.

Here's also a video of the map editor in action:

Worked on abilities with multiple stages. https://imgur.com/06gQMJG

Messing with a couple abilities. Hardcoding a couple first. https://i.imgur.com/xvDYYoi.mp4

Codename Prototype

Dev Logs