As some of you were made aware, I took part in my first games jam of the year. While I said in my End of 2018 In Review that I’d be taking a break from game jams, Ludum Dare felt like the ideal event to take part in as it was in late April and is still one of the biggest and favourite of the online game jams. Even then I wasn’t fully aware it was happening until the week before when theme voting was about to begin, and it happened to be on the weekend where I had no urgent plans. So as the days drew nearer, I made my preperations for a 48-hour game dev session.
It seems that because of how the internet and societies have changed so drastically, years now seem to feel like they’ve multiplied. I doubt anyone could really summarise what happened this year, as there appeared to be a lot of fighting back and forth. Outside of game development, I have had to deal with friends moving further away, my mascot costume being stolen as well as my grandmother needing serious treatment that has put a lot of us in the family on edge, and that’s not including all that’s going on in the UK and the news of some of the great people in the world we lost such as Isao Takahata, Ursula K. Le Guin, Totalbiscuit, Stan Lee, Fred Patten and many others.
But this is about progress and achievements, so let’s send of 2018 right!
My main New Years Resolution this year was to do one game jam per month, as I felt I wasn’t doing enough over a year. For all the challenges, I managed to succeed and get twelve games done this year. Few didn’t go as well as I hoped but most I feel were rather successful!
Doing this definitely felt worth while, as it lead me to create a whole new engine as well as update my 3D graphics system. In the end however, I do feel a bit burnt out from game jams, which is partially why soon after Ludum Dare 44 I decided not to do much. I might hold off on doing any more because as you’ll find later on in the post I have other reasons too.
The P Word
I think its safe to say that politics has gotten stronger and divisive now more than ever, it might be hard to believe considering my Twitter feed but I would consider myself mostly centre-left but not very openly vocal about political issues. Most of this changed in 2016 with Brexit and the US, and while I will still insist on being centre-left on many principles, I don’t think I should be quiet about issues such as our relationships with other countries, the treatment of people regardless of identity and funding to the public sector.
As such it’s great to see and contribute in any small ways to organisations such as Game Workers Unite and Games4EU. I first spotted leaflets for GWU at GDC, around the time when crunch and unions were hot button topics within games development. I tried to keep up to date with their progress and shared what they did, and imagine the response we had when GWU UK became an official union! I hope to keep supporting them and I look forward to seeing how they will progress.
Games4EU was set up to act as a voice for game developers who wish to remain in the EU, and largely support a people’s vote. I actually got to join them for the first ever protest march I participated in my life, walking alongside 700,000 people. It was a great experience and the support was overwhelming. I wish I could be hopeful and think that all this political mess would be sorted in the new year, but I’m not gonna stop.
I didn’t realise this until I checked my New Years post from last year, but I had a second new years resolution: to get into console games development. I also mentioned how I tried to get in touch with Nintendo but was not successful, so imagine my surprise in October when a representitive from Nintendo of Europe got in touch with me. I think it’s safe for me to confirm that I’m now a registered Nintendo Switch developer, and so now in 2019 I want to focus most of my game development efforts on getting SFML (and by extension, Vigilante) working on the Switch. Currently I’ve had to upgrade my workstation to get ready for it, and at some point I’ll get a proper dev kit to work with. It’s an aspiration to any game developer to work on a game for a major platform, and so while I imagine my tasks will be tough, I’ll get through!
The year of 2018 is drawing to a close, and so for December what other game jam I should take part in but the 44th Ludum Dare. I decided to take part in the compo as once again I managed to have a free weekend to work on it.
Before the compo commenced, I used my previous experience with game jams including the 11 previous ones I took part in this year to write a set of rules I think other aspiring game devs should follow when they work. Other devs seem to like them so I figured I’d use these rules to go over how I made my Ludum Dare 44 entry, Tank Gauntlet.
These won’t be in the order I originally set them for the sake of describing the progress.
Know your Tools
I already had my tools in mind before the theme was announced, I used my Piskell for animated sprites, Photoshop for any bigger assets, BFXR for SFX and cgMusic with LMMS for music. A lot of which I have used before, but for audio, I feel as though I need to find more other ways to create the SFX I need without the use of a sound library, and maybe diversify my music creativity (I used Megadrive Emulation Soundfonts so there was a bit of a 16 bit vibe to the music).,
Small Scope and Stick Mostly with What You Know
I’ve usually been pessimistic the themes for Ludum Dare, as you are given the opportunity to vote on them in multiple rounds but the themes I like the most do not tend to get chosen. Therefore, when the theme was announced to be “Sacrifices must be made”, it wasn’t one that I was entirely keen on, and the only idea I had jotted down was “diet simulator”. While that idea was doable, it wasn’t really that original and a simulator might have been a more laborious task. I slept on it and figured I’d do a tank combat game. To fit the theme and my “1 unique/main, 2 optional mechanics” approach, the unique mechanic would be sacrificing gameplay input for power/speed, with the two optional mechanics being shooting and melee attacks.
The first thing I did Saturday morning was work on the main game, by setting up a simple tilemap and a rectangle sprite for the player. Then I made sure the player could move, jump and collide with the tilemap, and the player could wrap in all directions.
Oh, a basic tip on how to handle platform jumps: Do math. Don’t bother guessing the right values for acceleration and jump velocity until you get it right, set up some variables and apply some vector maths, the below code will be enough to work out how high and how fast you want to jump, as well as how fast you want the player to move horizontally:
float Height = -85.0f; //Maximum Height of the Jump in Pixels float Distance = 80.0f; //Distance travelled in Pixels float Time = 0.5f; //Total Time of Jump float MoveSpeed = Distance / Time; //Speed in order to travel the set distance in the set time Player->MaxVelocity = sf::Vector2f(MoveSpeed, -2 * ((2 * Height) / Time)); Player->Acceleration.y = (-2 * Height) / (Time * Time); Player->Drag.x = Player->MaxVelocity.x * 10;
If you want to extend it further, I’d recommend watching this GDC Talk on Game Maths Programming:
After using the code I have written previously for bullets, tweaking it to my liking, and adding enemy rectangles that can spawn periodically and move at different speed and be of different sides. I had most of what I needed.
I also added knife melee attacks and enemy damage before I worked on the menu that would handle input sacrifice.
Make Your Content Easy and Noticeable
For the last Ludum Dare, I made a racoon sprite that had a full running animation and was heavily detailed to the best of my ability, along with a tilemap and background to resemble a temple, and it took five hours. In the end, the environment didn’t look all that great and the racoon sprite was so small that you couldn’t see the detail.
This time around, I decided I wanted something simpler and easy to resemble, a tank. I loosely based the design on the StarFox Landmaster. With it being a tank, there didn’t need to be many frames.
I decided to keep the sprites and tilemap monochrome, using shading and tones with around 20 shades of grey in total so I could randomize the tint to add some variety to it. The enemies were kept red, as it’s an easy way to convey them as dangerous.
I found using fonts a bit more frustrating than normal, SFML doesn’t use the nearest neighbour for fonts so on a game with a low resolution (Tank Gauntlet uses 320×180), it’s difficult to use a font that isn’t too big and wouldn’t get blurry if the font size wasn’t set to a specific factor, if I found a way to implement bitmap fonts I might not have this much of an issue.
621 and Take a Walk
On both Saturday and Sunday, I walked into the town centre to get food and other things to relax my mind and not stress over the game too much. I also tried to get some good sleep, so I didn’t stay up too late and got up at around 8-9am on each day, oh and I took showers.
Find a Friend
One of the comments I got from this rule is that it doesn’t have to apply to team-based projects, having a friend to look over the game or provide feedback is beneficial to a solo project. As such, I’d like to thank my friend Kris for putting up with me sending him screenshots and asking about ways to make the game feel better and if I’m making the game too cruel or not.
I hope you find this simple process interesting, after doing 12 game jams this year I’m kind of happy this one felt mostly streamlined. There were some issues like with audio, not to mention technical issues post-submission, but I hope people find the final product enjoyable.
I was going to include a final statement for 2018 as a year in review here, but with the length of this one I’m going to have to add it as an additional post. Happy New Year everyone!
Don’t worry to anyone who has been following what I’ve been doing this year, I haven’t missed October or November. I’m so close to finishing this goal of mine for 2018 and my next post will include not only that month’s jam entry but a summary of what I have done over the year. But for now, more jam games.
In October, I took part in 7DFPS, as the name implies the jam is focused around games in the first person shooter genre. The jam itself is probably best known for being the source of the wildly successful indie title SUPERHOT, where the prototype was created for the jam back in 2014. I decided to take part in this jam to see if I can add to the 3D game system I developed in September’s game jam.
One issue I had when working on this system was that I didn’t have a fully working software frustum culling system, this would allow me to avoid draw calls on 3D objects that were not in view of the camera. What you see above was the issue I had before. It took a number of trial and errors and reading on how to properly set up and transform the plans before I had it properly culling the right objects. I also added some other mechanics I need to make this a classic FPS, jumping while taking into consideration multiple floors and shooting projectiles.
As you can see from the projectiles, some of them were clipping unusally. This is a side effect of rendering textured objects in OpenGL with alpha transparency, any objects that are drawn after transparent objects will have the scene’s pixel data overwritten. The solution to this is to sort your 3D objects, first by making sure he fully opaque objects are in front, and transparent objects by their distance from the camera (aka depth/transparency sorting).
Then came the big additions, I used most of the same code from Fursuit Run for the enemies so they had the same 2.5D effect, but changed around the movement code and added the ability for them to shoot as well.
For the game’s hook, I wanted to have a mechanic based on Ikaruga, where only opposing colours hurt you and the enemy. As such I had to give the player and each enemy two batch renderers, one for each colour, to share one bullet group, as well as a flag for their current colour. Then I made sure the game checked what the colour of the bullets, players and enemies were during each collision to make sure that only opposing colours set damage.
Then it came round to the presentation, I decided to make the level much bigger (no easy task considering the original protoype used hard coded map sizes), changed the textures and added bloom so the game’s visuals had a neon aesthetic.
In the last few hours, I struggled to find how to give the game a proper goal for single players. As I was getting tired, I decided just to have an orb that the player must find to collect. The gun in the middle was the last touch, which also helped made distinguishing the player’s colours easier.
I managed to fix a few bugs later on, although I think I’ve done most that I can with this. Although one change that I don’t think will get finished but was cool was I managed to get multiple cameras working for one scene, which makes split-screen gameplay possible! So for making a number of improvements to my engine’s 3D capabilities, I call this a win. You can play RvB here on itch.io.
For November, I took part in the Desert Bus Game Jam, which started last Friday (9th November) and I managed to finish on Thursday (14th November). This jam is done in conjunction with Desert Bus For Hope, a charity video game stream to raise money for Child’s Play. The theme for each DB jam is around the desert bus, which itself is based on a notorious unreleased game of the same name.
I decided after two 3D games to make it slightly easy on myself while being experimental, so for my Desert Bus Game, you would see two perspectives, one to dodge stuff on the road and the other to keep your bus balanced.
Unfortunately, as of writing I do not have a proper physics system in Vigilante, so I made do with the standard collision system. The rear-view had a bus that leaned in the direction by changing the origin of rotation to the bottom corners. One low-level thing I did do for this game was to update the VSprite from using SFML’s sprite object to VertexArrays. This would allow me to adjust each vertex on the fly, instead of being restricted to a single square. It also allowed me to freely change the texture coordinates so I could do the endlessly scrolling roads, as well as skewing them. I hoped I would be able to get proper perspective to work, but even vertex arrays have their limits when it comes to skewed sprites.
You can play Bus on the Desert here.
One month to go!
For the month of September, I needed to take part in a game jam, but initially, I wasn’t sure which one. I looked through all the jams listed on indiegamejams.com and while you are spoilt for choice, not many were catching my eye. That was until one of my friends from the Birmingham Indie Developers, Kirsty Fraser, mentioned a game jam she was organising.
RainbowJam is a two-week games jam about exploring LGBT+ themes, running for its third year it’s partnered with the non-profit organization Queerly Represents Me and encourages representation and to “create games exploring and celebrating identity, gender, sexuality, sex, life, and love!” After working on Re(re4ti0n, I’ve felt a little urge to create some more experimental games that go against what I generally like, which would be arcade retro shooters/platformers with a neon glow or a retro aesthetic. I also knew I had some 3D functionality in Vigilante that deserve to be worked on enough for a complete game, so I spent a few weeks earlier in September to create a basic 3D game system.
Unfortunately, my 3D stuff was limited to what you can render. I consider Vigilante a 2D game framework with 3D elements, so I didn’t bother implementing 3D collision detection, but I had an idea: what if I make the game function in 2D space, but display in 3D space.
What I did was set up a small 2D enviroment with a tilemap and a basic sprite, and I set up the 3D models to display the scene based on the tilemap while the camera’s position and rotation is based on the sprite’s position and angle.
As you can see, I got the tilemape to display really well, the floor being a multi-segmented plane that could display mutliple different tiles in one model, and the walls being cubes that are scaled depending on where their neighbours are. Initially I was creating each cube as a separate model, which I felt was dangerously innefficient so I created a batch rendering group, creating one model but using multiple V3DObject instances to specifiy where that model should be rendered. I did need other things in the game though, stuff that the player can interact with, so I created a special model that could render a 2D sprite (including 2D animated sprites!) in a 3D enviroment, always facing the camera.
The last major thing I wanted was to add an additional level, as wondering a single room is good but extremely limited. As such I made a second tilemap, a model to represent a ramp of sorts and added variables and additional groups to tell what floor the player is on, and as such what should be displayed/collided with. The bigger challenge was implementing how the player will climb up stairs, as it also had to factor falling. Combining gravity with the player moving upwards if the sprite is overlapping the area where the said slope is situated took a lot of trial and error before I finally got a dituation where the player could fully explore the floor above and walk back down to the ground floor!
After making the slope look a bit more like steps, the demo was pretty much ready for RainbowJam.
To make a game for Rainbow Jam, I wanted to make a game that is about sharing love and making people happy. I went with a game about being a fursuiter because as a furry, I know the community is very supportive of LGBTQ+ people and as someone who’s performed in fursuits at conventions and meets, I feel the most important aspect is to make anyone you see feel happy, entertained and loved, even if it’s by portraying a character.
Making the attendees you interact with was probably the biggest challenge, I made a dough body sprite with frames for actions at each angle, and made the object switch frames based on what angle it’s facing from the player. As for the AI I considered setting up a finate-state machine, but fearing it would be too much work for a jam I went for a simple state model. I got my code for line of sight and path finding from previous projects in order to get the attendees to walk around the floors they are on, wave at the player when they see them and either hug or prepare a camera for a photo, responding to what the player does at the same time.
To simulate the limited vision of fursuits was to overlay the screen with a mask. I added a little bobbing while walking for fun, as seen in the tweet below, however a fellow gamedev suggested getting the camera to bob in time as well, which ended up working pretty effectively!
All the graphics and audio was done on the last day, I used the dough sprite as a base while I apply the colour and details over it. I unfortunately realised the limitation I set myself using a 20×20 tile size, but I think there is enough space to see who is who. As for the enviroments I used some references for hotels, such as the carpet and ceilings. There is a chandelier on the ground floor, which I designed myself to be multiple 2D images rotated because I found most 3D models online to be needlessly complex.
At around 11pm on Sunday, I uploaded Fursuit Run to Itch.io making this the game for September. There is still a voting period which begins when the jam officially ends on the 6th October. So far the reception has been fairly positive, mostly from furries, some non-furries don’t appear to like the idea without actually playing the game as of writing. I’m pretty happy with how the game turned out, as well as the 3D system. There is definitely room for improvement, as there isn’t much optimization that could be done such as view frustum culling. I’m hoping to get it improve for my next games jam, 7DFPS.
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 itch.io 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.
I hope things are going well with all those who read this, whether it be while hard at work or relaxing while browsing their social media. Since GDC 2018 happened, it took a while to adjust me back to a work routine. It didn’t help that the week after I returned to the UK I was off to Bristol celebrating a four-day weekend with friends and family for my birthday. Fortunately, with my day job going on, I have managed to recover from jetlag and get back into a coding routine with some bumpy roads. I figured it’d be good to detail what went on up to now.
The Games Jam for March was the Seven Day Roguelike (or 7DRL for short). This is a long-running one-week games jam dedicated to the roguelike genre. This year was the first year they hosted the jam on itch.io, instead of the Roguetemple forums and other hosting services that had since gone defunct.
The first time I took part in 7DRL was in 2016 with Dungeon Racer, while I was glad to get a game done using my engine for the first time since Gemstone Keeper’s early demos, in hindsight the concept was a bit too out of reach for me without preparation. This time I decided to do a bit more of a simple roguelike.
RDDL (pronounced Riddle) was originally going to be a dungeon based roguelike in the style of the Crystal Maze, where the player would have to find a key in each room to progress. Health would decrease over time and the only way to regain health was to either find it through treasure or defeat enemies. I used the GenLevelTools like I did previously, however, I noticed how lacking some of the features are (particularly with tilemap generation).
I ended up using the tile mapping system for this, which worked well with the tilesets made for Dwarf Fortress. I had considered adding the ability to change tilesets like I did previously with Dungeon Racer but I ran out of time. I also got to take advantage of GL-Transitions again with a cool grid flipping transition, people on the roguelikes Discord liked it so I took full advantage of it.
Overall it’s great to get a proper working roguelike, especially one that people would undisputely call a roguelike unlike my previous games. As of writing, voting has just ended on all entries, so you can check out how well it did on itch.io. Feel free to check out all the other entries too!
Speaking of previous games…
Gemstone Keeper: One Year On
As March 31st of this year is the one-year anniversary of the release of Gemstone Keeper on Steam, I figured it was a good idea on Twitter to talk about how it’s done and what I should learn from it. You can check out the start of the thread below.
I was inspired by Eniko of Kitsune Games to do this, after a tweet she posted on how stressful being an indie developer was. I feel it’s necessary to let people know that despite the success stories, a lot of stories aren’t as impressive. I still maintain that Gemstone Keeper’s response was positive, considering the circumstances, and I still appreciate the support and feedback people give.
So on Thursday 5th April, I was reading an article on my main game development and home desktop machine when suddenly I got a Blue Screen of Death. I initially thought this was typical, at least until the machine restarted and would go to a blank screen. I tried restarting again and the same blank screen appeared. I checked the bios and the hard drive looked fine, but the same blank screen.
Then after taking out all other drives, I tried again and this time it says that there are no bootable drives found… this doesn’t sound good. After a few diagnostics and checking the hardware with the help of some friends, we’ve come to the conclusion that while the hard drive is fine, something happened when the BSOD hit that caused the Windows OS to come corrupted.
The good news is that nothing has been lost. All of my game development work as well as personal files and other, less relevent, projects have all been backed up on either external HDs or online cloud services (meaning that after my last major technical mishap over three years ago, I’ve definitely learned from my mistakes). Not to mention that while I cannot boot into Windows, I am still able to access the HDD using a bootable Linux drive, so anything on it is still salvageable.
As a result of this incident, it’s been decided that it’ll be better to upgrade components of the desktop instead of trying to repair it. The current HDD is a little over six years old, so even if I managed to fix Windows then who knows when the drive completely dies. Plus with more modern components, I can take advantages of any addition performance of say, an SSD for the OS and a HDD for data as opposed to a HDD for everything else.
Hope that clears up everything. Just like to make two short announcements, I’ve began on a new project, development will continue once the upgrades have been finished sometime this week. The next games jam I’ll take part in for April will be Ludum Dare 41.
Enjoy April folks!