Data-driven game objects for use in simulated ecosystems

Voxel engine

The IsoEngine uses a custom voxel system for terrain and structures. Instead of cubes, terrain is composed of primitive low-poly shapes.

Different materials are supported in the engine (sand, dirt, stone brick etc.), and each material can have a unique set of models and textures.

Voxel terrain can be sculpted using “brushes” of different types. Voxels placed in this manor automatically chose the most appropriate surface primitives to “smooth out” overall appearance.

Prop placement

3D models can be placed using the prop system. This could be anything from plants, decorations, humanoids, or structures. To unify the voxel and prop system, each prop must be grid aligned and have a defined voxel volume. This allows systems such as navigation to treat props and voxels as one and the same.

Pathfinding

A working pathfinding system for organisms isn’t core to project goals but is useful for both AGCP and is a technical hurdle that if not crossed is a barrier to later ecosystem work. Implementing and testing pathfinding work early on ensures other work does not go to waste, and that the direction of the project can pivot if necessary.

AI agents must be able to navigate across all traversable terrain. This includes static props of various shapes and sizes. Existing voxels can be altered in real time, so dynamic navigation meshes must be considered by agents, and updates triggered upon alteration.

Agents can have various heights, but for simplicity will not have a front profile wider than 1 voxel unit (1 meter). This should fulfil requirements for most creature types while maintaining code simplicity. Future updates could improve this.

Merge old game object systems

The IsoEngine currently has three controllers for handling different types of 3D asset. Stationary 3D models placeable in a voxel world are handled by the current version of the prop controller. A separate controller handles objects with physics capabilities. Lastly, an AI controller can observe and effect changes on physics objects.

Each of these controllers achieve the same result, which is the manipulation of 3D objects in the voxel environment. This has led to a lot of code duplication and tightly coupled classes that are hard to make alterations to. To solve these issues all three will be combined into a single controller, that on a function-by-function basis can make special considerations for the physics state of an object, if necessary, as well as driving prop behaviours specified in the prop design interface. This new controller will be called the (new) prop system.

Ecosystem considerations

Long term, a major feature of the IsoEngine will be a simulated ecosystem of AI. Therefore, any systems, tools or processes need to be tailored towards this goal. The implementation of the ecosystem itself is not the aim of this development effort, but a basic design and exploration of potential features needs to be explored so that prop data storage and prop design interfaces can be designed and implemented accordingly.

Designer features

The interface for adding a new prop to the editor needs to replace an existing pipeline. At present, prop data is configured through UE4s blueprint system, which is a misuse of the toolset. During previous development cycles, many props were configured through blueprints, which has led to monolithic node connections, and a hard to maintain layout as seen below.

The new interface needs to be approachable by someone without programming knowledge or experience with the broader IsoEngine technology stack. It also needs to offer the right balance of the fewest fields to achieve maximum behavioural expression with said values.

Visual design goals

Throughout development, many assets have been bought for the IsoEngine featuring a low-poly aesthetic. Any opportunity to test the new prop design interface will make use of these assets.

Additional assets were purchased specifically in preparation to add animal ecosystems to the game. A few of these assets will also be implemented if the opportunity arises.

Sustainability/modularity

To sustain the project long-term and to support future additions, code and data storage methods will be modular where appropriate. Data-driven design is employed to support this.

Data-driven design

Many modern games, such as For Honor (Data-Driven Dynamic Gameplay Effects on For Honor, 2019) implement a data first approach when it comes to developing systems and gameplay mechanics. What is meant by this, is that behaviours are decoupled from values relating to specific entities and can be fed into behavioural systems without the need for a recompile of source-code, as described in a GDC talk by Gas Powered Games (Bilas, 2002). This technique will be strived towards during the development of prop data storage and configuration tools.

Platform

A comparison of potential IsoEngine development tools was carried out at the start of the development process, and general tools are finalized. IsoEngine is built within Unreal Engine 4, which was chosen over Unity due to its support for C++. Voxel engines and game optimisations enabling high entity counts at higher framerates are common academic pursuits for the C++ language (Wilder, 2015), broadening my pool of reference.

The target export platform for this project is Windows x64 for PC, due to it being my primary OS and therefore most convenient for testing and deployment purposes. Other target exports may be considered for final releases of the IsoEngine as a product.

Prop data storage

Choosing an appropriate replacement tool for prop configuration is key to an efficient prop design pipeline. Real-time prop data access must be efficient and the new system iteratively upgradable. Something that is easy to integrate with existing systems is a massive bonus.

Techniques for data storage and manipulation have been selected for comparison based on their commonality in the development of data-driven systems, game systems or UE4 content management processes.

With tight integrations and support for UE4 and C++, data-tables appear to be the obvious choice for the prop system’s development. XML lacks the approachability required by content designers, and databases can lack flexibility in the storage of dynamically sized fields, both of which are key to feasibility.

Project management

A development pipeline has already been established for IsoEngine. Version control is managed by Git and BitBucket is used to host the online repository. SourceTree is used to manage local repositories. To keep general track of feature implementation, Jira and its Kanban template are used. Use of these tools can be relaxed now IsoEngine is worked on by a single developer.

BitBucket over the course of development has been the cause of a few issues that have required a complete reset of repositories. It’s also incapable of tracking feature level changes on binary files, which is a major drawback considering most asset types in UE4 are binary files. Perforce is a prevalent contender, built with specific UE4 functionality that can handle binary files.

Weighing benefits of implementing Perforce based on online discussion (Arthur, 2021) against the time requirement of setup and learning Perforce it is decided that the project will continue using BitBucket. There’s currently only one developer on the project so smart binary file source tracking isn’t going to be an issue, but Perforce will be picked up at a later date once opened back up to a larger team.

Self-plagiarism

AGCP will be worked on alongside this project. To avoid self-plagiarism, some clear rules have been established to follow during development:

1. The AGCP assignment must have a separate set of development goals.

2. A* Pathfinding is specifically excluded from AGCP marking consideration.

3. Inversely, movement following generated paths is specifically excluded from this project’s marking consideration.

4. If a feature from this project is essential for AGCP or vice versa, they will be labelled as external efforts in design documents. The AGCP project has achieved this in a development graph using colour-coding.

5. Major changes will be made to AGCP AI behaviour, but these changes will be clearly documented throughout this report.

Data-table concerns

Technical limitations of UE4 data-tables have not been fully explored, and some limitations may be present. To avoid project altering discoveries the following will be done:

1. A data-table prototype will be designed in parallel to behavioural designs so that the planned architecture is feasible.

2. Behaviours will be built in C++ but rely heavily on fundamental datatypes and UE4 specific datatypes to ensure compatibility with the data-table.

Resource constraints

This project has to be worked on during final year studies and so has a strict deadline. Lab access is restricted due to lockdown and working from home has been a challenge due to personal circumstances. This will likely inflate planned timeframes significantly, but there are ways to mitigate such issues:

1. This project will be worked on alongside other assignments to lay out initial systems and prototype early concepts, saving time.

2. AGCP prototyping will help flesh out basic physics interactions and help explore basic asset loading techniques, which can be reused and altered for this projects behavioural testing.

3. Behaviours developed for the play mode will be an optional bonus used for testing purposes, limiting the scope of the initial implementation to something more feasible; an interface for designers to use that offers parameters for ecosystem and physics behaviours.

Monetary investments

There is no formal financial backing or investment for Arkode or IsoEngine requiring the following:

1. The specific goals of this project exclude polish and artistic direction. This limits scope to behavioural functionality, with art being an optional bonus.

2. Free or open-source development tools have been specifically selected to curb expenses. Epic games and Atlassian tools have free tiers at the time of development.

Organism growth

Almost all organism types in the real world undergo growth. Stages of aging (Otin et al., 2013) can be generally simplified into some common patterns (although many organisms do not fit this simplification):

1. Infancy/childhood – Once born organisms are focused on growth and mental development for a significant period. This can be simplified to limited exploration and following a parent.

2. Adulthood/reproductive age – Adults of a species typically focus on having children or raising them. This is true for both animals and plants.

3. Old age/death – Once past reproductive age animals tend to simply survive, continue to raise young or reach the end of their lifecycle.

As definable stages are common in organisms, but each stage is typically denoted by capabilities and characteristics, we can use a completely different prop for each growth stage. A designer could select one or more props that an individual could “grow” into, as well as a time taken to grow. These props could be chained together to form a complete lifecycle.

To reduce duplication, behavioural groups should be split up, including growth patterns, so they can be selected by several props and reused. More on this later.

Reproduction

Creatures in any ecosystem are at risk of death, so individuals need to be able to reproduce to perpetuate their species. Mechanisms for this also need to be simple. Organisms are not all the same in their reproduction patterns, even among plants (Bengtsson & Ceplitis, 2000), but as with growth stages, different categories can be identified:

1. Asexual reproduction – plants tend to follow a model of spawning offspring near their location once at maturity through seed dispersion.

2. Sexual reproduction – an animal of reproductive age tends to locate another animal of the same species but of the opposite sex.

Fields will be required to within the interface to define sexual preference and animal sex (male/female). A target range for a litter of offspring should also be defined. Reproduction is typically a resource intense process, so reproduction could force the parent to expend resources on their children. The reproductive cost for an organism could be equal to the internal spawn values of the organisms they are creating. This also necessitates internal resources.

Resources

To replicate real-world conditions for reproductive cost, and to drive organisms to interact with the environment around them, props must have an internal resources system or inventory. Ecosystems naturally evolve food-chains and resources persist, albeit in a constant state of transformation (Perry, 2021), which for IsoEngine means needing to categorise props by what materials they are composed of and what materials in the world they need to consume to survive. Living animals could drop consumable resources on death, whereas plants could be consumable as is.

Certain “soft” needs or “drives” will also be evaluated for integration with the prop interface, as social behaviours or bigger picture behaviours like stockpiling could be considered during implementation of complex ecosystem behaviours. Each prop may have a unique list of dietary requirements and needs.

Survival planning

With animals having to plan and carry out potentially complex actions to survive, GOAP (goal-oriented action planning) seems like a potential AI design paradigm according to the book AI for Games (Millington, 2021), which would allow organisms to chain together actions to achieve a given goal. For a designer to be able to implement a complex chain of actions however, data-tables would have to support function pointers, which unfortunately after much research, they do not.

Instead, state-machines will be used to manage simple, compartmentalized behaviours that a designer only has limited configuration access to.

Essential data-table features:

The following are going to be columns or tables configurable on a prop-by-prop basis.

1. Categories of prop for use by the editor.

2. A list of selectable movement types [static, dynamic, walk].

3. A list of selectable reproduction preferences [none, asexual, sexual].

4. A dietary list of other props.

5. A configurable inventory to be dropped on death or consumed by others.

6. Something a prop can grow into, and timer denoting how long growth takes.

7. A size, weight or strength value.

8. A list of potential offspring and min and max quantities for a litter.

Essential behaviours

1. Configured props being placeable in editor.

Optional behaviours (can be cherry picked and implemented for testing purposes)

1. Props swapping into the next growth stage after a timer has elapsed.

2. Props dying when no next available growth stage, but timer defined.

3. An internal resource list that decays over time.

4. The ability to move toward and consume dietary resources.

5. A prop dying when inventory resources are depleted.

6. The ability to for animals to kill smaller props for food.

7. The ability to for animals to avoid bigger animals trying to eat them.

8. Animals being born and consuming resources from their parent in the process.

9. Animals of sexual maturity will search for a male if they can afford the reproductive cost.

Pathfinding

Pathfinding is being considered separate from other objectives as it will be essential for the completion of AGCP. It’s implementation and use in this project however is optional, but setup for its eventual use will need to be considered as the architecture of the three object systems is consolidated.

1. A node generation step at world spawn.

2. Node updates on voxel and prop spawns/deletions.

3. A* pathfinding for multiple agents.

Node network population

Nodes on the navigation mesh need to be voxel aligned, and so are initialized through a 3-dimentional vector that can be resized as the world size changes. Each node contains a list of pointers to other nodes that it is connected to, i.e. it’s adjacent nodes that are traversable. These nodes are populated with links when the world is generated.

Dynamic node manipulation

Whenever a change is made to a prop or voxel, the position of the change is sent to the navigation mesh, so that the area effected can be rebuilt (if necessary).

A* search

A tutorial for A* pathfinding is available on YouTube (javidx9, 2017) and has been used as the basis for IsoEngine’s own A* implementation. In essence, as explained more thoroughly in the comparison of methods for pathfinding, the algorithm searches through nodes adjacent to the source object, slowly expanding it’s search space in the direction of its target. Once the target is found, the algorithm can backtrack though connected nodes until the calling agent is reached, and this path is retuned to the agent for navigation purposes.

Structure

C++ structs that inherit from “FTableRowBase” can be used to define layouts for data tables. “USTRUCT” macros expose C++ structures to UE4 and UAssets.

USTRUCT(BlueprintType)
struct FExampleStruct : public FTableRowBase {
    GENERATED_USTRUCT_BODY()
public:
    //Insert data here:
};

Data field

A piece of data for the end user to fill in can be implemented by simply adding a variable to the struct specified and providing it with the “UPROPERTY” macro on the line above. It’s through omitting this mechanism that some data can actually be made hidden from the UI if it’s for internal purposes only.

One to one relationships

To achieve a one-to-one relationship between data groups, an enumeration or plain struct can be used, removing the necessitation for another data table to be created. This option is only available for data with limited variability.

//Example of creating a one to one option
UENUM(BlueprintType)
enum MatingStrategy
{
    None        UMETA(DisplayName = "None"),
    Asexual     UMETA(DisplayName = "Asexual"),
    Sexual      UMETA(DisplayName = "Sexual")
};

//Example of using a one to one option
UPROPERTY(BlueprintReadWrite, EditAnywhere, Category = Attributes)
    TEnumAsByte<MatingStrategy> matingStrategy;

One to many relationship

Due to the grouping of data that has the potential for re-use, some categories of data can be placed in their own data table. These pre-configured containers can then be used by multiple props, saving time and storage costs down the road. This also allows behaviours to be centrally managed if certain data groups are shared.

“FDataTableRowHandle” is used to point to a row within another data-table. By housing this in a dynamic array, multiple of these handles can be stored together and a one-to-many relationship can be established (one row to many properties). The “UPROPERTY” macro can be modified to specify the structure type that our target data table is based on.

The above specifies that a prop can have different offspring defined, but that the row type must be another prop.

Result

After combining the above principles implementation principles, and breaking up data into tables based on design principles like normal form, a starting point for our data framework has been laid out:

One-to-one relationships are included in the diagram as fields (as they are simply enumerators stored in each data table). This diagram has been refined alongside the creation of each struct. If a new piece of data has been required as per the specification, I have added it to the first logical struct (or a new struct if required) and then applied database normal form principles to achieve a suitable layout.

Editing note: One small addition missing from this diagram is the categories table, which can contain many props. This is corrected in later diagrams.

Lower memory overhead

Rather than storing data locally in C++ structs, the new data table system can be queried directly, almost halving memory overhead. Additionally, global variables that were duplicated across classes, such as world size are now also consolidated, reducing global information by a third.

Lower cognitive load

Previously it was mentally taxing to juggle the needs and interactions between props, objects, and AI. If a new feature needed to be added, its interactions with 3 systems would have to be considered. Now only one system needs to be considered, and more time can be spent making it easy to use and adding additional functionality.

Reduced duplication

Previously, unique functions regarding physics, world information and states had to be written for each object type. Now however each object can be queried using a single function. While special considerations still must be made depending on the 3D model and physics type of certain props, these differences can be accounted for by each prop containing enumerators defining said states, and a function can have a switch statement for each state type.

Editor flexibility

Previously the editor could only support prop placement but now it is possible to spawn physics objects directly too. Assets can just be loaded in without running behaviours on them until required by the play mode.

Performance improvements

With a central controller, props can be split up pointer lists based on features. These lists can be queried selectively preventing searching through every item in the game for specific searches. The controller can now also apply sweeping changes to all props of a certain type if necessary.

Code cleanliness improvements

Certain helper functions such as converting between voxel and world space have been consolidated from the three older controllers into a separate “VoxelHelperFunctions” namespace. Code quality has generally improved across the board.

Interface view

Usability testing

Being the core prop table, implementation time variability is small. One key use-case missing from this test is a prop with a complex voxel volume, but no such suitable assets are available currently. With improved times for simple voxel volumes however, it can be assumed that timings are also improved across the board, although further testing may be required.

Interface view

Usability testing

Time to implement a new category or add a prop to an existing one is almost insignificant. Again, a great result. This is in addition to improvements in not needing to physically manage prop and category locations in a blueprint, and not needing to manage a tangle of connections. This will save in hidden time costs.

Example interface view

This interface supports non-linear growth patterns and complex branching lifecycles. Growth loops are also possible, although no use-case for such a pattern has become apparent yet. As seen above, Leverets are genderless, but if developed as a behaviour, can choose between male and female props when growing.

Ease of use test

While growth settings are new to IsoEngine props as a concept, configuring said settings is easy and fast.

Example interface

Ease of use test

Materials are easy to define through the data-table but may require lots of testing by the designer to achieve some sense of balance in the decay of the ecosystem.

Example interface

Despite being new data-tables, they can still be tested in relation to ease of use.

Ease of use test

Despite compositions being significantly slower to set up when designing prop behaviours, they are a category of data that generally will be shared across many props, and so relatively speaking will be a small portion of the work required for prop configuration. Adding an existing composition to a prop or its diet takes 10 seconds approx. per reference.

Example interface

Example interface

Per table implementation time breakdown

*Note 1: only 3 of the 7 materials were used by props within the system, so 3 is used for the average calculation.

*Note 2: only 5 of the 6 groups were used by props and so 5 is used for the average calculation.

Result analysis

Implementation times for props could be anywhere from 3 minutes to 30 minutes under the old system. Using the above values, the new minimum implementation time for a prop with new behaviours, is 2 minutes total. Not too impressive, but an improvement. If we assume categories and consumption groups are already established however, and that the prop in question has no behaviours, the theoretical minimum implementation time is 1 minute and 10 seconds. A nearly 3x improvement.

The new maximum implementation time including new behavioural tables and fields (excluding complex voxel volumes) is 3 minutes and 25 seconds. This assumes that new external categories must be created. Given that this is so close to the original minimum I would call this a massive success. This of course needs to be re-evaluated once an asset is implemented with a complex voxel volume to see if it significantly changes the result.

The most reliable metric for the success of the conversion is looking at the average time to implement individual props, categories and behaviours included. This new average is 1 minute and 57 seconds. One important note about this metric, is that in theory average timings will improve as assets are added to the system. This is due to prop and material categories generally being shared, so additional time due to category creation will become increasingly diminished, driving prop average times closer to the minimum recorded time.

Usability success summary

All three analysed metrics are incredibly promising and affirms that this project has been a success when measuring against content implementation times alone. Of course, this cannot speed up the process of external design efforts such as gameplay design, modelling, animation etc, but it does make the life of a designer much easier, as they only have to refine their own disciplinary skills and learn how to use this simpler refined interface.

Completion of project aims

Feature completion checklist

A result I’m extremely happy with is that every primary goal of the essential implementation plan was met during development. It was deliberately kept simple to focus on the experience of using the interface. Many optional secondary aims were not explored, but this will be left for when the ecosystem is fully developed.

Summary of project success

In conclusion, this project has been a massive success in terms of meeting target aims, and as a bonus, several test behaviours have been implemented to ensure suitability for long-term IsoEngine plans. The groundwork is now laid ready for ecosystems to be developed fully, and for new content to be added at an increased pace and quality.

As for areas of improvement, a better plan for how to develop the chosen systems should have been explored, as key areas like navigation meshes failed to make it into the final work simply due to oversights in planning. A major failure of testing also occurred in that it likely failed to capture realistic conditions for who would use the interface and the complexity of props being built. If repeated, this test should have been done with a small sample of users across a broader range of more complicated props.