Blogs - TheChayed

It's been a while since I last posted. A lot has happened in my game developing days. I've worked on a few minor projects, and a few bigons. I'm going to start blogging more. It might not make a whole lot of sense, considering the continuing trend toward AI generated content, and dummifying every possible media platform. I'm a tad concerned about the whole AI trend. But, obviously, if you're reading this, it's not all for not. Today, I'm introducing you to a project I've been contracted to develop.

CardMancer is a Real Time Trading Card Battler game. Inspired heavily by Yu-Gi-Oh! Duelists of the Roses and MegaMan Battle Network.
The gameplay focuses on a small field full of Tiles with different elemental attributes. Each match consists of two players, with a Heart Stone starting on either side of the board in the middle vertically. Each player has a Deck and Discard pile, on their respective side of the Field.
Players draw 5 cards at the start, and continually draw cards after one minute, and each minute players acquire Crystals. All Crystals are reacquired at this point, plus one, and a card is drawn. A brief timeout is given for using cards from the Player's hand, and after the time runs out, the game enters a semi-realtime battle system where a pendulum ticks, incrementing the move/attack timers of each Monster on the Field. When each Monster's timer is full, you can attack, move, or use one of their effects to move across the Field and attack the opponent's Heart Stone.
When a Player's Heart Stone is destroyed, they lose.

I've developed video games for a while now, and I've run into quite a few obstacles I've had to hurdle over. If all the obstacles that I've faced, I would have never expected that the Card Effects in this game would be the hardest thing of all the game's features to implement. So far I've begun implementing the Effects using three different methods, and a the simplest seeming implementations have, surprisingly, been the most complicated.

The first method I tried was adding all the features of the Effect system into one Inspector Editor in Unity. Honestly, I didn't think this would be very complex. This was implemented in a such a way that for every option that was selected/ticked, the script would rewrite the Effect Description based on these values. I found that, as I added parameters and features to the Effect system, it became more and more complicated to construct descriptions in a way that made sense. So, it quickly became obvious that this was not a good option.

Another method that I'd attempted was using Scriptable Object Events/Parameters with their own Descriptions. I had implemented a small code parser which behaves very similarly to Twine, which allowed me to create conditional strings and string interpolation on the descriptions based on their parameters. This method ended up being pretty darn good, honestly. The main issue was the fact that I was using Scriptable Objects for everything, and it ended up creating quite a lot of bloat for even simple effects.

Something I've considered doing from the very beginning, a code interpreter which simply parses and reconstructs the Effects as a set of actual code commands. I was avoiding this method the whole time, because I knew it'd be complex to implement, but after all my struggles, I've concluded that this is actually the simplest and cleanest method. Effects are now legitimate code. Of course, they don't read that way. They read nearly the same as an Yu-Gi-Oh! card effect. Technically, it's a programming language. It's just a written language programming language.

The effects in CardMancer are in their infancy at the moment, and I'm excited to experiment with them show them off as development continues. Please, feel welcome to come back to my blog, as I will be sharing more in the near future on my development progress. There is so much more to share, not just about CardMancer, but also a few other projects that I've yet to share with the public eye.

The Unity Development Toolkit (UDT) is a set of tools and scripts that are designed to make it easier for developers to create games using Unity. Recently, Cairo has been working on reworking the UDT to implement the Entity-Component-System (ECS) architecture. This change is intended to provide a major boost in performance for games made using the UDT.

ECS is a way of designing game systems that separates the data (entities) from the logic that operates on that data (components and systems). This separation allows for better performance, as the engine can more easily optimize the systems and data. Additionally, ECS allows for better scalability, making it easier to add new features and systems to a game without affecting the performance.

By implementing ECS in the UDT, Unity is aiming to provide developers with a powerful toolset that can help them create high-performance games with ease. With the UDT and ECS, developers will be able to create more complex and detailed games, with improved performance and scalability. This can be particularly beneficial for games that require high levels of performance, such as real-time multiplayer games, virtual reality experiences, and other interactive applications.

Overall, the reworking of the UDT to implement Unity's ECS is a major step forward for Unity and game developers using the engine. It will provide a powerful toolset that can help developers create high-performance games with ease.

The Unity Development Toolkit (UDT) is a set of tools and scripts that are designed to make it easier for developers to create games using Unity. According to recent announcements, the UDT will finally be published on the Unity Asset Store at the end of January. This means that developers will be able to easily access and use the UDT in their Unity projects without having to manually download or install it.

However, before the official release, there is an opportunity for developers to become a beta tester. By simply emailing Richy@CairoCreativeStudios.com, anyone can become a beta tester and get early access to the UDT. This allows developers to test the UDT and provide feedback before it is officially released on the Asset Store.

The UDT is designed to help developers create games with Unity more easily and efficiently. By implementing Unity's ECS architecture, it provides a major boost in performance for games made using it. With the UDT, developers will be able to create more complex and detailed games, with improved performance and scalability.

The availability of the UDT on the Asset Store, and the opportunity to become a beta tester, makes it easier for developers to access and use the toolkit in their Unity projects. It will also provide a way for developers to test and provide feedback on the UDT before its official release.

Now that you understand the power and potential of the Unity Development Toolkit (UDT) and its implementation of Unity's Entity-Component-System (ECS) architecture, we would like to invite you to join our community on Discord. Our Discord channel is a great place to connect with other developers, share knowledge, and stay up-to-date on the latest developments with the UDT.

In addition to our Discord channel, we also encourage you to visit CairoCreativeStudios.com, where you can learn more about the UDT and other tools and resources we have to offer. While you're there, be sure to subscribe to our newsletter to stay informed about new updates, tutorials, and upcoming events.

By joining our community and subscribing to our newsletter, you'll be the first to know about new developments with the UDT and other tools, as well as have access to exclusive resources and tutorials. We look forward to connecting with you and helping you create high-performance games using the UDT and Unity's ECS architecture.

Here is the link to CairoCreativeStudios.com: cairocreativestudios.com/

and to join our discord server: Discord.gg

Hello everyone!

We are excited to announce that the Unity Development Toolkit (UDT) will be receiving major updates and will be moving from its free version to a paid Asset Store package. We understand that this may come as a surprise to some of our users, but we believe that this change will allow us to better support and develop the UDT in the future.

But don't worry, we haven't forgotten about our dedicated users. The UDT will still be an affordable option, costing less than half the price of leading competitors such as Game Creator and PlayMaker. We believe that the UDT provides valuable tools and resources for game developers and we want to make sure it is accessible to as many people as possible.

The updates to the UDT will include new features, improvements to existing tools, and bug fixes. We are constantly working to improve the UDT and make it the best it can be for our users.

We understand that change can be difficult, but we hope that our users will support us in this transition and continue to use the UDT as their go-to development toolkit. Thank you for your support and we can't wait to see what you create with the updated UDT.

Remade From Ground Zero

We are excited to announce that the Unity Development Toolkit (UDT) has been completely recoded from the ground up for easier use and better optimization. With the UDT, creating elaborate gameplay systems is as easy as the click of a button.

One of the major features of the UDT is its full vehicle system with customizable seats. This allows you to easily set up vehicle controls and create immersive driving experiences in your games.

In addition to vehicles, the UDT also includes various character types with easy control setup using Unity's input maps. This makes it simple to create and control different types of characters in your game.

The UDT also includes player controllers, which determine what the player is actually controlling. This helps to make your gameplay systems more intuitive and immersive for the player.

One of the biggest advantages of the UDT is its ease of use. All of its features can be accessed through a drop down menu at the top of the Unity editor, making it easy to find what you need without having to search for specific MonoBehaviours and figure out how to set them up.

Overall, the UDT is a powerful and user-friendly toolkit that will help you create elaborate gameplay systems with ease.

the old Unity Development Toolkit (UDT) were based on a misunderstanding of optimization and a lack of experience in streamlining Unity's development experience. Unfortunately, there are many packages out there that make this same mistake.

However, the UDT overcomes these issues in an elegant way through its simple interface. The UDT has been completely recoded from the ground up to provide better optimization and ease of use.

Real Code > Visual Code

the Unity Development Toolkit (UDT) has not abandoned the use of C# in favor of a "simpler" visual scripting language. In fact, we believe that doing so is limiting by design. While visual scripting can be useful in certain situations, it is not a one-size-fits-all solution.

Instead, the UDT will contain a lot of documentation and tutorials in the future to help guide users in using it to fine tune their gameplay experiences. We believe that understanding the underlying code and being able to work with C# is important for creating truly powerful and customizable gameplay systems.

However, that's not to say that the interfaces provided by the UDT features are particularly complex. In fact, they are designed to be simple and easy to use. A lot of gameplay features can actually be built with Unity Events alone, and the UDT also comes with UX features and script templates that are generated for objects when the button is pressed.

Overall, the UDT is a powerful toolkit that provides a balance of simplicity and flexibility.

The Third Person Character Controller

Setting up a third person character with the Unity Development Toolkit (UDT) is quick and easy. Simply select the option from the UDT dropdown menu and the whole setup for the character will be generated instantly within the editor.

The UDT third person character comes with a variety of features to make it easy to use and heavily extendable. It has fine-tuned platforming controls, an inventory system, a damage system, and more.

One of the key features of the UDT third person character is its integration with the Kinematic Character Controller and Cinemachine. These systems work together to provide smooth and immersive gameplay, and can be easily customized to suit the needs of your game.

The UDT third person character is also designed to be highly extendable. It has a variety of customization options and can be easily modified to add new features or behaviors. Whether you are building a platformer, an RPG, or any other type of game, the UDT third person character has you covered.

Overall, the UDT third person character is a powerful and easy-to-use tool that will help you bring your game to life. We can't wait to see what you create with it!

Vehicles

Setting up vehicles with the Unity Development Toolkit (UDT) is similar to setting up a third person character. Simply select the option from the UDT dropdown menu and the whole setup for the vehicle will be generated instantly within the editor.

When setting up seats that characters can sit in, they are displayed as collision boxes in the editor, along with a child object on the inside that displays a seat icon. The seat is where the character will actually be positioned when entering the vehicle, and the collision box is used to determine whether the character is close enough to the seat to enter it.

Each seat also has its own camera, which communicates with the character's player controller to switch cameras to the seat's camera when it is entered.

Streamable Objects

We are thrilled to announce a brand new feature in the Unity Development Toolkit (UDT): Streamable Objects. These innovative objects allow you to take your prefab workflow to the next level.

To create a Streamable Object, simply click the appropriate button in the UDT dropdown menu. Streamable Objects act as a layer on top of Unity's Prefab system, giving you the ability to build and edit your prefabs both inside and outside of the Prefab editor. Any changes you make to the Streamable Object will automatically be reflected in the corresponding Prefab.

But that's not all - Streamable Objects also provide an efficient solution for level streaming. Rather than loading all objects in the scene at once, Streamable Objects are only instantiated (loaded) when needed. This means you can place a Streamable Object in your scene, build onto it, and then when the scene is started, it won't actually exist until it is told to load. This can save valuable system resources and improve performance in your game.

Overall, Streamable Objects are a powerful tool that can simplify and streamline your prefab workflow. We can't wait to see what you create with them!

Level Components

We are excited to announce the addition of Level Components to the Unity Development Toolkit (UDT). These powerful tools can help you create immersive and interactive game worlds.

One type of Level Component available in the UDT is Trigger Volumes. These special objects use Unity Events and check for collisions with objects with certain tags to call the appropriate events. This can be useful for creating game flow and triggering events based on player actions.

Another type of Level Component is Platforms. The UDT includes a variety of platform types to help you build out the physical world of your game. These platforms can have different properties and behaviors, such as movable platforms or platforms that break when the player jumps on them.

In addition to Platforms, the UDT also includes Gravity Volumes. These special objects allow you to affect the gravity intensity and direction in your game world. This can be used to create interesting and unique gameplay mechanics.

Finally, the UDT includes Spline Collections, which communicate with Spline Agents (a layer on top of the vehicle system) to create smooth and realistic motion. Each spline in a Spline Collection has its own Animation Curve properties to allow for fine-tuned control over the motion of the Spline Agent.

Overall, the UDT Level Components are a powerful and versatile set of tools that can help you create immersive and interactive game worlds.

Rendering and Post Processing Features

The Unity Development Toolkit (UDT) includes a number of powerful Render and Post Processing features to help you create stunning visuals in your games.

One of the Render features is Shadow Projections, which allows you to create fake shadows that can be used to optimize your game and improve platforming mechanics. Another Render feature is Mirror Projection, which mirrors the appearance of an object in the scene.

Another Render feature is Squash and Stretch, which adjusts the scale of an object based on its velocity. This can be used to create a sense of momentum and weight in your game.

In addition to Render features, the UDT also includes a number of Post Process features. One of these is Focus On Object, which adjusts the Depth of Field in the Post Processing chain to focus on specific objects in the scene. This can be used to draw the player's attention to important objects or events in the game.

Another Post Process feature is Time of Day Bloom, which increases or decreases the bloom effect depending on the time of day. This can be used to create a sense of progression and atmosphere in your game.

Finally, the Time of Day Motion Blur feature adjusts the amount of motion blur in the scene based on the time of day. This can be used to create a sense of realism and immersion in your game.

Overall, the UDT Render and Post Processing features are a powerful set of tools that can help you create stunning visuals in your games!

Object Pools

One of the key features of the Unity Development Toolkit (UDT) is the use of Object Pools to improve performance. All UDT objects are already managed within Object Pools, which allows for efficient use of system resources.

Object Pools can also be used with Prefabs to store a certain number of objects that should exist for the current level. The Object Pool module will handle the rest, ensuring that objects are efficiently created and destroyed as needed.

Using Object Pools can significantly improve performance in your games, especially when working with large numbers of objects. The UDT makes it easy to take advantage of this powerful optimization technique.

Component State Machines

The Unity Development Toolkit (UDT) includes a powerful Component State Machine that allows you to fine-tune the flow of your game and objects in the world.

The Component State Machine has an interface that allows you to add MonoBehaviours to a state. When the state is entered, the MonoBehaviour will be enabled, and when it is left, it will be disabled. This makes it easy to control the behavior of your objects based on their state.

In addition to enabling and disabling MonoBehaviours, the Component State Machine also calls Unity Events and C# events that can be used to append functionality to their state status. This makes it easy to add custom behavior and logic to your objects based on their state.

Modules/Singletons

The modules in the Unity Development Toolkit (UDT) are automatically generated as singletons on an as-needed basis, so they never exist until they are used. When they are used, they are created as Game Objects in the scene that don't destroy on load. This ensures that they are always available when needed, while also minimizing the impact on system resources.

In the future, these singletons will assist in the control of the features of the UDT by utilizing Unity's ECS (Entity Component System). This will further boost the performance of games made using the UDT.

All of the features listed above, such as third person characters, vehicles, level components, and render and post processing features, will be easily accessible and modifiable through the modules. This will make creating complex games far simpler, as you can theoretically generate it all in one simple C# script.

Game Modes

The Unity Development Toolkit (UDT) includes a Game Mode module that helps you manage the various aspects of your game. The Game Mode module keeps track of characters killing or being killed, match time and status events, scoring, and team management.

Using the Game Mode module, you can easily set up different game modes, such as deathmatch, capture the flag, or any other type of game mode you can imagine. The Game Mode module provides a flexible and customizable framework for managing these aspects of your game.

One of the key benefits of the Game Mode module is its ability to keep track of character death and scoring. You can use this information to determine the winner of the match, or to track progress and leaderboards.

Overall, the UDT Game Mode module is a powerful tool that can help you create engaging and competitive gameplay experiences.

Introducing A Neu Adventure: a new game from Cairo Creative Studios

Previously known as Gumbot,A Neu Adventure is a 3D platformer game that takes inspiration from Disney Pixar films in its visuals and story. Players control Neu, a small robot toy, as they help a young boy named Billie overcome the struggles he faces during his summer vacation. By interacting with objects in the game world, players can come up with creative solutions to help Billie make the most of his vacation and even bring his parents back together.

As players control Neu, they must use their problem-solving skills to help Billie overcome the struggles he faces, including feeling alone due to his parents' constant fighting and his father's busy work schedule. By interacting with objects in the game world, players can come up with creative solutions to help Billie make the most of his vacation and even bring his parents back together!

In addition to Billie and Neu, the game also introduces other characters, such as Billie's friend Austin. Austin is a soccer-loving, boyish girl who has a crush on Billie, but he is oblivious to her feelings. As players progress through the game, they will encounter Austin and other characters who play a role in the story.

In addition to its heartwarming story, A Neu Adventure also introduces new gameplay systems and tools for Neu to use. These include a grappling hook, jetpack, and cannons that function as attachments. These tools will be essential as players must also confront an infectious virus known as "The Struggle" that threatens to harm children around the world. Neu and the other Home Health Bots must work together to save the children from this threat, all while remaining hidden from human knowledge.

As the game nears its conclusion, Neu comes into contact with other robots on the production line where he was originally built, leading to a shocking revelation!

Overall, A Neu Adventure is a heartwarming and exciting game that will appeal to fans of Disney Pixar, Ape Escape, Kingdom Hearts, and other 3D platformers. The game's emphasis on problem-solving and its unique blend of inspiration from different sources make it a must-play for any gamer.

Concept art for the game is currently being developed, some of which are included in this blog post.

As a game developer, I recently found myself in a situation where I was over-engineering problems while developing my game using the Unity Development Toolkit. I was so focused on trying to solve every possible issue that I ended up creating brand new problems for myself.

At first, I thought that sharing my code with others and making it easily adaptable for use in projects outside of my game was a good idea. However, I quickly realized that this was a distraction and was not helping me move the project forward. Instead, it was causing me to focus on problems that were unrelated to my game and were not contributing to its development.

In order to fix this, I had to rewrite my code and approach problem-solving in a different way. Instead of trying to solve every potential issue upfront, I learned to tackle problems as they arose and make sure that they were directly related to the development of my game. This allowed me to stay focused on the project and move it forward in a more efficient manner.

Additionally, I started making checklists of tasks that were directly related to the project and held myself accountable for completing them. This helped me stay on track and avoid getting sidetracked by unimportant issues.

Overall, I learned the importance of staying focused on the task at hand and solving problems as they come up rather than trying to anticipate and solve every potential issue upfront. By doing this, I was able to make progress on my game and ensure that my work was contributing directly to its development

A demo will be released near the end of the month.

Thank you for reading and we hope you are as excited for the release of A Neu Adventure as we are. Follow Cairo Creative Studio on social media and sign up for the newsletter on CairoCreativeStudios.com to stay up-to-date on the latest news and developments for A Neu Adventure.

when you're ready, follow this link to get the Toolkit and donate to it's development: Cairocreative.itch.io

Hello, everyone! Welcome to this little blog space of mine! Today I'm going to be talking about something I've been working on for quite a while, and I've posted about on and off since the creation of a game I titled "Spektor". I ended up shifting focus due to intrigue from my studio to work on something else, Gumbot. I've been simultaneously working on a project called Project Armada, which is a 3D Platformer based on Tails from Sonic the Hedgehog.

These, of course, are not the only things I've been working on, but they're important because they all involve the use of the UDT, which was previously labeled the Cairo Engine, and then the Cairo Gameplay Toolkit. I have now decided it's official title with the release of Beta 0.4, the Unity Development Toolkit.

The UDT is a powerful toolkit for game development. It takes a design approach where it uses modularization where each module is usable independent of each other, and can be used in many different ways using code, visual scripting, or by using other scripting solutions as well.

The UDT provides every single thing, code side, the developer needs to create a game. It could be called a codeless solution to game development because of this, but it doesn't have to be, and it doesn't encourage it. While you can make all the mechanics of a game without touching code, the Toolkit also is being developed with it's own Visual Scripting solution that uses Event Sheets (a Spreadsheet style scripting format).

It doesn't stop there, though. It is also set up in such a way to make it's features easy to extend with C# as well, so that you can create your own extensions to the Toolkit (Event Sheets included), allowing those with programming experience more of a power up than a hand hold.
The toolkit is made this way, passionately, because I personally don't like the Engines, Toolkits, etc. that take too much control when they try to simplify the process of creation. The only control that should ever be given away in exchange, is the control to make that exact thing that you're installing. But, many paid toolkits are very overbearing with their control, which can make extending the game with your own code troublesome at times.

Visual Scripting and feature extension with C# is not all, though! There is also a feature of the Toolkit called Asset Scripting, which allows Methods and Variables to be created as assets, and can be used as normal through C#, Event Sheets, and the powerhouses of the Toolkit, Drivers, call Events and set Variable values automatically if set up in their Script Containers. This allows for even more customization, and acts as the bare minimum amount of "scripting" that can be done to get entire gameplay systems working with the Tookit.
Asset Scripting is built to map features of the Toolkit together without complex logic.

Last, but probably most importantly, the feature that makes the Toolkit so useful for game dev, is Drivers.
Driver Cores contain State Machines that contain Drivers. and Drivers perform some specific gameplay function, using a Driver Template to customize it's behaviour. Within seconds you'll find yourself tweaking values to perfect the mechanics of whatever kind of game you're wanting to create! Drivers are a minimal later on top of MonoBehaviours that aid in streamlining the development of game mechanics.

In this short clip you can see Tails from Project Armada's game, running and jumping around the world. Tails was created in seconds using the Character Controller Driver provided with the Toolkit. The Camera Rig is also generated by a driver, and they're all controlled using the simple Controller System, making a totally functioning Third Person Character system, in as little as 5 minutes.

The Unity Development Toolkit is still in it's prerelease beta stages, meaning many of the features will be actively worked on and added, and despite it's current usefulness and capabilites, there is still so much to do. This is why I'm so keen on asking for donations, so that I can be given more time to work on it. It is my belief that the UDT can push game development to a new level of focus and simplicity, and I will make it happen with your help!

Until next time, guys, I'll see you next week!

Hey, guys! I'm back with more Cairo Engine news, and a new title by Cairo Creative Studios. Before getting too far into our upcoming release, I want to share the updates on the Engine.

Major changes occur in the Cairo Engine as I constantly learn better ways to do things, both through trial and error and constant input from other creators. As I continue development, I begin to realize that some of the components that I've developed for this framework are poorly designed, and I often find myself run into cases where my implementation of a certain feature is just flat out stupid. 🙃

Well, that's fine. The code compiles, the code runs, and it can always be improved.

I've learned that while the current code is decently organized, it would be nice to separate all the modules completely, so they don't depend on eachother at all. This would allow them to be used independently and keep developers using it from including any code they're not using.

One way to make this possible is to create Scriptable Objects that act as the root of each Module, which extend from a template Scriptable Object and pass Method calls between its Module and other classes in the Engine.

Also, MANY classes are going to be removed/migrated to the old Behaviour Module, These Cairo Behaviors will be added to Cairo Objects, without exception.

A Tree Data Type has been added that contains many useful features for containing data as nodes, searching for values, and saving/loading with JSON.

The old State Machine has been removed in favor of a hierarchical state machine using the new Tree data type. This allows for complex State driven functionality.

And, I'm not sure if I've commented on it yet, but Event Sheet code is approaching completion as well, and naturally they will also be built from a Tree.

Well, everyone and their uncles are doing it, so why not me?

Don't you just love those images I grab from the top of Google results when searching basic terms used in my Blog posts? No? Oh, well, too bad. It looks better this way. Maybe one day I'll have some gameplay to share here.

So I know what you must be thinking at this point.. Why are you here? No, you should be wondering what I'm doing with Machine Learning, that's why I brought you here. And yes, I did bring you here.

Okay, enough talk, let's discuss something.

Just kidding, it's great, Unity is amazing, ML Agents is amazing, and I love it. Except... I don't. My complaints are about the way that the agents are implemented. In a different language, using a different toolset, with pretrained data? As a game developer, I don't like that.

Before I continue, I will admit that I haven't worked with the package enough to know for sure that it won't work without the Command Line and Python, but that certainly seems to be the most common way that people are training agents.

But, this is not my only issue. The package is overcomplicating simple things. There is way too much code to be done to achieve relatively simple results, but that is exactly the case that the Cairo Engine is meant to tackle.

So, in order to abstract complex systems, we look at the heart of the problem that system is trying to solve.

Before I move on, you must have a solid understanding of how the Cairo Engine's framework is built.
The Engine is comprised of nothing but Modules, and these Modules are composed of "Objects", which is this case is not related to the variable type or Unity's Objects... and honestly, I may come up with a better name for them later.

But here is the layout for how Cairo Engine Modules are composed:

• Classes (Threads)
  • Simple Classes instanced within the Module, they are not MonoBehaviours or Scriptable Objects
• MonoBehaviours (Component)
  • Monobehaviours that represent the core functionality of one element of the Module, which may be extended from for further customization
• Scriptable Object (Templates)
  • Scriptable Objects for holding an Element's data... And I think we've found the name for our "Objects", huh?

Module Elements. I like that. Anyways, Modules don't always use each type of Element.
In most instances, though, every Module uses a pair of Template and Scriptable, where when the Module is told to create a Template object, it is created from the Scriptable.

And perhaps I should come up with a better name for Scriptables as well... Actually, maybe Scriptables should be called Templates, Templates should be called Components, and classes should be called Threads. This way we can make some sense of this crap!!

Oh well, let's move on.

So, I'm just going to create a simple outline of how complexity issues in the Cairo Engine are solved, using Machine Learning as an example:

• Ask: What do we want to do?
  • Create Neural Networks (optionally as Game Objects) with some Machine Learning algorithms
  • Set properties for the network, such as inputs and outputs and lifespan for the Genetic Algorithm
  • Train the network with input and desired output data, presumably automatically, as the agent exists in the world.
• Ask: How can we simplify it?
  
  • Make the MLModule do all the heavy work.
  • In the above example, only 2 methods will be created to accomplish the task: "Create", and "Train"
  • Use a Template for all of the Agent's Properties, including Inputs, Outputs, and Sensers that should be added to the Object Instantiated from the Prefab value of the Template.
  • Create Senser Templates, and use any of the predefined Senser objects. These will function as Inputs.
  • Make the Prefab an AI Controller by creating an AIController Template with it set to it's Prefab as well.
  • Type in the Runtime code, "MLModule.Create(*MyMLAgentName*)"
  • Type "Train(*PlayerControllerName*)"

The bit about the Controllers are VERY important. Controllers in the Cairo Engine works similarly to any system (notably Unreal) that uses a Controller to interface with Pawns/Entities to move them around in the game. The Controller is a consistent object in the game that represents the Player's (or AI's) presence in the game, so they can be told what Entities or Pawns they can give commands to.

Thus, the Cairo Engine is designed to pass Controllers for Input and Output data that also keeps track of Player and AI controller inputs (simulated for AI's, of course). Because of this system, when training an ML Agent with a Player Controller, the Player Controller's Possessed Pawn will also get all t he same Sensers as the AI Controller's Pawn. Thus, the AI Controller will learn from the way the Player is playing the game.

This means, in just two lines of code, you can Create and Train various kinds of game AI. Then, of course, the Neural Networks are Serializable. They can be saved, and then reloaded and imported into the Template.

I know, there's a lot of talk without much to show for it, but trust me, it's coming. The system is nearly complete. I've been doing more coding and less naming as you can tell, but I've got Agents in the game, moving around just barely. At the moment, I need to make better Sensers and complete the Controller set up previously described, but it won't take long at all.

And you know, I just got a neat idea... You can use the Inputs and Outputs of ANY Controller to train the ML Agents. That means, I could hypothetically code AI Bots as well, and then train the agents with said bots. I'm not sure how well that would work out, but I suppose it's worth a shot. Maybe mixing the two will somehow produce smarter results?
Now you know, I have to do it!

Catch ya next time,

Richy

ps I renamed Threads to Bolts, I feel like the word Thread is used too commonly in the code world for conceptually different things.

Hey, howdy, hey, y'all!! Haha... So, I'm going to be talking here on a relatively large topics. Today I'm going to be talking about Frameworks. And I don't mean things as basic as Angular or React, or Game Engines like Godot or Unity, I mean the WHOLE build of whatever you're creating. Every tool, every extended or reused class, everything.

Today I'm going to be sharing a controversial (or maybe not so much) opinion. Which is that MOST frameworks are... Pretty bad. I'm also going to share another controversial opinion, and that is about programming paradigms. Functional programming is better.

So.. now that I've annoyed you with my opinions, are you interested to hear what I have to say about them? No? Well, too bad, you're in my domain. I'm telling you anyway!

For real, neither is better. That's all I can say! Actually though, there's a point to this. I think that many people tend to VASTLY over complicate their development Pipeline, Tech Stack, whatever the hell you want to call it. It doesn't have to be so hard!

Listen, Angular is a beast. But, can we really say that React isn't? And on that note, when compared go Vanilla JS, can we really go for one or the other? Or are there times we have to use both? And why?

I think it all comes down to what we are asking from our Frameworks. What is it that we want. Some Frameworks to some things better than others. And that's exactly the problem! We keep focusing on very specific aspects of development in the Framework, rather than asking how we can simplify the implementation of larger scale functionality into the Framework.

This is where I'm going to be sharing even more controversial opinions...

Yeah, that's right. A noob game engine. That's what I'm going to advise to you, and the whole.damn.world.

I'm not using Construct, I'm using Unity. I'm not using anything that simplifies development, I'm building my own framework with C# in Unity. So, don't get the wrong idea! But...

Construct is brilliant!!!

You see, Event Sheets in Construct are very similar in design to the Javscript programming language. At least in functionality. They basically follow the same rules. At first glance, it seems like just another simple "No Coding Needed" game engine. And... Well, it is. But I personally believe they achieved something that no one has ever achieved so well before... And that is a Framework that enables incredibly easy access to all objects in the project, and easy extensibility of the object's functionality.

The Event Sheets are not, in reality, a solution to avoid code, or having to learn how code works. In reality, they work quite similarly to actual code. Each Event has a Condition and Action, and is basically just a very clean way to display the code. At least, on it's own. But, it's a little more than that.

Event Sheets are coupled with Object Types, Families, and Behaviours.

Objects contain quite a bit of base code that determines important functionality of that object. A sprite, for example, contains an image and a Collision Shape. You can then couple this Sprite with a Behaviour, like Platform for platformer style movement, or solid to make it act as a floor, or even Anchor which will pin it to it's original place on the screen (usually good for HUD and UI Images), and much more.

You can then easily extend the functionality of the Engine by creating new Objects and Behaviours with Javascript code.

I ADORE this workflow. It doesn't attempt to step away from programming, it simply couples code into a cleaner context. And, luckily for me, this paradigm does not at all depend on Event Sheets.

Well, it does a little bit. The process of picking Objects and all that is a bit more challenging with raw code, but if done well can still be rather simple.

Well, how about we get to an example, then?

The example above is the code for the Deathmatch Game Mode in Spektor so far. At least, it's all the code unique to Spektor. I say this because the Cairo Engine framework takes a similar approach of abstracting all of the objects in the game into bigger, and simpler to use, systems. Now, of course, this example is all that we have for now, as I'm not going to be sharing the Behaviours that can be applied to Objects just yet, but I will be going into more depth about how this all works now. (In the future, Managers will be renamed to Modules)

The Level Manager handles level Creation, Loading, Saving, etc. You create Scenes, include them in your build settings, Create a Level Scriptable Object for it, and apply settings to it that communicates with the Engine. Thus, Load Level does exactly what we need. Loads the Level.

The Game Mode Manager handles conditions for winning and losing, as well as scoring, and some cinematics, and some other things. In Spektor, every mode will be controlled using Game Modes, because Win/Loss conditions and scoring can be anything, and don't have to be hard coded. I'll talk more on that subject later. But, as of now, we create a Game Mode Scriptable Object called Deathmatch, define the kinds of Player Controllers, Pawns, etc that are used, the Team compositions, and other settings, and then Start the Game!

The UI Manager creates UI Displays, prefabs that have an overlay Camera at the root, for displaying UI/HUD. UI Values can be Linked to children of the UI Display by name, and the value can be set through code. This will be done in the Update() method later.

Now, most of you who have experience with Unity would look at my GameMode_DeathMatch Class and assume that it extends from Monobehaviour (what, with the Update Method and all), but in reality the State class is an entirely different beast. Now, don't get discouraged, there is a point to everything I'm explaining right now, I'll get to the in the next section.

This actually my second attempt at writing a Class based State Machine in C#, but this one, in my opinion, takes the cake. It's far simpler, by design.

The previous required A LOT of work to develop, but it did have it's advantages. For starters, you could access Methods, Fields, etc. of the Parent Class for simply using self.Method() or self.Field, but it was incredibly difficult to work with even after it was completely working. It was not very easy to enable the State Machine on an object, and I can't say for certain whether the functionality was even performant by comparison.

First of all, when creating a State Enabled Object using my previous toolset, you would have to extend from the StateEnabledMonobehaviour class, which itself used the Start and Update methods of Monobehaviour. Some of you may have experience with this, but I'll let you know if you don't already, this is NOT a good idea. First of all, whenever you want to create a new class that extends it, you now have to be sure to properly override the class. And, on top of that, each instance of a StateEnabledMonobehaviour has it's own instance of a State Machine, which itself used Reflection, and a lot of code that is probably pretty heavy on the processor.

The new system takes a different approach. Instead of making it part of the Object itself, there is now a StateMachineManager which acts as a the driver for State based functionality. It then calls a few Methods, by default, on all States that are currently active and contain them (Enter, Update, and Exit), and calling more Methods simply requires StateMachineManager.CallMethod(ObjectName,Method).

The nicest thing about the implementation is that it works on everything and requires only one line of code.
StateMachineManager.Enable(Object)

Yupp, that little line of code above automatically enables State Machines on any object you pass to it. The State Machine Manager intelligently finds and calls appropriate methods based on the Current State of the Object. Easy breasy!

Now, we're going to talk about Behaviours, just briefly, but with enough understanding of how these Managers are able to interact with Gameplay with very little input from the user. Now, we're going to be talking about the Behaviour Manager.

Adding a Behaviour to an Object is as simple as calling BehaviourManager.Add(Object, BehaviourType). This is not a MonoBehaviour that you're adding, btw. This is a very simple Behaviour that fulfills a very specific purpose, and it can be controlled by other Managers in the Engine as well. These Behaviours are modeled after those of Construct.

Say, for example, you want to move a Character around in the game. You would add the Character Controller Behaviour. This Behaviour will request information from the ControllerManager about inputs that their respective controller is attempting to communicate to it. It will then move based on this information, and you can set properties the determine how the Character Controller Behaviour moves the object through the BehaviourType Scriptable Object settings (which is what is passed when the Behaviour is added).

These Behaviours, again, work on everything right out of the gate. Although, most of them will be easier to use in conjunction with the Entity Manager in the Engine, but we will dig deeper into that later.

This the game in and out of Play Mode at the moment. There is, of course, not much to see just yet. But, the demonstration I'm giving here is meant to focus on the Game Hierarchy more than anything. This is an example of the Engine intelligently creating a root Level Object for the open Scene, and using the code from the Runtime Game Mode described above to render the Player's weapon into the UI (as it didn't previously exist before entering Play Mode).

You may be wondering why the requested Level in Runtime didn't load, and that is because it doesn't actually exist yet. A Warning is displayed in the Log stating this when it happens. But, everything else worked. The only things that need done now are to complete the Game Mode Manager functionality, make a level, code some bots, and make the game look and play fun.

Today we delved into Frameworks and Game Engines, how they're built and how I think they're lacking. I expressed my concerns about Frameworks being vastly over complicated and often distracted, and also my interest in creating a Framework much like that of Construct's very organized Event Sheet approach, and how I'm developing my own.

And I will say, to hopefully qualm some concerns that people may have with possible bias, I have and do also use other engines and frameworks other than the ones mentioned. As far as Game Engines, I've used Unreal, Godot, Game Maker, and many more. I'm no stranger to the different Engines. But, in the end, I would always find my way back to this programming paradigm. And hell, maybe it's just better for me and nobody else... Or maybe I'm right that it's simple the most efficient. Only time can tell.

Until further ado, my lovelies!

A young boy finds himself amidst a battle between hell and Earth, inheriting powers beyond his control. Through his search in finding himself, he must, too, find a way to control the evil urges carries with his incredible power.

Hey guys, Richy here! It's been years since I've made a post to IndieDB, so this post acts as both an announcement that I will be posting here more regularly and as an update to the world about what I'm working on. Well, what my team is working on anyway.

Our small team of three, Cairo Creative Studios, have just recently came together to make video games. We haven't gotten far just yet, but the future looks full of promise. There's a lot to say about our journeys. Anyone can easily see that I'd previously attempted to make a Multiplayer Platformer MegaMan-like that didn't amount to anything. Yeah, there's a lot to say about that. There's a lot to say about a lot of things. And you deserve to know, so I will share... In time.

For starters, I want to introduce myself from a more personal perspective. A point of view which is honestly somewhat embarrassing to share.

As a father of 4, I find myself struggling to stay out of poverty, despite my apparent passion for Game Development, and coding and general. My skills are robust, and I am quite capable... At least, I would like to think so. But, much to my dismay, things have very well not worked in my favor in the past. So much so that I've had to put aside my own health to ensure that I could carry the weight of my decisions and still reach my goals.

It's been... Rough, to say the least. I would understand if you though that maybe I should have waited to become a father, as that's something I've been told and honestly pondered myself. But, there's not a day that goes by that I regret my decisions. My family means the world to me, and it's quite possible I wouldn't have gotten out of the depressive slump I'd been in without them. Children aren't meant to fix my issues, I know... But, if it weren't for them, I fear that I may not have otherwise noticed I even had them. Just as I was before, unknowing.

So, from Byte Sized Heroes to many other failed project, to today. Here I am again, trying to take make something of this passion for development of mine. With a game that is quite dear to my heart. Let me explain...

My childhood was fairly strange. Me, and my three sisters, would look after eachother and care for one another. My parents were hardly present, and it was usually better that way. When they were home, they were usually fighting. There were many times one of my parents held a gun toward the other, or toward themselves. These nights weren't much unlike a UFC match. The difference was that my parents truly hated eachother, and cared little for us, or our wellbeing.

My grandparents did provide financially for us at most times. While that wasn't always the case, we never went without. And, at times, they were physically present too, although it was relatively uncommon.

All of this, as you can imagine, affected my quite intensely and played a part in shaping the man that speaks to you today. A man who has battled addiction. A man who has battled anger management and thoughts of suicide and abuse. A autistic child who's only comfort, and only escape from the madness, was video games and computers.

Well, I've had to overcome all the trauma that's been done to me to simultaneously ensure my children won't have to deal with it themselves. And I found myself in a position of creativity that inspired me to want to make games based off of my personal experiences that spoke more to the feeling of what was happening that most healthy people would be capable of properly expressing. And thus, my outlet for my emotions have also become my canvas for expression.

Gun face was a game that came to me on a whim, and my heart exploded with passion for it's development. It didn't amount to much, but despite it's lack of progress in development, there were many people that saw what I wanted to do with it and quite liked the idea.

Shortly after creating the game, I went on to watch Edward Scissorhands and realized that that movie that everyone adored was much like my concept for Gunface. That being the feeling of loneliness that comes from being a freak, but also somehow being adored in some strange way because you're different, but never fully understood, and thus still incredibly lonely.

The difference was in the fact that in Gun Face, a young boy becomes a freak as he was infected by a creature that turns flesh into weapons. But, Gun Face can control his weapon, and finds his way back out of the cave he was in when he became infected. But, the village that he'd previously called home was not very accepting of this monstrous humanoid crawling out of the depths of a cave, whose faces was bleeding around the seams of a giant cannon.

Nonetheless, Gun Face would go on to prove himself, but never be able to return to the life he once lived, and would have to say goodbye to the relationships with those he'd once been close to.

Now we're on to Spektor. Not a Jam game, just a whole game that will be developed in Unity. It's development started in Construct 3, but I found it's 3D tools limiting even despite being able to make a full 3D editor. It simply wasn't efficient. Unity gives me the power to make the game of my dreams. And soon, you will be able to see what my mind has been conjuring up for the last few weeks.

The code for the engine is almost complete, but there are no visuals yet. I've been developing a framework to easily create a multiplayer shooter, and the code base takes a lot of inspiration from the simplicity of Construct, as well as having the power of Unreal. The goal is to take this framework, titled the Cairo Engine, and create a simple Event Sheet interface akin to Construct, but have many Object Types for further simplification of game development, like Game Modes, Levels, Inventory, etc. Nothing too fancy, of course.

As I said, the framework is almost complete. I'm not sure how to make an editor as complex as what I'd need for Event Sheets, but C# works just as well. There's only one thing that I'm really itching to add, and that's artificial intelligence that created code to work with it. I'll be going back to that one soon, but for now I need to work on this game primarily. No Event Sheet Editor, no AI powered game generator, but Spektor.

Stay tuned, I'll be right back. ;)

I've spent quite a long time away from the site, although updating my artwork gallery periodically on Open Game Art. For quite some time I've spoken of some games I've worked on, and for a while I've also been nearly silent about everything. The reason being, I'm making a big ass game. This game is Byte Sized Heroes.

What is Byte Sized Heroes, you might have asked? Well I'm glad you might have asked, because for such a question, I have quite an awesome answer.

Byte Sized Heroes is an action/platformer/shooter that takes inspiration from Mega Man, Halo, and a couple other well known titles, including Time Splitters, Thing Thing Arena, and Super Smassh Bros.

In the beta, you play as BYTE, a young soldier who's soul has been injected into a chip that combines with different armored suits. These suits, known as casts, give him abilities that manipulate his movement and combat skills. The use of these armors are quite similar to the Models in Mega Man ZX, with exception to the mass array of interchangable weapons, skills to use with said weapons, and multiple armor gadgets that allow you to change the flow of battle at will.

Byte Sized Heroes' story will be visited later in development, after the Patreon is going, that is to say if we're successful, though, of course. I'm hoping to get some very nice voice actors in on the project, along with some nice animation and anime artwork. I've already started the writing of the story though, and so will explain in a moment how the story will progress, and how the player will be able to interact with the single player world. For now, I'll explain, in detail, the multiplayer, and future plans for the multiplayer development.

Multiplayer will mostly be map based, and by that I mean that the game modes will require you to interact with the maps in certain ways. The first map and game mode, playable in the beta are Foundation and CAT.

Foundation is a symmetrical map that has a large underground base in the center, as well as a large ground area above it. A large gate splits the two apart vertically, and two rooms are horizontally aligned, symmetrically, on each side of the ground area on top. Above those two areas are two rooms of the same size and horizontal positioning, as well as under. The two on the bottom are connected to the base at the bottom middle. The two areas on the sides carry temporary invincible shields, as neither area will include capture fields which will multiply the teams score. This will pull the player's interest away from the two areas on top, while still allowing them time to collect them if they go out of their way to do so.

I'm trying my best to make an experience that seems like something you'd expect from Mega Man and Halo being combined to make a 2D Action Platformer, so let's hope I'm making a right direction in the development. I'd really like to know what everything happens whenever the game is actually uploaded.

The upload of the game is planned for a later date, because multiplayer gameplay is still in development. Once it's all complete, the game will be shared here on IndieDB, as well as my website. Until that release is announced, I'll be sharing all information about the game development here on my blog.