I’m in for the Compo. Using Unity as a platform. Blender for modelling. Photoshop for art. My own usfxr for audio. Publishing for the web. I have a few gameplay ideas I want to explore; hopefully some of them fits the theme!
Are you looking for a simple, easy way to create original sound effects for your Unity games with procedural audio synthesis?
As a preparation for the next Ludum Dare, I have finished adding all advanced sound synthesis features first introduced by BFXR to usfxr, my own port of the SFXR game audio synthesis engine for Unity. The new version is 1.2 and is available as a zip download on the GitHub usfxr repository (the asset store version will be updated later this week).
At first, I wasn’t so sure I’d like to add those features; I have to confess I always saw BFXR as a rogue fork of SFXR, and the fact that parameter strings were incompatible between the two projects always irked me the wrong way. However, after testing BFXR for a while, I came to really like its original features, and saw them as a very positive thing to have.
The new features are as such (as described by BFXR’s interface):
On top of that, this new version is still compatible with the previous version; instead of starting anew and breaking compatibility, usfxr accepts both standard (SFXR/as3sfxr style) parameter strings, as well as BFXR parameter strings. This means old code will still work, but you can also copy & paste effect parameter strings directly between usfxr and BFXR.
There are a few additional BFXR properties that I will have to add support for in the future, specifically property locking (for mutation). This is not a core part of the synthesis engine, however, so it’s not part of this update.
Now that Escape Enclosures Expeditiously is finished, and I even had time to do a post-Ludum Dare version, I figured I’d post its post-mortem on the LD website! Granted, this is a cross-post from my own blog, but probably interesting for the audience here.
Escape Enclosures Expeditiously (or Escape Drill in the improved, post-Ludum Dare version) is a simple puzzle-like isometric game where the player should to the exit of each map without being touched by one of the enemies.
It’s a short game – only 3 levels (plus an ending level). Here’s a video of a full playthrough with no deaths.
But of course, this being a post-mortem, what follows is some more information about the game development process.
I started development without much of an idea of what I wanted to create. My initial approach – which is fast becoming my common approach for Ludum Dare compos – is to just try something different for the sake of learning, rather than actually trying to create a full fledged game. This means that my emphasis is normally on the technical side of things – as long as it’s new to me – rather than on the fun. It sounds harsh, but that’s what makes it fun to me.
This time around, I had my mind set on using Unity to create a custom level editor to make game creation easier. I was inspired by several different things: Hitman Go, a surprisingly simple but ingenious twist on the Hitman series; isometric turn-based games to the likes of Final Fantasy Tactics, Tactics Ogre and Disgaea; and a series of tutorials of someone recreating Doom’s classic E1M1 level on Unity using a plugin of some sort, something that showed me how powerful custom editors can be in Unity.
My goal, however, was not really to create a game in itself, but to learn how to extend Unity in a way that allowed that kind of map to be created more easily. I ended up with enough time to actually create some gameplay, but it’s almost a side effect.
What went right
Using Unity: in a previous Ludum Dare post mortem I mentioned Unity as one of the sore spots of my experience (although it doubles as one of the pros too). This time around, it shows exclusively as a positive point. I was able to leverage my past experience with the platform (as little of it as I have), work on top of what I learned (and side projects as usfxr) and basically spend more time implementing things rather than learning how to implement them.
That’s not to say there was not much to learn. Quite the opposite. At any point in development, I had dozens of browser tabs open with the most random items from Unity’s references or random tutorials, blog posts, and questions/answers pages out there.
What’s more, my conclusion is that Unity is pretty powerful when creating custom editors and elements. I can see how the ability to customize your working environment can be a big boost for developers working on a game, especially on members dealing with content creation such as level design. Even if my level design solution was pretty ghetto (I had the worst method for painting tiles with different terrain types, for example), it was still a pretty important time saver.
I still feel a little weird with the platform. Its emphasis on what I can only describe as concrete elements, such as adding scripts to physical objects and using the 3d view for everything, is still what feels strange to me. That, and maybe the emphasis on global access to everything from everything and a lot of helper functions to query the level elements. However, I believe I’m slowly learning to ignore my impulse for abstractionism and just get stuff done as inelegant as I might think it is. My hope is that with time I’ll understand what’s the actual ethos of the platform for performance and correctness, but I know I’m still far from that point.
Using simple assets: this time I purposely used very simple assets. The only texture used in the game was a 256×256 noise texture quickly created in Photoshop, and all the 3d models were simple boxes spliced and reshaped into basic shapes using Blender. I get very easily distracted into doing mundane tasks such as making sure none of my vertices are duplicated and everything invisible has a proper name or something of the sort, so I’m happy I managed to not spend too much time doing complicated art. I only had to deal with broken normals twice!
Now, what went wrong? Nothing, I think. This was fun, and I learned a lot. Given more time for level design and testing, I’m sure I could come up with more, and better puzzles. But that’s true of every Ludum Dare, so that’s something I can live with.
You can play Escape Enclosures Expeditiously on the web. The improved, post-Ludum Dare version is also available online. And as a test of the respective website APIs, I’ve uploaded a version to Kongregate (with high-scores) and to Newgrounds (not supporting medals or scoreboards yet; I’m currently implementing that as an exercise for future LDs).
I suppose Ludum Dare is about to start, so before the site crashes, it’s probably better for me to make my first post for this edition!
This time around my focus will be learning – I’m going to use Unity, which is not something I’ve used a lot, and probably some of my Unity code like usfxr for dynamic audio generation and some of the shaders and code I wrote for dynamic generation of flat-shaded meshes with fake occlusion. I’ll probably create some kind of tile-based, isometric kind of game, but I’ll wait until I know the theme so I can decide for sure.
Good luck to all!
Available for free on the GDC Vault. This is an incredible (and sadly missed) magazine. I recommend any aspiring, hobbyist, or independent game developer peruse through this archive. Many insightful articles for all fields related to game development.
I previously wrote about how you should subscribe to this magazine. Alas, the magazine is now gone, but you can read everything in PDF form.
Hijack Humans Hastily was my compo entry for Ludum Dare #27 under the theme “10 seconds”. It was a game developed in pure ActionScript 3 (using Adobe AIR), with the OUYA as its main target but with a web version available (given the platform). Here’s a short gameplay video:
Here’s the mandatory post-mortem, with a few development snapshots scattered around the article.
What went right
Reusing stuff I already knew about
In my previous Ludum Dare entries, I’ve rarely re-used many systems. I like to build my own stuff. In fact, so far I’ve refused to use full-fledged engines, and while I’ve used Unity previously, it was mostly an excuse to force myself to get acquainted with it.
This time around, I had decided ahead of time that I would be using AS3 and a couple of frameworks for certain features (Nape for physics, Starling for GPU graphics). I had no engine, per se, but I complemented those by developing several additional libraries for game controller input, game looping, and physics level data loading (most of which are open-source and posted on my blog). I was certain I’d spend more time working on a game, rather than working on systems for a game (which, as fun as it is in itself, doesn’t make a good Ludum Dare entry).
The strategy worked pretty well. While I still had to use a pretty amount of time getting basic stuff working (due to my lack of knowledge of some Nape features, for example), I felt I was actually building a game earlier than on my previous entries.
Art was straightforward
I loved doing the art for the game, even though I hadn’t been drawing in a while. While a bit was dropped and unused (specially background art), I think the simple aesthetic I reached was pretty flawless even if it wasn’t brilliant.
What went wrong
Getting a game idea is always the hardest part for me, specially under pressure. I spent the whole first semi-day of the compo (Friday) doing nothing other than dicking around online, or reading, just because I couldn’t figure out an idea. The idea Saturday morning – of a flying UFO capturing humans – was a mechanic I’ve been thinking of for a while, but to be honest I didn’t have the gameplay challenge or the relation to theme figured out for a while.
Features were dropped (surprise)
While I tried having a smaller scope, some features were dropped out of the game. There’s only one level, for example, and while it’s randomized and it’s all based in easily configurable parameters (size, assets, etc), I never had the time to add actual level progression and assets for more levels. The current level used (city-ish) is a mix of my two initial levels ideas, park and city.
Worst of all, I couldn’t even begin to implement the enemy A.I. In the best Choplifter fashion, the second level of the games was supposed to game enemy tanks that would shoot at you. They would not do any damage, but their projectiles would throw you out of balance and make control a bit more difficult.
Not enough time for bug testing/QA
While I didn’t run into any huge problem, my entry still had some issues I had no time to test. Those include some bugs related to web playback (losing 3D context when switching between fullscreen, for example), and some OUYA pitfalls I wasn’t aware of (having the game suspended by the system puts it in an unplayable state when restored). Those are things that are likely easily fixable, but were noticed too late.
I think this was probably my most well-rounded Ludum Dare entry so far. I’m pretty happy with how it turned out, and I spent plenty of time watching my own time-lapse video of the development process. It’s great seeing it slowly transform before your eyes.
Still, the relative smoothness of this Ludum Dare made me realize something. Ludum Dare is a lot more about the content, and I’m not sure I’m very happy with it.
Because of the limited time, it’s better to have a great idea, create a lot of content and gameplay, and test it out until you have something fun. Some of the compo and jam entries I’ve tested were really fun to play, more than just being an interesting concept that could become a game.
In my mind, I like to use Ludum Dares to explore new mechanics – mostly in the form of new code – and almost as an excuse for learning something. And to be sure, I’ve done a lot of that; all Ludum Dares have been a great experience, even the ones where I didn’t have anything very playable in the end. I learned a lot in a short period of time.
Still, having to be forced to spend more time with content and gameplay is something bums me out. Having to ignore bugs unless they’re showstopping, and having to get things to work fast (as opposed to right) is something that, over time, I’ve almost forgot how to do. Nowadays, I like to get a cool system to work as a stepping stone. In a way, it’s almost as if gameplay is secondary to that (in that it comes after that, not that it isn’t important).
Something else made me realize that. Over the past few months, I’ve been slowly developing a game prototype on my free time. It makes me really, really happy. I take my time to get some things right – be it gameplay, animation, or lower-level systems – and it’s very rewarding. I do one thing at a time. Putting a pause in developing that to do Ludum Dare #27 was good in technical terms – I ended up learning several features I plan on adding to my game, such as ray casting in Nape – but I also realized I wanted to get some things right rather than just getting them done. For example, my starling shape utility classes – to transform imported Flash Sprites and MovieClip into Starling textures – is a mess. It works, but there’s a lot of edge cases where it doesn’t work as intended, or where there’s a lot of redundant code. And I’ve used it in 3 projects already, with no actual time for refactoring them and making them elegant.
I know the usual solution for Ludum Dares it to use an engine. Some might say I should have used Flashpunk, Citrus, or any other engine. And they would be right. But the reality is that it wouldn’t have been as much fun for me. As weird as it sounds, to me, Ludum Dare is an excuse to write something from the ground up. Not just to get something done, but to appreciate the journey of development. And I’m sure that, for many people, seeing something done is what motivates them over everything else. It surely motivates me. But I’m starting to realize that I care too much about getting systems right. Maybe it’s an annoying developer thing. My own professional work is always done on tight deadlines, make no mistake, but over time I’ve learned to balance it all and use time well to get something that’s mostly right from the get go. It normally means a better, more stable project in the long run.
I’m very grateful for everything I’ve done and learned. Ludum Dare is an awesome idea. But I’m not sure what I’ll do with the next Ludum Dares. I might do them, but maybe as part of a team, or maybe without submitting anything. I may use it as an excuse to build a “demo” of a system – e.g. my game controller classes, which need a few additional features – rather than an actual game to be played. We’ll see.
Whether the game is, is another story entirely!
You can play it online, or watch the video below (warning: I forgot I was recording all my audio input, so it has some music being played by mistake).
Overall it was an OK game for me to make. It’s nothing super but it’s more well round than my previous entries, I think. More on a post-mortem soon.
I’m again. This will be my 4th Ludum Dare.
Last time I used Unity, but this time around I’ll be once again creating an ActionScript game. While it’s great to explore technologies that I’m not very good with, I think I’m going to try making an actual game this time!
Code-wise, I’ll be using my generic, public code that I’ve been sharing on GitHub. Many of it includes game-related classes made especially for Ludum Dare, including a new GameLooper, and a a game input abstract class.
For third-party libraries, I’ll be using Starling for rendering and Nape for physics. I plan on having levels of some kind; I’ll be creating those levels with the R.U.B.E. Box2D editor, and loading them into my game with my R.U.B.E. loading function.
For audio, I’ll be using static files from sfxr. Art will be created with Illustrator and Photoshop.
I’m not sure of the target platform yet. It’ll be Flash, so this means either as a desktop app, a web game, or an OUYA/Android game. My recent prototypes have been targetting desktop and OUYA, so hopefully that’s what I’ll do.
I will be broadcasting my progress on my Twitch.tv channel.
Finished my jam entry. Not bad for a weekend on a platform I hadn’t used before.
Try rescuing Dr. Frank Poole from the emptiness of space in 2001: A Space Oculus (requires Oculus Rift).
Controls are somewhat hard. I was going for a QWOP-style control, but I’m not sure I made it fun.
Regardless, a noclip/free mode is included in case you just want to float in space and look at the ships.
For my Ludum Dare entry, I’m actually using content found elsewhere on the Internet (I suppose this means I’m being part of the jam, not the compo). Still fun. Unfortunately while it makes things faster, using “free” models usually mean you have to ignore certain missing features. In this case, the pod doesn’t have an interior.
I’m finally getting to a point where I know what to do to make it a “game” though.