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.

Concept

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.

Carlos, Carlos’ Bistro’s founder and owner

Setup

No major changes were made from my work setup. I used FDT and Starling creating an Adobe AIR (ActionScript) project, all tools or frameworks I already had some knowledge with.

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.

Design

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

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.

Pastas used in the game. Unfortunately, the macs where never used

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.

To-do list: lots of things were not done

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.

Conclusion

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).

…as the approach of the deadline means the inevitable drop of very important features. I’ll be happy if it works as a game now. It doesn’t mean, however, that things can’t be a little bit funny and lighthearted.

Did you know that Charles Darwin was a foodie? That take, hipsters.

Also, he may or may not have founded an Italian bistro called “Carlos’ Bistro” in Rome, where he debated the merits and evolutionary mutations of the Pasta. That’s still up for debate as we don’t have enough proof that he didn’t. Teach the controversy!

Time is running out, but objectives are falling into place and things are getting scratched from the to-do list. Right now, I’m working on the “bill”, as seen below.

My attempt is to have a game set on a dinner table where customers see their pasta flying around and fighting each other in an attempt to conquer each other’s plate. In other words, just your usual Italian bistro experience.

The Evolution theme works on top of that, by allowing you to evolve your pasta over time (the whole idea is about the “evolution of pasta”). That’s not working yet though; right now it just spawns different types of pasta on every plate, to test the gameplay mechanics.

But anyway, what I’m trying to do is to have visual game representations that are as metaphorical as possible. For example, since each plate has to be “conquered” by a number of flying pasta pieces (think Battlefield’s “Conquest” mode), you need a way to indicate which team (or “customer”) owns that plate, and what’s its status if other pasta pieces are trying to conquer it. Instead of having some abstract graphical representation, everything is indicated on a “bill” next to a plate. It makes actual state readout somewhat difficult (e.g. some bills are actually upside down, you have to rotate the tablet or the table using gestures), but I’m counting that as part of the game’s physical context.

Kinda, sorta, getting there.

Low FPS is because of sprites that never get cleared out of the World. Like sauce projectiles that go on forever.

What do you think? This is… well, it is something.

I just have a faint idea of what this is actually is though. I guess that’s the point!

Edit: “Survival of the Tastiest”? Brillante!

As Ludum Dare #24 draws closer, I supposed I’d set my own limits and state what I’ll be using here (as it’s part of the Ludum Dare compo rules too, of course).

• The language will be ActionScript 3.
• The IDE will be FDT 5.6. The Flash IDE won’t be used (maybe for packing some vector art as embedded SWFs, but not as an actual development tool).
• The compiler will be Flex SDK 4.6, with AIR SDK 3.3.
• Image editing will be done in Photoshop, if not generated in real time.
• The target platform will be Android, distributed as an .APK file. But since this is Flash afterall, it’ll also run on the web with a few conditionals. But I’m targeting a multi-touch input, so I’ll have to wait after the theme is announced before I know how well it’ll work on the web. I’ll probably use the “porting” time to do it after the compo time is over. (While an iOS version is actually trivial, deploying and installing device-independent development .IPAs isn’t, so I won’t be spending any time on that.)
• As a general framework, I’ll be using the Starling Framework, which I have used and is everything I expected it to be: simple, fast, and easy.
• I’ll be using a collection of general libraries I use on pretty much all my ActionScript 3 projects. That is open-source and pubic, and can be found in GitHub. I’ll also be using a separate tweening engine that is somewhat kept separated from my generic libraries but is also something I use on all my Flash projects.
• For audio (if I have time to include it), I’ll be using sfxr. Audio is not very high in my list of priorities, however.

See you there!

Why Hello!

So as I was saying, Ludum Dare 24 will be my first Ludum Dare compo. I’m pretty excited! So excited, I’m writing this one post here to start things the right way.

I don’t know exactly what I’ll be doing. I guess I’ll be waiting for the theme announcement on August 24th before I decide.

I know, more or less, which platform I’ll be using, though. I want to create a Flash/Actionscript project, using Adobe AIR, and the Starling Framework. I haven’t used this framework yet, but from the demos I’ve seen, it has an amazing performance (it’s a library used to leverage Stage3D in Flash, that is, use GPU acceleration more easily). It will be also good to be back an ActionScript project; that way I can focus on making the game functional, rather than learning a whole new platform.

No 3D, though. All 2d.

I want the target to be multi-touch devices (maybe especially tablets); my main compilation will be as an Android APK. I may have something on the desktop/web too (since it will be Flash after all), but if I rely on multi-touch input, this may get tricky (I’d have to add a simulation layer for things like pinching and rotating).

I just want to create a kind of a frantic touch-based game where you use your fingers to control… something, like a map from above, with little Actor AIs. Code-wise, that’s what I want to focus on: self-sufficient AI.

What I have in mind right now is a game where you see a battlefield from above, and you have your own little dudes being constantly spawned. You can’t control your own little dudes; they’re independent. You can, however, control some parameters like their spawning rate and maybe their classes, if they have that.

Objective wise, I’m thinking something where you have to get your dudes to a certain point of the screen and do something, either reach the objective or retrieve a goal.

In my head, it looks a little bit like DotA, where the lane creeps sorta help you, but you don’t control them. The difference is that in DotA you have your own hero to control; I’m thinking something more macro.

Control of the dudes could be done by forcing grouping (e.g. tell them to “wait” at a certain point of the path, then releasing them) and changing the route they take. Maybe allowing different routes to the objective. Other than that, they’d be on their own.

The first idea I had was of a game where you had a sort of a tactical Team Fortress 2 game, where you could spawn different classes and they had to reach an objective. A kind of a “Tower Defense”-style game in reverse. That’s why I think you could have different classes of creepers… say, a bunch of “Scout” creepers rushing, but then meeting a bunch of “Heavy Weapons” enemy creepers. Oops.

Objectives could be varied. Team Fortress 2 also shows this pretty well: certain modes can change the game radically. Arena, Control Point, CTF… they’re all very different, even with just a few small rules changed.

Which all also remind me of Battlefield’s “Conquest” mode. For that control of your dudes would be more fine-grained (e.g. select a few of them and send them to a control point) but still sounds fun.

A lot of ideas. Nothing set on stone but it’s a good exercise. Too bad I only have one weekend for it, but it should be enough for a cool prototype.

Visually I think it’ll all be extremely simple, and retro-looking – Geometry Wars/Radiant Style. This would allow me to focus on the game experience rather than creating graphics (even though I think the graphics could still look great), and make it work better in case there’s an immense amount of actors on screen.

In the end, the image I have in mind is of something scribbling on a tablet frantically while his/her troops execute his/her orders. That’d be fun.