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.
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!
The game jam for August was Ludum Dare 42, so with it coming to a close, I thought it’d be good to talk about how the submission [Closing in on Pascal](https://ldjam.com/events/ludum-dare/42/closing-in-on-pascal) came about and what I learned from it.
Ludum Dare 42 was particularly exciting for me, as it was the first LD in a long time that I had a completely free weekend. As such, I decided to plan the first day entirely for gameplay, with graphics and audio on the second day. That way I get a solid game and then plenty of time to work on making it look and sound nice, you’ll find out why that plan isn’t flawless as it sounds.
When it came to the theme, I was already very pessimistic that it would be a theme I’d be happy with, it’s been a common trend for people to vote on the theme that no one wants. I even voted against the theme “Running Out of Space” but when it turns out to be the chosen one, I thought it was pretty good.
The concept of running out of space I had was inspired by the cartoon trap of the walls closing in on someone in a temple. I figured a game where the player has to reach an exit before the room crushes them to death.
Fortunately, I have a bit of experience with platformers in my game engine from a previous jam, so the tilemap, jump physics and mechanics such as wall jumping I have previously implemented.
The jump animations itself was done because I remembered the indie platformer INK having good squash & stretch. To achieve it I modify the scale so that it squashes inwards when going up and stretches outward. If I had more abilities to adjust the individual vertices I could do more fun aspects of moving like skewing.
Since my idea was inspired by a temple film/TV trope, I already had the visual theme in my mind. I also thought it would be good if I had a little cartoon character who’d look like Indiana Jones. It was fun working with pixel art and animation once again, but if I was to do this again I would have done a much simpler approach. The player character is way too small for the game screen, meaning that its animations are pretty much useless. I also had a bit of issue with making the colours stand out so it doesn’t feel all yellow and brown.
In the end, it took around 3 – 4 hours to work on the background environments and 5 hours to work on the player sprite and all the obstacles. If I went with a much simpler design or scrapped the temple theming and used the simple colours and shapes it would have been much clearer and easier to look at.
The sound and music was achieved with LMMS and BFXR. I like making NES-like chiptune in there but I do notice it’s restrictive in areas like tones and tempo, so I couldn’t get the sounds I want. It also didn’t help that thanks to the graphics, I had much less time to work on sound and music so it ended up rushed.
The post-jam has most of what I would have added or done better if I had time. Particle effects, using directional keys as well as the WASD buttons, and a better title logo. I would have also worked on more levels but seeing how many levels players are willing to go through, then maybe the existing levels should have been improved slightly.
I’m a little worried about what the rankings will be for this one, I’m definitely glad I could take part but I feel as though I wasted too much time on the graphics when a simpler approach would have been effective. You can go check out [Closing in on Pascal](https://ldjam.com/events/ludum-dare/42/closing-in-on-pascal).
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!
I was meaning to post this sooner, but along with work piling up and losing track, I did quite a few game jams. Three in particular: RemakeJam, Jamchester and Ludum Dare.
I’ll mention Running The Marathon first, because I only finished the game two days ago from posting. This was made for Ludum Dare 39, which makes it the 10th Ludum Dare I participated (and 9th I submitted a game independently). This was a bit of a last minute entry because until Saturday evening, I had no intention of making something for LD. What changed my mind was a game idea I was coming up with as a joke, running a marathon and making sure you don’t run out of energy. What I ended up with was a bit of a joke on the Track & Field concept, by having rapid button presses make your chances at success worse. Because of how little time I worked on this, the background animations and sounds are lacking, although I do think the running animation on the player turned out okay.
As is the tradition of Ludum Dare, voting will be going on by all participants for a total of three weeks. Any Ludum Dare entrants can go to the game’s Ludum Dare event page to vote and comment.
Next I’ll talk about Dash Dodge, which was developed for Jamchester 2017, a professional games jam that I took part in last year. This year, I was in a team which consisted of another programmer & sound designer (Jessica Winters) and two artists (Li Huang and Andrea Maestri). All in all, this was a great team to work with, and we had a heavily planned out game about combatting bosses using only dashing, with a time travel element, although we may have over-anticipated our goals a bit. Needless to say, we made a game with a nice visual style and some neat mechanics thrown around. Hopefully at some point in the future I would like to work with these three again at some point.
Finally, there is 8-Bit Theater: Black Mage is in a Shooting Game. This game, developed for RemakeJam, is a remake of a previous game of mine. In particular, this is a remake of the first game I ever made from back in 2010. What was great about working on this is that I still have the original source project and most of the original assets and notes, although I did have to dig through Google for a copy of GameMaker 8.1 in order to view the original project. Sadly because of lack of time (I rarely allow full days of focus for these game jams, I’ve noticed), I just about managed to remake the original two levels and boss. This wasn’t for naught though, as way back when it took me over a year to reach this far, and this time I managed to achieve the same amount in less than a week. I also took advantage of my own game framework to try out some technical challenges, such as parallax scrolling.
Game Jams are fun, I like taking part in them for those short bursts of game ideas and development challenges. Sadly participating is made more difficult when my day-job takes priority, but when I get a chance to take part I’d like to take full reigns!
Now time for some voting and other challenges!
Last weekend was Ludum Dare 38, not only is it the 38th main game, as well as the 8th or 10th one I’ve taken part in (whether or not you take into account failed attempts), but it also marks the 15 Year Anniversary of the competition/jam as a whole! Not only is it celebrated with another jam, but with a brand new website. For now you can still access the old website, but game submissions are currently being handled entirely on the new site.
The theme this time around was Small World, so I (like a lot of devs) made a game either around a small game world or a tiny planet. I went with the latter and drew up a run ‘n gun shooter on a little planet.
Sadly I had plans with my friends on Saturday so I didn’t start work on the game until around 8PM GMT, so development felt more rushed than a full games jam but I managed to make what I set out to design: littlePLANETblast
Similar to my past Ludum Dare projects, I used HaxeFlixel. It’s straightforward to use, multiplatform (Flash, HTML, Windows and Android maybe…) and it’s still being maintained so there have been several improvements. I’ve provided the game’s source code on Github so feel free to have a look to see how the game works.
The first problem I had to solve to make this game work is how to make a sprite orbit a planet. HaxeFlixel has a FlxVector object for vector math, so using that with a sprite’s acceleration meant having the sprite fall towards the centre of a circular planet was pretty easy, but how do you get the sprite to stop on the planet’s surface?
HaxeFlixel has no circular collision, only rectangtle collision. When I wrote my own C++ framework for Gemstone Keeper, which took inspirations from HaxeFlixel, I included Circular collision by giving each object a Radius property and writing my own circle overlap and separation functions. This would have been too much work for the time I had, so I wrote a hack method for a derived sprite class that always checked and updated the distance between a sprite’s centre and the planet’s centre, and if the distance was less than both the planet’s radius and sprite’s radius combined, then the game pushes the sprite up to the edge of the planet. This circle collision method is only applied between a sprite and the planet, and since rectangles don’t rotate then all sprites had to be perfect squares.
Bullets were one of the only sprites that weren’t built to orbit the planet, instead simply moving in an angle that combines the firing direction with the player’s current angle. I’ve had some feedback that said that the bullets should also be affected by gravity. I decided against it because it would make enemies on the planet easier to hit, while enemies in the sky would be harder to aim, not to mention the game loses a strategy element because of where bullets travel.
I went with three base enemy types: Rockets, Spikes and Robots.
Robots functions no differently from the player, except that it moves in a fix direction and smaller ones bounce by constantly jumping. Spikes has the same orbiting system, but it’s planet radius is much smaller to allow it to go into the planet. I use FlxTween and the FlxTimer to allow the spikes to move in sequence. Rockets simply spawn outside the screen at an angle and move towards the centre of the planet. If a rocket touches the planet then it would be destroyed, resulting in an instant game over.
I also added an escape object, which changes the planets side and makes the level a little bit more harder. This was for variety, so you wouldn’t have to stay on the same planet. If I had a bit more time I would have included more animations on the planet itself.
Speaking of the planet, that was one of the first objects I applied polished graphics to. To give it a more detailed pattern, I used the built in Cellular Automata function, and applied the pixels to the circle. Since it uses a random seed, the pattern is different on each playthrough.
The planet’s destruction is a particle effect that uses the planet sprite’s texture, a technique I used a lot in Gemstone Keeper. However one gripe was that I had to make a derived FlxEmitter class that could allow me to set how many frames I wanted based on the particle’s frame size.
Along with proper sprites, smoke was added to the spikes so that the game can provide a one second warning before spikes hit. I also added a distance check to avoid some unfair spike deaths. Finally I added a second camera mode incase the first one wasn’t interesting enough. The follow camera simply rotates with the player so they can stay in one spot while all the other objects rotated around. It did mean having to create a new Camera for UI elements, since objects can only be parallax scrolled by position.
The last elements I added were the title screen and audio. Sound effects were produced with BFXR and music with Abundent-Music’s Procedural Music Generator. Audio is one of my weakest skills so these procedural tools made that quick and simple, although I probably wouldn’t enter myself into the audio category for them.
I figured I add a smaller version of the planet in the title screen and have the player sprite on a bigger world to give a vague sense of a setting, with emphasis that the player is fighting on tiny planets and not just a giant on a regular sized planet.
And that’s basically how I made littleBLASTplanet. If I had more time I probably would have created more enemies and made proper transitions between planets. Aside from that I’m pretty happy with the results, particularly hacking the physics to getting jumping and moving around a 2D planet to be possible.
Voting for the game begins on
Wednesday Friday, so if you took part in Ludum Dare, please check it out!
It has now been one full week of 2017, and a lot of people (including myself) have slowly gotten back to work. Since Gemstone Keeper has been getting close to release, I’ve started work as soon as we can to get stuff done.
Before I get into Gemstone Keeper, I worked on a little game for Ludum Dare 37 where the player is stuck in a porta-loo balancing in the air. That game was Danger: Mondays, and after two weeks of voting the results are in. The results for this Ludum Dare were definitely beyond my expectations. While the amount of submissions for the compo were smaller compared to past years (901 compared to 1117 at LD35), that doesn’t devalue the fact that Danger: Mondays achieved a rank just a few places shy of Top 25 in the Humour category of all categories.
Reading all the comments, I was glad people found the concept amusing, but I’m completely grateful at the how well I did this time around. Thank you to everyone who voted during the day. Apologies for not posting about Ludum Dare any sooner, but I was working on a bigger game.
To be a bit more descriptive, Boss Rush will have the player beating all five bosses as fast as possible, they are able to set the stats and weapons of their explorer before hand and they regain some of their health after defeating each boss.
Score mode allows the player to go through the caverns, and like the daily run mode, will try and get the highest score possible by collecting as many gemstones and materials as they can on a single run. This time however, the player is free to set the seed they want, which will effect all aspects of the game from the levels, player stats, which weapon they have and which items they’ll have at the start.
One of the benefits of working on these game modes (from a developer’s perspective) is that we go through all the main game modes again to not only ensure they work through both the main game mode and these smaller game modes, but to find any bugs or issues that was missed out the first few times.
Another update we’ve done is on the gemstones themselves, namely how they are rendered. Originally, the Gemstone Geometry was generated using a Gemstone Mesh Generator that was developed at PROCJAM, and then rendered using a custom software approach using SFML (you can read a comprehensive write up of this on my websites in part 1 and part 2). However, over the last week of December, it was decided that it was time to update this for performance and to improve quality by changing the rendering process to an OpenGL Hardware render approach.
Below you can see the difference, on the left is the software approach, and the right is the new hardware approach:
This weekend I’ve been playing around with post-process effects, as it would be nice to have some visual effects that would appear through the entire game, although it would be possible for the player to disable certain effects if that want to. To pull this off, the framework now has a multipass post processing system where it’s possible to disable certain effects.
This allows us to apply multiple post process effects at once, and allows us to add the options we need to allow players to enable/disable certain ones.
This is only a small sample of what is being planned, leading up to Gemstone Keeper’s release on March 31st 2017. I’ll also be attending London Gaming & Anime Con in early February and GDC in San Francisco later in the month, however the latter will just be as an attendee.
Here’s to 2017 being a successful year for many people!