Game Dev Blog #9: More component libraries!

Most of the weekend was spent making some basic component libraries for some functionality that I will need, but building them in such a way that they can be re-used in other Love2D projects. For example, they should be self contained with no dependencies like Middleclass, or directly referencing constants in the project. Initialising the components should take values which the caller can pass in when setting it up.

Three Achievements

1. TextScreen component – This component lets you specify title text, an array of text lines, and footer text and it’ll render it consistently to screen. It gave me a clean way to quickly add an instructions screen and a credits screen into my main menu. I think I’ll replace this at some point As part of a bigger and better UI component library.
2. Menu Maker component – Speaking of the main menu, this is something I started making as part of my “Love2D boilerplate project” – An attempt to create a repo that would contain common code and components for any future game I wanted to make in Love2D. Again, this could eventually become part of a more comprehensive UI component library. I stopped working on the boilerplate project when I realised I had to get the my final course project completed, but some of what I’m building now for this project (The ConfigManager, the SoundManager, for example) will eventually be added back into that boilerplate project, as I learn more and build new bits. One of the other components from that boiler plate project is a Radial Menu component, which I’m not using in this project submission but will be used in the final version of the game so that the player can quickly pick a tool from their inventory. Other types of components might include a Localisation Manager, an Asset Manager, and an Input Manager to handle keyboard, mouse, controller and allow the player to remap controls.
3. ConfigManager component – You may remember in a previous blog that I’d added a config.ini file which stores the game’s version/build number, which is auto incremented each time I package up a version of the game for distribution. I wanted to show this version number in the main menu screen, and knew I’d soon want to load and save other values. I had a quick look at inifile, which apparently will do what I want, but it doesn’t appear to be maintained. So I started making my own config manager. So far all I’m using it for is to pull the version from config.ini to show on the main menu screen, but the plan is to use it for an eventual settings and new game option screens, It will expect a config.ini path and a path to a user settings file, which will be where customised settings get stored. My plan is that if I release a game update, and config.ini is updated, the user settings won’t get lost and can be merged with any new settings and defaults defined in config.ini.

Two Things I’ve Learned

1. I should have prototyped UI elements! I was planning to build out a more complex UI component library for making settings screens with sliders, toggle options, etc. I have an idea of how I want it to work, and how it would work in conjunction with the ConfigManager (though neither should be dependent on the other), but I realised this is a big project that will take me longer than I have left before the deadline for this course. So, I’ve parked the idea for now, and have made a more simplistic “New Game” screen, which lets you set some options when you start a new game. I don’t think I will be adding the Other settings screen yet (to adjust volume, resolution, full screen etc) that will all come later, as it’s going to rely on making nice UI components, or find an existing solution that works well.
2. Always be pragmatic! The above is an example of a situation where I could have got bogged down trying to make the game perfect, but there’s an alternative solution that functionally does the same thing and will do for now. Similarly, I’m looking at things like the tweening of the health bar, particles and juice for being hurt/dying, etc, and while I’d like to include them, they aren’t needed right now, so I’ll focus on the important mechanics first, and then if we have time, I’ll add some of the nice-to-haves.

One thing coming up

Build 0.1.0.10 will technically be a playable game with instructions, credits, new game options, a win state, lose state, etc. Next thing to decide is whether to make the game compatible with a controller first, or add paralax background scrolling.