Game thing progress #3
Since the last post, everything except the terminal part has been rewritten in moonscript. I'm still not sure if I like it that much better, but I like to think that the time spent dealing with the lua module linking hasn't gone to waste.
A simple change has been made in the walking part, to make it a bit longer, requiring the player to go back to the computer, where they previously were at the start, and then interacting with it to get back to the terminal, instead of just going there when the "puzzle" has been solved.
A simple prefab system has been implemented. It allows separating entities into different files and loading them from other scenes. This way, the player entity can be recreated in the new room easily.
A beginning of a second room, which will contain a simple puzzle, has been drawn and inserted into the game, along with a passage sprite to separate the rooms. When the player interacts with the passage, the ECS resets and loads the new room's contents. The passage is, in turn, implemented using the same mechanism the push button used, except it's been generalized for usage with anything interactable.
A simple collision system, using bump.lua, has been implemented, which replaced the "just compare sprite bounds" system. This allows
entities without sprites to have collisions too, invisible walls (or walls that imitate the level geometry) can be made this way. If the entity
does have a sprite though, the collider component can be told to use the sprite size as its bounds, or, as with those without the sprites,
it can be told to use constant sized bounds defined in the entity description. The position for the boundaries is taken from the entity's
transformable
component (which is basically SFML's Transformable
). If the entity has a sprite, then the sprite as used as a transformable,
and if it does not, a new transformable is created and used.
The above exposed a bug with render Z sorting: before, everything was drawable, so this wasn't a problem, but introduction of things
that are not to be drawn also introduced gaps into the entity array of the drawing system. This means that virtually all built-in things that work
with arrays do not work anymore. Particularly, sorting either silently fails or passes nil
to the sorting function, because it assumes there are
no gaps. It took me about a day and a trip to the #lua
channel on IRC to figure that out. Now, there's a separate array of entities to be drawn,
sorted and without gaps, which is updated when entities are added or removed.
Synchronizing collisions betwen the physics world and the actual trasnformables and moving things accoring to those collisions also turned out to be a non-trivial thing to do. I implemented a debug overlay that draws red boxes around colliders, this overlay will probably be easily togglable in the future. The positions of the objects are now synchronized with the physics world in the following way:
- If the entity wasn't in the world before, put it in there with the position of the transformable minus the origin/pivot point
- If the entity was there already, put the position from the world plus the origin/pivot point, and update the size of the entity in the physics world from the sprite
And that's how things have been in the past few days, I think that's enough for this post, so I'll end it here. Thank you for reading my blog post :)
Comments