Note: this is a cross post from http://williamhart.info/ludum-dare-32-postmortem-colour-rocket/

Game Jamming for LD32

A couple of weekends ago I participated in my first Ludum Dare, “an unconventional weapon”. My game was called Colour Rocket and the concept was an “infinite runner” inspired asteroid dodger, where you aim was to guide a rocket to an enemy planet through flying asteroids, and use it to return colour to a darkened universe.

At about 5pm on the final day of Ludum Dare, I decided I’d had enough. I put down my keyboard and picked up my baby daughter for a cuddle. She has since forgiven me for ignoring her for the best part of a day. This left me with a fully functional, complete but very minimal game with only three levels. I’m pretty happy that I was able to get that far.

Toolset
I picked a fairly standard free toolset early on:

– Unity to make the game,
– Blender for artwork, and
– Sunvox for music

What worked

Music

With the exception of one or two minor volume issues, I’m pretty happy with the music I made. There is a different song for each menu screen or level, and although they aren’t going to win any prizes, given its the first time I’ve tried to make music I don’t think the songs are too horrendous.

Artwork

The artwork was very basic low poly stuff and I quite like the look of the black and white planets before colour is returned to the universe. Its very basic as a few comments have noted, but yeah “programmer art”.

Controller

I tried something a bit different with the player controller. The player’s rocket is always at `(0,0,0)`, and the asteroids move around the player. I can’t really say I have a logical reason for doing it this way other than it meant I didn’t have to think about the camera or moving cleanup/spawn regions. In the end I think this worked ok.

What didn’t work

There were a couple of areas where the game clearly fell short. Although its promising to think that most of these would have been easily solved if I’d spent more time on them! In no particular order…
Obstacles

My method for slinging asteroids towards the player was to spawn a whole lot at the back of the screen. However this lead to disconcerting “pop in” in the background as asteroids were recycled. As the asteroids were rigid bodies with collisions, it also meant that the target planet effectively carved a tunnel in to the asteroid field that would sometimes let the player travel through the whole level without touching the controls… oops!

I fixed the pop in issue by running a coroutine to gradually scale asteroids up from 0 to 1 as they were spawned in, but the difficulty and asteroid placement proved to be a bit more difficult. I tried adding some pre-existing asteroids which improved things a bit, but I think if I’d had more time I should have:

• created some more larger static obstacles,
• created more asteroid spawn points to the sides, shooting asteroids across the player’s path
• had the target planets move around instead of sitting still

 

User Feedback and UI

Many of the comments so far have been along the lines of “the controls stopped working”. At first I thought this was a weird bug I hadn’t seen, then I realised that it was probably related to one of the game mechanics I’d implemented.

So that players can’t just mash the controls non-stop, the rocket has a limited amount of fuel. The idea was to make the player chose between getting hit by an asteroid and running out of fuel by moving too much. (Move around too much and you lose the ability to manoeuvre).

On realising that players were thinking of a game mechanic as a big, my first reaction was in truth a bit defensive…

well, it mentions fuel on the first screen and there is a fuel bar on the GUI, so it should be obvious, right? RIGHT?!?!?!!?!”.

Then I realised that the comments were actually letting me know that the game mechanic was a bit too obscure. To be “intuitive”, every important player action in the game needs to have visual or audio feedback.

It wasn’t enough to hope the player read three paragraphs of text, or noticed a small fuel bar in one corner of the screen – I needed flashing text, colour or sounds to notify the user they were about to run afoul of a crucial game mechanic.

This is even more important in something like Ludum Dare where players may only spend a minute or two with your game.

 

 

What I learned

To summarise, there were two main lessons for me from this Ludum Dare entry:

1. Don’t get defensive about feedback – listen to what the players are saying, and try to work out why they are saying it.
2. Audio and visual cues are critical for communicating game mechanics.

I enjoyed the weekend a lot, and I’ve been playing and enjoying some of the other entries. Bring on the next Ludum Dare!

Tags: post mortem postmortem

I’m in… usually I use Unity/C# but I’ve been thinking it would be interesting to try making a web based game using react.js (depending on the theme of course!)

If I go down this path I will be using a react template – https://github.com/will-hart/ludum_react_boilerplate. I’ve also been working on a simple commodity market library which I may use, again depending on theme https://github.com/will-hart/commodity

Tags: ld34

I’ve finished the basic game play. You all the dials and switches working. I’m off to bed now but tomorrow I’ll be working on some victory conditions, sound effects and a bit more polish.

P.S. thats a GIF above, click it to see the switches… err… switch

Button Simulator in action

Play the game here

The Concept

I had the idea for Button Simulator, my LD34 entry, while watching a crappy science fiction movie. The characters sat at their space ship consoles, flicking switches and pressing buttons. There was something strangely entertaining about the experience – the link between human and machine – a sense of power, and a satisfaction in being able to control the world around you with just a flick of your fingers. I suppose its also the same little itch that DCS A-10 and its hard-core simulator siblings scratch, or this mission control desk (https://www.youtube.com/watch?v=j6zseFi070E). But how to translate a switch flicking simulation into something that was fun to play and could be completed in a weekend?

I suppose I completed the process back to front – instead of using the theme to generate a game idea, I used the theme to flavour the game idea I already had! In the final days leading up to the theme announcement I took the 20 final themes and wrote a short paragraph – a “hook” – for as many themes as I could that set out how my game idea would fit into each theme. My hook for the “growing” theme was:

    "Last year's crop wasn't that great,
 and unfortunately we had to let Freddy go...
 ...from altitude.
 Don't let the crop die"
 

This turned out to be pretty close to the final intro text. Even if my approach was back to front it meant that although I wasn’t ecstatic about the themes that were announced, at least I had something ready to go.

Making the game

My last Ludum Dare entry was probably the worst thing I have ever publicly released. I wasn’t happy with it at all, and I think it was because I didn’t have a solid concept in mind before I started, and as such was a bit all over the place. This time I decided to do a lot more planning and so I spent the morning of the first day jotting down some thoughts and scribbling out the UI. My idea was that there was a relatively old fashioned computer terminal that controlled the growth of a crop. You had to flick switches and turn dials to manage light, food and water, and keep the crop growing.

I had decided ahead of time to make the game using React.js and Redux. I’ve played around with web interfaces using these technologies, but I was curious to apply the Redux/Flux methodology to a game. (If you aren’t aware of React/Flux then its worth reading up on, if nothing else as another way to approach application design) As it turned out React was very well suited to the type of game I made and I felt it helped me develop very rapidly and relatively bug free. Hot reloading (i.e. when you save the source the changes get immediately injected into the browser) is a massive productivity increase, particularly when playing around with styles and layout.

I could probably have made more use of ES6 and javascript features, in particular a lot of my game logic could have been simplified using a few calls to Array.reduce(), and I should probably have used selectors for some of my UI code, however overall I’m happy with the way the code base turned out. Would I use React again for another LD entry? Depending on the type of game, yes I probably would.

I used Inkscape for the graphics and Audacity to make the sounds. The sounds effects were all bundled in a single file and I used Howler.js to treat them as a sound sprite. I think the buttons have a really nice tactile feel to them, and at least some of you agree.

How it was received

Most comments have been positive, although time will tell what people have actually rated the game!

I did wonder a bit about the difficulty level. As I made it and am aware of the logic, I can win quite easily. However for other players (although its not meant to be an easy game) a lot of the comments have been that its a bit confusing and challenging. I did put in some help tucked away in one corner which explains a lot of the mechanics (and one of the game screenshots shows the help screen), but many players didn’t seem to find the option.

I’m a bit torn about this feedback – the “plot” of the game is that you have no idea what you are doing, so providing any sort of help is kind of breaking that premise. At the same time the game is meant to be fun. I think in future I’ll make the help button a bit more prominent.

What now?

I’m thinking of making the game into a sort of multiplayer party game that I can play with my mates. This could probably be done in React using RethinkDB and websockets, however in this case I think I’ll do it in Unity as I want to try out Forge Networking. I do want to bring a lot of the React/Flux mentality to the C# version though, where appropriate, particularly the idea of a single global state – although I think I’ll discard some of the immutability Flux favours for its state.

Play the game here

I’m probably in for this weekend, but actually I’ll be setting myself a challenge for a warm up activity just in case. I want to come up with (at least) 80 game ideas in a week, 1 for each theme that is voted on. I’m hoping this will get my creative juices flowing and give me some practice for thinking of new game ideas!

Does anybody else do this or something similar before LDs?

Tags: LD36

Like a lot of people, things are currently a little hectic at home following several weeks locked inside with some bored kids. I'm hoping to find the time (sanity? energy?) to participate in this LD after a few years off. Also, as an unexpected bonus of lockdown, I won't be losing the traditional 1/4 of the compo to a work day! :star:

Depending on the theme I'm planning to base the game off this open source multiplayer card game framework I've been working on https://github.com/will-hart/jou

I'm making a card game (1-4 players in theory) based on keeping a group of gladiators alive in the arena long enough to earn their freedom. Its fairly ambitions so I'm about 50/50 chance of making it for the compo. So far I've created all the action, fighter and creature cards I'll need (about 70 cards in total). There is a lot of placeholder artwork which probably won't get fixed. Some example cards (need to fix the blurred icons EDIT- fixed):

Objective tomorrow - implement the rules system and do some play testing :fingerscrossed:, but first time for some rest!

I'm aiming to do the compo, although mostly it ends up in me being way too ambitious and ending the weekend a little embarrassed by what I've produced :grimacing:

I'm planning to use bevy engine, which is a new (i.e. quite unstable) game engine written in Rust I've been playing around with for the past week or so.