| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The AutomatableComponent now links to the Runnable entity representing the behavior script.
Also reordered the SystemManager and EntityManager members of the Game class such that the EntityManager is destroyed before the SystemManager is. This fixes a bug where the destruction of a component has some affect on the state of a system. Specifically, if the ScriptingSystem (and thus the Lua state) is destroyed before the EntityManager is and there are any Runnable entities, the game will crash when trying to destroy them.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AutomatingSystem has been renamed to the ScriptingSystem, since the automatic behavior script is just a special case of the scripts that an entity can exhibit. The AutomatableComponent has largely been moved to the new RunnableComponent (might not be the final name for it).
The Lua state object, previously living on the singleton RealizableComponent, is now a member of the ScriptingSystem itself, because it A) doesn't really belong on the realizable entity, and B) a singleton entity seems weird and like a cumbersome attempt to apply the ECS rules to places they don't apply. In a similar vein, the RealizableComponent itself will probably soon be integrated into the RealizingSystem too.
The attempt at using Lua environments in order to encapsulate the different behaviors that objects exhibit was scrapped in preference of just creating differently named Lua tables for each prototype.
The new PrototypableComponent contains some information about entities which were prototyped. It is partially used by the ScriptingSystem to figure out what event handlers are appropriate, which may not be the best approach. It also has some data about automatic behavior, which also maybe does not belong in this component.
The OnTouch event is raised by a player colliding with a physics body with the collider type "event", which may not be the best way to implement this.
The result of all of this is that checkpoints now work, although no sound is played, and the result is not persistent across exiting the game.
|
| |
|
|
| |
Currently moving platforms are able to have their movement controlled by a script rather than by XML, which is probably a better implementation and scales better to other things. The scripts, instead of using the components as state, use the stack as state. In this way, they pretend to be multithreaded. For instance, the moving platform calls moveRight and then moveLeft. Both of those functions internally make calls that say to wait until the next tick. When the AutomatingSystem ticks, it continues execution of all scripts (sequentially, of course) until they ask for the next tick again. This is implemented using coroutines.
|
| |
|
|
| |
Positions and sizes are now stored as vectors (of doubles and ints, respectively). This allows for at least minor code simplification in many places, and cleans up the CollisionParams code in PonderingSystem quite a bit.
|
| |
|
|
|
|
|
|
| |
The new AutomatingSystem and AutomatableComponent are responsible for simple AI tasks. This currently is limited to moving entities at a certain speed for certain periods of time. These tasks are arranged as a set of behaviors, which are picked randomly when automation starts or when a behavior finishes executing. A behavior is a sequence of actions that run one after another.
Currently, if an automated entity is blocked from moving by a collision, it will be coerced out of its intended path. This is because the automation parameters are stored as a speed and a duration, rather than a starting location and an ending location. This may end up being changed, or made configurable, as this is an early implementation of this feature and will need to be more complex later.
Added an RNG object to the Game class, so that the AutomatingSystem can pick behaviors at random.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Collision checking in PonderingSystem was rewritten to work as follows: horizontal movement is step first, then vertical. In each step, the closest environmental boundary to the body is found on the axis of movement in the space traversed by the body. Then, if any map objects fall in the region between the body's old position and the environmental boundary (or body new position if no boundary was found), process collision with those bodies in increasing distance order, stopping if a collision stops movement short of where the next collision would take place. After this, process collision with all of the environmental boundaries at the axis distance found earlier, as long as movement hasn't stopped short.
This is not the most optimal implementation, and there is a lot of code repetition, but it is a start and it works.
All map objects currently function as walls.
This fixes the bug where you could, with pixel-perfect precision, jump into the corner of a wall tile.
The top of the hitbox for the spike tile was lowered by one pixel. This fixes a problem where if the player is halfway on a floor tile and halfway over a spike tile, the floor tile would not stop the spike tile from being processed, and the player would die.
|
| |
|
|
| |
Map objects cannot be interacted with or collided with yet but the sprites are loaded.
|
|
|
The World class was removed and replaced by the RealizingSystem and RealizableComponent. The realizable entity is intended to be a singleton and to represent the world. The Map class was also removed and integrated into the MappableComponent.
These changes are to facilitate implementation of map objects without needing special intermediary objects (including the Map class). Now, map entities are created as soon as the world is created, and map object entities will be as well. They will simply be deactivated while the map is not active. Multiple players are now slightly better supported, which will be important in the future.
This will likely become inefficient as the world becomes bigger, and some sort of sector-loading process will have to be designed. This also reduces the usefulness of EntityManager's entity-searching capabilities (which are not the most efficiently implemented currently anyway), and will likely in the future require some added functionality to better search subsets of entities.
A lot of the components were also rewritten to use bare member variables instead of accessor methods, as they never had special functionality and just took up space. These components were also documented.
|
