Ludum Dare and the CFZ GameJam

To show my commitment to the “One Games Jam Per Month” resolution I set myself, I took part in Ludum Dare 41 in April and the Confuzzled Games Jam in May. You can click below to try out the entries, while I explain the development approach to both.

Ludum Dare 41 had a promising selection of theme, but it ended up with the problem of people picking what many considered the worst one: Combining Two Incompatible Genres. The main issue with this theme is that in theory, there are no incompatible genre combinations. Granted there are genres which in a broad sense looks like they wouldn’t fit, but with infinite creative possibilities and countless examples in previous Ludum Dares, you can make any two genres work together.

Several submissions had examples combining music-rhythm with adventure, the visual novel with point ‘n click, racing with city building and many more. I went with what turned out to be a more common submission, combining a shooter with a puzzle game. Specifically, I had the idea of a vertical shooter in the style of an interactive board game.

The concept was simple, you had players controlling the ships, and one player controlling the enemies. The ships can move and shoot one each turn based on dice rolls, and the enemies movement, placement and shooting are based on cards picked up each turn. The ships have the goal of surviving long enough to defeat the boss, while the enemy has to defeat all the enemy ships. It was a concept that I felt was easy enough to implement, with it mainly being event-based, with a game flow that could easily work as a physical board game.

However, a lot of issues came from delivering the game. Most of the issues, such as the game’s pacing, weird controls, the lack of CPU players + no options to set how many people in play meaning that five people were needed to play the game properly, could be narrowed down to time and how rusty I was with the engine I used, HaxeFlixel.

I made the mistake I’ve done in the past where I go out on the Saturday with friends, thinking that whatever notes I come up with was enough for me to power through the game on Sunday and Monday. However with the idea being so unconventional, that having the Saturday to set up how the game would work would have been a lot more beneficial.

Instead of using Vigilante as I have done with the past game jams, I went with my usual go-to engine for Ludum Dares, HaxeFlixel. As Vigilante was based on HaxeFlixel, they do have a similar structure. HaxeFlixel also has the benefit of being able to build for both web and desktop platforms, but I should have had a bit more practice with the latest version as on Sunday the rust was already showing. Some aspects such as asset loading were aggravating, functions weren’t performing how I assumed they would and Haxe doesn’t have the same syntax as C++ so I had to think more about what to write. It especially didn’t help that building for Windows didn’t work in time, and the HTML5 build would freeze at random points making it unplayable, which is why the game’s page requires Adobe Flash, as it’s the most stable build for HaxeFlixel.

By the time the Monday deadline was creeping up, I was becoming less and less driven to get the game feeling good and more getting it out. That’s why I couldn’t get the features I wanted, but because I already put so much effort in and wanted to get a games jam entry submitted for April, I went ahead and submitted… something.

Looking at the feedback, I can understand the criticism of it being slow, and I really wish I at least had the option to set the number of players and added in some form of CPU player, even if it was just RNG responses. I’m not happy with the score I’ve gotten, it’s definitely my worst LD entry not counting the even number curse where the entries that I made didn’t even get a ranking. There is a lot to learn and I have to take those lessons in, because not every games jam is gonna go as planned.

If you want to see what an experimental board game shooter looks like, feel free to have a go at Strategysphere.

The games jam for this month was ran by Confuzzled, a convention that I’ve been going to since 2011, but this year’s theme is video games and as such, they held the first ever Confuzzled Game Jam. The jam was three weeks long, with no specific theme but people could get ideas any of the previous convention themes, so my initial idea was an Osu style game where you had to play through a level while a scene would display your performance, and the level would be a music-rythm based auto-runner. I felt that the cutscene portion would have been too complex with my slow and sub-par drawing skills, to get what I want on time, and after Ludum Dare I wanted to focus more on the game so I stuck with the auto-runner.

Fortunately, this isn’t the first time I’ve tried to build a game for Confuzzled this year, I worked on a platformer prototype for a few months but motivation and other work got in the way, however the work did mean I already had suitable code for platformer physics. The biggest challenge I had was creating a level long enough for a music track, that was where a level editor comes in.

I initially thought of using Tiled, but I wanted to easily preview segments of the track and have game relevent infomation that I can use for reference, that’s when an idea occured to me to make my own. I wasn’t sure what GUI library to use until I saw a really good article on SFML with dear imgui. dear imgui is what’s called an Immediate Mode Graphical User Interface, essentially, unlike a traditional GUI library where you have to set up your UI elements, handle their input responses and render them individually, an IMGUI will set up and handle the UI elements you want during your update function. For example, if you want a button, in an IMGUI library you simply call a single function in an if statement condition bracket, and write the button press response in the braces of the if statement. While there is global setup for dear imgui, there is still less set up compared to when I used GWEN years earlier, making setting up the level editor’s user interface super easy.

Despite my ealier comments on drawing, I could still draw passable enough to do a running animation with a run-cycle reference, and once I added in some visual effects and some music from LMMS, I got a game! My sister came up with the idea of calling one of the foxes Foxtrot and giving him a buddy called Tango, so that’s why the game is called Foxtrot + Tango!

All entries for the Confuzzled Game Jam will get their games showcased at the convention itself, but you can play all the entries on Confuzzled’s website. Now I have the rest of the con to prepare for, as not only am I showing off a game I made for it, but I’m talking about game development as well.

New Years Resolutions

Good evening everyone! It’s no doubt that 2017 has been a hell of a year following what happened in 2016, but we fought through and we are still here fighting! This year has also been huge in terms of game development for me. I managed to finish SEVEN games this year, six from game jams such as #RemakeJam, PROCJam, Jamchester and Three Ludum Dares!

The seventh game was the nearly two year project Gemstone Keeper, which made an initial release on March 31st earlier this year and has since had numerous updates, although grouped together as four updates. The most recent of which was 1.0.4 that was announced on 21st of December. The game is currently on part of the Steam Winter Sale, and is currently 50% off!

Gemstone Keeper also had a second smaller release as it was ported to Linux, the build being available on Steam in June. I documented the progress to port the game in three blog posts (part 1, part 2 and part 3), and got a small amount of coverage from dedicated linux gaming websites as a result.

There was also an accomplishment in travel as well, 2017 was the year I went to both GDC in San Francisco and Develop in Brighton for the first time! Both events were great opportunities to meet up and socialise with fellow game developers and listen to talks from great minds such as Ken Perlin, John and Brenda Romero, Jordan Mechnar and Tim Sweeny.

As for 2018, I want to set some goals. As with many New Years Resolutions, chances are they will be forgotten and unaccomplished, but considering I managed to lose weight this year, I might pull through with a bit of committment.

First one is that I want to take part in at least one game jam a month, meaning I’d be finishing 12 games next year. I like the challenge and creativity from game jams, but this year I feel like six isn’t enough. At least spacing out the game jams to one a month will give me time to find a weekend or so to get my head down and finish something.

Second one is to get a game on console. It’s not like I haven’t bothered trying before (I’ve reached out to Nintendo about developing Gemstone Keeper for the Switch to no avail), but it would be nice to expand my work beyond desktop PCs and web development. Porting my own game to Linux should show how when I put my mind to it, building a game to another platform by hand is possible, and it would be great to show I can do that on one of the three main systems.

Thanks for reading and have a happy new year everyone!

Gemstone Keeper – Quest to Linux Part 3 – Gemstone Keeper

Finally, after beginning soon after the game’s Windows release on Steam, and well over a month after I initially wrote my first post about this topic, I’m finally done with porting Gemstone Keeper to Linux (for the most part) and ready to write about what I’ve learned from porting it over. Since both the Framework and Level Generator have been ported, getting the whole game to compile and run wasn’t as confusing as the last two, but that didn’t stop it being tedious.

Continue reading

Final Stretch: Gemstone Keeper’s Release

Back in May, I made a simple demo for a University Thesis, now it’s less than two weeks away from being released onto Steam. This is such an exciting occassion for me, but also a nerve wracking one. If all goes to plan, Gemstone Keeper will be available on Steam on March 31st at 6pm GMT.

For the time being I will be working hard on polishing the game and getting the word out, I appreciate any help from that. There have been several updates from when the game was shown at LAGC, especially thanks to the feedback I got of the game from both GEEK Play Expo and GDC. Game has been balanced (repeatedly), boss battles have been redone and several bugs have been fixed.

I’d also like to give my thanks to Gemstone Keeper’s composer for the soundtrack, Vincent Rubinetti. He is probably best known for producing the music to the game INK, the colourful yet minimal platformer by Zack Bell. We’ve been in regular discussions both online and at GDC about the game’s music, and you can hear one of the tracks from the game’s brand new trailer above, I think it’s some brilliant work.

I’d like to thank everyone who has shown support for Gemstone Keeper over the last year or more, this game has been a huge milestone to conquer and I hope all those who try it will have a great experience.

It’s just amazing to think of how it all started…

Procedural Meshes: Generating Gemstones Part 2

Last time I talked about writing a gemstone generator for Unity, in this part I’ll talk about taking that script and making it work in SFML 2 using C++. What makes this challenging is that Unity is a 3D engine with a Mesh class making it easy for procedural geometry, while SFML is a C++ framework made primarily for 2D games. The most SFML gives you is the sf::Vector3f object, which allows you to store 3D [x,y,z] coordinates, which means the rest of it is up to you. As of writing, this is the approach I went to generate 3D gemstones in Gemstone Keeper.

Continue reading

Weapons of Gemstone Keeper

So for this week (11th – 17th January) I decided to focus on weapons, a pretty important element of twin-stick shooters. I didn’t want to stick with using one weapon for testing, so I decided to see if I could make a few more for the game. This should explain how I approached the problem and what the weapons system currently looks like for Gemstone Keeper.

Continue reading

New Year

Celebrate what you have accomplished, learn from what went wrong, and most importantly you must move forward. Hope everyone has a great 2016!

We Are SurroundedTitle


One of my goals for 2016 is for Gemstone Keeper to be on Steam Greenlight. I’ll will be sure to have an alpha build ready for play within the next few months.

Understanding ASCII Art

It’s pretty easy to see that I’ve taken the step of using ASCII art in my next game, Gemstone Keeper, and it’s pretty difficult to not notice it if you see the screenshots I’ve been posting for #IndieDevHour or Screenshot Saturday.

This writeup will explain my understanding as mainly an outsider and relative newcomer to the ASCII art and Roguelike Development scenes, and hopefully explain my reasons why I chose to move to ASCII art, and how I am approaching it to make my own style to the art form.

Continue reading

IRDC 2015 Review

So to sum up last weekend, when I went to Nottingham for the International Roguelike Developer Conference 2015’s UK event, I’m not kidding when I said I had little expectations, considering that the Roguelike genre is still fairly new to me, despite spending a year researching procedural level generation for my University dissertation. Despite this, I had a great time and was able to gain a lot from the games, the genre and the role of procedural generation from these two days.

Day Zero

Although I have met the event organiser Mark Johnson and Roguelike developer Darren Grey from the PROCJAM conference organised last year, I wasn’t sure if I was able to meet anyone at the pre-meetup, especially since Mark unfortunately went down with food poisoning before the pre-meet began. However I decided to head off to the Bell Inn and see if I could find anyone.

By chance, I went to the bar and a man sitting at the table asked me “You here for IRDC?”, that man was Johannes Kristmann, and with him was Paul Jeffries. We talked about games, had drinks, and they joked about IRDC events of the past and eventually more people showed up, including Alan Charlesworth, Tom Betts and Ido Yehieli. We all decided to have more talks and drinks at Darren’s apartment block until we all decided to head to our respective hotels to prepare for tomorrow.

Day One

These were all the talks that were given that day (taken from Mark Johnson’s blog):

1025 – “”And [my bot] vowed to return victorious!”: Spelunky as an AI Benchmark” (Tommy Thompson)
1050 – “Dungeon Crawl Stone Soup Development” (Pete Hurst)
1115 – “Alternative Death Systems” (Darren Grey)
1140 – “Generative Design” (Paul Jeffries)
1205 – “Modability and You” (DarkGod)
1330 – “Making a Roguelike that uses Twitter Data” (Sean Oxspring)
1355 – “KeeperRL Development” (Michal Brzozowski)
1420 – “The Curious Expedition Development” (Johannes Kristmann)
1445 – “Murder Puzzle – No Longer a Roguelike” (Ido Yehieli)
1510 – “Scaling Brogue“ (Flend)
1535 – “Creating a Procedural Level Editor” (Me)
1600 – “Sir, you are Being Hunted Development” (Tom Betts)
1625 – “Algorithmic Generation of Global Racial, Cultural, Religious, and Architectural Variation” (Mark Johnson)

There were so many great talks, some were really funny and others were really informative, I even managed my talk, despite all my nerves. I spoke about a part of my University dissertation, the Procedural Level Editor.

If you didn’t catch them on Twitch, all of the talks will be online on Youtube in the coming weeks. These talks were followed by curry, and then drinks at Ye Olde Trip to Jerusulem, possibly the oldest pub in England.

Day Two

This was an experimental part of the day, where members of the public got to try out some classic and modern roguelikes such as DoomRL, Angband and Incursion among others, as well as a selection of board games that possibly inspired Roguelikes.

So I had a really fun time, and got to speak to a lot of talented game developers about procedural generation and gaming in general. I got to talk about my University dissertation, and I also got to speak on roguelike radio about the conference, which should also be online soon as well.

So I think it’s time to announce my new main project, during my dissertation I wrote a short prototype game to demonstrate the procedural level editor. I’ve decided to extend this game to be Gemstone Keeper, the roguelike twin-stick shooter. It will use the Procedural Level Editor, which I will also release for public use when it comes to a stable enough point.

ThreeThingGame and the Ricoh2DFramework

Between the 11-12th of June, I went up with a friend and fellow Windows Games Ambassador Aaron Smith, along with a games design student Nathan Holding to the University of Hull for ThreeThingGame, the University’s 24 hour games jam. The premise is that each team was provided three words, and were tasked with making a game that incorporated them. The games would be judged on how well they fit the three things, and the quality of the game overall and the winning teams would get prizes.

This was going to be an interesting event for all three of us, as despite being used to travelling around several campuses for events, Hull was way far out for us. We were also aware that the majority of students there had been at ThreeThingGame before and new how it all worked. However Aaron and I were a bit more confident in what we could pull off together since we went through a games jam one week prior, where we learned to have a proper functioning version control system that the tools can work with, as well as having an actual artist working with us this time. Our three words were Room, Moon and Lune, and from that we made a Lunar Lander style space game where you avoided asteroids and landed on moon bases.

We also had an additional tool to work with, my Ricoh2DFramework. I don’t think I’ve mentioned it before on this site, but the Ricoh2DFramework is a framework for MonoGame. The purpose of the framework is to provide classes to assist with graphics, collision, input and audio among other functions. I was actually quite eager to use Ricoh2D in a game development project to see how well it works practically.

Game Development went rather well, and while there were some small issues found in the Ricoh2DFramework, they were easily fixed and all of those changes have been uploaded to the Ricoh2DFramework’s repository. There were also some performance issues that required some work arounds in order to avoid (slow downs, glitches and crashes galore), but in the end we finished the game.

What went right:

  • Proper source control: Using C# and MonoGame with Github is much better than the last games jam at Stafford, where we tried to use Unity with Git. Overall it was a nightmare back then to merge all the changes and ensure the project work. Using a system that is completely text based and readable made the process much more easier.
  • More prepared: Using the Ricoh2DFramework definitely saved some time in developing the game, and even though the framework had issues they were much quicker to deal with instead of having to build everything up from scratch.
  • Having an artist: Definitely enables the team to work on the game while assets are being created, instead of having to be made during or after development where issues can arise.

What went wrong:

  • Didn’t sleep enough: All three of us, me especially, thought we could spend the entire night working on the game. We didn’t. I could barely stay awake after literally staying awake for 24 hours, even with an abundance of food, drink and snacks to help us keep our energy.
  • Technical issues: While some performance issues were most likely due to some of the original code that was developed for the game, we also had numerous unexplained crashes from Microsoft and SharpDX libraries. This was especially bad when the game crashed unexpectedly with an unhandled exception while judges were looking at our game. This could’ve been one of the reasons why we didn’t get a place in the rankings, but since we were still using the Technical preview, hopefully issues would be ironed out afterwards.

Overall, I rather enjoyed ThreeThingGame. It’s a neat idea for a games jam and everyone at the University of Hull was very enthusiastic and eager to make games, which makes it even more impressive as the University doesn’t have a specialist games course unlike Staffordshire University.

Now it’s back to the Procedural Level Editor and my newest game project Gem Finder, where I’ve already started on new features…