Input mapping screen.
Work Since Last Devlog
Menus
The input mapping screen is now functional. It supports keyboard key codes, scancodes and gamepad buttons, and the bindings take effect immediately. It’s possible to trap yourself in the menu if you delete the menu navigation bindings, but you can recover by pressing F8 eight times in a row.
I wanted to include turbo mappings for every individual binding. After some reflection, I can’t foresee a use for that in the one game which will use this iteration of the engine. Maybe next time, or if there are requests.
I made icons for the gamepad buttons, and then spent way too much time trying to make a matching set of graphics for keyboard keys. I chose a base resolution (16×16) that isn’t large enough for all of the key cap labels such as Backspace, so those inputs are just plain text.
Besides input, the mute and volume sliders for master volume, SFX, music and DSP effects are now working. Most of it’s working now actually, except for saving config and resetting all config.
I wrote a resolution selector widget / scene, and ended up having to rewrite a good chunk of the window management code in order to support the functionality that I need. Hibernator never supported fullscreen mode because I couldn’t get it working to a reasonable level in a short timeframe. The codebase is now good enough to handle it.
Scene and Map Reorganization
I rearranged the scene and map structures to better support loading and reloading maps into existing scenes. Previously, when you registered a scene, it had an optional map_filename field, and it imported the map data during initialization, and that was that. Now, maps are registered independently of scenes, and are stored in a separate array. When a scene needs a map, it copies the map from this array and overwrites its existing actor and widget lists with the ones tied to the map.
I panicked a bit last week because I thought maps were taking up a lot more RAM than they actually are. I drew up plans for incremental map decompression, chunked loading, etc. I’m very happy that I was just making a mistake in my calculations, and that this won’t be necessary to deal with right now. (No doubt it’d be a different story if this was going to be a larger game, or one that stores a lot of in-the-moment map state.)
I did make a few changes based on mulling this over, though, which should help a little bit with memory usage:
- Layer data now defaults to being run-length encoded. When maps are loaded into a scene, the layers are decoded to full arrays.
- Previously, maps in scenes were optional, but if a scene did have a map, it was required to have all of the hardcoded layers present and accounted for. All map layers are now optional.
- Added support for the background color parameter in Tiled so that you don’t need a BG tile layer to pre-fill a scene with a certain color.
I’m thinking that for commonly-used scrolling backgrounds, they can be designed to be their own scene + map combos, and the main gameplay scene can then attach one of them as a subscene, so a large 128×128 area could use a smaller 32×32 parallax wrapping background.
Thoughts
I’ve been complaining about widget and UI stuff since … June? I’ve been putting off the actual game design part of the game while dealing with technical issues. I’m still not sure how the player character is going to interact with opponents. But wow, what a feeling to be coming up short on the question of ‘what engine-level technical features are missing and need to be implemented.’
Plans For Next Post
- The last remaining task I have on the planning list for October is to refactor camera / scrolling / scene transitions. So I’ll get on that, and I’ll also add in the functionality for game-start and restart, loss of life, game over, continuing, and associating actor spawnpoints to the current difficulty setting.
