Hey there! Now that LD20 is submitted and done, and I’m busy trying out all your awesome games, here are some updates.

Short development cycles
First of all I’m already looking forward to the next LD, or mini LD. I really liked this style of making something small in a small amount of time. Most of my other projects have been much larger scale and much longer development time, which often can result in lack of motivation to complete the project. I’m also very impressed to see what everyone has come up with in such a short amount of time. I’ve tried some really great games so far and looking forward to trying more!

Music
Before the deadline for the jam I managed to put some music in my game too by landon podbielski, you should check it out! You can toggle the music on the ‘m’ key, incase you are playing for longer periods of time.

Beyond my Expectations
One thing I was very impressed with, is that some people played my game way beyond my own expectations, so much so that I had to add even more extra content to it. I’m also keeping a local highscore list in on the projects page just for fun, be sure to tell me if you want a place there.

Timelapse
Finally, I got to putting together the timelapse I made of the development of my entry ‘hollow’. Used that killed app that Keeyai made. (Thanks man!)

Check out the timelapse here!

Finally
I’d really appreciate if you would try out my game and tell me what you think with comments and ratings, I’ll be sure to try out yours as well!
Your feedback is really worth a lot!
http://www.ludumdare.com/compo/ludum-dare-20/?action=rate&uid=3933

This past LD was great, now i want a Mini LD, does anyone else?

Everybody else is doing one of these. I want to do one too. There may be spoilers here, so if you haven’t played Don’t Go Alone, why not check it out?.

“It’s dangerous to go alone, take this:”

I wasn’t thrilled with the theme when I first saw it. I thought, “Great… old video game reference in a video game competition. THAT WILL INSPIRE NEW AND ORIGINAL IDEAS!”

Of course, it’s silly to be disappointed in the theme. Part of the fun of these things is that they provide boundaries for you to creatively hack away at. People who complain that a theme is too limiting.. probably just aren’t that creative.

It was Friday night for me when the theme was announced. My first thought was, “if it’s dangerous to go alone, why not have somebody escort you?” From there I though, “who would escort you through a dangerous forest?” Maybe a creepy stranger. Maybe this stranger could start out being helpful, but become malicious along the way.

I did not open up Game Maker right away… I don’t really see the point. Instead I opened up MilkyTracker and started composing a gloomy tune. As I was working on/listening to that, I opened up Graphics Gale and started doodling. And then I went to bed.

What Went Wrong:

My main problem was a lack of time. I had to work Saturday afternoon, so that cut a few hours. Also, Saturday was like the nicest day of the year, which made it kind of depressing to sit in front of a computer making a gloomy game.

So I did most of my work on Sunday. Which is fine, although it’s also when I came up with my best ideas. Hence, as the clock is ticking I have to resist the urge to make this game more ambitious. I added a second path through the game, and made the stranger react if you got too far away from him. Then, 30 minutes before the deadline, I realized I hadn’t created any ending to the game. I made a quick still image with some fade effects for the “normal” ending. And for the ending “bad” ending, if you make the stranger angry? I used the same graphics and added a stupid caption. Art!

Graphics were kind of a mess. For my two main characters, I had ZERO animation. Yet for a single enemy (the big wolf-gorilla gate that shoots lasers), I made a big death animation. Also, the tiles are as ugly as can be. I left out a lot of details in order to get the game done on time. For future LD games I might just throw in some auto-tiling scripts.

What Went Right:
In spite of my time crunch issues and my half-assing of things, a lot of things went well. On the technical side, I learned that GameMaker’s built in pathfinding stuff actually is pretty cool if you know how to use it. It certainly saved me a lot of time. Music and sound were easy, and probably the most enjoyable part of this whole thing. Sfxr definitely made things easy, and I know it well enough that I can petty much get it to do what I want. I’ve been using MilkyTracker for years (and Fast Tracker II for years before that), so I can churn out some decent music in half an hour.

Now What?

I like the basic idea of this game. I think I’ll focus on polishing the graphics… Work on the tiling and give the characters some real animations. After that… who knows? Once I finish something I’m usually sick of looking at it, so I don’t see myself expanding on this idea anytime soon. But I do think it has potential.

If you still haven’t played Don’t Go Alone, please check it out here and tell me what you think.

I feel a bit guilty posting this in the compo blog, but I think this is a legitimate inquiry that might be of help to others besides myself.

Here’s the deal:

I want to set up a personal website as a permanent portal for my game development news and any games I write.  To this point I’ve been using dropbox to host files and linking them from my tumblr blog.  I’d like to find a solution that allows more flexibility than tumblr in site layout but still supports a blog format.  Being a game development site I would need to be able to support hosting my projects and ideally I would like to have support for embedded flash content since my recent experimentation with flixel.  Another want is the ability to write completely custom html and css, while php would be a bonus.

I’m interested in what solutions other developers (like you) are using.  What has worked for you?  What hasn’t?  I’ve experimented with Google Sites, WordPress, and some other options but I haven’t found anything to really fit the bill.  So what do you use?  Are you happy with it?  Would you recommend it as a solution?

I trust LD community and its varied experience can provide some good input on this topic, just as I am sure there are others in the community with the same question I have.  Thank you.

P.S.  This would be an excellent question for an LD forum if there was one…

Hi guys! Long time no post. It’s been pretty hectic for me, unfortunately, so it’s taken me almost a week to fix a few small but crippling bugs in the game:

• Elevator shafts are now less lethal to enter
• Elevator damage is now higher if you end up being crushed
• The ability to restart from last checkpoint has been added (press R)
• Removed the stuck-behind-a-staircase-forever checkpoint, if you get stuck there hit R

If you haven’t already played it, play it by clicking here!

The entry has been updated with a link to the new bug-fixed version with the original one left there for comparison. Now, the post-mortem! It’s a little short because I’m new at this and not so sure what I’m doing.

Those scuttlers served no purpose other than to look threatening.

What Went Well

Considering this was my first Ludum Dare, I’d say it was a pretty big success. In 48 hours I actually got a game from a bare basic moving-a-box-around-other-boxes to something that was actually more of a game! I was even able to factor in a few miles walk at the start to get my brain going. The coding went pretty well and I got in every single feature I wanted except for a boss fight I was on the fence about adding to begin with. The programmer art I ended up keeping in as the final art due to a far more positive reception than I was expecting (and also to save time as covered later).

I think I kept my scope realistic for the deadline, and am overall happy with the result, except…

What Went Badly

I of course ran out of time. I wasn’t so good at time management and perhaps spent a little too long on breaks than I would have liked. I massively underestimated the amount of time it’d take to create and add content like graphics, sounds and music to the game, but the number one thing that tripped me up was the level editor I used, DAME. You may notice that I never mentioned DAME in my initial “I’m In!” post. This was because I literally just remembered I had it as I started the competition, and so I spent a good deal of my 48 hours looking up various features in it and learning my way around it. Well, lesson learned for next time: familiarise myself with every piece of tech I have even the slightest chance of possibly using.

I also left most of my content planning to the last minute. Bad idea. This is why one of the rooms ended up trapping the player behind a moving staircase – I had to rush the play-testing so I could submit before time ran out.

I also regret not being able to give my timelapse better background music. I apologise once again for the choice of background music.

Behold the most hastily rendered sunset I've ever drawn.

What I’d Do Differently Next Time

Next time I’d definitely familiarise myself with the tech and probably plan a little more rigorously than I did this time (where I spent about 30 minutes planning before giving up and going back to coding). I’d also consider elements of the game that would make it easier to recover from error (either the player’s or mine) by including features like a restart button, and perhaps focus less on a game demanding a level and more of an endless arcade sort of game.

Future Plans

I aim to eventually (not immediately, due to various real life things whirling around me) get the game polished, with better graphics, art, sound, and cutscenes, and aim to include more than one level (probably five or sixish). After that I’ll be submitting it to somewhere like Flash Game License to see if I can get a sponsorship for it and go from there. I’m completely new at this so my ideas are likely laughably naive, but hey, if you’re fully aware I’m walking into an obvious trap, I’d appreciate it greatly if you could leave a comment for me

[Timelapse here]

Upon starting this Ludum Dare competition I was, like many others, surprised. But only for a short moment. The thing being, I believe you can pick really a lot of different “themes” or “words” or “sentences” – and distill something out of them.  When I read the theme I wanted to try to make a mechanic that would “read“: “It’s dangerous to go alone. (Take this)”.I believe this is possible and that someday we will be able to pronounce it through games and play.

So this was my main goal for this Ludum Dare: Try to build a mechanic that feels like (or incorporates) an interpretation of the very theme-sentence.
And honestly: this took me a very very long time. It took me so much time that I was (often) at the point where I saw, that this would fail. Fortunately for me, Ludum Dare is a 48 hour competition and with a little bit of determination you will pull it off anyway, in a way where it doesn’t matter whether you can submit the game or not. Certainly that’s what we tell ourselves during development but in the end it makes all the difference. We can learn from both. But while one variant is hard and painful, the other one is rewarding and encouraging. I’m sorry for all who weren’t able to finish in time.

Concept

My Ludum Dare concept started out as a stealth game. The reason why it was dangerous to go alone in the first place, was that the player character was different – but not in the sense as it turned up in the final piece. At first, the avatar was something like a thief. But she should’ve looked like the rest. In one of my notes it says: ‘like blending in AssCreed‘. That was essentially what this game would’ve been. I wanted to design the rules in a way that you’d have to switch between moving crowds and you would only have a small time window to switch from one crowd to another. Then you’d have been spotted and – well [insert punishment here]. But after half a day I still wasn’t happy with that and in the end I was glad I changed everything (if only by little).

What went wrong:

1) I had no plan. I had tools but I hadn’t checked that everything would work fine. I.E. Since the last time that I had used flixel a lot of stuff had changed and I forogt how to do other stuff. Bottom Line: I wasn’t prepared – at least not coding-wise.

2) Ever-changing core concept: As I illustrated above, I tried to interpret the theme as a mechanic. But I never actually got around writing everything down. I knew roughly what it should play/feel like but never set clear directions for myself. This cost me a lot of time. Time that I should’ve invested into building everything in an according size.

3)  Tilemaps: I said before, that I had not worked with flixel for quite some time and therefore wasn’t sure (I never really knew) how tilemaps in flx work. My bad. Again. Should’ve checked the engine out before. In the end i hardcoded the borders of the levels. But then again – I’m an artist not a coder (so I wouldn’t even call it a hack).

4) Visuals: Jumping into the production of graphics too early made me develop a character, and a style, that was too expensive resource-wise. I even had a walk animation for the character. So much wasted time. I never fell in love with the character and the visual style I was about to enforce on this project. This most likely had to do with the lack of fleshing-out the main concept of the game.

5) Audio-stereo: Upon waking on the 2nd day I had this great (at the time) idea of measuring the distance between player and a soundsource and then adjusting the amplitudes of left and right stereo channel. I never did that – but sure enough I wasted time on it.

Some things went right as well, and I’m glad they did:

1) Visuals: During the failing process of my first art-attempt I discovered a black-and-white character which was much smaller than the one I developed at the time. And it worked perfectly. This lead me to rethinking everything. I don’t know how and when I came up with the new concept. Looking at the character now, she looks like a negative of Chell’s jumpsuit (I didn’t play or possess Portal 2 but it was in the media lately) + I like to have other ethnicities in my characters + white for contrast + a hairstyle I personally find very interesting. The remaining visual style was really a lucky accident that came about after realizing that the dominant green of her jumpsuit didn’t fit the colors of the environment.

2) Music: I did all the “composing” in Logic Studio, which comes with a huge library of Software Instruments. Although the look proposes something 8bity I decided to go with some more-real-sounding instruments. Bass plays a very important part in my pieces (I used to play bass in the past) and it is my belief, that this instrument can support a lot of emotionality. Instrumentation is in fact a key aspect I try to think of. E-Pianos and Pianos have this deep melancholy to them. You can do so many amazing things with that. Basses can span from cool to confident-melancholic – which is it’s role in my ambient track. I think pad sounds provide sort of a transcendent quality. These are all things I didn’t learn but hear from other pieces of music. At the time I was listening to a lot of Tortoise and Mogwai – hence probably the focus on bass. The composition came out of a variation of bass patterns AND the . I really like how the track turned out.

3) Finishing: Although I found it hard to submit such a short game in the beginning – I  realized that I had implemented the core gameplay I wanted to have in there. I think the mechanic has the potential to expand on it. The comments suggestet that the game
was too short and that the mechanics could’ve been conveyed better with a certain length and I absolutely agree.But finishing some game and achieving my main goal – if only in part – was quite something.

CONCLUDING
Lessons learned?

1) Never constrain yourself to do something other people can enjoy lightheartedly.I know I was never that kind of guy – and boy did I try. I obviously can’t make “fun” gameplay? My understanding of “fun” is broader than the term suggests. Deep down I probably am a mess. But resigation and melancholy have a unique aesthetic to them – and I think we should embrace that.

2) The lack of clarity in controls or mechanics can be backbreaking for a game.
I hope some of you could enjoy the game. If you haven’t played it yet I would appreciate if you’d take some time and play it once or twice HERE. I am very thankful for all the comments Entity has received and am glad for every single one of them. Thank you organizers and staff of Ludum Dare. It was a great experience for me. I hope I’ll be able to participate again. That’s it from me – take care everyone – LeafThief

ADDENDUM

My thoughts or rules behind the design of Entity (spoiler alert?):

1) You strive for independence – some may call it individuality as well.

2) You can not go alone for long. It is dangerous not to have social contacts.

3) A majority of people are not really interested in you. They wear a mask and won’t open up to you.

4) If you become independent from that social pressure people will take their masks off and open up to you ( this feature wasn’t implemented – you could’ve turned masks into people without masks who’d provide you ).

5) If you depend too much on a society that is not interested in you, you will become one of them, thus putting on a mask yourself.

6) Memories can content your social needs. They can help you build up your independence ( this feature wasn’t implemented).

Thanks to you all nice people out there, I’ve got some interesting feedback and decided to update the game a little bit.

Updated controls: jump using UP key (instead of SPACE), attack by shortly pressing X (instead of Z), clone yourself by holding X (400 ms).

Throughout the levels, spawn points now appear – this should give some action to the clones at the rear of the group.

Play in browser (FLASH): http://www.jarnik.com/pub/ld20/index-v6.html

If you care, share your thoughts, please.

I liked some of the sprites, so I’ve created a little mashup of the in-game graphics on DeviantArt.

Hey guys!

I am massively pleased with the outcome of this Ludum Dare! There are some great entries, and I was fortunate enough to be mentioned on a few sites:

Rock Paper Shotgun

Indiegames.com

But I want to poll you guys for your opinion. What should I do next?

The way I see it I have 3 choices:

1) Turn the game into a full game. Take the ideas from the LD, and work on them until I have a full polished game, in the same way that World of Goo was developed from Tower of Goo.

2) Add “DLC”. Make more levels, more content, and put it up on the site so players can get more out of the game, as I realise it is easy and short at the moment

3) Screw it all and work on something else.

Let me know what you guys think!

Benn

Before Evil Come

Well, I really made it. This is my first Ludum Dare, and actually my second playable game.

Before this competition start, I’m  so exciting and also doubt whether I can finish it. I made a strategy for myself, no collision detection, no physic and no animation. I know they’re important for a game, but I can’t count them in before I really conquer them.

Game Overview

This is an evil game like the title said. You’re a demon, came to our world, because good man protect us you have nothing to do without some buddies. So you go to the wild and hope get some buddies join you. Although it’s wild, still some enemy out there. You can have rest in house and graveyard, but be careful your enemy also rest in some house. After defeat your enemy, you gain exp and may level up. The more buddies and hight level you have, you can kill more people. If you don’t have any buddies, you die.

Developing Tools

I used below great tools.

Libgdx: an open source Java game engine, also supports Android. It’s really good and best game engine on Android in my mind. The texture packer and bitmap font generator tools are very helpful for me in this competition.

Gimp and Inkscape: all graphic assets are made by this two software.  I think Inkscape is a good tool to draw cartoon style graphic.

Bfxr, LMMS and Audacity: The BGM was made by LMMS and other sounds were from Bfxr. Audacity handle the polish work.

Developing Process

Ok, enough background, I want talk about how I made this game. When I knew the theme It’s Dangerous to Go Alone, Take This., the first idea was ant. Tiny ants group a great army to defeat strong army. Based this idea, I split gameplay to two steps, first summon army and second defeat big boss. The bigger army got in step 1, the easier in step 2.

Because I like dead creatures so I replace ants with zombie and skeleton. I’m not expert of complicated control game, so one click control is my choice. Top view, tile map and my cute dead creature, first stage is done.

When I start made second stage, I hesitated. It’s actually a totally different game, did I have enough time to finish it? I give it up at last, instead I made a slot machine mini game, whose digit number is lead by gain points in first stage.  (OK, actually I am just lazy 

After add story board of game background, this game finally done. It’s mini and some kind shabby, but I really love it. So do my girlfriend, though she just like click things and don’t care game content.

Conclution

Cons:

1.Not enough feedback when player made decision.

2.Inside game mechanic is too simple. OK, maybe it’s some kind pro  .

3.Not enough introduction, player would be confused 

Pros :

1.It’s really very easy.

2.My cartoon characters are cute, isn’t it, especially when player lose. I love the skeleton on the cross.

Hope you like this game and my poor English not disturb you. 

So it’s time to look back at my 48 hours of game-making, like many are doing. Let’s see what happened during the development of A Steampunk Axebot Supply Run.

What went wrong

The Theme - “It’s dangerous to go alone” was the one on the bottom of my list. Why would anyone vote for it, I thought, when there are so many interesting alternatives, like nihilism, or climbing? Why, indeed. I had nothing prepared whatsoever for this theme, and spent the first 2 hours panicking over what to do.

The Level – It occured to me only later that I could have made this in 2D, or using tile-based movement, either of which would have made creating this stuff considerably easier. Oh well.

Textures – As in “I don’t have any”. Adapting UVs is a grueling and time-consuming task,which I would rather avoid, and spend the time otherwise. Using the toon-shader for all 3d-objects was a great choice, but it would have been prettier with added textures. The terrain clashed with this. I couldn’t use the toon-shader on it (so far I know), and creating extra textures for it alone was not efficient.

Preparation – Slept too little the first day. Woke up at start-time (4am), but forgot to check the theme. Felt unmotivated and guilty for first 36 hours, bevofre I finally kicked into non-stop game-making mode.

What went right/not-so-wrong

Timelapse – It felt weird, at first, knowing that my every move was being recorded. But the video makes everything seem ultra-efficient

Music – this one actually surprised me. I never really composed anything bigger, and I just aimed for something unobstrusive. I ended up with a sweet theme which fits the game awseomely, complements it, and people actually like.

The Title – No matter how good or bad this was going to turn out, “Steampunk Axebots” sounds awesome.

The Scoring system – Your profit is determined by several systems, which are based on enemies killed, health of the robots, extra fuel left, and over-healing. Each robot has an own pattern and unity set of enemies at different times, so it is quite challenging to figure out the best combination. I still haven’t.

The fuel gauge – The rockets can travel only for a limited time, before they crash. I intented this to stop players from hovering over the playing  field or leaving it, but the time-constraint added another tactical layer. The rocket takes some time to reach its target, but once it passed a certain point, reaching the other targets would be impossible. It was however possible, that the robot you tried to heal died while you were on your way, meaning you had to carefully decide where to shoot. But since all robots converge on a central point later in the game, it became at that point possible to switch targets should something happen.

3D-models – My first though was a little knight, which I would have need to animate. Unfortunately, there was no time to either animate one or learn how to include animations in Unity (note to self: learn how to include animations in unity).

Biff-Particles  – They are quite a good substitute for fighting-animations.

Healing-Particles – They look much better than I planned.

What I would have liked to add

More stages – which become increasingly complex and tell a story

A menu – Which I already had  around, but no time, and no good reason (with only one level) to implement

No introduction screen – I’ve always hated these. Dammit, I want to play the game, not read a novel! There are ways to start the game at once, and teach the player on the fly.

Destroyed robots and rockets – Which I would have added were it not for a game-stopping bug I encountered with only 40 minutes to spare

Having the title of the game appear somewhere in the first level – Like I did in Unstoppaball. I love that gag.

-Matthew

This Ludum Dare meant more to me than usual. I had been blocked for quite some time and hadn’t written a lone of code in ages. The reasons for that are varied I guess, but the Feb 22 earthquake probably played a big part. The center of the city is still off-limits all this time later.

The game I made was more than I was expecting to be able to accomplish by a long margin.

There has been a lot of talk about HTML5/Canvas/JavaScript being good enough for games. I decided to give it a go. I would have to come to the conclusion that it is vary nearly there. While developing I was using FireFox 4 and I periodically tried a couple of versions of Chrome. I cut back on a few things like particle systems to maintain 60fps in FireFox on my dev machine. That meant Chrome was fine on one of my slower systems.

I have heard a number of people make comments on difficulties doing audio for games in HTML5, I decided to not attempt lest I get bogged down in some browser specific niggle.

I deliberately chose to use an absolute minimal interface to the canvas. I only use drawImage(image,x,y), no shadow effects, no rotation or scaling, no text rendering. I wanted to be able to trust that the browser would do things quickly without screwing up.

The graphics were quite a surprise. I don’t rate myself as an artist, but things ended up looking much better than expected. I used Drpetter’s Scupltris to quicky knock out some shapes that seemed about right and then painted them and saved. It worked a charm, Chalk up another one for Drpetter in the tools for the talentless artist category.

I used Haxe as a base language. Switching between languages as often as I do makes it difficult to remember some of the finer details of each language at times. I had a few hiccups, for instance when I needed to pass a class type as a Parameter. In Haxe, the prototype came out as.

public function addEntity(kind :Class, x : Float, y:Float);


I discovered I really need a good mechanism for animating models. I remember having a rendered character with walk frames in an earlier LD48 but I can’t for the life of me remember what software I used. Scupltris works great at making the base, but I need to be able to bend things around, I don’t need full 3d animation capability because it’s just sprites. What I ended up doing for the player walk animation is render the model then move the bits around in PhotoShop to make the walk frames. I only made the 5 frames of walk because of that.

The same problem manifested for the baddies. The wasps were a simple choice because they can be done with a two frame anim. I had a couple of wheeled baddies rendered but didn’t get them in.
I managed to make this thing

, which possibly says something about my brain at the late stage of a Ludum Dare. It didn’t make it into the game though.

I didn’t make a level editor, instead creating the entire level out of createSomething calls. This meant a cycle of play/tweak/play/tweak to get the position just right. In hindsight I think that might be a good thing for platform game design. I manually positioned the player before each area of construction and played the sequence several times. I think remarkably little is lost by not being able to edit the entire level quickly, because it’s the play phase that is the most critical part. In future I wouldn’t dispense with a level editor entirely, but I’m inclined to bind it even more tightly to the game so you can test small sections as you make them.

Now that I have seen how people have played the game, The one tweak I would make (that could’ve easy been added during the compo) was an indicator showing how many gumcube things you have collected. There’s more to the game than people realise. Showing a 53/107 display would encourage people to aim to collect all of the bits. Then they’d find there is more present than meets the eye.
(there are, in fact, secrets).

I now have a dilemma of what to do with the game. Normally I have a policy of not continuing LD48 games after the end of the comp, but I think there is enough here to work with. Maybe just a little more.
Not being restricted to the comp rules means I could maybe bring in some sprites from elsewhere for the baddies.

After a few days to reflect on my game and get comments from people, here’s a brief post-mortem:

Overall, responses have been positive.  Between the comments here and from friends, the general consensus is that my game is based on a cool idea, but that there’s not enough gameplay there.  It’s too simple/easy.  Also, people have often said that the sonar sound gets annoying over time.  I definitely agree with these opinions (and sometimes hear that sound effect as I fall asleep).  These are certainly issues that can be fixed though, and I plan to update the game in the coming days/weeks to get it up to a state where I feel comfortable giving it a wider release.  On to the specifics:

What Went Right:

Brainstorming/Planning – It didn’t take me long to come up with a few ideas that used the theme, and I’m definitely happy with the one I ultimately chose.  My initial planning of the game- the general design, what pieces of code I needed to write, and what content I had to make- also went well.  Having a design that didn’t require many changes certainly helped with working in such a time frame.  I was able to budget my time a lot better because of this.

Coding the Big Pieces – Though not perfect, I got the core pieces of the game working in good time.  The level generation, sonar, and control code didn’t take too long to get working on a basic level.  Debugging and getting things working just how I wanted took a bit longer though.

Asset Creation Process – Although I didn’t get as much sound in the game as I wanted (I’ll get to that in a minute), the creation of the art and sound that did make it into the game went a lot smoother and quicker than I expected.  Obviously I’m no great artist, but I’m happy with the way everything looks, particularly the monsters death animations, and none of it took me very long.  I made the music and sound effects in the last hour of the competition, and that too was quicker-going than I expected.

What Went Wrong:

Not Enough Playtesting – Definitely the biggest problem.  I was so concerned with getting all the basic functionality and assets done that I didn’t take much time to actually play the game.  If I did, I would have realized that it’s a bit simplistic, as well as exploitable.  Next time, I will certainly leave more time for playtesting, as well as getting opinions from friends during the process, not exclusively after I’m done.

Not Enough Sounds/Music – My game ended up with one very short piece of music and two sound effects.  Not at all enough for a game based on sound.  I think prioritizing other aspects of the game was the right decision, but I wish I fit in more time for sound, especially figuring out how to make the sonar less annoying over an extended session.

Key Bugs – There were a few issues that took way too long to resolve.  For example, being a bit lazy with determining how fast the sonar should beep led to at least an hour of debugging caused by a shortcut that would only have saved me five minutes.  Though I can’t think of specific examples, there were definitely a number of other bugs that really slowed down development for long periods of time.

What I Learned:

That I can release a game!

That I can make a game with a small scope that is still interesting, and that I should do so more often.

Even though I already knew the importance of playtesting and rely on it heavily in my larger project, I learned that even on a small project it is one of the most important aspects of game development.  Especially when working in such a tight time frame, I get to know my game so well that I can’t make any objective judgements about it or consider alternate solutions.  Therefore, I need a nice dose of outside perspective.

That about wraps it up.  If you haven’t played my game yet, give it a try and rate it.  If you have, keep an eye out for updates to fix some of the issues I talked about here, as well as those which I didn’t address but that are mentioned in the comments.  I put the first (small) one out about an hour ago.  And of course, I can always use more feedback!

-Tim ‘Fueelin’ Beck

Hi,

A video of my game made by a website dedicated to video games from my country – Chile (www.glitch.cl). It’s in spanish

My entry

So I successfully completed my 2nd ever Ludum Dare. I had worked really hard during Ludum Dare 19 to deliver my game, and I really enjoyed the experience. This time was same, and I’ve delivered a unique game that turned out just how I wanted it to.

“A Tiny Sin” was fun to develop. My goal from the start, no matter what the theme, was to create a space-shooter. When the themes for the GMC jam and LD20 were announced, I wanted to combine them, and after some design ended up with a goal to make a more story-orientated game than I originally had planned. In fact, I’ve never made a game just to tell a story, so this was new to me.

The development process was fairly easy-going for me this time. For Ludum Dare 19 I made an RTS in 48 hours which in itself was quite a feat, but it didn’t turn out to be a fun game. This time I was set on my final product being enjoyable to play, and as polished as possible. I wanted it to have a “completed” feel after the 48 hours. I wanted to be able to release it publicly knowing that someone would actually enjoy it.

"A Tiny Sin"

And I was happy with the final result. It certainly isn’t a game for everyone, but from the feedback I’ve received so far I’m glad to see at least a couple of people understanding what this game is meant to be. People playing it just for the gameplay or graphics, don’t “get” it. But that’s OK, I knew this would be the case from the start. The gameplay is fairly simplistic at its core, but it was the storyline I really wanted to focus on, and in the end it was delivered just how I wanted.

Graphically, the feedback has been entirely positive, and while I don’t mean to boast – this was expected. If I have even the slightest chance of doing well in any of these Ludum Dare categories, it’s graphics. In LD19 I came 6th in graphics, and I’m hoping maybe I have a chance for top 5 this time around…

In regard to feedback, I’ve received surprisingly little on the Ludum Dare site itself…3 comments really. Now at first I thought maybe everyone was just recovering from the event itself, but I see some games with 50+ comments already! Granted, some of these other games look amazing, but I feel like either my game has gone unnoticed or it just doesn’t appeal to as many people as I’d hoped. All I can really do is be patient, though, so that’s what I’ll do.

On the GMC I received some great feedback, and on GameJolt, YoYo Games, and 64D I got a bit as well. The common complaint seemed to be that the bullets are too small to see, and that the gameplay is a little lacking. While I agree the gameplay is more consumable as opposed to in-depth, I think it serves its purpose. In regard to the bullets being too small to see I’m still trying to figure out if this is due to resolution issues or just personal taste. The game runs at 800*600 but on my laptop (1024*768) they look fine to me. Slow text was an initial complaint so I fixed that very quickly, though said text only appears at the start and end of the game anyway. I also got a few reports of an unexpected error occurring on game start, which I found out was because GM throws this error on older PCs if you have a large image in the game (the background texture). This has since been fixed too.

Overall I really enjoyed this experience once again. I spend most of my year developing a single, large project, so by entering Ludum Dare I have an excuse to take a break and actually release a game every 3 months. I’m proud of what I’ve been able to produce in 48 hours – I think it’s amazing what others have achieved too. I really hope to find some time to play and review at least some of the other entries, here and at the GMC.

But thanks for reading, and for the experience – this is a great community and I hope to contribute to each and every Ludum Dare for many years to come. It’s been fun.

@TrueValhalla, “A Tiny Sin“

Well, that was a fiasco.

Well, for me, anyway. Great job to those who finished.

Here’s how it went for me:

I initially had an idea I liked and knew what tools to use. Then, I decided to change all of that. That was Friday night and Saturday.

Saturday I stayed up late, had nightmares when I did go to sleep, and woke up ill and tired. I decided not so soldier through it, and abandoned the day.

Monday, I looked at the clock and decided not to even try. Disgraceful.

So, when it all comes together, I started with certainty, changed my mind, mismanaged my sleep, and gave up too easily.

What Went Well

Not a whole lot. I did begin with a good idea, I think. It was very ambitious, though. That’s about it.

What Went Badly

I abandoned my first idea on a whim.

The second idea I chose (Same premise, differently language/library) was also abandoned too readily.

I tried to stay up through Saturday night, woke up Sunday after nightmares and was too tired to work.

Gave up Monday morning because I didn’t think I had enough time left. No desire to do anything for the jam.

Basically, I gave up too easily and didn’t take care of myself.

Where to Go From Here

One thing that working with Panda3D taught me is that I am not good with making models quickly. That will be a point that I will focus on before the upcoming Mini-LD.

I also learned that I need to discipline myself in not giving up on ideas. That’s another point for me to focus on.

In the near future, I plan on finding a project to work on and sticking with it. I’m not entirely sure what it will be, though. I’m also going to start looking for a job this Friday, so that may cut into my time.

Peace,

— Mr. Dude

Gameplay Video

Post-mortem

Firstly, I had a lot of trouble with the theme. I wasted 26 hours of the competition trying to come up with a decent yet feasible (to finish within the remaining time) idea. However, once I knew what I was going for, the bulk of the game was finished with around 10 hours left.

I went on to add sound effects, but when I got to making background music, I just couldn’t get anything decent that I decided to scrap background music after wasting maybe 5-6 hours trying a bunch of things. This left me with very little time for smaller details I had wanted to add in, such as power ups.

The only power up I managed to get done was the shield. I had a grappling hook functional (It would shoot up and carry you several platforms up) but it was a bit buggy and would have ruined the quality of the game. That wasted time on the grappling hook could have added a first aid kit of sorts which I had also planned.

Overall I’m happy with the finished product, but of course there were things I should’ve spent less time on (background music) to make room for things that I was more confident I’d be able to properly implement. In a nutshell, it was (like always) a hectic 48 hours. However, it was very enjoyable and definitely worth it.

Entry Page

Fancy Schmancy

I’ve been working on my game and updating it and stuff mainly the graphics, but also fixing many bugs

I’m not too sure about the basic ground, so I might redo it.

I’ve also updated my entry with a link to it:http://www.ludumdare.com/compo/ludum-dare-20/?action=rate&uid=3501

Link to the entry

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

Gameplay

TimeLapse

Postmortem

What a blast. Our team entered the Jam for LD48 #20 on a whim. I watched @notch live streaming his LD48 entry progress in LD48 #19 and it inspired me to clear the weekend and participate in the next one. I had an idea I wanted to try during the compo but I also wanted to work with two of my good friends. I was glad when they both decided to participate and we all entered the Jam. We’ve worked together in the past on other project but never tried to do anything within the scope of 72h.

What went right

Tech – We decided to use a new XPlatform basecode layer my friend has been working on for quite some time. It had never really been tested outside of a few component tests on his machine. This turned out to be a huge win for us and the tech enabled us to get in way more content and achieve much higher production values then could have ever anticipated.

Team – I know LD48 celebrates the lone wolf developer and I love that and I have huge respect for all the participants who submitted entries. You work is inspiring. But man, I love working with these two friends. There’s something about getting a small team together and seeing something come together that is better then any one of you would have thought of individually.

Refactoring – This was pretty key to my contributions to the game, if I ran into code that was getting brute force or fairly unmaintainable I would think about it and come up with an implementation that significantly reduced the amount of code and the complexity of the task. This was the key to getting multiple enemies in with behaviors and art in various directions. If I hadn’t taken the time to refine the code for one enemy before adding the others I’m not sure they all would have made it in. This is kind of counter intuitive when you think that you are supposed to be coding quickly, sometimes taking the time time to go slow helps you go fast

Art – I wasn’t expecting it but we all ended up falling in love with how the look of the game came together. Enough that I think we’ll keep working on it and round it out into a full product.

What went Wrong

Slow start - When we started we hadn’t even got our machines set up and ensured that we could buil and run the tech on more then one computer. The first few hours of LD48 were spent configuring an SVN repository and installing drivers. Next time we’ll be sure to be start with fully prepped dev environments ready to start strong out of the gates.

Low Sleep / Bad Food – We had too much beer and deep fried things. Note to self, next compo eat healty and sleep more.

Leaving Interface Issues to the end – The mouse interface in the game feels more like a barrier to playing the game then something that enables it. The issues with it were known as are the solutions, but leaving it till late in the timeline was a mistake. Get your control issues sorted early!

Only one dude did the timelapse – The other dudes know, and next time they will do it too!

LD48 – In the end, being productive is just so much fun! It’s still hard to believe we made as much game as we did in such a short amount of time. I start fantasizing about how many games we could make if we keep doing these jams. It’s really exciting.

I updated my final Ludum Dare #20 Jam entry to include a link to the Windows port of Hot Potato. Whew! Now I can get back to working on Stop That Hero!. B-)

I finally managed to port my compo entry to windows. Phew, what a fight.

So here you can find my entry and the link to the windows version. Hopefully a linux version will follow soon too.
But first, the next step will be to finalize the timelapse.