About zeh (twitter: @zeh)
Ludum Dare 27
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24
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.
In preparation for the next Ludum Dare, I’ve playing around with Unity for the past few months and there’s something I’d like to share with other aspiring game developers.
My previous Ludum Dare games where created in Flash, and while I was somewhat happy with my coding effort, the games didn’t have any audio. I decided to make things different next time, and have some simple audio feedback on whatever I built.
To get myself acclimated with the language, I decided to port Thomas Vian’s as3sfxr to Unity. What’s as3sfxr, you ask?
This short video from Flash on the Beach 2010 has a great explanation. In a nutshell, however, sfxr is an engine for dynamic generation of game-like audio effects. Thomas ported Tomas Pettersson’s original sfxr to ActionScript, creating a nice API for dynamic audio generation. This API was the basis for usfxr – and really, much of the code in usfxr is a direct translation of as3sfxr, albeit in a more C#-friendly, Unity-happy way.
In practice, what does usfxr do, though? It allows you to publish a game with no static audio assets (all effects are defined by a parameter string), and to generate small variations of the same audio in real time, thus making the audio playback a bit more colorful.
Code for a normal audio effect looks like this:
SfxrSynth synth = new SfxrSynth(); synth.parameters.SetSettingsString("0,,0.032,0.4138,0.4365,0.834,,,,,,0.3117,0.6925,,,,,,1,,,,,0.5"); synth.Play();
While “mutated” versions of the audio can be played like so:
The library is a pure code port, with no GUI whatsoever (you can generate audio strings in as3sfxr‘s GUI, copy it, come back to your C# code, and paste the string). Other than that, the biggest difference is that audio data is (almost) always generated on a separate thread, so the need for pre-emptive caching is diminished.
I have an example of usfxr in action in a (terrible-looking) Shmup example (requires Unity web player):
The full code is available on GitHub. I’ll probably fix a few more things – mainly write proper documentation, add a different sample, and maybe make it faster – but overall it’s working. And obviously, I’ll be using it on Ludum Dare this weekend.
Some input would be welcomed, of course – I’m not a experienced Unity developer.
This post is a shortened version of something I’ve originally published on my own website.
I’m in again for Ludum Dare #26. This time around I’ll be creating something in Unity, which is a platform that I’ve only recently started learning. That’s a good excuse as any, right?
I’ve also decided to finally add some sound to my entry this time around (my previous entries were all silent). For this, I’ll be using usfxr - my Unity port of the sfxr/as3sfxr engine (I’ll hopefully write a bit more about this prior to LD #26, so more people can use it if they need dynamically generated, randomly mutated audio).
Good luck everyone!
It’s been nearly a week now, so I figured I’d post a post-mortem about Fry Fleshlings Fast, my Ludum Dare #25 entry for the theme “You Are The Villain”.
The game is an ActionScript 3-game compiled in Flash. It runs online, or as Android AIR installs (I guess it could work as iOS installs too, but, you know, it’s a pain in the ass to create all certificates for that and only people with jailbroken phones would be able to install it since it’s not an App Store release, so why bother).
The original idea I came up with was a game where the player acted as an invading Alien overlord. You’d have a top-down view of a map and your task was to kill everyone below. For this, I envisioned a mechanic where you would have actors – the fleshlings – roaming around a map, going from checkpoint to checkpoint. The player would have the ability to cut their paths short (by using lasers) with the objective of getting everyone to move to the same general area, where you could then drop a meteor attack on top of them, killing everyone. The challenge would be in using as few lasers as possible.
Although the systems were different (using point- and line-based roaming paths, rather than a two-dimensional plane), the whole idea was heavily inspired by Jezzball, a very simple yet addicting game for Windows 95.
What went right
Reusing code: although I failed to do a post about it prior to starting the project, in this project I reused much of the code I developed for my previous Ludum Dare game attempt, Survival of the Tastiest. While much of the code is, of course, garbage – many shortcuts were taken – a lot of the support code and more abstract frameworks for handling objects and Starling entities came out very handy for this new project.
I now feel like, for a Ludum Dare project, you can’t plan on working on a new engine and a new game at the same time. Unless it’s a very unique but simple mechanic, it’s just a lot of effort that means you can’t get both really right. It’s better to develop an engine with a simple game layer on top of it, or to work on a cool game idea based off a well established engine. Of course, this is not something I did right this time around – I was developing both again – but having somewhat of a starting point helped.
Over time, it’s likely that my own entity engine – which doesn’t have a name – could shape up pretty well. There are many well known, polished engines for games in Flash out there, of course, but having one of your own is a great learning tool and, with time, allow you greater freedom since you can tweak and change it to fit your needs better.
Programming a system I enjoyed: I never get to spend my (full-time) programming job on game-like systems anymore, and while creating this game I was dead set on creating a point-based pathfinding and routing system that allowed for routes to be created and cut dynamically during gameplay. I love the code I produced for that – one where I didn’t take any shortcut on – and it makes me happy knowing that no I have this additional library to carry with me whenever I need it. I believe challenging systems like that are what I do best – rather that repetitive tasks – and I was a great joy to get this working from the group up. This made this Ludum Dare effort really worth it.
Not worrying too much about the idea: truth be told, until Saturday at noon, I didn’t even know if I was going to participate in Ludum Dare at all (because, like I said, I had other work to do). So I decided not to fret over it. I was thinking of ideas and discussing them with my girlfriend and friends, but not going crazy over it. Maybe because of that, the idea came naturally and I started implementing a few hours later.
What went so-so
Scope: with my previous game attempt, I had a very audacious plan that failed to materialize in a game; it took so much effort to get something playable done, that by the time it was ready, I didn’t have enough time to make it easier, more approachable, or just fun. It was an engine, but not a real game. With this entry, I made sure to think smaller – creating something that could be accomplished without a lot of effort. This was also made more important because I actually had Emergency Real Work to do that same weekend, so I wanted to spend just a few hours with the Ludum Dare entry.
In the end, while the scope of the game was much better aligned with a Ludum Dare project, it still failed to materialize into a fun game. I only spent 6 or so hours with it, and I feel the results were more or less the same: there’s a game engine in there, but it’s not that challenging, or fun. It’s a gimmick.
Still, I think that, given enough time, it could be pivoted to something more fun.
What went wrong
Assets: Even if I decided to use simple assets this time around, I ended up spending too much time creating graphics, animation frames, and map textures for the game. Sometimes, it’s better to have extremely simple assets and concentrate on everything else.I’m convinced my next game will have circles, triangles, squares and lines first and foremost, and no animation frames. But then maybe it’ll finally have audio.
Not giving enough time for testing: the gameplay concept was something kind of unclear, and my problem was assuming it would just work. It’s only later in the development process that I realized it wasn’t the case. The mechanic was there – you cut paths down, limiting fleshlings to a given area – but it wasn’t fun. For one thing, their behavior was too unpredictable (they would take random paths once they reached a path connection) so the idea of funneling them into a common area never worked out. It would be better if they had clear rules – for example, when reaching a connection point, if there’s a clear path ahead of them, take that instead of turning the corner randomly – or if the map had additional mechanics, like one-way routes (maybe by deploying signs of some sort).
I feel like the need for those changes would have came out earlier in development if I was focused on getting a prototype working, rather than on getting a game working. I heard this is how World of Goo has come to exist: they developed a simple prototype over a week to see if the mechanic would work (as a part of a large, a-game-a-week effort), tweaked that as necessary, and only then decided to create a full game with its unique but fun mechanic.
Much was dropped: once again, I had to drop a few features that made the game less cool than I thought it could be. The end-game meteor attack was removed – the new objective was just to kill everyone with lasers themselves – and potential new weapons were never seriously considered. In way, this made the game interface better – I didn’t need a HUD for weapon switching, so the map could take the whole screen – but it also meant it was a bit repetitive.
This game was great in that it taught me one thing: I normally plan a system and then try to develop a game out of it. Maybe, given enough time, this can be a solution; but it means you need to give time to work on the gameplay after the system is complete, because at first, it’ll only be an engine of possibilities.
Many lessons learned for the next Ludum Dare. I like to believe I’m getting better. Code-wise, it has been a lot of fun, but maybe one day it’ll also be fun gameplay-wise!
Once in a while I find something surprises me by both the fact that it exists and because I’m probably the last person to know about it, hell, why didn’t anyone tell me about this before?!?!?!?. As of recently, this something has been the Game Developer magazine.
The Game Developer magazine is a thin little publication – with both print and digital (PDF) versions – with articles on the craft of, well, game development. The surprising part, however, lies on the pure quality of the magazine’s content, packaged in what seems to be an independent, honest-to-god straightforward bag of game development goodness.
Consider this. You’re looking at your game elements’ life cycle
postUpdate() methods, and wondering how should each method deal with each specific step of the frame update cycle, and whether you’re doing the right thing. You’d like to discuss this with someone else. And then you open the magazine and you find someone talking about the same subject for 4 or so pages. It’s unadulterated programming porn.
(This actually happened yesterday.)
More importantly, you don’t have to be a professional game developer to appreciate the content offered in its monthly installments (hell, I’m not one myself). However, if you need to do any kind of visual programming, or if you’re really just interested in the art of game development, this magazine is the real deal; it covers it all, from art to programming to marketing. And because it’s so thin – it’s usually around 80 pages – it’s easy and quick to read it every month. The noise is nowhere to be seen.
You have no excuse. Go subscribe for it now.
(This is a cross-post from something I’ve posted on my personal blog earlier this year but that I find bears repeating)
It is done, and submitted. You can play “Survival of the Tastiest” on Android, and on the web. Playing on the web works, but you have to simulate multi-touch for table moving and that can be a bit confusing.
There’s a lot I’d like to talk about. I’ll go through every topic, insted of making the typical what went right/wrong list.
Working over the theme was probably one of the hardest tasks I had to face.
Originally, I had an idea of what kind of game I wanted to develop, gameplay wise – something with lots of enemies/actors, simple graphics, maybe set in space, controlled from a top-down view. I was confident I could fit any theme around it.
In the end, the problem with a theme like “Evolution” in a game is that evolution is unassisted. It happens through several seemingly random mutations over time, with the most apt permutation surviving. This genetic car simulator is, in my opinion, a great example of actual evolution of a species facing a challenge. But is it a game?
In a game, you need to control something to reach an objective. That control goes against what evolution is supposed to be like. If you allow the user to pick how to evolve something, it’s not evolution anymore – it’s the equivalent of intelligent design, the fable invented by creationists to combat the very idea of evolution. Being agnostic and a Pastafarian, that’s not something that rubbed me the right way.
Hence, my biggest dillema when deciding what to create was not with what I wanted to create, but with what I did not. I didn’t want to create an “intelligent design” simulator and wrongly call it evolution.
This is a problem, of course, every other contestant also had to face. And judging by the entries submitted, not many managed to work around it. I’d say the only real solution was through the use of artificial selection, somehow. So far, I haven’t seen any entry using this at its core gameplay.
Alas, this is just a fun competition and after a while I decided not to be as strict with the game idea, and allowed myself to pick whatever I thought would work out.
My initial idea was to create something where humanity tried to evolve to a next level but had some kind of foe trying to stop them from doing so. I kind of had this image of human souls flying in space towards a monolith or a space baby (all based in 2001: A Space Odyssey of course) but I couldn’t think of compelling (read: serious) mechanics for that.
Borgs were my next inspiration, as their whole hypothesis fit pretty well into the evolution theme. But how to make it work? Are you the borg, or fighting the Borg?
The third and final idea came to me through my girlfriend, who somehow gave me the idea of making something about the evolution of Pasta. The more I thought about it the more it sounded like it would work, so I decided to go with it.
Conversations with my inspiring co-worker Roushey (who also created the “Mechanical Underdogs” signature logo for my intros) further matured the concept, as it involved into the idea of having individual pieces of pasta flying around and trying to evolve until they became all-powerful. A secondary idea here was that the game would work to explain how the Flying Spaghetti Monster came to exist – by evolving from a normal dinner table.
So the idea evolved more or less into this: you are sitting a table. You have your own plate, with is your “base”. There are 5 other guests at the table, each with their own plate.
Your plate can spawn little pieces of pasta. You do so by “ordering” them through a menu. Some pastas are better than others; some are faster, some are stronger. They have varying costs, which are debited from your credits (you start with a number of credits).
Once spawned, your pastas start flying around. Their instinct is to fly to other plates, in order to conquer them (the objective of the game is having your pasta conquer all the plates on the table). But they are really autonomous, so after being spawned, you have no control over your pasta (think DotA or LoL creeps).
Your pasta doesn’t like other people’s pasta, so if they meet, they shoot sauce at each other until one dies. You get credits for other pastas your own pasta kill.
Once a pasta is in the vicinity of a plate, it starts conquering it for its team. It takes around 10 seconds for a plate to be conquered; less if more pasta from the same team are around. If pasta from other team are around, though, they get locked down in their attempt, unable to conquer the plate, until one of them die (think Battlefield’s standard “Conquest” mode).
You get points every second for every plate you own.
Over time, the concept also evolved to use an Italian bistro as its main scenario.
One big change for me was that I livestreamed my work through a twitch.tv account. This was a new thing for me. As recommended by Roushey, I used a program called XSplit and I got to say, it is pretty amazing. It made the livestream pretty effortless and the features are awesome, even for the free version. It was great to have some of my friends watch me, and then interact with them and random people through chat. It was also good knowing that I was also recording a local version of the files, so I could make a timelapse video later.
Knowing the video was being recorded also made me a lot more self-conscious about my computer use, as if someone was watching over my shoulder. It made me realize that sometimes I spend too much time in seemingly inane tasks (I ended up wasting the longest time just to get some text alignment the way I wanted – it’ll probably drive someone crazy if they watch it) and that I do way too many typos where writing code. I pretty much spend half of the time writing a line and the other half fixing the crazy characters in it.
My own stream was probably boring to watch since I was coding for the most time. But livestreaming is one of the cool things to do as a spectator too. It was great seeing other people working – I had a few tabs opened on my second monitor all the time. It’s actually a bit sad, because if I could, I could have spent the whole weekend just watching other people working! But I had to do my own work, so I’d only do it once in a while, when resting for a bit.
Although I wanted some simple, low-fi, high-contrast kind of design, I ended up going with somewhat realistic (vector) art. I think it worked very well, fitting the mood of the game, but I also went overboard.
For example: to know the state of a plate (who owns it, who’s conquering it and how much time they have left before conquering it, which pasta units are in the queue, etc), you have to look at the plate’s bill.
The problem I realized when doing some tests is that people never look at the bill! They think it’s some kind of prop, so they never actually read its details.
Plus, if you’re zoomed out too much, you can’t actually read it, so it’s hard to know what’s going on with the game until you zoom in to the area of a specific plate.
One other solution that didn’t turn out to be as perfect as I thought was how to indicate who a plate base belongs to. In the game, that’s indicated by the plate’s decoration – its color denotes the team owner. But it’s something that fits so well into the design that people never realized it, until they were told about it.
In the end, the idea of going with a full physical metaphor is one that should be done with care. Things that are very important risk becoming background noise, unless the player knows its importance.
Originally, I wanted to avoid any kind of heads-up display in my game. In the end, I ended up adding it at the bottom to indicate your credits and bases owned, as well as the hideous out-of-place-and-still-not-obvious “Call Waiter” button. But in hindsight, I should have gone with a simple HUD from the start, especially one that indicated each team’s colors and general state of the game without the need for zooming in and out.
Development went fast. But not fast enough.
Even though I worked around 32+ hours for this Ludum Dare, the biggest problem I had to face in the end was overscoping. I had too much planned, and couldn’t get it all done.
Content-wise, I had several kinds of pasta planned (Wikipedia is just amazing in that regard), split into several different groups, from small Pastina to huge Pasta al forno. But because of time constraints, I ended up scratching most of them, and ended up with 5 different types of very small pasta – barely something to start when talking about the evolution of Pasta.
Which is one of the saddest things about the project, really. It had the framework and the features to allow an endless number of elements in there, but I just didn’t have time to draw the rest of the assets needed (something I loved to do, by the way).
Other non-obvious features had to be dropped, too. For example, when ordering some pasta, you were supposed to select what kind of sauce you’d like with your pasta, each with different attributes. Bolognese, for example, is very strong, but inaccurate; Pesto is very accurate and has great range, but it’s weaker; and my favorite, Vodka, would triggers 10% loss of speed on the pasta hit by it.
The code for that is mostly in there. But in the end, I didn’t have time to implement the sauce selection interface; all pasta ended up using bolognese sauce.
Actual programming also took a toll in the development time. Having been programming for a while, I like to believe I got to a point where I know how to make things right, but at the expense of forgetting how to do things wrong in a seemingly good way. What I mean is that I had to take a lot of shortcuts in my code to save time (e.g. a lot of singletons references for cross-communication rather than events or observers, all-encompassing check loops, not fast enough) that left a very sour taste in my mouth. While I know I used to do those a few years ago and survive, I almost cannot accept the state my code is in right now.
At the same time, I do know it was the right thing to do given the timeframe.
One small thing that had some impact was using a somewhat new platform for me. That’s Starling, the accelerated graphics framework I used in Flash. I had tested it before and I knew how to use it well – the API is very similar to Flash itself. However, there were some small details that had some impact during development, making me feel somewhat uneasy the whole time I was writing the game. It was, again, the right thing to do, but I should have used Starling more deeply before (which is the conundrum: I used it for Ludum Dare just so I could learn more about it).
Argument and user experience
One final aspect of the game that I learned is that making the game obvious for your players goes a long way into making it fun. If you have to spend the longest time explaining things, your game is doing something wrong.
And that’s exactly the problem Survival of the Tastiest ultimately faced. It’s very hard for people to understand what’s going on with the game, why, and how. I did have some introductory text at the beginning, but that was a last-minute thing. More importantly, I should have had a better interface or simplified the whole concept so it would be easier for people to understand.
That doesn’t mean the game itself should be simple. It just means that the experience and interface should be approachable and understandable.
I’m extremely happy with what I’ve done and, especially given that this was my first Ludum Dare. However, I feel like I’ve learned a lot of what not to do.
The biggest problem is overscoping. Like Eric Decker said, the biggest lesson we can learn with this is probably with scoping – deciding what to do beforehand in a way you can complete it without having to rush and do something half-assed.
I’m sure I will do more Ludum Dares in the future. But if there are any lessons I can take of it, they are to make it simple, to use frameworks and platforms you already have some absolute experience with (otherwise you’ll spend too much time trying to solve easy questions), and to scope for a game that you can complete in one day only (that way, you can actually take two days and make it cool).