Sabbatical Log: November 8thPosted: 2018/11/16 Filed under: code 2 Comments
This blog series is running about a week behind my actual work, giving me time to clean things up. The date the actual work was done is in the title, horizontal lines indicate when I stopped writing and started coding.
Time to get to work on some flowers! These should be a basic entity with nothing fancy, just a position (existing component) and a frame counter (new component). The lion’s share of the work is going to be making room instances instead of just using room “templates”.
I’ve got animated, collision-less, objects loading into rooms now. Doesn’t look that impressive, but it’s laid the groundwork for much more complicated things.
Rooms now exist (and have state), there’s a new AnimationSystem that handles advancing frames for anything animating, and GameState now manages room instances rather than only tracking the name of the room your in. RoomTemplates also grew a notion of objects with properties, so things can be placed in rooms with Tiled.
There’s really nothing fancy enough to be worth showing in the code. I still need to make animations configurable (right now they’re hard coded), and convert the collision demo and player to use animations instead of being “known” by the renderer.
I’ve changed animations to actually be backed by files on disk. Like everything else, I went through the trouble of getting hot loading working so changes to the definition files are reflected immediately.
The format is just a frequency followed by frames, nothing fancy.
I had a question about your camera system (even though this post isn’t about that). Is the camera system responsible for actually drawing stuff onto the screen? Like, lookup where the player entity is, use the room manager to query for rooms around the player position and draw them using the MonoGame engine?
The camera doesn’t draw, drawing is currently handled in the “Game” class (which extends MonoGames built in https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework/Game.cs ).
The render code works over a FrameState that is produced by looking at the “State” class, and that captures what’s needed from the camera _entity_ (which is managed by the camera system).
At some point I’ll want to move the rendering code out of the Game class, and probably abstract over the MonoGame-y bits – I just haven’t gotten to it yet. It’s not a lot of code right now (snapshot is here: https://i.stack.imgur.com/r2Qwv.png ).