In my previous news post "More about
Component Systems" I presented the central ideas and concepts about
the two component systems that we are about to introduce to the Cafu
Engine. Since then, a lot of work has been achieved, and it is time for
an update:
The biggest challenge and the focus of my efforts has been the porting of the old DeathMatch game code to the new component system. This was very successful, and in fact the old DeathMatch game code could be entirely removed and be replaced with newly-written components that have just the right mix of C++ and Lua script code.
In fact, the successful removal of the old, intertwined and tricky DeathMatch C++ code was the key step that motivated me to write this news update. However, that doesn't mean that we're done yet. Some things had consciously (and temporarily) to be broken and must now be fixed again, and other things are not yet as they should be. Here is a summary of the technical aspects:
Updates to the repository
If you're following the Cafu source code repository, especially on branch
Please note that although I felt that this is the right time to continue the development of the entity component system in the
These problems are well known to me (but any feedback is welcome, don't fear duplicate reports), and the rest of this news post summarizes the problems and the plans to resolve them.
Plans regarding "Player Prototype" entities
Implementing the "carried weapons" of a human player is, in all its details, surprisingly difficult. A lot more difficult than the code for monsters and other non-player entities. In fact I managed to move its previous, old implementation into the component system -- but there it is still old and inflexible code, and not in the useful and helpful spirit of the component system as everything else.
Also, moving the code necessitated some compromises, and these compromises, while they made it possible to integrate
Pondering this gave raise to another insight: So far, we have no concept for human player entities in the component system at all! That is, giving the map designer a chance to make any settings or script code adjustments for the human player entities that are supposed to spawn in the map was just not possible.
To fix all this, the idea is to introduce a new special entity that acts as a "Player Prototype". Of this new entity, exactly one instance exists in each map that the map designer can use to customize all details to his heart's contents, including that of possibly carried weapons. The Cafu Engine then spawns an entity for each human player that joins the map by cloning the "Player Prototype".
Among others, the player prototype entity has a list of components of type "CarriedWeapon", whose properties and script callbacks define one weapon each, and each such weapon would be completely self-contained, keeping information about e.g. its availability to the player ("has it been picked up earlier?"), whether it is active or holstered (more than one weapon can be active at a time, e.g left and right hands), the current, minimum and maximum ammo, and so on.
Developing this "Player Prototype", the carried weapons, and all related functionality will amount to a total rewrite of the old code, and be the immediate goal of my next steps -- this is exactly what we have introduced the component system for, after all! Even if it is not obvious from this text alone, when done you will see that the result is very very worthwhile!
More work to be done
The above is crucial, but there is still a lot more important work to be done, and branch
Most importantly, the carried weapons must be fixed as described above. However, also the particle engine needs a thorough overhaul, and we really have to re-implement the precaching feature also for our component system, whose current lack causes noticeable lag.
Finally, the Map Editor is the only part left that is not yet adapted to the entity component system. This is very important, as the Map Editor is often the program that new users look at first.
The biggest challenge and the focus of my efforts has been the porting of the old DeathMatch game code to the new component system. This was very successful, and in fact the old DeathMatch game code could be entirely removed and be replaced with newly-written components that have just the right mix of C++ and Lua script code.
In fact, the successful removal of the old, intertwined and tricky DeathMatch C++ code was the key step that motivated me to write this news update. However, that doesn't mean that we're done yet. Some things had consciously (and temporarily) to be broken and must now be fixed again, and other things are not yet as they should be. Here is a summary of the technical aspects:
Updates to the repository
If you're following the Cafu source code repository, especially on branch
master-vc2012 or
entity-component-system,
the following recent changes are important:- I just tagged revision 1debdc3 (of 2013-05-25, almost exactly one year
old!) with name
pre-entity-component-system. This is the revision where ourmasterbranch was at the time when the development of the entity component system was begun. The annotated tag message is this:
This is the last revision before the extensive work was begun to introduce a component system for game entities to Cafu. It is expected that the development will take a long time. Although it is intended to keep backwards-compatibility wherever possible, it is expected that compatibility to now existing binary files (especially `cw` world files) and to custom Lua map scripts (e.g. `TechDemo.lua`) must and will be given up in the process. Contrary to the already completed introduction of a component system for GUI windows, it is expected that the upcoming work is of a long-running nature, comes with extensive changes to almost all parts of the Cafu Engine, and is possibly "open-ended". It is therefore developed in the `master` branch rather than a feature branch that would run for months and years, and in the meantime only leave `master` back at this commit, which will sooner rather than later become old and unsupported. Also see https://www.cafu.de/forum/viewtopic.php?p=6212#p6212 for additional information.
- Next, I fast-forwarded branch
mastertoentity-component-system(integratingentity-component-systemintomaster), in which until now the entity component system was developed, then deleted the now no longer needed branchentity-component-system(andmaster-vc2012as well).
- If you are among those who, like me, had checked out branch
entity-component-system, and possibly based work on it, you can use these steps to update your working copy (the steps are shown for Windows, but are very similar under Linux):
# Fetch all the new branches, commits and tags: > git fetch --all --prune > git fetch --tags # Clean up the working copy, i.e. stash or commit local uncommitted changes # as necessary, and (on latest entity-component-system), delete possible # leftovers from previous revisions: > rd /s Games\DeathMatch\Code > rd /s Games\VSWM # Checkout the "old" master branch, and fast-forward to origin/master: > git checkout master # old master > git merge origin/master --ff-only # In my case, it was sufficient to delete the now obsolete local branch, # however if you have based own work on it, you'll rather want to rebase it # onto or merge into master first. > git branch -d entity-component-system
Please note that although I felt that this is the right time to continue the development of the entity component system in the
master branch rather than
keeping it further artificially separated in the now gone entity-component-system, at this
time master is
not in a state where a release could be made from it: In fact, if you
compile and run it, you will quickly find a lot of problems.These problems are well known to me (but any feedback is welcome, don't fear duplicate reports), and the rest of this news post summarizes the problems and the plans to resolve them.
Plans regarding "Player Prototype" entities
Implementing the "carried weapons" of a human player is, in all its details, surprisingly difficult. A lot more difficult than the code for monsters and other non-player entities. In fact I managed to move its previous, old implementation into the component system -- but there it is still old and inflexible code, and not in the useful and helpful spirit of the component system as everything else.
Also, moving the code necessitated some compromises, and these compromises, while they made it possible to integrate
entity-component-system into
master, are also
responsible for the "broken" look and feel of today's (May 2014's) master.Pondering this gave raise to another insight: So far, we have no concept for human player entities in the component system at all! That is, giving the map designer a chance to make any settings or script code adjustments for the human player entities that are supposed to spawn in the map was just not possible.
To fix all this, the idea is to introduce a new special entity that acts as a "Player Prototype". Of this new entity, exactly one instance exists in each map that the map designer can use to customize all details to his heart's contents, including that of possibly carried weapons. The Cafu Engine then spawns an entity for each human player that joins the map by cloning the "Player Prototype".
Among others, the player prototype entity has a list of components of type "CarriedWeapon", whose properties and script callbacks define one weapon each, and each such weapon would be completely self-contained, keeping information about e.g. its availability to the player ("has it been picked up earlier?"), whether it is active or holstered (more than one weapon can be active at a time, e.g left and right hands), the current, minimum and maximum ammo, and so on.
Developing this "Player Prototype", the carried weapons, and all related functionality will amount to a total rewrite of the old code, and be the immediate goal of my next steps -- this is exactly what we have introduced the component system for, after all! Even if it is not obvious from this text alone, when done you will see that the result is very very worthwhile!
More work to be done
The above is crucial, but there is still a lot more important work to be done, and branch
master,
despite my promoting it as described above, currently has known bugs and
generally not the quality that we normally strive to achieve and are used
to.Most importantly, the carried weapons must be fixed as described above. However, also the particle engine needs a thorough overhaul, and we really have to re-implement the precaching feature also for our component system, whose current lack causes noticeable lag.
Finally, the Map Editor is the only part left that is not yet adapted to the entity component system. This is very important, as the Map Editor is often the program that new users look at first.