my first ever competition, and i’m pretty happy with what i achieved. although it didn’t look or play as i had originally imagined (mostly because of a lack of artistic ability) and i got stuck on some very simple programming, it feels good to have a game out. had some positive feedback too, including:
– is it supposed to be so pink?
– it made my ears hurt
– i want to barf
– so where exactly is the “game” aspect

really selling my game here. here’s the link if you want to play it.
http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=5579

i’ve found some really great games too. some people have mad skills. i’m tearing through my random ratings. the WYSIWYG blog post thing isn’t working right at the moment, but keep playing the games here, there are some genuine gems!

Is it allowed to fix a level bug?

Astar Postmortem

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

Tools used

Flashdevelop – $0

Flashpunk – $0

PXtone – $0

ASEprite – $0

Postmortemdinner – $16

Total cost – Not going to laser-tag with my friends on Saturday D:

Learn from my mistakes –

– and don’t leave butternut squash soup out for 48 hours, it goes bad. Also, making games is hard:

The first risk I took was implementing the A* pathfinding algorithm into flash, which beforehand I had only ever done in Gamemaker, and that was a looong time ago. So I opened that up for reference and away I went.

The first implementation “worked” but had some sorta hilarious path results. I wish I had a screenshot but it looked somthing like this ->

My professional representation of pathfinding gone wrong

The Second issue was sound. I knew I needed music and I had a nebulous idea of the type of feeling I wanted from the music. “Puzzle-y music” I thought… “Puzzle-y music”… So I started to fool around with some violins and realized I sucked at that. So I ended up using my old friend the Sin-wave and was glad I did. It took about three tries before I had the sound I wanted.

So I suppose the lesson here is to experiment, because my favorite part of this compo/exercise is the risks I took and learned from.

blah blah blah, you can play it here.

P.S. I secretly have a crush on every participant, don’t tell. Great job everyone!

After breezing through two previous LDs, I felt this time I should push my game design out a bit further, both technologically and in design. I wanted something that I knew would be challenging; not just a game I knew I could complete in the timeframe.

With this in mine, I added some goodies to my game such as an upgrade system, expansive map sets, multiple weapons, and complex enemy types. I looked at parts of games I loved and used them as foundations for various game mechanics. In the end I had a lot more than I could hope to achieve, so i had to trim some fat, and began coding.

At first progress felt a lot slower, dangerously slow compared to previous LDs. I was worried I wouldn’t make the deadline so I trimmed out multiple weapons, shortened the game a bit, and scrapped additional enemy types. I figured I could add these back in later as time allowed.

When I woke up on Sunday I was pretty unhappy with the game. The nature of projectiles made them frustrating when facing Banshees, which were the most common enemy type in the game. I tried nerfing the banshee’s move speed and changing the movement patterns, but nothing really helped.  The game had content and was going well progress wise, but it wasn’t fun. I actually considered throwing in the towel here.

After about an hour of level design to take my mind of gameplay, I had a bit of an epiphany. Prior to LD I had been playing Quake 4, and started drawing connections to my gameplay flaw and my frustrations with Q4’s nailgun. Ultimately the machine gun worked better in Q4 due to not giving Strogg any time to dodge your attacks. While the AI in my game didn’t dodge, the movement patterns were hard to properly lead. So I changed the player’s gun to an instant fire laser.

Everything just clicked at once. Suddenly you could easily hit most targets with minimal issue if you lined up your targets well; and early game energy limits prevent you from just spamming down everything in a quarter of a second. Upgrades made you choose between various gameplay styles. The aiming mechanic of enemies made sure you couldn’t just camp one spot and shoot when everything lined up; but instead rewarded you moving WITH the banshee, constantly leading its shots but still keeping lined up.

After taking some time to balance upgrades and flesh out some levels, I was cutting it a bit close so I ran a final polish run on the level set (though I would have liked to expand it), and submitted.

In the end I have mixed feelings about the final result. The endings aren’t really “proper” endings, and there’s no menu/config/pause/etc. It feels incomplete to me. But despite having some spare time at the end where I could have mocked up some quick simple menus, I was sick of coding it when I submitted; and I felt that a rushed menu would be worse than no menu at all. On the other hand it’s a lot more than I could have done previously, so as a progress indicator it’s great. LD is never about winning to me, it’s about seeing what you can do. Testing your limits and learning new things. Seeing what you’re capable of…. And in that regard it’s been a roaring success.

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

I’ll see you nerds in October :3

Here it is. I kinda screwed it up though when I stopped and restarted chronolapse…sometimes it didn’t record. So some hours are missing. Better luck next time, and I’ll try to have one of these neat on screen clocks.

 
My entry: elastic prison

Tags: java, lwjgl, timelapse

Poor Ball - Click the image to rate the game !

Poor Ball – Fififox – Competition Entry

Now that the stress of coding/packaging/testing/submitting is gone, the time is right to sum up what I’ve done, the good choices and the bad choices.

What I’ve done right (based on my previous and first LD experience, LD19):

• I finished my game (I haven’t been overly ambitious);
• I only made graphics and sounds after the game was working;
• I made something (relatively) nice and with good sound effects;
• I made a title screen and wrote a short story to introduce the game mechanics;
• I spent time on IRC, but only time which I didn’t miss as the deadline approached;
• I didn’t feel stressed until the very end !

What I’ve done wrong:

• I thought that good ideas would come by browsing dictionnaries and wikipedia and probably lost time by not really concentrating;
• I got used to my game’s difficulty and didn’t see that removing the two easiest levels was a bad idea.
• I spent a long time trying to repair a library instead of just replacing it by another one directly;
• I tried to cross-compile my game and the libraries I was using instead of booting that old slow Windows box.
• I should have written more progress reports instead of being on IRC for time.

What I’ve done during those days:

First day:

• 9 am (theme announcement at 4am for me): Woke up and looked for some ideas using theme list / dictionnary / wikipedia;
• 10:00 — Created a base system in C++ with SFML2;
• 10:20 — Thought, not looking at the computer;
• 11:00 — Tried to write down an idea;
• 11:40 — Threw that idea away and thought again (also played prototypes seen on IRC);
• 13:00 — Back to code, looked in detail at the SFML API;
• 14:00 — Suddenly had an idea: posted the idea on LD blog and started coding like mad;
• 14:45 — Had the basic physics working, so screenshot and lunch on LD blog;
• 15:00 — Kept working on physics;
• 16:00 — Took a break;
• 17:00 — Back to code, added controls;
• 17:30 — Created a minimal user interface, worked on graphics;
• 20:00 — Had the physics working, posted progress report and screenshot on LD blog which is getting slow, tweeted, talked on IRC;
• 20:40 — Created some bad background music (removed from the final game, was very bad 😛 );
• 22:00 — Tried to get music working, SFML uses OpenAL, which is apparently badly broken on my computer, tried to find a solution to that (but I didn’t);
• 02:00 — Stopped searching, went to bed.

Second day:

• 08:00 — Woke up, 20 hours remaining, eating some croissants (yeah, I’m french 😀 );
• 08:30 — Took a crash course to use FMOD for sound in my game, and set up background music;
• 09:00 — Heard about LD server failure;
• 09:15 — Tweaked physics and changed gameplay idea, implemented some GUI;
• 11:40 — Added some graphics;
• 11:45 — Fixed a race condition-related segmentation fault, added levels, lives and death to the game;
• 13:30 — Got tired of adding game code to the physics thread and edited some graphics;
• 13:35 — Talked on IRC and looked at some other sound libraries;
• 14:00 — Got back to gameplay, and eventually broke the whole physics/gameplay thing, causing dead locks every now and then, but somehow I got it working nearly seemlessly;
• 15:40 — Talked on IRC, helped testing some games;
• 16:20 — Wrote a progress report on the really slow but working LD blog, while still talking on IRC and failing at finding FMOD documentation on compressed sound;
• 18:00 — Added code for sound effects and created some, which made me remove the background music;
• 19:45 — Refactored a part of the physics code to remove an old feature which looked more like a bug from the outside;
• 20:10 — Created other sound effects, reworked the sound load/play system;
• 21:00 — Talked on IRC, posted an update on the LD blog, and tweeted;
• 22:00 — Rewrote the GUI and added a graphical title screen
• 00:00 — Sumbitted my entry with description, screenshots, sources and Linux x86_64 executable.
• 01:00 — Wrote a post about my entry on the LD blog;
• 01:10 — Talked on IRC and started packaging for Windows and Linux i686;
• 03:00 — Read about FMOD’s API on Windows which doesn’t support C++ (only C) when using MinGW, converted the source to use FMOD through it’s C API, compiled, packaged and sent;
• 03:30 — Reuploaded different versions with more and more libraries for people to play the game just by unpacking and running: thanks to people on IRC who tested my game until the very end, at 04:00 for me !
• 05:30 — Encoded my timelapse and posted it on Youtube and on the LD blog.

Tags: postmortem

As most people say they find my game too complex decided to make a little video of my passing it and give few advices.

Here is the video:

And some advices:

• Use space to pause the game and issue many commands at once
• Remember about center of mass when you try to push
• Relaxed parts absorb shocks, stiff ones bounce, so its a good idea to be relaxed when you don’t want to bounce, or stiff all parts when you want to push with maximal force
• And it is space, if you are flying in right direction just relax and wait, no need to go crazy and ruin your right direction

Hope this will help some.

Go to the entree page and try yourself 😉

Tags: gameplay, video

I’ve been looking at the LD compos for a couple years now, always wanting to do one, but due to various life events (generally, caring for my toddler) I was unable to join in.  This year was different.  We were on vacation, and would be driving home on Saturday.  This gave me 5-6 solid hours in the car to work on it, so I figured, why not!

Once the theme “Escape” was given, I was instantly unable to figure out anything.  I knew I didn’t want to do a standard, expected type of game… something predictable.  And I knew that I would be writing it for iOS, meaning that basically 98% of the reviewing audience would likely not be able to rate it, instantly guaranteeing that I will not come anywhere near placing… which is fine.  The reason to do this is to do it… to get my brain working… to get something accomplished… and I did.

I started thinking out of the box a little.  Journey had an album called “Escape”, containing the hit “Don’t Stop Believing”.  Seems like a good point to start with.  But honestly, I didn’t really settle on this until Sunday morning.

I spent Friday night thinking about something to do, a game mechanic or somesuch.  I also got the git repository started up, and came up with a codename for it in my current codenaming theme, cheeses.  “Raclette”.

Personally, I find that I can’t get started on a project until I have a name for it, and can start the source repository… so I started using code names with a cheese theme.  It works for me.  It let me get the project going, and got the process of naming it out of my head so that I can just start working on it.

Saturday afternoon, in the car, first I made an icon for the game, a fancy “R” for Raclette.  I know this seems like the wrong order to do things, naming it then giving it an icon, but it was necessary for the way my brain works.

Next, I started up the Xcode project.  OpenGLES template project, removed GLES2, added BL2D (my 2D sprite and tilemap library, released last fall), did other general GLES2 cleanups.  Then I brought in the hooks for the BL2D engine, cleaned up the sprite and tilemap PNG spritesheets to bring them back to “font only” condition, to satisfy the rules of the compo.

Note: all of this is visible in the following timelapse video, 0:00 thru 0:23 or so.

One of the other things I added in the car ride was the game state engine.  After working on “The 7th Guest: Infection” I came to realize that for the way I work on games, having the state engine in place earlier rather than later is very much welcomed.  I had worked on a state engine for a game last week, so I essentially worked out a new version of that from scratch.

At this point, about 6 hours of work in, we got home.  I spent much of the evening helping out around the house and unpacking.  I got a few extra minutes in to integrate the tile/sprite engine a little more.  I

Sunday, I was able to spend a lot of time in the afternoon to work on it.  I managed to somehow clean the entire house, and play with my kid beforehand as well, so that was nice.  While doing all of this, I thought about a game mechanic that involved clicking or drawing on the screen, and it color cycling.  I wasn’t sure where it would take me, but I felt it was an ok place to start.  It was also about this time that I almost gave up completely, feeling unable to finish in the time available to me.

Then it hit me.  The lyrics to the song were the basis for the game.  E5c4P3.  Don’t Stop Believin. Streetlights, People.  Escape the streetlights.  You’re Steve Perry.. too specific.  You’re Perry.  Got it.  People attracted to streetlights like moths.  When you hit some streetlights they go out.  There we go.  Run around, hit streetlights, people attracted to them will scurry away.

I then spent a lot of time getting simple cheesy people graphics and a horrible streetlight graphic worked out.  Horrible graphics are better than no graphics.  By the time dinner rolled around, i had the basic mechanic of the game working, but no real goals or score or anything.  My wife suggested that the guy gets zapped from the lights.   Danger! Great!  Then I added health bar in a half hour.  Added a few more states to the game state machine for “died”, hook the state paths around, and i have a basic, mostly feature-complete game!

The initial engine effort i made was essentially abandoned, but I did use a remnant from it to do the color cycling background for the intro screens, so all was not lost.

So what’s left for it?  I want to get it into the App store asap, so that people have more of a chance of trying it out.  After judgment period, I’ll be adding in things I ran out of time to do: sound, progressively harder levels, more clever people, graphics for the “street” rather than just black, a time limit, and perhaps high score saving.

I know it’s not the best game ever, but I made it.  I made it in about 16 of the alotted 48 hours to do it.  I know I could do better, I know I have done better, but I started it, I did it, and I got it done. And I think it’s a fairly amusing stretch from the song.

And here’s the gameplay…

Link to the compo page for “Streetlights”. To build it, you’ll need Xcode 4 with the iOS SDK (included with Xcode 4).

If you haven’t, check my game out in here!  It’s bound to get lost among the 599 we got!

Some of my ramblings about the project to follow..

This is the first time I’ve managed to enter an entry to the compo – I’ve tried several times but due to mix of IRL stuff happening and just generally not being able to pull it off I haven’t finished an entry before. I did have to go to work on Saturday this time as well which cost me some time, but hey, can’t help it.

At first my game was going to be something completely different and a lot more gamey, with some puzzley-platforming elements. The thing was, in secret I’ve been working on a platform game and quickly discovered I was doing pretty much the same thing I already had – just from scratch. Repeating the same work I’d already done didn’t feel right to me in a sense, so I decided to scrap the idea and take into a different direction. Plus I knew if I wanted to take it further, I’d have to start building tools and soon all my time would’ve been used on that! Or tweaking collisions.

Instead of focusing on the gameplay, I stripped all the gameplay elements to a minimalistic core and focused on writing – however much there is of it -, art and sound. My intention was to also make something I could release quickly, though in the end, that proved not to be the case as much as I initially thought!

I had bounced the theme Escape around in my head and had a concept about a guy locked in his room in deep depression. Dunno where it came from, but there you have it. At first, the idea had some grim turns with suicidal implications but I thought taking it that route might be going too far. Instead, I wanted to portray the idea of seeking help.

Basically, the intention is to get the protagonist out of his room. The game has two phases, dark and light. Dark phase is meant to represent the protagonists current “true” state of mind, where the whole world is bleak and dark and in this phase, escaping from the room is actually impossible, as the character is unable to function normally. Every action takes an extra effort. The way I went about this was implementing a hidden meter which increases every time you try to use an item until the main character finds it in him to pull through the action. At first even moving was implemented by forcing the player to tap move buttons while in the dark phase instead of letting them be held, but during playtesting I soon found it a bit annoying so for my own sanity I just made the PC move at half speed while in the dark phase. The protagonist’s fears manifest as monsters which attack him raising his anxiety, if he stays put. So he has to keep moving to stay functioning, which is one of the concepts I wanted to explore a bit. If he chooses to stay, eventually the monsters of his mind overwhelm him again.

The one way out is by grabbing the healing item, which calms the protagonists inner turmoil, his anxiety level resets and his view of the world shifts more to a normal one. This is represented in the world by the world outside the windows turning light blue instead of black, and black clouds turning white. Now he’s able to open the door and leave his room. But I wanted to portray that while he’s out, he’s not okay really… yet. The sky’s still cloudy with no sun to be seen. Also the song that plays as the screen fades out is slightly distorted.

Holy crap reading what I wrote I do sound like an art douche, goddamnit.

What went wrong

There are some things I didn’t get to implement. I planned to make the house represent the main protagonists level of anxiety, with walls pounding and moving in a heartbeat like fashion in the dark world – accelerating as the anxiety levels climbed. My intention was to present the house in more of an organic manner that way while also solving another problem – lack of any on screen indicators for anything. I didn’t want to make a HUD or any indicators for the fact that it would make my game more game-like.

I also initially had a bit more interaction in my game but took nearly all of it out due to my implementation not really liking having too many objects which would overlap in x-dimension. Also, no indicators for what you’d be interacting with, again. A problem I didn’t get to solve in time.

I think the game is a tad too obscure or artsy to really get into. It certainly is not fun, but it’s not intended to be.

I also got a bit sick during the LD, so there’s that!

My code is awful. No surprise there! During the second day I really just decided to do some pretty ugly stuff, just to get it done and over with. Oh well!

What went right

I got it done! Hell yeah!

I managed to implement most things I wanted to. I have an actual soundtrack. I have hand drawn animations. I have hand drawn graphics. Those are the things I set to do, those are things I did. Quality is another matter!

What’s next

If I choose to go back to this thing, first thing is to clean up the code. Then I’m going to implement rest of the features I missed and maybe even some gameplay. Sky’s the limit. Well, Skyrim’s the limit. Once that bastard is released I’m unable to do any actual work…

Other than that, I’m going to be working on some fun things. I have my github at github.com/shinD and my webpage at digitalcheeseplate.com or conspiravision.net and if I get something released, those are the places to find about them!

Tags: postmortem

This was my first (but certainly not last) Ludum Dare participation, and it was a real blast. I had already made a game in 48 hours but it didnt have the same thrilling atmosphere I found on the IRC channel and on this blog. I think it was quite epic (in the original sense of the word) to see hundreds of people struggling against time to get their games (or website) running before the deadline. Thank you all that was great !

And now for the Post Mortem. I kept a text log of my activities so it should be pretty accurate. I got up on saturday at 10, 6 hours after the beginning of the compo and the theme did not inspire me much. I tried to think over it during breakfast and shower but it didnt bring much of an idea. Three quarters later, I ended up deciding I would make a somewhat conservative platformer featuring vertical gameplay in procedural levels to escape from rising water. My scratchpad also had a few notes about a science fiction game involving unlocking gates before some ship autodestruction, but that’s probably because I was listening to Farenheit Project Part 6 at that time.

I spent the rest of the morning in photoshop, producing base graphics to get me started. I know most people like to start coding right away and make games with red and blue rectangles, that’s probably a more reasonable thing to do but it doesnt motivate me as much. By lunch, I had the most important assets of my game : Ernest, a jewel, three platform tiles and two water tiles (none of them animated). I think that’s about the time I posted my journal entry =)

The afternoon and evening were spent coding the core mechanics (platforming, dying, changing level) and animating the graphics. I gave up procedural generation quite early because I found it would take ages to get it to make interesting levels. I think I avoided a major pitfall there. After that, I ate tons of food (as in 400g of pasta + sauce) and drank enough beer to get motivated for the rest of the night which was spent level designing until 5AM (I made the first 10 levels in that period. Yes, this also means I got the idea of the balloon level around 3AM after lots of beer).

Since I did not have a map editor, I set up a crazy workflow (image below). I made an “editor” image in photoshop which was simply a big file with grid enabled and some measurements added on the sides. I drew my levels in this file, then measured everything and hardcoded the data in the game.

At that point, I was too tired to make more levels so I made the title screen instead. It had an artwork but it was so awful I trashed it away (that’s the only thing I did not keep for archives’ sake). Then off to bed for 5 hours.

I woke up at 10AM again and I felt more motivated than ever. I’m sure the neighbours loved my speakers and I blasting WHEN I’M UP I CAN’T GET DOWN, CAN’T GET DOWN !” super super loud. Designing the last five levels took me a while and they were done by 3PM. I made the end game content ((terrible artwork), congratulations message, credits etc.) and from this moment on, the game was playable from start to finish. I was still considering the addition of more levels but I had basically run out of ideas around level 11 or 12 so it didn’t happen.

At this point, I thought I should start making music but I really wanted to add torches in the background. So torches time it was. I quickly made them in Photoshop and started adding some torches to the first levels. the problem is that I had not saved some of my photoshop level sketches and that it was very hard to guess the coordinates where I should put the torches. I came up with another dirty trick for this : I made a debug build where the character had infinite jumps, could not die, and would output his position to the debug log when I pressed “T” (for “Torch”). I flew around the levels and hit “T” everytime I was on a potential torch position and then I got all the necessary coordinates from the debug log. The entire process took only half and hour. Pfew.

I spent the next few hours making the end game music (which was supposed to be the title screen music at this point) and the main music. Then a friend of mine popped in and I tied him to a chair so he would play the game on and on, reporting bugs while I was fixing them. Since I still had a bit of time, I made a different music for the bonus level, changed the title screen, added the oxygen gauge someone suggested on IRC and polished a few things. Of course, the huge collision bugs (falling through elevators) started showing up 1 hour before the deadline and I hastely hid them the best I could by slowing the elevators and called it a night.

After submitting the game (20 minutes before the deadline), I laid back on my chair, removed the cap on my very last beer, and there was a huge grin on my face. I felt a fantastic sense of accomplishment as I was leaving the almost trance-like state this competition (and beer) put me in. The game was far from perfect, but I was still baffled by how much content I had made in comparison to my previous 48h competition.

What went well :

• Having a dedicated tester. Having someone spending more than a couple minutes testing the game was very very helpful because it saved ME lots of time and brought to my knowledge some bugs I would never have seen. Hanging around IRC was also very helpful.
• Bacchus. This competition was a great occasion to try using my custom HaXe game framework and see if it was really usable. Turns out it is. It never got in my way and provided lots of useful features and some useful error messages.
• Sticking to an idea. Almost all of the work I did ended up somewhere in the game. The only things I wasted are a shitty artwork, 30 minutes of code trying to generate procedural levels and a crackled tile.
• Rushing art. I consider myself a very slow artist, I like to polish things for hours. The competition made me rush things and I think it doesnt show too much. Picking colors super fast turns out to be a decent alternative to carefully selecting them, it did yield surprisingly good results.

What could have been better :

• Theme and game idea. I did not make much out of the theme and my game is very classic. I had the same problem last time I made a game in 48 hours so that’s something I’ll try to improve next time. Thinking outside the box is a quality I envy.
• Preparation. I had problems making Chronolapse work and gave it up. If I had done that a few days before I would have a sweet timelapse by now. I also did not do the weekly shopping before the compo so I ended up starving on Monday night. No good. Also, I should have borrowed a screen because making a game on a single 15″ screen is not very comfortable.
• Spaghetti code. My code started nice and clean, but as time went on, I allowed myself more and more dirty hacks. It’s still ~readable (at least by me) but definitely NOT pretty. I would probably have had the time to notice and fix the remaining bugs if I had been careful all the way through.
• Level design and balance. I’m still in the process of collecting feedback but most of the issues raised so far related to level design and difficulty. I agree with that and I think a few levels are very uninteresting. There are a few ones I like a lot though.
• My favorite bug. If you listen to the end game music, you’ll notice that the lead instrument doesnt play in your right speaker. Here’s the reason why :
  

TL;DR : I love you and I love LD.
And here’s my entry.

Resources used :

The Planning (or Lack Thereof)

It’s funny the way things turn out. Every time the contest comes around, I hope that I have honed my game-making skills so I’ll really be ready to make something great. The reality is that I only make games as a hobby and I don’t have that much time to spend on it, so I’m always ill prepared when the time comes. I think I know what language and framework I’m going to use, but I’m always watching the board to find that Magic Bullet to help allow me to spend more time making the game and less time on all the other crap.

So this time the Magic Bullet that would save me was Stencyl (at least I was praying), which I noticed in posts on here a few times. It is a tool that lets you make games without coding. It is one of those, do-it-all game making environments like GameMaker, Multimedia Fusion and Unity. Out of those three I only really like Unity, but I don’t think it’s ideal for contests like this one because 3D tends to add a lot of complexity that can keep you from making a great game in the time frame allotted.

Stencyl is a java based IDE that generates flash games. Internally, It uses many popular frameworks such as flixel and box2d. I guess the idea of it is based on some sort of MIT project. Basically it lets you code your game with “lego-like” blocks that you drag and drop around. Here’s the funny thing. It actually works. It saves time. And it’s fun. It lets you visualize all of your code in one page, which is pretty amazing.

The Coding

Wait, there was no coding actually. I wrote not a single line of code. Now you can do that with GameMaker and such, but I always found them limiting. Building your game with Blocks in Stencyl did not feel nearly so limiting to me. Here’s the thing. When I started I knew nothing about Stencyl. The first thing I did when the contest started was build the 15 minute game which allowed me to create a few actors and behaviors and create a scene. I had something working immediately.

But I had no idea of what kind of game to make. All I knew was that I wanted to make something that looked like a classic arcade game. I was tired with doing experiments and weird stuff and wanted to try making a platformer for the first time ever.

Scratchy Get Out actually just came about through playing with the actors, deciding to try something, creating an actor or behavior, and seeing how it turned out. I was amazed at how quickly I was able to add AI details that I never would have had time to do if I were just coding this in FlashPunk. Every actor has multiple AI behaviors. All of the behaviors are simple but there were so many, that the game started to develop into something I had not comprehended before. I was very simply able to lay out accurate collision boxes (or other shapes) and control what actors interacted with what. For example, the crane was probably the most complex AI. It could catch boulders or players showing different animations for each action. When it was loaded, you could control it. It passed messages to tell the player to halt all movement. Then you could release the object the crane was holding (actually the crane created the object) and it would reset itself and reactivate everything. I know from my past experiences, that I’ve never had time in one of these contests to delve into such AI details and polish things as much as I was able to.

The thing is I didn’t have that much time so I was only able to do one level. I had to do all the graphics (including animations) and I barely had time to create some sound effects with SFXR. But later I made another level. A totally cool indiana jones style levels with falling boulders that would shake the screen when they hit the ground. I think I could easily pump out ten more fun levels today if I set my mind to it because stencyl makes level design so ridiculously easy.

And even though Stencyl was easy to learn, I did learn a ton over that 48 hours. If I was to redo it, I know some things that could probably cut my work time in half. I’m now aware of some things I was doing the hard way or incorrectly that should be much easier now.

The Graphics

I am really crappy with graphics. Stencyl really helped for this though. What I did was just design my game by picking out placeholder graphics provided by the Stencyl community. I think this has a big advantage to just making quick temporary graphics. I was able to pick out images that I actually liked and enjoyed playing with during development. I think it helped with the actual development because I was inspired by how cool things looked. Then when the game was completely done and I was running out of time, I fired up the Stencyl graphic editor and created my own likenesses of the graphics that were in placeholder. Because I kind of knew what I wanted, it was really easy and I actually think some of my art turned out better than the fine placeholder art (like the cannon for example).

The Sounds

I was determined to get sounds in. Usually I try to do something ambitious with my synths and effects machines, but I just didn’t have time on this one. I only spent about an hour on sound, generating a few sound effects with SFXR which is a wonderful time saving tool. Ok, it’s a classic must have for when you only have ten minutes left in a contest and you want sound! I mean what else is there for that?

What Went Right

Well, everything went right this time. I’ve done this enough to know every time the contest starts, the experience is going to be different. Sometimes it’s going to be easy as smooth sailing and somethings things are going to go so badly that I will want to kill myself (or at least just give up, which I have done more than once). This time I felt very calm the whole time because when using stencyl I was spending about 95% of time actually making the high-level AI for the game. I knew that at any point, I could just add a couple more actors and behaviors and whip up a game of some sort. So the whole time I could just work with total confidence and spend the time adding more and more cool game AI like fun death scenes and little animation details like the player’s head stuck in the crane.

What Went Wrong

I wish I had had another few hours because I really didn’t get to utilize one aspect of Stencyl which is its great level designing tools. Once I had the first level done and the art and the sound and all those actors and behaviors, I could have easily built ten more cool levels in a matter of a couple of hours. I mean, just with the actors and behaviors I created, I left so much on the table that the player will never see that it is kinda sad. Because of that, I’m going to work up about 40 levels or so and release a new version later on. Hopefully it will have the things I didn’t have time for like a menu screen and all the features a game should have.

Final Comments

As always, it was a wonderful experience. I look forward to trying everyone’s games. I hope all of you got what you wanted out of this contest as well. In the end, we aren’t competing against each other, but against ourselves and if there’s one thing I learned is that doing as many of these contests as you can, will only make you better and better at making games.

Since this was my first LD48 I used what I knew. Java and Jmonkey.

What is peoples opinion of platforms to use?

Seems like the web based games are a lot easier for people to access. Maybe next time I should do HTML5?

Well, this was a harrowing weekend. As usual, I decided to shoot for the moon and make yet another adventure platformer type dealie — and I’m happy to say that not only did I finish more or less on schedule, it was the biggest LD48 I’ve done so far (75 whole rooms!). The last time I did this, the result was a paltry dozen rooms or so. What was different this time? The simple answer is: better tools.

One of the biggest hurdles during LD19 (Grand Mystic Quest of Discovery) for me was making all those rooms. At the time I used Tiled; a fine editor with a file format that’s easily parsed in AS3, but being limited to a single tilemap at a time (thus a single room at a time) and a clunky entity editing system made making all those rooms very, very time-consuming. This time, I had a secret weapon; Unimap, a personal tile editor project of mine, built specially for my needs. (The screenshot below contains spoilers, by the way, so don’t look too closely if you want to explore the game yourself.)

A screenshot of Unimap with the Hell Fortress world file open.

I’m not going to harp on about why Unimap is awesome; my point is to say that having a tool customized for you personally really helps in time-constrained situations like this. Every minute spent fighting against your own tools is a minute wasted. So here’s a lesson to be learned: The rules allow you to use any tools at your disposal without restriction; take advantage of that. Don’t limit the kind of technology you allow yourself to use for no good reason. Use whatever tools you are comfortable with that offer the least amount of resistance. And don’t be afraid to repurpose an existing tool if it will help you reach your goal more easily.

The missing Ring item.

Originally, I had planned for a lot more than actually shows up in the game. The place where this is most obvious is the unsightly hole in the inventory between the Dagger and Flute items; there was originally a Ring item that was supposed to increase the number of Talisman projectiles you could fire at one time. If you’ve played the game, you might be confused, since there is no limit to the number of projectiles you can fire anyway.

The plan at the start was to have a lot more combat situations than made it into the final game. My opinion is that any game needs a variety of elements to be successful; even though puzzle-solving is fun, if you make the player spend all his time solving puzzles, he will be burned out. The same can be said for dexterity sections (“jumping puzzles” as some strangely call it) and combat. In short: too much of a good thing is a bad thing. Unfortunately, around Sunday noon I realized there was no time left for me to implement more features (as opposed to producing more world map content).

No new features meant no new combat mechanics and no new enemies, and at that time there was really only the Knight enemy that could be killed at all. In the end, I decided that finishing the game with strong puzzle and dexterity sections was more important than spending effort on rounding out the combat sections. The downside of this was that the Dagger is practically useless and the Ring never got made at all. The upside, however, was important, and that’s lesson two: Don’t be afraid to jettison features if you risk overextending your game design. If I had attempted to finish the combat sections as originally planned, the world layout and puzzles would surely have suffered. If your choice is between two mediocre solutions on the one hand, and one great solution and one kinda lacking solution on the other, choose the latter.

That being said, combat is the part of Hell Fortress that is lacking the most. If I revisit it for a post-competition version (and I might!), that is the first thing that will be remedied for sure.

Hell Fortress has no sound. I have a tendency to skip out on that. If I had another chance, would I go back and make audio a higher priority? Maybe. But it’s a big maybe. This comes back to what I said above; would I rather have some mediocre audio (I have no talent in this area at all!) and risk the rest of the game suffer, or focus on a polished visual experience? I chose the latter, but I don’t know if this is the right choice for everyone.

Somewhat complicating the question is the lack of good tools for generating MSX-style audio, at least that I’m aware. If there’s a lesson to be learned here, I guess it is that if you are unsure of how a feature will come out, it is best to cut it and focus on the things you know will have a strong impact. Again, though, I’m not entirely sure my choice was correct, in the end; the final product absolutely did suffer from its silence. If you feel confident that you can deliver a compelling audio experience, great! Make that your strong feature.

All in all, though, I am very happy with my entry this time around. I hope you all have had a fun time, and made some great games, too! Good luck in the voting!

P. S. My personal record for beating the game with 100% item collection is 77 deaths in just under 20 minutes. See if you can beat it!

“Hold on a minute… ” I hear you cry, “that game wasn’t submitted!”
Indeed it wasn’t… for if I had not been chasing imaginary rendering bugs two hours before the Jam deadline, it would have been.
There’s logic in restarting your machine now and then…

Anyway, the curious can still play it, as links and stuff will be provided at the end.
For now, sit back and listen, for I have quite a tale to tell….

 Deciding that being overly tired is bad and produces silly mistakes, I decided to sleep normal times on the Friday and woke up about 6am on the Saturday – three hours after the theme had been announced. Ironically, after going through the theme list before heading off, I actually quite liked the look of Escape and had inadvertently designed the game before going to sleep, so was rather surprised to see it when I woke up! As such, I dove right into code.

Speaking of which, I brought along a bit of base code… the little bits of an engine I had been working on, complete with shiny new Resource Manager that I had just fixed the previous day.
Or so I thought.
Well.. actually, I had.. but I had not committed it to the repository, so when the bugs started appearing, I was none the wiser that the fixed Resource Management code wasn’t actually in until I noticed some parts were missing and went checking on my other machine.
I think in total, the Resources stuff was rewritten a good three or four times this weekend… so that’s black mark number one.

Saturday went about as well as you could hope, considering the major bits of my framework were quite broken and needed rewriting… I managed to load up something though, and make a start on the framework for the game itself along with a SpriteFactory to take in a good old fashioned Sprite Sheet ( or Texture Atlas if you want ) and split it up into a bunch of meshes; so I got something on the screen at least and a bit of movement with the mouse.

The game I was aiming to make harkens back to the 8bit days of flip-screen rooms with a larger scrolling area to run around in. Each room filled with traps and things to kill you. Your job, as a thief named “Fingers,” was to test the security of a Mansion on the owner’s behest. You had to steal the Star Diamond – a large and priceless artefact – while avoiding the security system. If you made it out, you got to keep the Diamond and anything else you might’ve pocketed on the way. They didn’t go into much detail on what would happen otherwise, but as you hadn’t failed a job yet, you didn’t put much thought into it… least you didn’t till you saw the spikes, crushers, spotlights and pressure pads that awaited you just as the main door slammed behind you.

Here lies black mark number two. Due to the engine being very young, there’s no real data pipeline, so everything ended up hard coded into it. There’s also no bound scripting language as I had in my previous engine, so iterating room and trap logic was highly tedious… I reckon I probably could’ve bound Lua and still done a better game in the same amount of time. Assuming the other bugs hadn’t caught me that is!

Sunday comes around and I pick up where I left off… some stuff on the screen, basic controls, and a camera that follows the player around.
I then began working out the logic for the rooms.. deciding that I’d have three floors, each with 7 or 8 rooms interlinked. Obviously having not learned from Derelict and Moons of Subterrane that planning out lots of content is always a bad idea! Black Mark Three!
The morning was spent again wrestling with the Resource system… and were it not for a feint glimmer of hope when the Room framework started to work nicely, and I was able to traverse the Mansion, I’d have given up here.
The afternoon rolls round, and I lay out a plan of action… detailing what was missing and what I drastically needed to do to try squeeze it into the Compo.

• Traps.. any traps.. just something to kill the player!
• Ability to push stuff around – particularly the titular Star Diamond we’re meant to be after.
• Puzzles would be nice to keep the player involved.. though this comes in with the Traps.
• Probably need to cut down the size of the Mansion.
• Game Over/Completion State
• Keyboard Controls
• Fix this worrying frame rate issue that’s starting to appear….

By the Evening, I did have a couple of traps in, and some basic enough physics to detect collisions and push things around as needed. I had also drawn everything bar the Game Over and Completion graphics that I’d needed, as well as put in the Keyboard Controls making it much easier to deal with ( rather than dragging the character around with the mouse as I had, and still do if you want to try it! )
However, the frame rate was steadily plummeting for no apparent reason.. so all my efforts suddenly started to focus on that…but as the deadline for the Compo loomed, I decided to postpone it to the Jam.. and get some sleep as a fresh mind might spot something wrong quicker.

Now, I hadn’t really planned on pushing it into the Jam originally, so I hadn’t much of a plan for Monday short of sleeping, and fixing another black mark – that the engine only currently works on Linux; there’s no support for Windows, Mac, or anything else ( apart from the Pandora… though I haven’t tested if the game runs on one.. I’d imagine it should though. ) There’s no Sound support either  – which is yet another black mark – and something I had planned on doing on Sunday. In fact, my plan was framework and engine bits on Saturday, content and extra bits on Sunday, quick port and sleep on Monday.

Anyway, Monday was rather worthwhile actually, as I implemented about half a dozen trap types and started cleaning up the code a bit to try make room generation somewhat less painful. It was also clear that my resource management system, which I had designed to be simple, was utterly broken and was insanely complex if I wanted to keep track of anything. The fact I had to have a helper struct to find things through the Resources system says enough, I think. By the evening I was making great strides, and as long as I didn’t draw too much on the screen, the frame rate was bearable.. I had also tested it on my main desktop machine at this point and it ran full speed, so I was putting it down to my laptop being a bit old ( and being the same one I used in LD11! )
That said.. when it suddenly started chugging at single digit FPS… I dragged out gDEbugger and had a poke to optimize everything I could… I managed to get it up a bit to 10FPS, which was enough to finish four rooms, and stuff the Star Diamond in another room with a single lowly health pack to help you on your way back.
Oh yes… you had to push the Star Diamond back through the Mansion to escape with it.
Think yourself lucky that the version I’ve linked here only has five rooms, and only one of them is really going to cause you trouble, as that’s the main one you have to go through with the Star Diamond.

An hour before the deadline, however… I gave up.

I couldn’t get it running any faster… it just was not playable in it’s current state and I couldn’t fathom why… so I didn’t submit it.
I now regret this in hindsight, as this morning when I turned the laptop on, it ran in a frame without any hassle. I shall point out that during the weekend, the laptop was not reset once.. it ran constantly… so the only thing I can think of to have caused it was my graphics driver going a bit funky and getting itself into a state it couldn’t get out of until I restarted; as I had been checking for rogue processes to kill when the FPS originally started to fall and found nothing.

Oh well.. it’s the experience which counts! but I could’ve been lucky 600!

Should you want to play Thieving Fingers, you can do so from here: http://www.stuckiegamez.co.uk/gamez/ludumdare/ld21/ where a bunch of screenshots are also included.
It’s been compiled on 32bit Debian Lenny so should run on most things as the only dependency is OpenGL.. if not, the entire source is also available here: https://stuckieworld.net/publicsvn/ludumdare/LD21/ … just ignore that self-signed certificate 😉
There is an amusing oddity on 64bit machines though.. because I’m using floats to store delta time, and I optimized things a bit much.. the delta can alias to zero and you get a stutter. It took me a while to figure out what it was too as obviously sticking in printfs and suchlike is going to slow it down!.. but yes, the game runs so fast, it aliases a float… that’s optimization!

Will I know better for next time? Perhaps… scary thing is though, I almost made it.. if I hadn’t been dealing with the resource system as much as I had, I’d likely have finished it in time for the Compo… and if I had reset even just each night.. I probably would’ve submitted for the Jam.

Oh well… for now, it’ll sit in peace for a while, until I brave the courage to go back in and redo the resource system once more…

Check (and rate) the game here:

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

Making a game in 48 hours is never easy, but thankfully it was less hard this time. Mainly because I decided to use tools I was more familiar with, instead of using the weekend to learn a new tool or framework.

I started the weekend with the idea of making a super-hero canabalt. Something that lends a bit of variety to the one-button run genre. A constant threat from the rear, a path that makes it difficult to stay out in front and some kind of upgrade system.

I structured my development a lot more than usual, with index cards and a vague agile methodology (and the entire living floor). I tried to sleep well during the weekend, getting 6 hours on Friday night, and 9(!) on Saturday. I also ate well, cooking rather than the usual takeaways, and only drinking one energy drink the whole weekend. (I did manage to polish off 5 pots of coffee though, which was around 25+ cups.)

What Went Right™

Organisation – I didn’t feel stressed much at all during the weekend. I managed time for music and even some graphics polishing at the end (not much mind, I’m not an artist and it’s hard to make faeces shine). All in all, I always felt like I knew what I was doing, what I had done, and what I would have to do.

Tools – I normally take a sackcloth-and-ashes approach to development: “If it can’t be done on the command line, then… you’re lying, because everything can be done on the command line. Fiend!” – But this weekend, I used FlashDevelop and worked on windows most of the time. FlashDevelop really is unparalleled when it comes to Actionscript coding.

K.I.S.S. (Keep It Simple, Stupid) – I nailed down the initial mechanics early. Platformer with tilemaps, jumping, double jumping. I did it all with multi-coloured squares too, sprites were an afterthought. I didn’t try to invent a new genre, and I didn’t try to rewrite the entirety of FlashPunk’s BitmapData handling (see: LD #19). I took a simple idea, and made it.

Asset Pipeline – I learned the workings of D.A.M.E. very early on in the weekend. Got familiar with its output format, its awkward, awkward tools, and it’s habit of refusing to write to CSV on occasion because it believes MXMLC is still holding on to the files (although this is more likely Adobe’s fault). I got much better at using Graphics Gale for initial pixel pushing and animating, and then using Photoshop to touch up and bake in some vague lighting.

Emitters! – Who doesn’t love little objects that fire random things in random directions? More Emitters, I say. More. I wish I could have Emitters every day of the week. My next game might be made entirely out of Emitters.

Guinness – Thanks to my first point, Organisation, I afforded myself an hour on Sunday for a few relaxing pints of Black. Boom.

What Went Wrong™

Tilemaps – I spent a lot of time trying different ideas on how to procedural generate the maps. I had never made a platformer before, nor any game that made use of tilemaps. My first 30+ hours, I simply used a very very large tilemap, ~10000 tiles wide. This allowed me the ability to continue working and come back to this issue.
Eventually I decided upon much smaller (200 wide) tilemap segments. These were manually arranged in sets within the Level class, with each set corresponding to the players current powerup progression, and then randomly appended to the scene when the player was < 1600 pixels from nothingness.
This worked fine for a while, until I realised that these tilemaps were persisting, and even being called in collision routines LONG AFTER THE PLAYER HAD MOVED PAST…. Some rewriting here, and some destroy()’s there and we gained a little bit of performance back.

(It’s worth noting however that I didn’t infinite-ize ALL of the tilemaps in the game, and getting more than 2000m will cause the world to end in a dramatic, double-buffer kind of way, go-on, I dare you.)

Helicopters – See those bombs that keep dropping? Aye, they’re coming from a helicopter. Do you know why you can’t see the helicopter? Because I suck at drawing helicopters.

Wall Jump – Not as easy as I first thought, I had it working early on, but it didn’t feel right and it looked weird. Definitely a brick for the post-compo window.

Communicating with the player – Even in a relatively simple game (perhaps more so if its a well establish genre, actually), its hard to communicate certain ideas, goals and hazards to the player.
My intention for this game was for the player to only lose if they got caught (or, more accurately, blown up). This meant you didn’t lose any health if you fell down a hole.The holes served simply as a setback, in order to close the distance between you and the doom of fiery sky-bombs.
Seemingly, people missed this, and thought it either odd that health wasn’t removed by falling down, or that it was cruel that health wasn’t restored when returned to the last checkpoint. In the post-compo version, I will address this with 2 changes.

First, I will record player position AND bomb position at each checkpoint, and restore on death, as opposed to just the player position being restored as it is now (and then the bombs being teleported to a nearby threatening location).

Second, when a player dies, I will animate the scrolling of the screen back to the checkpoint position, display both player character and distance from danger. I will then visually display a reduction in this distance, to reinforce the punishment.

What’s Next?

Aside from the aforementioned changes, I have a few other ideas I’m going to be implementing in the near future, including, but not limited to:

Story mode, with a number of discrete, designed levels, catered to the current unlocked DNA.
New DNA’s, including Spider-Monkey, Electric Eel and Mole.
Highscores, self explanatory!
Better graphics, self revelatory!
High Definition Jazz Kittens, only at participating stores.

Crazy Idea?

Passive Multiplayer

After a playthrough, a replay of the players run, along with the generated map of their run would be saved with their highscore. Next time someone plays, instead of getting a freshly generated map, they would retrieve one from a server, along with the “ghosts” of everyone else who played that map. Allowing for an indirect, asynchronous level of multiplayer competition.

Conclusion

What a bloody great way to spend a weekend. I always enjoy it too much. This time I feel more accomplished and I’m looking forward to working on this game for quite a while to come. Hope you all had a great time too!

Timelapse

Tags: as3, flash, Flixel, postmortem, timelapse

So I chose to make a game with HTML5 / Javascript using the JawsJS html5 gamelib.

I used the <canvas>-tag since I wanted to make a freeform level with pixelperfect collisions, basically I made the whole thing in graphics gale, could as well have done it in paintbrush.

The new HTML5 <canvas> tag makes it easy to get the data in raw format, basically an array with RGBA values. From there on it’s to check collisions.. 1 pixel at the feet is a decent start.

The most annoying thing is probably the audio-formats that’s supported for the new <audio>-tag.

Safari doesn’t play OGGs for some lame reason, and Firefox doesn’t do MP3s. So all audio has to be provided in 2 formats.. also you wan’t detection at asset-loading time etc. I could have lived without that cruft.

Otherwise Javascript has become amazingly fast, I think V8 is faster then ruby and python. All browsers come with good debugging possibilites.

Javascript doesn’t have the traditional classes and inheritence, but rather prototypical inheritence.. which can be confusing at first.

What I love is the dynamic nature of objects in Javascript.. basically all objects are big key-value storages (hashes).

So you can whenever you want just set a new flag/property on whatever object.

/* Player.dead has never been defined or used at this point */

if(player.dead) { … do sometting …} // won’t throw any error.. played.dead will just return undefined

player.dead = true

if(player.dead) { … do something .. } // played.dead is now true and code will be executed

The biggest upside with javascript is ofcourse ppl not having to download anything. No virus-scan etc etc. Just instant gaming. And the big players are making the javascript engines faster on a daily basis.

Play my Javascript game here:

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

Here’s a teaser-shot from the game, you start in the “west prison” and have to find your way out of a huge castle.

Tags: canvas, html5, javascript, postmortem

This post is about if python and pygame is feasible for LD48. But first… an action screenshot!!

So. How good is Python/Pygame for making games?

Good parts:

• Python is a lovely language, an absolute joy to program in compared to just about anything else. It is definitely superior to any brand of ActionScript. I never got bogged down in syntax or trivialities, and bug fixing/iterating flew by.
• Programming in Vim, favorite native text editor by far*, was orders of magnitude better than being relegated to some IDE, or worse, Flash’s cobbled-together editing environment.
• I was worried that a lot of the things that I loved about the rapid development cycle in Flash would be lost in python/pygame, but I turned out to be almost completely wrong. For instance, I liked that in Flash you could just draw something and instantly have it in game, but as soon as I wrote a nice abstraction layer I had that in Pygame too. In flash I really like how you get animated sprites for free with keyframes, but that was about 5 lines in Pygame. There was some oddness about text not being multiline by default, but I managed to fix that quickly by taking some open source code. Which leads me to my next point:
• Pygame has a fairly respectable community. Every time I have encountered a bug (so far), I have managed to fix it just with a simple Google search.

Bad parts:

• One big missing thing from pygame is the wealth of neat filers and effects in Flash. I really wanted to do some nice TV static or something over my game, and make some stuff glow, but I was simply incapable, and I felt like in general my graphics were a bit worse than they could have been in Flash.
• Another really nice thing in Flash: Tweens. And then even better is the open source Tweener library for AS3 which does a lot of really slick transitions and effects. I hand coded these in Escape Artist, and Flash could have saved me some time.
• Now for the absolute worst part about python/pygame: porting. Turns out not too many people are excited about taking your raw source code and compiling it. py2exe and py2app are the standard for Windows and Mac porting, respectively, but it was still really hard to get them set up, and in fact I’m hearing reports of really obscure crashes in the Mac port – something that I’ve never encountered in my Ubuntu testing.
• It actually took about 24 hours to port, which was really sad for me since it (understandably) got no votes during that period

Tags: postmortem

Day 1

This weekend I started with a game where you had to escape from jail by warping around, teleporting, picking up keys, and by avoiding or killing guards. That game almost worked except for the guard part (click), and I had added particles that where being moved by a fractal noise. worked most of the Saturday on that game but than i decided that it wasn’t good. And i came up with  a better idea. In this game you had to get to the other side of the game. But there were walls, lots of walls that are in your way. So to get to the other side of the room you need to move those walls. Sounds very simple. So i made a level loader first (click) and added some graphics. Next thing what i did was let the player move and detect the walls. Dit a simple check on my 18×18 level bitmap if the pixel was white. If that was true you could go there. I got that to work pretty fast (click). But than I had to move the walls. I’m not very good with math… So that was a problem. how could i ever select those walls. I’ve tried some scripts where it checks the first pixel you click and than checks up/left/right/down and so fort. but that didnt work. The rest of the day i only hurt my brain more and i played some games.

Day 2

I came up with the idea that I could select them by color. So I build that. And it works. It checks every 18×18 pixels and if the color is the same as the clicked one it would be stored in an Vector. Than i made something to move those blocks and check if there are no blocks in the way. I did that a little bit too fast. now you can only move 1 block at a time. and it goes very buggy. Sandly toke too much time to fix before end of LD21.  And than. a error from the compiler: Not_Found. that was all, nothing more.. 30 minutes of searching… a Compiler bug. added one line non-related code to a function and it worked again, pfew.

What i used:

• haXe
• FlashDevelop
• A modified Autotracker-C
• SFXR
• Paint.NET
• Photoshop (but nothing of that is used in the final product :P)

Still i’m happy that i finished this game. It works good except for the movement and it looks nice too. Just bought a domain. pixelhead.org time to make myself to a Indie game developper.

See you all next LD

Corné

Tags: flashdevel, haXe, post-mortem

I have 200 downloads but no one commented on my game. Is it really bad or is something wrong with the comments:)

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

I’ve finally managed to crunch 95 GB of images into a time-lapse for my game, Facilitated Escape. You can view at the link below:

Ludum Dare 21 Time-lapse