I'll be giving LD41 a try - hopefully there'll be a theme I feel on board with :-). I'll be using C/SDL, uploading an entry (should I finish) to itch.io and source to GitHub.

Good luck to everyone :-)

I've just woken up, and am thinking of what I should make for the jam - and came to thinking of combining classic arcade games when I remembered some years ago writing a mash up of snake and tetris (imaginatively called snetris). Anyone interested in a brief distraction is welcome to try it ^_^.

https://www.jf89.co.uk/snetris/

The game I'm making is called "YATBBH" for "Yet Another Turn Based Bullet Hell" (as I imagine there'll be quite a few of those this Ludum Dare). I'm actually sort of hedging my bets, and have written it so that I should be able to tune it to be turn based or rhythm based, depending on how hard the puzzles turn out to be.

Here's a gif of where I'm currently at:

I do intend to add better artwork later (it will still very much be programmer art, though!)

Things achieved today: - major part of puzzle generator done (i.e. whatever's generated is guaranteed solvable) - rendering started

Tomorrow hopefully I'll be able to get some reasonable puzzles generated from this, and then handmake a couple of "tutorial" ones.

Also, code so far can be found here: https://github.com/jf89/ld41 (I've just noticed there's no license in there yet - I'll put in the GPLv2 at some point).

Hope everyone's having fun! I'm off to bed now as I'm exhausted ^_^

Here's a screen capture of the fruits of my labour: Yet Another Turn Based Bullet Hell

After making a hasty last minute windows build which didn't go as smoothly as hoped, I hope this will work without too many issues on people's machines!

I've taken part in a few LDs before, but this is certainly the result I'm happiest with. YATBBH generates bullet hell puzzles to try and work your way through. To help you get an idea of how to navigate them, you can watch YATBBH solve the puzzles for you :-).

Unfortunately, I was hoping to have some time to hand make some better levels than a generator is likely to output - alas, the Ludum Dare isn't known for being generous with time.

Perhaps I'll add to this in future, but as it stands I am satisfied this has been a good learning experience. In particular - I should probably make some template "menu" code for future projects - that was a stressful part of the jam - realising I had several menus that were basically the same and I needed to tear apart the main menu I'd just written to reuse its code for the others XD.

Hope everyone else had fun too! I look forward to playing your games ^_^

My aim in entering the competition was to learn more about game dev, and the purpose of this postmortem will be to try and make the lessons learnt explicit. My entry is available for download on itch, and the source code is available at github.

• Game: jf89.itch.io/yatbbh
• Code: github.com/jf89/ld41

There are many things one could focus to talk about in a postmortem - the number of choices made in making a game is staggering. So I want to make a number of posts, which otherwise would have been notes to myself, about the most important lessons I've learnt from this project. In this post I'll talk about the graphics.

Graphics

If you had told me I would be pleased with the graphics of my Ludum Dare entry when I started I don't think I would have believed you - I am no artist! However, after the competition, I think the graphics are perfectly acceptable. They are very basic, but are functional, have a consistent style and a consistent colour scheme. In particular, I think the conscious choice to keep to a restricted colour scheme was a very simple way to drastically increase the quality of what was produced, and something that can easily be replicated in future.

Beyond that, I encountered some issues and suggestions with the graphics which should be addressed in future. The first of these was handling edge cases. In an interactive medium like games it is inevitable that the game will produce some edge cases that were originally unaccounted for. In the case of my game, there are two edge cases which I've noticed crop up that I am unhappy with the handling of. Here is a screenshot showing both:

On the left are two overlapping bullets moving in opposite directions. Unforunately here the shape of the bullets does not work well and it is awkward to visually parse this information. On the right in this image is a gun with a timer which really just means "this gun always shoots", which could be more simply shown by having only one stage in the timer (in general, timers can have repeating patterns, which ought to be removed to simplify the player's information).

Unforeseen edge cases like this are by definition not something one can account for beforehand, however, whilst making my entry I did not pay attention to details like this at an earlier stage in development. Instead, I didn't take the time to test for things other than "does this code work", which was a mistake.

The second problem I had with the graphics was how good a job the graphics do of drawing the attention of the player to the important things happening in the game. Here is an example screenshot:

The most important thing in the game is probably the player themself, who is located in the top left here. I think that the robot is sufficiently visually distinct, so this is not a problem. However, the next most important thing the player probably ought to be aware of is the location of the goal, which in this screenshot is two squares down from the player. Unfortunately, I chose to draw the goal in a dark purple colour rather than a light purple, and the goal does not draw the eye well. In addition, a bullet may be located over the goal to further obscure it (this is not really avoidable, but is something I ought to have been aware of).

Other things in the scene of importance are the timers of each of the guns. I think these are quite visually distinct and self explanatory (I've not had anyone leave a comment saying they didn't understand when a gun would fire, or when it would rotate). However, I relied on the timers to give all information about when the guns fire, but neglected that this means there isn't a big visual cue about which guns are firing next turn. This means a common error whilst playing is to move into a square believing it is safe but find out you have overlooked a gun which was going to fire into that square next turn. This could be addressed by the guns changing colour to be brighter when they are going to fire next turn.

Finally, here is a better screenshot to demonstrate the problem of locating the most important information in the game. As it stands, the first part of the game is a mini-game of where's Waldo to locate the robot and the goal!

Finally, there are no sprite animations in the game, but this would have added a lot. Below is an example of the animations:

I think in light of how much it would add, I ought to look into learning to animate the robot (and perhaps upgrading the explosion animations from particle effects). We shall see about this in the future!

To summarise the lessons learnt for the future are:

• Use a colour scheme as an easy way of increasing graphics quality;
• Make notes on what important information the graphics need to convey;
• Try hand making animations.

I'll give this Ludum Dare a try, however my parents will be coming at around midday on Sunday so I'll have to be finished by then. I also don't intend to do any staying up late/silliness like that (I don't want to throw off my sleep pattern!). So, we'll see how it all goes. As with the last Ludum Dare, I will be using C/SDL.

Good luck to everyone, enjoy the jam!

This will be my ... not sure'th Ludum Dare, though the second one since I got an itch.io account! Unfortunately I'm in the middle of writing up a thesis right now, so won't be able to engage much with the community after the competition. So, the primary reason for this Ludum Dare is that LD is always a good opportunity to get some code written and learn something!

I'll be using C/SDL/OpenGL - and developing on Linux. I'm currently at my parents' house so only have my laptop with me - I'm going to have to borrow one of their machines for the final Windows build - but what would Ludum Dare be without a completely predictable stressful finish?

Good luck to everyone and have fun! I hope I'll be able to play some of your games!

I'm pretty exhausted after today. I got up at 6am and started right away with the jam. I like the theme, and am happy with the idea I have as being a decent game for a jam. However, executing the idea is taking quite a while... Hopefully tomorrow I'll be able to make some more progress. I think, as I did last time, I'll have to jettison sound again this time. Next Ludum Dare I'll have to make it a priority to have sounds!

One thing I decided to do this Ludum Dare was to try and create something 3D. I've been playing with OpenGL for a while now so thought I should try and push myself a little. Anyway, it certainly made things harder! I think I spent at least an hour or two just getting the matrices correct in the camera code.

Here's a screenshot of what there is so far. It's currently weighing in at 2,000 lines of code (source here for anyone interested)- which is about the entire size of my last Ludum Dare entry!

Phew, it's been a fair effort but I've made my entry for this Ludum Dare! Sadly, however, I won't be able to play other people's Ludum Dare entries much as tomorrow I have to go back to thesis writing (this has been a very welcome distraction).

This has been a great opportunity for me to check my understanding of some important things - in particular this is the first project I've made using OpenGL which doesn't link with a loader/wrangler library but just loads its own functions. It's very satisfying to have removed another dependency from my project creation method! On that note, I had a little more time than I first anticipated and I added sound - and SDL_mixer has, as expected, added many dependencies which I will aim to get rid of in future. Writing my own sound mixer is a definite todo on my list now...

I hope you've all had fun - and I'd be very grateful to anyone who'll play/rate what I've done (especially as it's unlikely I'll have time to return the favour!)

Ludum Dare Entry Page

Download the game

Source code