Escape Velocity is now on Linux-64! Many, many open-sourced thanks go to JohanAR!

I used SDL and FMOD, if anyone else out there is feeling port-venturous. Maybe somebody with OS/X?

Hi LD48ers,

I’ve had a couple of people ask me about how I put together my 2D game in unity and seeing as the techniques might be relevant in other games I thought I’d take some time to explain some of the things i did in my game, in the hopes that it helps someone out.

like my LD20 game Drum Hammer Dig I chose not to use any external sprite libraries (such as ex2D or SpriteManager), everything game related was written from scratch and there’s of course a link to the source in my compo entry should you want to check it out. ( As you’d expect its all over the place but it got the job done )

http://www.ludumdare.com/compo/ludum-dare-21/?action=rate&uid=4202

To start with, i’ll talk about how I handled landscape collision.

One thing I knew early on was that the level shapes themselves were probably going to change a lot as I put the game together. Collision wise I also knew that this game would be 2D, but I didn’t have the time ( or skill ) to write a custom 2d collision system.

Editor shot of the 9 areas

With that in mind I went with the “work with what you have” approach. In this case, Unity fortunatly has a great built in 3D Physics system that i wanted to utilise.

I wanted was to harness that system, in a way that allowed me to quickly create and layout collision without relying on an external 3d package, I also didn’t want to mess around placing lots of box colliders down for each level and then having to move or change them when the level changed.

I chose to write a simple mesh creator in the editor, and then used the generated geometry as a mesh collider. This gave me the best of both worlds. Fast turn around, and all the physics collisions I needed.

Its dirt simple but really effective;

1) First I have an array of points in space ( arranged in a clockwise order )

Points in space

2 ) A set of Vertices is created from these points, extending forward and backwards on the z axis.

Vertex positions based on previous points

3) triangles are created from the vertices

Triangles are created from the vertices

Translated into unity, I have a GameObject for each area in the game which has a “MeshHitcheck” component that contains array of positions (laid out in a clockwise direction)

Using the steps above a collider mesh is generated at runtime from those points.

Background painting on a single sprite

Clockwise layout of points with Gizmo draw in editor to show edges

Hitcheck mesh generated at startup

2D Collision Done!

Same area shot from in game

Editor Extra’s

Hand editing position values in an array isn’t exactly fast so to make editing and layout of the positions array as quick as possible, I created quick little editor helper script that basically draws position handles for each point, and a button to add new points into the array. Its not a perfect solution and there a number of ways to improve it, but it saved me plenty of precious time.

Quick editing of points inside the editor

I should also note that the seed character in game is simply a rigid-body sphere with a limit on the z axis, all other objects are sphere or box trigger colliders that don’t move.

That’s all for today, I hope this was of some use.
If you have any questions or want explanations on some of the other things in game, let me know.

Thanks for reading.

Steven Burgess

Ok, I have noticed that many people don’t actually know the full meaning of word escape which might be affecting voting in the Theme category. I don’t blame anyone and no one should, since most of the folk here aren’t native English speakers (me too, but I’m an English teacher ).

So, Here is a definition from The Free Dictionary with some pictures for better reading

escape [ɪˈskeɪp]
verb

1. to get away or break free from (confinements, captors, etc.)
   the lion escaped from the zoo
   
2. to manage to avoid (imminent danger, punishment, evil, etc.)
   to escape death
   
3. (intr; usually foll by from) (of gases, liquids, etc.) to issue gradually, as from a crack or fissure; seep; leak
   water was escaping from the dam
   
4. (tr) to elude; be forgotten by
   the actual figure escapes me
   
5. (tr) to be articulated inadvertently or involuntarily
   a roar escaped his lips
   
6. (Life Sciences & Allied Applications / Horticulture) (intr) (of cultivated plants) to grow wild
   

Here you go

So this was my first Ludum Dare, but not my first jam. However, this was my first jam as a code monkey, previously I’ve been doing only sound design. But since I’ve actually got a degree in computer sciences and programming, I thought to give it a try and see if I can push myself to make a game during one weekend. And yes, I more or less managed to do that, of course I had a friend doing almost all the graphics, but if you watch the timelapse you’ll see I did some gfx related tasks too.

Timelapse:

What went right:
Brainstorming ideas before the topic was announced – we had a suitable idea for almost every theme in the final votes. Escape suited us quite well but actually we were hoping for wormholes. I also had my own basecode written and ready with collision detection and controls in place. Graphics worked ok and my decision to take Gleed2D as a level editor was a good one, since it gave us a way to prototype the hud and levels prior to having actual game code ready. However I ended up tweaking the XML files generated by Gleed2D by hand after all. Porting to Mac OSX went smooth as ever and even the release bundle worked without any issues, unlike the Windows version. One thing that is good to mention here, is that we understood to cut features from the game when we saw that we don’t have time to implement them.

What went wrong:
Stuck on stupid bugs, mostly due to lack of sleep. I didn’t sleep nearly enough. Also our initial idea was way too big to implement in such a small timeframe so we had to drop lots of features. In the end, we had only the bare minimum of the story we had planned and basic set of the game mechanics. We didn’t use enough time for testing, and that showed up in the final phase, where I was playtesting and tweaking the difficulty constantly on OSX while trying to fix audio issues on Windows. And that brings me to the fact, that choosing Phonon as audio engine, even though it’s built into Qt, was a wrong decision due to severe problems on Windows. It might have worked if I’d have time to test it thoroughly beforehand. Two things I should make mental note about: have at least 1/3rd of the time dedicated to playtesting & debugging and stay away from doing sound design for other projects if your own code isn’t working!

Anyway, thanks for a great Ludum Dare, it was fun! Don’t forget to rate our game  http://www.ludumdare.com/compo/ludum-dare-21/?action=rate&uid=5118

Is it allowed to update during voting ?

I have a little perfomance update to do, as well as a missing key!

I’ve been playing some of the entries, mostly those of which I liked the screenshots and there have definitely been some really amazing games already. This is why I thought I could share my top11 (why top11? Because I couldn’t decide which one to leave out!) with you. I’d love to see your top5/10/11/whatever, I’m sure there are still a lot of great games I missed.
So here we go!
(more…)

While rating your games I came across several written using Unity3D, which is understandable as it looks like a modern 3d Flash on steroids. However, there still is no Linux player available, so go and vote for them to write one!

Most of you probably don’t use Linux, and might be thinking “why should I care”. But you should. It’s about freedom of choice as much as about anything else. One might think that people should be free to choose the operating system they like, without being punished by third parties. Ok, I know it’s not that simple, porting to a new OS requires an effort and some companies will have to make a cost/benefit calculation, while many others can afford to be selfless most of the time.

I  will always try to make my games multi-platform, even though I think Windows is crap and that Apple is an awful company (with good products ). Not because I think I can sell more copies, but because of you. You should be allowed to use the OS you chose, not the one I do.

So, all in all, I think this dare went WAY better than my last (which was my first). I think what mainly accounted for my better outcome was finally swallowing my pride and deciding to write a 2D game. It’s amazing how much removing that 3rd dimension simplifies things. I wanted to make something cool, so I really didn’t want to spend too much time just trying to think of ideas. I couldn’t think of any amazing revolutionary new game play style, so I just went with the good old classic top-down shooter. Of course, to keep it with the theme, I set the goal of the game to escape the game. I probably won’t do too well on theme points but I’m still proud of my creation. After all, who of us really does this in hopes of winning? I just do it as a motivational leap to start a new project.

http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=4069

What Went Right

So, for the most part, the beginning went very smoothly. I stayed up until 4:30 AM the first day and got a lot of the core coding done. I started with the basics – a basic OOP design in C++ (my language of choice), movement, and collisions. Then, I started to get my hands dirty with a weapon system. Unfortunately, I ended up changing the weapon system since adding new weapons eventually turned out to be a huge hassle (this was actually after I finished the compo version game). Next came the rovers. Rovers went along a lot smoother than I expected them to. No problems really there. All hell broke loose when I started programming doors though.

What Went Wrong

Basically, I thought doors were going to be like 30 minutes tops, but they ended up being like 2 hours. First, I had to write basic animation functionality in the object class – no problem. Switching states became a huge hassle and I finally  broke down and analyzed the update loop step by step – then I finally got it. I was forcing a specific frame in the door code on certain states, but this created problems, so I ended up just letting them flow naturally and not try to prevent the occurrence of a bad frame (which I later found was not possible to occur). Another huge issue that I didn’t expect was scrolling. Yes, scrolling. Of all things that could go wrong, scrolling did. I ended up having to edit a lot of drawing code that should have been there from the beginning.

All in all, I think my favorite thing to add was the shaking when an explosion goes off. It’s freakin’ awesome

Thanks for a great Ludum Dare guys! I had a great time.

Watch it if you still haven’t played it yet.

If that got you interested. You can play it here.

I always think it’s cool to respond to the comments I get, so here goes. If nothing else, it’s a fun way to talk about my game some without dedicating a ton of time to writing up stuff. I just entered college, so taking less time is a very good thing.

markengley says …
Aug 22, 2011 @ 11:50am
Really good idea. Looks like an optical illusion…

I forget why I originally designed it like this, but… well, it looked even more like an optical illusion before. (Go here and just click the play button. If you have ANY problems whatsoever with flashy lights, don’t do it.)

(more…)

…That didn’t come out right.

Anyways, everyone who plays my game on my pc likes it, everyone who doesn’t, doesn’t. Conclusion: there’s a bug causing framerate-dependence. I think I’ve fixed it and my game is WAY more responsive and hence fun, even on this pc .

So, if you hated Escape Velocity, or if you just feel like a generally good bloke or lady, check out my new-and-bugfixed-(I-hope-)Escape Velocity!!

Hi! My name is Lucas , me and my brother Pedro participated in this ludum dare, it’s the third one we try ^^
We couldn’t count on programmers this time so we did all graphs and programming ourselves, so it was quite a simpler and much more buggy game than we expected, but that’s the spirit of ludum dare : challenging yourself and showing your work. ( I hope i’m right about this )
Anyway, just wanted to create a post about our work, since we didn’t do that during the weekend .

I’ll be posting a link to our Jam Entry, it’s called “Perdiganawe” , all the description in there.

In here I just wanted to congratulate everyone , i’ve been seeing some great games around here and it makes me really happy =]

also wanted to say what’s different in this post-mortem version we’re uploading :

* Our game now has fog of war!
* In the first version, if you failed a level and clicked the option below the “you failed” message, you would go to the next level! D: that does not happen anymore
* Level two is harder, it was too easy before…

Well,that’s all for now, you’ll be hearing more from us along this month.
Hope everyone enjoys our game,as much as we enjoyed making it and playing yours \o

There ya go :

http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=4166

bye everyone ^^

The Thiers Brothers

Here’s how you do it .

20.35 seconds, but you get the idea.

So, I decided to do a video postmortem this time around. It’s available on YouTube: Slip Away Postmortem

I am not sure postmortem is the proper term for this entry, being I can’t be sure the life of the project has come to an end.  Perhaps it has.  Regardless of the lifetime of the project, this post is about what happened, what went right and what went wrong, as I worked on my Ludum Dare 21 entry: Escape.  Sorry, I made the “what happened” a little longer than I expected, skip to the bottom for a true post mortem.

Ludum Dare 21: Start – 1 month:

This weekend started at least a month before with preparation and cleaning my slate for the entire weekend.  I made it clear to family and friends that I would be busy during the weekend.  Under no exceptions, (perhaps a big pay bonus), was I going to go into work; regardless of the circumstances or consequences.  Luckily work didn’t want me to come in, so I didn’t need to worry about consequences.  I had my framework picked; homegrown DirectX 9 engine written in C++, my language of choice.  I was set.  The week leading up to Ludumdare I made a blank project from my template – in doing so I felt I’d automate this process; which took me the full week nights after work.  However, I can now type “CreateProject ProjectName” and out comes an already compiled template project that is at blank screen and ready for development.

Ludum Dare 21: Start – 5 hours:

No lie, there were several ideas floating around my head and was hoping for Castles to be the theme.  I went shopping for some food and supplies for the weekend so I didn’t need to waste time doing so later.  The IRC channel; #ludumdare was insane, I started a G+ hangout that filled with so many people, and I didn’t know them all, but we all shared a passion for Game Development.  Finally, it was time.

Ludum Dare 21: 48hrs Remaining

Theme: Escape.  Thoughts crossing my mind, #ludumdare going insane, I left the G+ hangout and went to my white board, and to cook a meal while I thought up ideas.  I was pretty surprised that I had three right off the bat, each with their own challenges.  One was a turnbased puzzler that would have been easy on the programming side, harder on the content side.  Another I threw away based on scope, it was much too big for a weekend.  The final was a physics based glider falling through a maze like puzzle to the ‘exit’.  Despite being harder with math and level design, I choose the physics based glider on the basis that content would be kept to a minimum.

Ludum Dare 21: 44hrs Remaining

I had created a 2D camera, and sprite class – two things I overlooked on my framework, which admittedly is typically used for 3D projects.  I managed to get the basics going before heading to bed to sleep on my idea before committing completely.

Ludum Dare 21: 36hrs Remaining

Woke up, ate a good meal and planned to work on the physics of the glider until I got it right, so that I could avoid wasting time on level design by setting the physics in stone before a level is started.  The physics gave me some problems, it took awhile to figure out that the equation for lift did not apply it in the correct direction.  That and other strange things.  I spent far longer on the physics that I wanted, and I never got quite what I wanted out of it – but it was somewhat controllable.

Ludum Dare 21: 24hrs Remaining

I spent about 2 hours trying to get a randomized tunnel to generate, and quickly gave up on the basis I didn’t like the outcome of any of the work.  So at this point the choice changed to making a quick and dirty level editor, which actually came out very well.  By the time I went to bed I had wrapped up a level editor that I could play, edit, play, edit in quick succession.  Hung out on G+ hangouts as much as possible, had some good discussions while still getting stuff done.

Ludum Dare 21: 13hrs Remaining

Motivation has dropped quite a bit even though I was on the final stretch.  Time pressure was starting to begin as I realized I didn’t have a level or anything – but I did have my main gameplay mechanic; physics.  To accurately test the level I was about to develop, I needed to add the collision for the game – which was much more difficult than it seemed.  Despite using code I had from another project for line-to-line collision, it did not work.  In the end, debugging proved that I was putting in the wrong lines…  Many hours wasted.

Ludum Dare 21: 6hrs Remaining

A final burst of energy to finish the level, add a score counter, title page and share it on #ludumdare – got some feedback, made a quick and dirty tutorial page – that added a lot to the look and feel of the game.  Removed the level editor and temp map files for the final build.  Tried making some music for the game, but failed miserably.

Ludum Dare 21: 0hrs Remaining

Submitted the project as a jam on the basis I did not share my code.  However, I followed every other rule strictly.

Ludum Dare 21: Postmortem; What went wrong

• This was the buggiest project I’ve worked on in years, I had to cross hurdle after hurdle; physics, line collision, level design.
• I did not put enough effort into created the game music, or sound effects – and this would have paid off huge in the end.
• My own expectations were let down on basis of; physical feeling and level design.
• Although I took a good share of breaks, getting out of the apartment would have been useful.

Ludum Dare 21: Postmortem; What went right

• The visual quality stunned me, it actually came out looking decent.
• I made good use of breaks for food, shower, sleep, and thinking.
• I finished, it was close to complete, and I had a lot of fun.

Check out the project, rate it, leave comments and most of all – hopefully it is enjoyable, even for a few moments.

So, now that things have calmed down (a little bit) I thought I’d take a moment to look back on how things went for me during this LD, how the game turned out, and what I learned.

Overview

First of all, I thought this was a really fun Ludum Dare. While some people were a little upset by the large amount of attention Notch got, I thought the fact that it raised the profile of LD was fun, and I think it got people aiming a little higher (in some cases) than they would have otherwise. Also, I really liked the theme. Even though it seems so open-ended and easy, the theme is what got me into this contest. I didn’t think I was going to do it, then going to sleep Friday night I had the idea for the game, woke up on Saturday and just made a decision to start working on it. I didn’t commit as many hours as last time, which actually ended up being good I think.

The Game: Red Rover

The game itself turned out a lot better than my first. Whereas the first game had really big (over-complicated?) ideas and conceits this one was very simple. A rover driving around a lonely planet, exploring and hoping to escape its fate. Right away I knew that I needed:

1. An overhead rover sprite that could rotate 360 degrees.
2. Tracks in the sand to show where the rover had been.
3. A world that wrapped (kind of simulating a small planet).
4. An obvious but boring mission (collecting rocks) with the secret mission of escaping boredom, the surface, the planet, etc.
5. Contrasting sensor read outs with internal thoughts and feelings.

I won’t go into too much detail to avoid spoiling the game, but I do want to point out that it’s not just about collecting rocks.

Schedule

I spent most of Saturday working on getting the “feel” of the game right, including the graphics, tracks, terrain, etc. I’m pretty proud of the graphical look, even if it straddles a line between too retro (very lo-res graphics) and not retro enough (the graphics are up-sampled, and rotation/wheel tracks are done at higher-resolution). I took a break to go to an art show in the evening, and then to play cards with some friends.

Sunday I woke up and started on the plot stuff. While I definitely ran out of time on some of these things, I was able to hit all my major objectives, commit about 3 hours to writing music (I ended up not having time to write music last time) and do enough testing that things were stable and worked. It did get a bit stressful toward the deadline, and I wish I had taken a bit more time to write in-game instructions/narration. But I did get the game released on time, in a working state.

Observations

After I started play testing other people’s games I realized that maybe an introspective, open-ended exploration game with an obvious linear goal and a bunch of secret interesting goals may not be the best design for Ludum Dare. It doesn’t have a lot of the gameplay stuff people might expect (levels, bullets, power-ups, challenge, death and retry, level design, etc) and it also might seem like a really boring, simple game when in fact there is some added depth there. I tried to add to the game description page and README to clue people in to the fact that the game intentionally seemed simple, but might have more to it, but I’m not sure how well that has worked.

Another thing I learned is that I need to somehow get a copy of Windows running somewhere, even just in a VM. I failed to package my game for Windows which meant tons of people couldn’t play it. Someone named ‘jplur’ kindly created a package, although it turns out that some people had problems, and ‘Jiggawatt’ (a.k.a. ‘ointment’) ended up creating a working one using py2exe. Without these helpful souls I probably would have far fewer players/reviewers, so I’m definitely grateful to them. In that vein, if someone has a python game that they want packaged for Mac/Linux I’d be happy to try to help!

That said, I have gotten a lot of nice feedback, especially on the music and look-and-feel, both of which I felt like I lavished time on. While I will probably aim a little bit higher next time I do like the fact that I created a game that feels pretty polished and playable, even if it has retro conceits and is kind of atypical. I doubt I am a serious contender in the overall category, but I hope to do well in the audio one.

Final Thoughts

To those who felt like they ended up with a lot of bugs or a game that wasn’t very playable, I would encourage them to boil the game down to its simplest systems (e.g. the “feel” of jumping, catapault physics, etc) and spend a lot of time early on making sure it feels good. Last time I was fixing weird bugs and trying to smooth out feel right at the end, and I never really got there. This time I put more effort into those things up front and it showed. Even if your game only has one level, if that level is fun to play and feels right, people will enjoy it.

Thanks to everyone who participated in Ludum Dare, chatted with me on IRC, reviewed games, and especially those who offered packaging advice and helped package the game. I hope to release a 0.2 version with more involved plot/story/secrets, maybe some sounds, and better instructions.

Take care, and dare to Ludum Dare!

Just a heads up that I’ve been out of town since the end of the compo, and will be posting a post mortem when I get back (in a few days).

I’m sure everyone has been holding their breath in anticipation!

Creating a game is a passionate experience. Doing it in 48 hours is equal parts divinity and torture. As such, a lot goes down during the development process, laughs are had, tears are shed, and ultimately you arrive at the end product – your game.
Well, maybe I’m being overdramatic. But you definitely learn a lot upon completing a development cycle, even one as short as two days. The post-mortem is a great way to share that knowledge, imparting wisdom upon those who seek it. In this I’m going to examine what was successful, what were failures, and what just plain drove me nuts during my development of The Man Who Sold The World.

Play The Game Here

The Good

Level Design Workflow (or “Levels are the meat of the meal“)

I had an excellent workflow for creating levels in TMWSTW. One of my favorite aspect of game design is creating levels, so I made sure that process would be as smooth as possible. This meant creating a method of designing, developing, testing and finaling levels in a minimum of time.

The first thing I did was create the character and camera systems, including physics and collision detection. This allowed me to get right into levels, as I knew how my player acted and moved within the first wee hours of development. The result was over a dozen enormous, hand-crafted levels that made it in-game; not only created, but tweaked and tuned for an ideal gameplay experience.

I had the time to fully explore what I wanted to with my level designs, creating many worlds in different environments, and even get experimental with more abstract locations. The process was effective, informative, mentally invigorating and, most importantly, fun.

Source of Inspiration (or “Why the Repeat Button is Your Friend“)

You’ll notice upon launching TMWSTW that a splash screen reads, “Inspired by David Bowie’s conceptual album and story, ‘The Rise and Fall of Ziggy Stardust and the Spiders From Mars’”. That’s there for a reason – it may sound silly, but I listened to David Bowie’s “Greatest Hits” album on repeat for nearly the entire Ludum Dare – having it on repeat allowed those songs to be constantly in my consciousness, influencing my design choices. Having that aural feedback not only encouraged me to keep working, but did wonders for keeping me focused and following a coherent vision for the game.

I did the same thing when I developed Nyan Cat FLY!, listening to the Nyan Cat song during development – I’ve spent over 100 hours of my life listening to that atrocious tune, but it helped the game reach its final state. Nyan Cat FLY!, like the meme itself, is cute. TMWSTW is, like the story it’s inspired by, an epic tale about the decline of humanity.

Plus, Bowie is pretty rocking, and helped me get through the long hours of the night.

Audio Design & Implementation (or “If it’s there, use it!“)

I’m proud of the audio in TMWSTW. I spend a liberal amount of time creating game audio tracks, and like to think I’m getting better at it. I primarily use Sony ACID Music Studio 8, of which I’m lucky enough to have amassed a liberal amount of assets I can use to develop custom music. However, that’s just so much bandwidth-drinking data unless you can get it to actually sound off in-game. Flash is notoriously awful at handling audio effects, and I didn’t want to struggle through creating my own audio manager in AS3.

This is where external classes and APIs come in. Guess what – you’re not the only programmer in the world, and other people have come across the same problems. I wish I’d realized this sooner, especially for audio. Matt Przybylski has creating an amazing tool in the AS3 Sound Manager v1.4, which controls the sound in TMWSTW (and all future AS3 krangGAMES projects). Unfortunately I implemented this system fairly late into development of TMWSTW, and had already lost time trying to foolishly use my own code. Had I gone straight for Sound Manager, I could’ve saved plenty of time and effort. I won’t make that mistake again, and if you ever use audio in AS3, I highly recommend looking into it.

The Bad

Unclear Art Direction (or “Know Your Limit, Play Within It“)

By no means am I an artist. I have a confession to make: while my LD19 entry PRIOR won 8th in graphics and was lauded in being beautifully stylized, the art is only the way it is because at hour 47/48, I realized, “Oh, this game needs some better art than the debug stuff.” I then proceeded to slap a gradient texture on every background I could find.

However, that was not the case in TMWSTW. Forgetting that I’m not an artist, I -wanted- to make custom retro/pixel art for every environment in the game. Ultimately, I lost several hours of work to something I ended up simply not using. The pixel environment art I made was ugly, low-quality, and took far too much time to develop (especially including the process of moving from Photoshop to Flash, then implementing it into the game). I finally abandoned that vain attempt, and moved to Flash-generated stylized art, similar to PRIOR (though, thankfully, with a bit more color. I’m kinda getting sick of black-and-white, and actually spent a few hours on the art this time.)

The moral of the story: Don’t be something your not. If you have to, do it in the easiest way possible.

Misallocation of Time (or “Why Your Brain and Time are NOT Friends“)

In Ludum Dare, time is not just a commodity, but a deceptive bastard of a resource. What I mean is, your psychological interpretation of time is never representative of true amount of time left. Even when you KNOW that you’re running out of time, you can still very easily lose track of it and waste it on badly prioritized endeavours.

If you’ve been reading this post-mortem through, you know how much time I lost working with audio and Photoshop (more on Photoshop in a moment). This happened primarily because I misjudged both the amount of time required on these tasks, and the amount of time remaining. Admittedly I’m vastly unfamiliar with Photoshop and couldn’t make a proper work-time estimate there to save my life, but that’s a poor excuse for losing the number of hours that I did. Estimating time and collecting those estimations into a proper timeline is incredibly difficult, and it’s all too easy to misjudge that and stray too far from the path of your development.

I suppose the best method to avoid this tragedy is to quantify everything you have to do objectively, at the beginning of development. What I’m going to do for the next Dare: create a task list of everything I need to do and estimate the time it’ll take to do it. Then add 15% to those tasks. Then reserve at least six hours for polish and miscellanea, and strip away everything of low-priority that pushes me over the 48-hour timeline. Hopefully, that’ll keep me on time.

Lack of Sleep (or “Quality Is Better Than Quantity“)

Here’s an unsurprising truth: you lose sleep in Ludum Dare. There’s no way around it, making a decent game in 48 hours will suck away time like nobody’s business. Spare time doesn’t come from nowhere, so if you want to make a decent product, you’ve gotta cut something away, and sleep is the most obvious victim.

Don’t get me wrong – there’s nothing wrong with that, at least from the Dare’s perspective. Staying up late can be fun, as any eleven-year-old would attest, and the constant flow of energy and creativity that arises from game development is exceptionally invigorating.

But there’s an fine-yet-extremely-important line between sacrificing sleep and neglecting your needs. Time limit or not, your brain needs sleep, even if only for a few hours. Staying up too late under a naive notion of “If I sleep, I won’t have time finish” is one of the most dangerous things you can possibly do.

Lack of sleep will take its toll, a far worse toll than spending three-hundred minutes unconscious will. Your focus will drift, your quality of work will decline, and your overall product will suffer for your self-negligence. Taking a four-hour powernap and a shower upon waking up will do far more for your product than an extra five hours of half-baked development, followed by more hours of ever-increasing tiredness. At one point I was falling asleep at my computer – it sucked, and my game knew it. So learn from my mistakes. Go take a nap.

Either that, or adopt the Uberman Sleep Schedule.

The Ugly… Sotra

Theme Interpretation (or “Livin’ By Your Own Rules In Someone Else’s House“)

The theme for Ludum Dare 21 was “Escape”. I’ve noticed that people tend to treat the theme differently. Most people take it literally, which is fine, and often produces some pretty excellent gameplay experiences (such as NMcCoy’s excellent “Planetary Mission“, which I recommend trying out). Others view the theme in a different light, more like a guiding star than a criteria point.

This is how I viewed it in TMWSTW. Make no mistake – “Escape” is the dominant theme in my game, and it’s represented metaphorically through the player’s final actions in the game. This is not some kind of excuse for my game design, nor is it an attempt at being a pretentious douche. It is simply my interpretation of the theme, and how I chose to represent it through a video game.

Ludum Dare Compo Rule #3 states “Games must be based on the theme.” Ludum Dare is all about rapid development, and creating a product out of unfiltered passion. Basing the entire development cycle on a theme, like what the Dare has done, is ingenious, and manipulating that theme in your own fashion is an exciting thing. No matter how you interpret the theme, you’re taking a universally acknowledged concept, and making it your own. So do so however you see fit.

F**k Photoshop (or “No, seriously.“)

Please, bear with me for a moment while I depart from a more eloquent dialog and instead relinquish to the world a personal opinion that I hold, in the most base and understandable form possible:

F**k Photoshop.

For real. I love Adobe, I’m a huge fan of Flash (as anyone who knows me can attest), and the entire Creative Suite is a great product. But Photoshop and I have a beef, and I’ve gotta address it. I’ve stated on several occasions that I am NOT an artist, and as such I don’t pretend to have any level of skill in Photoshop, or Illustrator or even creating advanced artistic elements in Flash. But I do know a thing or two about product design, and creating features for users of all skill levels.

In this case, the chip on my shoulder comes from Photoshop’s inability to mass-modify colors on different layers, and then export them. You simply cannot find-and-replace colors on multiple layers (or at least, after a few hours of forum-sifting, I couldn’t find a way). As my player character had many different layers for animation, this was a huge issue. I could simply place a layer mask that changes all layers beneath it, sure, but then you can’t mass export those assets – the layer mask is not included in the export, and only default images get created. Ultimately I made a keyboard macro to duplicate the layer mask, combine it with the layer below, export that layer only, delete the layer, and move the original mask down to the next layer. Lather, rinse, repeat – a major pain.

I lost over four hours to trying to change BLACK and WHITE to ORANGE and BLUE. Four hours. Now, feel free to go off and rant, “You were using a poor method/That’s easy to do if you know how/there’s technical reasons it can’t be done/You’re a PS noob!” or whatever other retorts you may have. My point is, usability design has to take novices into account – a program SHOULD be intuitive enough that users can perform simple tasks. And replacing one color with another should be a simple task, and it is, if you’re only working on a single layer. I’m no slouch when it comes to finding solutions on online forums or hunting for methods of completing tasks, but when it takes you over four hours to jury-rig an impromptu solution to a presumably simple issue, I’m left at the conclusion that Adobe dropped the ball. Photoshop is a great program, but it’s far from perfect.

</rant>

Scope, and Knowing Yourself (or “The Uplifting Conclusion“)

I think I’m masochistic. Maybe that’s more than you wanted to know, but that’s the only explanation for the decisions I make during Ludum Dare. I’m constantly pushing myself beyond my self-determined reach in terms of development. In Ludum Dare 19, I crafted a facility larger than a standard city block and populated it with a complete, twisted back story. In LD20, I created a fully-functional level editor and allowed players to not only take the game into their own hands, but record the fruits of their labor and share them around. And in LD21, I wove a Universe. With David Bowie at my side, I explored love, spirit, daring, and the fate and frailty of humanity.

Those lofty reviews aside, the point is I established the scope of my development as HUGE. I did this intentionally, for a few reasons. One reason is, I simply love creating stuff. “Stuff” is the correct word there: I love creating levels, NPCs, obstacles, stories, music, everything that goes into a game experience. So I set ludicrous goals for myself, and push myself beyond my reach. It’s risky, and it isn’t for everyone, but it’s how I generate the best personal results (usually).

The point I’m trying to make here, is be true to yourself and your habits. Take every bit of advice with a grain of salt, and find your own best practices. Biting off more than I can chew works for me, but it can be catastrophic for others (just as trying to do pixel art nearly did me in, while some people are savants with retro graphics). We’re game designers. Only through creating games can we get better at our craft, and only by being true to ourselves can we really create a game. Anyone can build a game, but to really create an interactive experience, you have to play to your skills, nurture your muse, and be true to yourself. That’s where games come from.

In summary: David Bowie rules. F**k Photoshop. Thanks for reading. <3

<3 Nick Yonge
Founder, Director, MCS-EOOEJ, krangGAMES
www.kranggames.com
nick@kranggames.com
Facebook ~ Twitter

Well, I finally got my entry, Fred the Astro-Miner, compiled for Windows! It was such a pain! I tried Visual Studio, but after spending hours modifying my (valid) C++ code so it was happy and finally compiled .o files, it refused to link. Hours later, it linked. And it didn’t work. I threw more hours of work into it and then I got a window to appear! Yay! But it always segfaulted at startup, no matter what I did -_-

Then I thought,”Why don’t I use Eclipse and G++, like I do in Linux?”. So many more hours later, after compiling GLEW from source and remembering to use Mingw libs instead of VS ones (!!!) I got it to work! Then much jumping around my room screaming with excitement ensued (I’m not joking. I was that happy). I didn’t need to modify my code at all by the way, except for replacing gl.h includes with glew.h. I’m pretty happy with that!

So you can check out my entry here, now in Windows!

http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=4920

I’m fist-deep in the Director’s Cut for my LD21 entry (“and just like that“), and I just finished off some music for the challenge mode.

Check it out here (note that the first bit IS EXACTLY the original piano exercise sounding melody)