Action Component System

[dayrinni]

Hello!

I wanted to write a short post on the Action Component System (ACS). This system is very complex yet astoundingly powerful.

Before I begin, we must travel back in time. Back in 2003, we were on the FastRom2.4 code base. This had something called Mob Programs. You could write some basic codes and the game would parse it and then do stuff. This is how we make the game interactive, like npc echoes, the event in the stream bank with the hydrae and so on.

Mobprogs could only be placed on mobs. Over the years, custom code was added to make them more powerful. However, they were super buggy on ROM. Like, really buggy. It also made us do some really ghetto things, such as having invisible mobs that would run programs in the background. There were no programs for rooms, items, abilities and the like. When we moved to the custom code base we have today, the Titan Engine, I implemented my own version of mob programs (I also fixed a ton of issues, including many game crashes) because that is what we had. Long term, we knew we didn't want to go this route. But the alternative, was a very difficult and complex system to implement.

When I visited Actinate this month, he crawled all over my face asking for the ACS. So I gave it to him! This is a very big project, with many complex codes and design aspects. However, the pay off will be great.

The ACS will be able to go on NPCs, rooms, items, literally anything. It will offer up a whole host of new functionality for the game and the builders. The idea, is to offer the tools and the functionality to piece together, to make something larger. This means, I, will have to spend less time coding, and instead, focus on more fun stuff (events, classes, races, abilities, and so on).

To demonstrate the power of the ACS, I will present two examples. One will be simple and another will be more complex.

Simple Example: Room Echo
You make an ACS Manager that attaches itself to a room. The ACSM will trigger whenever a player (not NPC) enters the room. When the trigger occurs, a message will be displayed to the player, “You have entered the dark cave!”.

Currently, in the mobprogs, we would need to make a NPC that was invisible, then a mob program (containing actual mob program code) and attach it to the NPC.

I hope you can see the difference. The ACSM goes on the ROOM rather than the NPC! We also don't need to write mob program code – which is prone to errors.

Complex Example: Keypad to open a door
You make an ACS Manager that contains the key combination, and then states (in a chain) for each button press. Each state will have a failure action that displays a message if something wrong was done (ie: press 12, when the button only has keys 0-9). The final action is verification, where all of the inputs are checked and if successful: the door opens, otherwise, a killer mud stalker spawns to defend the door!

Currently, there is no way to do this with mob programs. It may be possible using the ACTIVATE command coupled with mob programs, but it would be very tedious, difficult and error prone. The better situation would be me coding up something very specific.

So, again, I hope you can see the difference.



In both cases, the builder can do the entire process, and not involve me. They will get more freedom, more power, and be able to make things that are easier to put into realization. I won't say the system is easy to learn – it is complex – as needed for something like this. But, once you understand the system, you realize its potential and then are able to do truly amazing and wondrous things. You'll be able to do them faster and have them be less error prone.

Long term, we will be using the ACS for everything. This will allow us to truly make a very interactive world!

Where do we stand today with the ACS? It is 25% completed. I intend to hopefully finish it by the end of January. (I'll be making a State of the Game post soon).

Thanks for taking a few moments to read this post. If you have questions, feel free to ask. I know this is a complex subject and a lot of abstraction was used in this post.

[dayrinni]

Hello!

Here is a little update on the ACS. We are in pretty good shape. Progress hasn't moved significantly, but it has moved. The reason for this are the limitations of Java and the way it handles types. To make a long story short, I had to implement some rather complicated pieces of code in order to get around these, so I can make the system behave as I want:
-Flexible: able to take any type of defined data (ie: player, room or item).
-Robust: able to prevent as many errors as possible during processing. It will also point to the user where errors are must apt to happen so we can prepare for failures and recover during processing.
-Usability: able to be easily used by me, so I can implement functionality everywhere (ie: pressing a button, entering a room, etc).
-Maintainable: able to maintain it easily. So as we evolve as a game, new features can easily be added without much effort and rework.
-Quality: finally, because this is a really complex system, where anyone (including myself), is unable to truly grasp its power, I had to write some test cases for this. These will be executed prior to every roll out of a new version of the game.

So, those are some really good characteristics to have. Unfortunately, they take a long time and a lot of effort to implement.

NOW! Having said all of that, good progress has been made! For example, I have been able to make an ACS Manager that when activated by a player spawns a mud stalker and displays a message after 5 seconds! I also made a keypad, where you can input some codes and if you're successful, a message appears and if you're incorrect, another message appears. This one can be extended easily to load items/npcs and so on.

This is all great! I hope to be wrapping up the fundamental system soon and then start working on the editor portion - so Actinate can start using it. I will also be working on the saving/loading portion.

The saving and loading - a quick note here. Remember all that effort we put in writing a new way to save and load areas? Well! This system was designed with the ACS specifically in mind! And the way I designed that system, is I can reuse the same code where an ACS Manager will be saved (ie: the code will be the same on the Players, Items and Rooms). Reuse at its best folks.

Anyways, I hope you enjoyed reading this. It really is a bunch of ramblings, but I wanted to give some insight here besides "Progress Occurred".

Thanks!

[dayrinni]

The ACS has become self aware and tried to take out the game with an army of mud stalkers. They were growing at an exponential rate and my character became unresponsive. Then, ZMud froze and I could not do anything. I was forced to terminate the program outside of the game!

I just hope I can contain this... if you see an army of Robots attacking, or robots time traveling, you know I have failed!

[dayrinni]

Hello!

The ACS implementation is going very well. I have added a lot of the checks into the game. However, I do have some concerns about performance here, so I need to do some testing, which I'll be doing this week. This involves testing the performance on my local machine and then possibility testing it on the server (the server gets better performance, so if it looks good on my machine this generally bodes well!).

To outline what I'd like to see:
For instances where there are no ACS present, the performance is very close to what we have today.
For instances where there are ACS present, they run in at a reasonable speed, typically under 2 MS in processing on average.

Ideally, we aim for 10 MS per player to enter a command. We are usually close to 0.50 MS to 5 MS depending on the action a player is doing.

This means, we can have 100 players inputting commands and we'd have subsecond response time. This is good!

Anyways, I've done a lot of caching for things, and really, I expect performance to be good for the most part except items. Items take a lot of processing and I've done some clever caching for these.

That about wraps things up here. If performance looks good, I'll be moving into the editor portion, and then saving/loading. Afterwards, we'll give this to Actinate to break!

I am aiming for a release sometime late January or February.

Thanks!

[dayrinni]

Greetings,

Here is a short update:

I have done some performance testing and the cases where there are no ACS managers present, we get some good performance.

Since the last update, I have put in all of the basic actions, including editors, saving and loading. I had to make some changes to the saving/loading to add in a few new features, and I managed to accomplish that.

Next, I am going to move on to the statements. These are similar to actions, but should hopefully go faster.

On a related note. I have been experimenting with more abstraction in the game's code. TO make a long story short, abstraction can make things a lot easier to implement and add to. However, it does come with its downsides. One being, it can be restrictive depending on the framework you design/have. Also, it can make things super complex and hard to understand what is going on. It can also introduce some really odd bugs. Anyways. I used a lot of abstraction for a lot of stuff for the ACS system to test it out. If things go well, I may expand it to other portions of the game. This will not be seen by anyone, but it will make my life a lot easier, in theory. This change would simply occur over time, inbetween different projects.

I am still aiming for somewhere around an early Feb release of the first part of the ACS (Actinate will find a lot of bugs [the system is very complex and powerful]), and the initial feature set).

Thanks.

[dayrinni]

I'll be releasing this on Saturday. Hopefully it'll do what we think it'll do!