About oatsbarley (twitter: @oatsbarley)

I'm very new at Ludum Dare, although I've known about it for quite some time now. I've been coding for the past five or six years, mostly non-gaming stuff though. Let's see how this goes!


Ludum Dare 32
Ludum Dare 31
Ludum Dare 30
Ludum Dare 29
Ludum Dare 26
Ludum Dare 21

oatsbarley's Trophies

oatsbarley's Archive

Getting there, eventually…

Posted by (twitter: @oatsbarley)
Sunday, August 24th, 2014 9:35 am


My idea was very ambitious for 48 hours. I’ll be lucky if I get it all done!

The Gathering now has a Windows build!

Posted by (twitter: @oatsbarley)
Thursday, May 1st, 2014 7:16 am

5 Good Games Without Many Votes

Posted by (twitter: @oatsbarley)
Wednesday, April 30th, 2014 1:09 am

I’ve played 75 games so far, quite a few of which have been pretty good. A handful of the really good ones haven’t had very many votes, and so here’s 5 good games that I think need more people playing them. Click the images or the titles to go to their game page!

Deep Blue Home

Diving Simulator 2015



An Ode to Violence

Lost Sheep

And if you’ve got the time, here’s my game:

The Gathering

I made a wallpaper using footage of my entry, The Gathering!

Posted by (twitter: @oatsbarley)
Tuesday, April 29th, 2014 6:38 am

The Gathering: A Quick Postmortem

Posted by (twitter: @oatsbarley)
Monday, April 28th, 2014 3:05 pm


For this LD I decided I should try out something new, and boy did I ever. The Gathering was designed as a 2D puzzle/town-planning minigame, and ended up being a 3D low-poly, resource-management town-builder with a semi-realistic day/night cycle and atmospheric fog/haze/hues that change as the day goes on.

I thought I’d go through the things I think helped me get through this competition, and what I’d do differently next time.

What went right

  • Day 1 was gameplay, day 2 was art & tweaking – this meant that I had a fully-working game that I could play with for all of day two. I wasn’t worrying about game-breaking bugs or missing features while I was modelling or playing around with balance.
  • I went with what I know – While I did use the opportunity to branch out a little (into 3D games/art) I used C# in Unity, which I’ve been working with almost daily for the past year and a half. It meant I knew straight away how to get a lot of the game off the ground, and any tricky bits weren’t compounded by having to learn a new engine/language.
  • I tried something new – I spend every day working on games, and a lot of it is the same stuff over and over, so I thought I’d use the opportunity to try something different. I’ve never done a 3D game before, and having a 48 hour deadline focused what could have been a really daunting task. I was forced to go low-poly because of the time limit, and this meant I could try/fail fast and then learn a lot of 3D techniques. If I was doing this in my spare time I’d probably still be working on that first model, trying to get it just right.

What went not right

  • I didn’t think about first impressions – everybody who I’ve shown the game to has cooed at the graphics, and then said “so what do I do?” There’s no hint system or back-story ingame, and so as a stand-alone game my entry fails pretty hard when it comes to user-friendliness. If I could, I’d make a more intuitive UI, or introduce the game a little before it starts.
  • Not enough juice – Juice is super important. I’ve seen gorgeous-looking games that fall flat, and pretty ugly games that win everybody over, purely because of the amount of juice in them. Things like easing, bounces, sound effects, etc. could have made my game a lot more engaging. Always plan for adding juice.
  • No real forward planning – I had no idea I was doing a 3D game until about 2 hours into planning my game idea. So all of the 3D stuff I had to learn as I went. A little bit of forward planning would have saved me a ton of time and headaches.

Overall, I’m really happy with how this competition went for me. I spent a solid 16 hours each day working, and got something done that I’m proud of. I hope I can do the next Ludum Dare; I’m excited to see what I can come up with next!

You can check out my game, The Gathering, here, if you’d like to play it. I’d appreciate any votes!

Nearly there!

Posted by (twitter: @oatsbarley)
Sunday, April 27th, 2014 11:03 am

ld29_3Not too long left now, but most of my game is done! Woooooooo..

First GIF!

Posted by (twitter: @oatsbarley)
Saturday, April 26th, 2014 5:30 am


It’s all placeholder art at the moment. Not gonna talk about the main point of the game until I’ve got some more stuff working!


(Making this in Unity)

100 COOLNESS GET! Now look at these 7 games, they are good.

Posted by (twitter: @oatsbarley)
Tuesday, May 7th, 2013 4:52 am

I finally managed to play and rate 100 of the entries for LD26. I’d planned to do 500 in 21 days, but I think a better target is 200 if I’m going to give them all a chance.

Anyway, here are 7 games that I really like from Ludum Dare 26:

Lunar Rain by LeafThief


Mind the Gap by shiprib


You Must Escape by GertJohnny


Weapons of Minimal Destruction by bluescrn


Dock Zone by Farfin


Sky Tea by OysterKLAN


Moonshine by TravisChen


If you don’t mind, I don’t have nearly as many votes as I could have. I’d love it if you’d check out my game:

crush. by oatsbarley (me)


On to the next 100!

crush. Post-mortem

Posted by (twitter: @oatsbarley)
Monday, April 29th, 2013 1:43 am

Phew! That went a heck of a lot better than the last LD I took part in, but it was still a lot of work. I got it all finished within a few hours of the deadline — except for an uncooperative timelapse video — so overall it was definitely less stressful. I thought I’d write up a post-mortem for the process. Hopefully somebody else will find it useful or interesting but, at the very least, it’ll help me get stuff straight in my head.

What happened

I live in England, so I found out about the theme around 6 or 7 hours after it was revealed. I wasn’t particularly inspired by it so I did what I’m guessing almost everybody else did and looked at the Wikipedia article for “minimalism.” After about half an hour of looking around, I decided to focus more on minimalist music than art, since I never really understand art and I’d end up just copying an art style and not thinking about the game.  Minimalism in music is about building up really simple phrases so that they make something, which led me to the idea of building up the player’s obstacles over time. At first they’d be really easy, but then as more of them started appearing at once it’d get harder and harder.

A wall was an obvious obstacle and putting gaps in the wall was an obvious way to overcome the obstacle, so that didn’t take much to come up with. There had to be some way for the obstacles to appear, and I couldn’t really control it very well if I had the player moving through a level at their own pace, so I made the level just an arena the size of the screen and had the obstacles approach the player instead of the other way round. The lose condition was another obvious one: if you get caught in between two walls, you lose.

And that was that! It took about 5 minutes after I’d finished reading up on minimalism for me to come up with the idea (due in no small part to how simple (minimalist!) they were), which meant I was about 35-40 minutes into my time and I’d already come up with the mechanics. I took a quick break to get breakfast and then came back and made a mock-up in photoshop of what the game was going to look like.

It looked sort of like this, except not broken. This is actually a very early screenshot.

I made some quick assets from my mock-up and started coding the game. I used AS3 and Flixel and I didn’t really have any issues with either of them. I only used Flixel initially because the Flashpunk website was down, but I didn’t miss it too much when I really got into coding. Once I’d got the mechanics down it was about midday and I was about 4 hours in. I took a lunch break and then decided to work on some music (I used Ableton Live and the Nexus2 VST); obviously the idea was to have the music be in a minimalist style, so I stuck with a single instrument and a droning bassline with a melody plinking away over the top.

When I tried the music out with the game to see how it fit in, I accidentally lined up the timings of the first few walls with the beat of the music. It had a really nice effect, so I worked on syncing up the entire game with the music and it instantly felt a lot more atmospheric. At this point it was about 5PM and I’d been working on difficult stuff for most of the day, so since I felt as if I had a lot of time to spare I spent the rest of the night polishing aspects of the movement and the graphics. I’d been having a lot of trouble with collisions for a few hours, and it turned out that I’d just forgot to call super.update() when I overrode it, so I kicked myself for the rest of the night.

A shot from the final game. It actually gets kind of zen-like when the pace picks up and you have to be in the zone otherwise it gets a bit stressful.

The second day was polish day! I added nice colour schemes, coded a background fader that faded between colours, cut the music up into instrument tracks and made a rudimentary tracker which looped instruments at the right times (and halved the filesize of the game), spent 3 hours fixing the wall-generation algorithm, then made a win/lose screen, a title/instruction screen (with nifty little keyboard keys that light up when you press the actual keyboard keys) and set them up to fade between each other. Half-way through the day I’d come up with the name “Minima,” and I’m sure I don’t need to explain where it came from, but after a few hours I was getting sick of it and just ran through the tags on colourlovers.com palettes for inspiration. “Crush” came up and it fit perfectly. At first I was searching for another word to pair with it, but I remembered the theme and just went with a one word title. I added the full-stop after the title because it’s final; when you get crushed, it’s the end. It’s very gimmicky but I think it looks nice.

I tried to make the title screen as minimal as possible. Originally it just said “SPACE” underneath the title, but my playtesters (thanks mam and dad!) thought it was part of the title and weren’t sure how to get to the next screen.

After all of that was done, I was pretty much finished. There were some eleventh-hour bugs to fix, but they went away with some hackish fixes, and then I was done. I compiled a SWF, hastily made an AIR installer just in case anybody wanted it, uploaded the background music (the track I’d been using before I cut it up to use with the tracker) to soundcloud, committed the code to a github repo, filled in the submission page and… then sat for about an hour trying to get my timelapse video to render. At one point I restarted my PC, forgetting that I still had the submission page filled out, and had to retype and relink everything. Eventually I gave up on the timelapse and just submitted everything else. Ludum Dare 26 accomplished!

What went right

Okay, so here are the things that I’m glad I did and that I think contributed to me being happy with the end result:

  • I didn’t stay up for the theme announcement – if I had, it would have been 2AM for me and then I probably wouldn’t have gotten to sleep for worrying about ideas. I would have woken up later, been more tired, and I probably wouldn’t have had a good start to the first day.
  • I focused on the mechanics first – every time I caught myself doing something that wasn’t mechanics-related in the first few hours, I quit it instantly and got back to coding the core game. It meant that I had the actual “game” done by midday on the first day, and left a day and a half for making it a good game.
  • I came up with a really simple idea – my typical game ideas are overly ambitious, so I’m proud of myself for come up with something appropriate for the time-scale. The could have come up with something more complicated and barely got it done in 48 hours, but being able to get the game done in 3-4 hours and then having the rest of the time for polish meant that I was actually happy with the end result and not just pleased that I’d done something.
  • I didn’t tweak until near the end – so I wasn’t fiddling with optimisations or better sounds or neater graphics or neater mechanics until I’d got the core game (with music and graphics) done. This meant I didn’t get lost in the details without actually making any progress.
  • Got some second opinions – I had people try my game out, and they found some big bugs that I had never seen before, and also threw up some UI/UX issues that I’d thought were complete non-issues. There’s a world of difference between the game before playtesting and the game afterwards, and it was all new stuff.

There were lots more little things that went right, but those were the main things that really had a big impact.

What I wish I’d done, or not done (and will, or won’t, be doing next time)

And here are the main things that didn’t go so well:

  • I didn’t have any version control – I did have a backup though, since my stuff was on Google Drive. What a lack of version control meant for me was that when I made a big change to the code and then decided I didn’t like it, I had to rewrite it the old way based on memory, and it almost never worked out right.
  • I wasn’t totally familiar with the libary I was using – this didn’t turn out to be a huge problem, but it did mean that the majority of my time spent coding involved reading through the Flixel documentation. It’s similar to Flashpunk (which I know really well) but just minutely different enough to cause a lot of hidden problems when I assume something works a certain way and it doesn’t. If I could do it again I’d get some practice in with Flixel in the couple of days before the compo.

I think that’s actually all that went wrong. It went surprisingly smoothly, which is great! I would maybe do a stream next time, although it would make me very self-conscious which could really affect my productivity. I could see myself pandering to whatever audience I had instead of getting work done, so… maybe not.

So that’s another LD down. I’m going to be free from university life when the next one comes around, and hopefully I’ll be making progress as a full-time indie developer, so I’ll definitely take part in LD27. Now I need to grab some breakfast and start playing everybody else’s games. There’s no way I’m getting 1700 done in 3 weeks, so I think my target is going to be 500+ so that I can give each of them a fair amount of time.

Good luck in the voting, everybody!

OKAY, day two.

Posted by (twitter: @oatsbarley)
Sunday, April 28th, 2013 1:49 am

At the moment my game is pretty much just avoid the bars that come across the screen. It gradually builds up over time with them coming from different directions and more often. I sort of got it fitting with the music, although it does go out of sync after a couple minutes so I’ll need to figure that out.

My plan for today:

* More colours!
* Cut the music up into tracks and play them over each other dynamically! (hopefully this will make the filesize smaller, too)
* Make the obstacles a bit fairer, since sometimes it’s literally impossible to beat.
* Title screen!
* Maybe another piece of music with a different tempo/rhythm? Just to mix things up a bit if you replay it.

Hmm, sort of a lot to do, but I think I can do it! Good luck to every one else, too.

Thought I should post a screenshot!

Posted by (twitter: @oatsbarley)
Saturday, April 27th, 2013 3:34 am



Here’s a link to the submission page!

It’s the morning after (technically it’s the same morning, but my feeble little mind can’t handle that) and I managed to get my submission in with 40 minutes until the official deadline to go. Ignoring any sort of evaluation of what I did right or wrong and how good my game is, I’m feeling a huge sense of accomplishment just from getting something done within the timeframe set for me.

How it all went down

So I started the competition 7 hours after the theme was revealed and had no idea what I was going to do with it. I’d been playing around with some platformer mechanics the night before and sort of had a handle on how something like that should work, so I decided to make it a platformer. Even though I really didn’t know which direction I was going in, I decided that there needed to be something to escape from and, because I’m super original, that ended up being a rising water-level. So I made some little square sprites and tiles and coded some basic platformer mechanics. This is what it looked like at that point:

Now, the aim of the game was to escape the water for long enough to reach the exit, or at least not drown before you got to the exit. The issue I’d come across with that was that once you were in the water you couldn’t get out, which meant that as soon as the water caught up you were swimming and that (with the level design ideas I had in mind) this wasn’t going to be very fun. You’d just end up coasting along, lazily avoiding a platform or two, then reach the exit. The platformer mechanics were also awful. The character would often get caught in the side of platforms or just not jump at all when he was supposed to. I gave up on work for the day and left any improvements for Day 2.

So along came the second day. My issues consisted of bad platformer mechanics and a boring main mechanic. I decided that, to completely avoid these problems instead of solving them, I would change the aim of the game.

I completely embraced the idea of floating along on the surface of the water and made this the entire point of the game. You wouldn’t be able to jump anymore, so the platformer mechanics went out of the window, and you would instead wait for a moment until you were picked up by the water. At this point you’d avoid some more closely-packed obstacles on your way to the exit. The water would move faster, so that it was a challenge to avoid the platforms and to catch up with it if you were pushed underwater. I hastily coded this up (or at least a horribly buggy version) and put together some quick graphics (literally, five minutes worth) and ended up with something a bit like this:

The character was now “Stubbs”, a little block of something like sponge (or something else that floats until it’s filled with water) with stubby little legs that meant he couldn’t jump. This was much more interesting to play and I was actually pretty happy with it. At this point I was starting to feel the deadline looming over me and got pretty worried about how I was going to make this interesting to play. I decided that, instead of making a lot of varied and handcoded levels, I was going to do some lazy procedural generation. In other words, I created some level sections, then made the game stitch them together in some random order. This worked pretty well and if I’d had more level sections I’m sure it would have been pretty interesting.

As time was short, I hastily created some (annoying) music and got to fixing the bugs. Oh, the bugs.

I spent at least 3 hours trying to get the levels to load, then the levels to display properly, then the levels to scroll, then the levels to not scroll when the player was at the bottom or top, then the water to scroll, then have it not scroll, etc. etc. etc. I ended up completely scrapping the code for scrolling and rewriting it just so that I could get my head around what I was doing. Eventually it worked. I packaged everything up and submitted it all. I was finally done.

What I should have done

I should have planned it out a little bit better. I really had no idea what I was doing other than that I wanted it to be a platformer. This really came back to bite me when I changed my idea on the second day and practically had to recode half of the game. Planning would have meant that I could have spent the first day coding everything and the second day bug-fixing and making the assets. As it was, the assets were an afterthought and bug-fixing was something I had to do as I was coding (which lasted until the final hour), otherwise I wouldn’t have had time.

I should have documented more of my code. I tried to document some of it, but I got lazy or I thought, “I’ll just get this mechanic quickly coded and test it out”. I’d then find a bug which would distract me from my initial code and by the time I came back to it it looked incomprehensible and I ended up leaving it as it was instead of spending a good while deciphering it. If I’d documented, half of my bug-fixing issues would have been a lot simpler because I’d not have had to go through, line-by-line, figuring out what everything meant. Heck, I probably wasted more time scrolling through classes looking for a particular piece of code, that would have been obvious had I documented it, than I would have in just adding a few comments here and there.

I should have just gotten to work instead of procrastinating. I’m actually not sure I want to beat myself up over this, because I’m amazed that I got the game finished at all. That said, if I had spent more time coding and less time watching TV or talking to people, it would have been a lot less of a rush when it got towards the deadline.

What I’d do if I spent more time on this

  • More levels
  • More varied tilesets
  • Main character animations
  • Tweak the speeds of the main character and the water so that it’s not as punishing
  • Spend more time on the level design so that I’m sure it’s possible to get through them all
  • Sound effects more movement, drowning, underwater effects on the music, maybe?
  • A proper title screen as well as proper win/lose screens with art and not just text
  • Better music. I think the music I have at the moment is too slow compared to the speed of the water
I’m feeling a huge sense of accomplishment from finishing this and I’m really glad that I decided to try it out and actually made it to the end. I’d like it if people liked my game, but I don’t expect to win any categories with it. That’s not really the point though, this was all about finishing a game in 48 hours for me and I’ve done that. I’m definitely going to enter Ludum Dare 22 and I might even enter some of the mini-LDs in the meantime.
Now excuse me while I go and play some of the amazing games from this LD, and thank you for taking the time to read this.

Mechanics are done!

Posted by (twitter: @oatsbarley)
Sunday, August 21st, 2011 10:20 am

Now to get onto some quick SFX, then music. After that I’ll decide between making some levels myself or coding in some procedural generation for them.

Oh, and I might have to do something about the title screen if I have time…


Posted by (twitter: @oatsbarley)
Sunday, August 21st, 2011 9:16 am

Changed my mind!

Posted by (twitter: @oatsbarley)
Sunday, August 21st, 2011 8:54 am

So at first I wanted to just make a game where you run away from water, but that’s been done so many times that I felt it was kind of cheating to use it for my entry. So now the idea is that you’re stuck in a dungeon that’s slowly filling with water and there’s an exit somewhere higher up that you have to get to.

But wait, isn’t that the same idea? Well, it would be if you didn’t have stubby little legs and could actually make it to those platforms. The only solution is to ride the wave to the top of the chamber, avoiding what would have been handy platforms but are now annoying obstacles, then swim down to the exit once you’re pushed under the water by the ceiling.

All I have left to do is code in some buoyancy and I’m done with the mechanics, then I can move on to putting in some levels (or, if I have enough time, adding some procedural generation for the levels) and adding some SFX/Music.

Wish me luck!


Posted by (twitter: @oatsbarley)
Saturday, August 20th, 2011 6:45 am

Healthy wraps, get me ;D

I only started coding about 3 and a half hours ago, but I’ve managed to get basic platformer mechanics working so far. I’ll post screenshots as soon as I have something interesting.

[cache: storing page]