Work Since Last Devlog
- Started working on a simple UI widget implementation for option menus and HUD elements. At this point, I think I only have a real need for menus with vertical lists of options, and things like showing the player’s stats in the corner, but for future projects I could extend this to other layouts. Widgets can be either bodies or items, and are drawn and processed recursively every tick:
- Bodies are the focus point for the end user’s cursor, and contain items and other bodies.
- Items can be options linked to an action (such as quitting the game) or a variable (such as for changing the master volume), or they can just be non-interactive labels. They’re drawn relative to their associated body’s position on the screen.
- Scenes can now have sub-scenes which are processed and drawn recursively, allowing things like menu widgets to be separated from scenes that represent gameplay areas.
- Did some work on input reading as part of the widget cursor handling. I used LÖVE’s keypressed / keyreleased callbacks with a per-tick function to keep track of how long each key has been held down for, and also a global value indicating the most recently-pressed key. With this info, One function can check if a key was just pressed, or held for at least n_ticks, and also require that it is globally the last-pressed key. Reviewing the LÖVE docs, it looks like there is already a way to get input with key-repeat, but what’s done is done.
- Changed the main actor processing loop from for to while as the former was not processing newly-added actors during the same tick. Oops. Just writing this, I realize I’ve made another goof-up by adding actors to slots that may have already been passed-over by the iterator.
- Map functions had been stored in the source file that handled collision checks and wrappers for Lua math functions. I moved map creation / management to its own source file, and rewrote the map loader to use love.filesystem.load() and pcall() instead of require() so that a map can be loaded multiple times, and so that the Lua code/data chunk can be safely evaluated before returning it to the scene manager. Added an option to keep backups of the map data and actor data so that a scene can be restored to its original condition, for example to reset a map after the player has been defeated and sent back to a checkpoint.
Thoughts
Wow. If there is one thing I’ve learned about myself this week, it’s that I do not like writing widget-handling software at all. At least, when there are other things I’d rather be working on that are being held up by it. If I end up going the embedded live-editing route in the future, I’ll probably look into integrating someone else’s widget framework.
I did end up cobbling together a simple animation viewer. At some point, I could add a widget menu to adjust parameters, and save that info back to the source files.
I don’t feel like this has been a productive week, and I’m a bit concerned about my progress. The codebase perennially needs work, owing in part to me not knowing what I want out of it, or what I’m doing. I should have just started with a simple scrolling shooter or breakout game!
Plans For Next Post
The widgets are half-baked and messy, but they’ll be fine for one game. I suppose this applies to just about everything else in the engine as well. In light of that, then, what I want for next week is to have the skeleton of the game decided upon and sketched out, from beginning to end. Then spend another week filling it out and fixing issues as they arise. Come 31st of March, I should have a reasonable prototype, and something to refine and extend for future projects. That will be the point to decide on whether to keep moving forward, or if this project needs to be axed in favor of something else.
(e 18/Mar/2019: Spelling)
