After messing around with the platformer a little more in the days following my last post, I decided that I had gleaned most everything I wanted to know out of that project and that it was time for a new one. I never intended the platformer to be a releasable project, more just a project to mess around with LibGDX and try new things. Having learned quite a bit to get the project where it was, I wanted to switch focus to a project that I actually intend to release to the public.

At the beginning of every year I try to sit down for a couple of hours and come up with goals that I’d like to achieve that year. For 2021, one of the goals I wrote was to make a feature complete game that had a somewhat advanced level of complexity (the example I gave at the time was multiple levels, preferences, etc). I wanted to complete a game with this level of complexity, get it to a releasable point, and then actually realease it where other people could play it. My thought process was/is that even going through the motions of taking a project from the idea stage, all the way through development, landing on a complete product, and then making this product available for others, is in and of itself quite an accomplishment. When you add all the other things that are needed for actual game development, like coming up with fun and new mechanics/concepts, creative art, advertising, monetization, etc, this becomes a little untenable, especially for someone new to game development. So, producing something (even if that thing is not being sold for money, is not a new concept, and isn’t advertised), would be a big feat to have accomplished.

With all that said my goal for my next project is to make a Breakout clone in LibGDX. I hope to make a complete game out of this clone, with multiple game mechanics. This will be developed in a very “professional” work flow, in that I’m capturing all potential features I have in my idea journal, planning feature additions and future work in advance, managing my tasks on the project through a work tracking system, using a version tracking system, and managing builds/etc in a CI pipeline. Once I decide to release this project, I plan to do so via itch.io.

I have a large number of potential features, some half baked and some mostly baked. I always try to keep a notebook with me, and whenever I think of anything (for any project, not just this one) I make it a point to write down what I’m thinking. In all likelihood, you won’t be able to immediately start implementing something as you’re thinking of it. You may have to learn a new technology, you may have to flesh out the idea more, or you may just be busy with stuff when an idea comes to mind. But by writing everything down, you can try to get your mind back on it later when the opportunity better presents itself to actually use that idea. So with this Breakout project I have assembled quite a list of features and have been working through whether or not each one is needed, not needed, nice to have, impractical, etc.

Immediately on setting out with this project I decided that it should be broken up into two phases. For phase one my goal is to make a minimum viable product. This should include a breakout clone with one level, multiple UI screens that give the user choices/options, at least one sound effect, at least one ‘brick’ type for the user to play against, and tracking as to whether the player has won, lost, or is still playing. With this I would have a minimally viable game that works. Once I have this MVP it can then be iterated forward with cooler features like game music, additional ‘brick’ types, additional levels, a level editor, power ups, etc.

Once I had a feature list for the MVP of phase one I began writing the individual tasks that would need to be taken in order to get the project from step zero to an MVP. To track these tasks I’ve been using a self hosted kanban board application called Planka. I’m running this Planka instance on my internal network and haven’t put it on my web hosting pipeline, as I’m using this project as a test run to really get to know the application.

Now after all of that lead up, lets get into how the project has been going. Obviously I’ve been lightly working on this project for about a week now. A significant amount of that time was eaten up in scope decisions, project planning, CI setup, and the boiler plate of starting a LibGDX project, but I have actually made some progress on the game. I had started a project called BreakoutGDX about a year ago when I first found the LibGDX framework, but I had abandoned that project very early. I had gotten it to the point where it had a menu screen, a preferences screen, and a game screen, and where the user could click between these screens. They didn’t do anything, and there was no game functionality implemented whatsoever, but it felt like a good start. I blew the dust off of that old project and got it updated to LWJGL3 and the latest version of LibGDX.

The menu screen looks oddly close to the PongGDX screen, because this is where I learned how to use LibGDX stages and such. I spent about two hours getting the project to a place where I could move forward with it. I then set about finding my art for the game. There are some phase two features that I think will need additional art, but for the time being I decided to go ahead with one of the puzzle packs from Kenney Assets. I separated the paddle and ball assets out, downsized them by 50%, and then turned them into a TextureAtlas using TexturePacker.

For the game walls, I actually used a couple of assets I found from the Kenney roguelike pack (not sure if they’ll stay though, I’m not completely sold on those walls yet). After putting some boilerplate together to basically get a paddle sprite on the screen, and load in a TiledMap object for the game wall, this was the result.

The last thing I did this week was add some functionality to assist with builds and deployments. I built the version number into the application, by setting it as the ‘Implementation-Version’ field in the desktop JARs manifest file, and built a helper class in the application to return this information at run time. Ideally I can use this later to show the running version number from within the application somehow, and also use it in the logger whenever that’s implemented. I also added fields to the manifest file that are populated at build time that capture the date and time of compilation, and the JDK that was used to compile the application.