Our LD31 entry is “BIRDS!”. You can play it here:
BIRDS! is a tranquil, light game where you can annoy or scare a gathering of birds. You can lightly disturb the birds, force them to move around, or if you’re not careful, scare them away entirely. The game starts in “Chill” mode, and is open-ended. You can switch on the power, and enter “Shock” mode where you must protect the birds from electrical surges before too many birds get fried.
Loi LeMix – Artist
Rex Soriano – Programming
Barry Rowe – Programming
Our team was made up of three active members of @GameDevLouKY (http://gamedevlou.org). Loi and myself have been working together since Ludum Dare 30 where we first collaborated on Sneaky Nessie. Rex joined our team for the Jam.
I’ve been working in Java with libGDX for game development for a little over a year, so we went with it as our framework. I felt I could get up and running most quickly with it, and Rex was comfortable picking it up along the way. We used IntelliJ for our IDE, Git (hosted on Bitbucket) for source control. Loi used the usual artist’s sorcery for visuals (Photoshop/Illustrator).
We worked the entire Jam at the Game Dev Lou “real-world gathering” working alongside at least 7 other teams. (See all of the GameDevLou games here: http://gamedevlou.org/?p=876)
Taken during our Sunday night Demos
When the theme was revealed we were pretty stunned that Unicode Snowman didn’t win, and it took us a little time to get out of the winter/snowman mindset. We did eventually break through that, and came up with several ideas. Without describing the concepts in detail, here is a quick list of some of the ideas we had, in no particular order, before settling on “Birds on a Line.” Imagine what you will:
Reverse Tower Defense
Screen is the Weapon
Click Escape from the Room
Build your Own Platformer
Longest Lasting Snowman
Direct a Play Perfectly
DJ Please the Crowd
Survive in a Bubble
Reverse Katamari Maze
Mind Controlled Goldfish
Birds on a Line
Of these, our top three were Reverse Tower Defense (RTD), Mind Controlled Goldfish (MCG), and Birds on a Line. (I really liked longest lasting snowman, and had some funny ideas for it, but as a team we decided it wasn’t likely to turn out fun). After some internal discussion, we actually discarded “Birds on a Line” and started a pros/cons list between RTD and MCG. Loi worked up a few sketches to get us visualizing the game, to see which we might LOOK more fun.
Top Left: “Mind Controlled Goldfish”, Bottom Left: “Reverse Tower Defense”, Right: “Birds on a Line”
When we looked at this, we all agreed the Reverse Tower Defense (which had morphed into more of a overwhelm the giant boss) concept looked the most fun. Plus while we had some really funny ideas for MCG, we were afraid of some of the mechanics being annoying/frustrating rather than challenging. So we had decided on RTD.
We began clearing up all of the mechanics and effects we had individually been designing. The game sounded really fun: waves of upgraded minions that would get smashed, throwing cats to distract the boss, and simple controls. Then we realized how many different animations, sounds, and GUI elements we were going to need. To make the game we wanted, it was too much for the Jam time frame (We were limiting ourselves to the COMPO time frame so that groups could present their games Sunday night). We were pretty bummed, but that’s why we brainstormed right?
After giving MCG another round of redesign, we settled on switching to “Birds on a Line.” Our final reasoning, which I still stand 100% behind, came down to these factors:
- A simple mechanic is much easier to make FEEL good than complex interactions (Doing simple well > doing complex poorly)
- A simple environment gives us much more room to JUICE the game without being too busy (JUICE is NOT equal to “All the Features!”)
- Our concept felt like it gained more from the theme than it lost (the constraints work in its favor)
- We were all comfortable with how we might approach the unknown/difficult aspects of this game (this is super important for a Jam game)
- The game still contained challenges for all team members (Jams should teach you something)
Our process was simple:
1. Discuss the next feature(s) to build
2. Divide the programming tasks
3. Decide what art assets were needed next
4. Integrate current art iterations into working features
5. Discuss what is working, what isn’t
An unintentional part of our process (as was the case with Sneaky Nessie) is Loi not actually getting a chance to play the game until we stop Jamming. This occurs because of the development tools we use for programming offer no value to Loi so he never has a running copy of the game until we’re finished. We don’t do this on purpose, it just happens. It may help or it may hurt . We love the way things have turned out visually, so it didn’t hurt for this game. We plan to change this part of the process in the future.
What Went Well
The Art. Number one. Plain and simple. The Art makes this game. Loi nailed it. We are very proud of the way this game looks. The birds look awesome, the environment looks sleek, and the background transitions/movements add to the scene without too much distraction.
Loi’s main canvas for towards the end
Keeping it simple. We were able to stick to our simple mechanics. We focused an entire day and a half on just making it feel good interacting with the birds. Rex and I caught ourselves just sitting there messing with the birds for long periods of time when we would be testing a new feature well after confirming it worked. Keeping the game simple also let us quickly add environment enhancements towards the end to make the game feel better.
Collaboration. Our team came together really well. Rex and I were able to easily split programming tasks and never really stepped over one another. Loi was able to produce more assets than we could actually add into the game. Not only was our team collaboration great, but having other teams working in the same open space was a great experience. It’s really nice to be able to take a break and see what others are doing, discuss a feature with someone who hasn’t been staring at the thing for hours, and just generally interact with other developers while building a game.
A silly, late-night comment to make things clear
Mood. So far, it seems our main goal to make a chill, relaxing experience translates to other people. Those that have played it have all seemed to enjoy that aspect, and we were pretty worried we’d get a lot of “i don’t get it”, or “is this really a game?” kind of responses. We’re glad to see at least some people enjoy the experience.
What Didn’t Go Well
Ending the Game. We really didn’t have a good way to “end” the game. In fact, the Shock mode for the longest time was more of an annoyance (due to the sound) than a way to lose the game. Sunday night, we introduced the concept of only being able to lose X birds before all of the remaining birds fly away. In theory we thought this was a good end to the game. However, once we added this in, we found ourselves being more frustrated with the game rather than relaxed, and enjoying it. This is the version we demoed to the other groups, and we felt it didn’t really demo well this way either. So Monday we switched the game back to starting in Chill mode. We introduced the transformer box to turn on Shock mode for players that weren’t looking for a chill, goalless experience. While this seems to work a lot better, we ended up with some bugs in the Shock mode. (sometimes not all the birds scatter away. Also you have to flip the switch to reset the mode.)
Web Version. Using libGDX is great because we write the core game once, and can deploy to all platforms. Unfortunately, the worst performing platform is usually the Web version, which also happens to be the most accessible. I believe we just have some poor object management that I hope we can iron out in a post-jam version. If you feel like checking out the game, I suggest downloading the desktop version, or at least restarting your browser if you want to play the web version.
Some Math. Rex really pulled through sorting out some of the math that I wasn’t ready to tackle. This game didn’t require overly complicated math, but I had gotten used to leaning on some built-in utilities to libGDX that weren’t quite what we needed for this instance (or at least we didn’t apply them correctly if they were fit to solve our problems). There were also several features we wanted to add that were going to be heavy in calculations that we weren’t used to. This kept us from completing them. I really wish I had pushed myself to properly implement a “sphere of influence” around each bird so that you could start a chain reaction if you scared the right bird(s).
Sleeping. This one is just myself, as Loi and Rex intelligently rested up appropriately. I will be sleeping more for the next Jam.
We plan to release this as a mobile game. The game is touch ready. We’d like to polish up a few things, sort out the “ending the game” bugs, and add in a few more features that didn’t make the cut (even out the landing of the birds so they don’t clump, add some more ambient touches to the BG, and maybe that bird influence radius).
We also plan to create a version without the shocks as a Live Wallpaper for Android devices. This idea was mentioned to us by the guys of TwoScoopGames during the Jam, and it just so happens libGDX supports Live Wallpapers.
More Games! We’ll all be making more games, and participating in future Ludum Dare Jams.
Loi: “I was comfortable with the silhouette art style, but I initially questioned myself on how to make monochromatic silhouettes look lively. I overcame that challenge by adding a dark purple-black gradient and placing it over most of the foreground artwork. This promoted subtle contrasts throughout the level. Since we were only working with one screen, I wanted the level to look like an interactive canvas. This was achieved by animating items like the clouds, trees and a cycled day-night background; making it seem like birds aren’t the only living elements in the level. And humor, I love humor! Fortunately, I had the opportunity to once again “moon” the players.”
Barry: “I was fully comfortable working with libGDX, but I was nervous about teaching it as we went along. When you teach something is when you really find out if you understand what you’re doing, and I was afraid I did not understand as well as I hoped. Luckily collaborating with Rex was smooth, and he picked up the language and tools quickly. I think what helped us the most is that all three of us had a similar vision for the game, and felt comfortable putting forth design ideas, as well as explaining why we didn’t think an idea would work.”
Thanks for reading, Thanks for playing,