Finally the results of Ludum Dare 21, and not bad for my first real ludum dare compo 17th on community and score for the rest of my game that isnt bad. Winners are great games, and overal second did use haXe

Don’t forget, MINI LD on this weekend! : D

I’m kinda slow at developing games because I get tangled up in the collisions and stuff. By next compo I’m gonna make a game engine.

XD

LOL

LOL

XD

I am laughing so hard. This is so great. #1 at not actually making a game! I knew you all would like my crepes. Next time I will make something even more awesome.

But more seriously, I think I could have rocked it (in overall too, of which I got approx #200) had I had the time to balance the game, so next time I’ll bring it.

Also, I’ve got 5 levels to the post-compo game now and a nice difficulty curve. I will post here when ready.

It’s that time! Three weeks and a whopping 599 games later, here are the results:

Top 50 Games

Due to our HUGE recent increase in submissions, we’ve bumped the top 20 to a top 50. Check out the best competition games here:

Compo Top 50: ludumdare.com/compo/ludum-dare-21/?action=top

Winners are decided by the Overall category. In addition to the top 50 compo games (solo, stricter rules), here are the top 50 jam games (solo and teams, relaxed rules):

Jam Top 50: ludumdare.com/compo/ludum-dare-21/?action=top&cat=Overall(Jam)

Congratulations to all the winners.

NEW: The lists have gotten so big lately. So to keep the site fast and snappy during the heavy loads (events and results), we had to truncate them at 50. Don’t worry though, you can see your individual categorical ratings on your games page.

Categorical Top 25s

Here at Ludum Dare, being the best game isn’t the only way to win. Games are rated in 7 additional categories, with a special “Coolness” category highlighting people that went above and beyond to be sure you got a vote.

Categorical Top 25s: ludumdare.com/compo/ludum-dare-21/?more=1

(And for the press, a shorter Top 5′s is available here)

*NOTE*: You can click on the titles of the categories for Top 50 style lists per category.

More Ludum Dare 21 links

- Keynote!, with Breakdance McFunkypants and special guest Sos
- Theme Voting Results
- Post Event Post
- Wallpaper of all 599 games, by ExciteMike

Interesting Tags: montage, motivation, foodphoto, food, deskphoto, desk, timelapse

October Challenge 2011!

Yes, we’re doing it again this year. Details about the upcoming event will be posted soon.

In summary, yes, basically the same thing as last year. Go make money.

Ludum Dare 22 – Coming December 2011!!

Stop by again this December for our next regularly scheduled event. We’ll try to have a date nailed down a month or two ahead of time. Don’t forget the mailing list, and Twitter.

September Mini LD, hosted by increpare

Still got that Ludum Dare fever?

Tune in Friday for a brand new Mini LD event hosted by increpare. Unfamiliar with Mini LDs? It’s like a regular LD without the weeks of voting (and waiting).

A Busy Busy September

Mini LD isn’t the only thing going on this weekend. Breakdance McFunkypants has posted a comprehensive list of 7 game jams going on this weekend (and/or ending/crossing this weekend). Check it out.

http://www.ludumdare.com/compo/2011/08/29/5-jams-in-one-weekend/

Don’t let the URL fool you. There was more going on than initially thought.

Suggestions

If you have any suggestions for us (website, observations, etc), we continue to collect them in the comments here:

http://www.ludumdare.com/compo/2009/08/30/suggestion-post/

Thanks everyone for coming out and making Ludum Dare 21 such a HUGE success! We hope to see you again soon!

- Mike Kasprzak (PoV)

sooo i started a new game:)
zombidith sortof a series continueum from pyramidiath, and my friend is making bookidith; he sorta ripped the dith of me but instead we made it into a series of gamed

This was my first real LD, after having done miniLD 28.

Like a few others I’ve read about, I knew I was going to be a little short on time — getting about 12 hours of coding in since we were driving for much of the weekend.  Future LDs might also be cut short, but I’m encouraged by the people who finished something in 3 hours, or did full games in 10 hours.

I had a few ideas before the compo.  Once I saw the escape theme, I thought about possibilities while watching a kids movie with my daughter.  Before going to sleep I mostly settled on a smash tv like idea.  I always liked that game in the arcade, and the basics seemed simple enough that I should be able get something working.

Difficulty!

Good things:
- I finished something that was playable.

- Even if it was only for a few minutes, I actually got to the point where I was creating stages of attacking enemies.  I quickly typed in a couple of arrays and didn’t get to tweak them, but it was somehow thrilling to at least get to that point.  My miniLD 28 entry had no ending nor obvious objectives, so this was an improvement.

- From reading about everyone else’s LDs, I’m learning that if I can be ready for tweaking and level editing after the first day, I should be in pretty good shape to finish well next time.

Things that could have been better:
- I spent the first couple hours with framework/learning box2d problems — lining up and scaling graphics to match the physics.  Before the compo I didn’t realize my simple framework needed more work, but at least it should be better for the next miniLD.

- Control bugs
It turns out that having working controls is really important!
I didn’t test the game in native Windows with the mouse, just with the keyboard.  This made it unplayable for many people until I fixed the bug.  Personally, I like using the keyboard for both aiming and moving, but that’s a problem for some keyboards where simultaneous key presses interfere with each other.

- Controls were not clear
On-screen directions would have helped.  I’ll try to add this next time if I have non-standard controls.  Actually, maybe I’ll just use more obvious controls for one game

- Difficulty
After a few minutes, the game eventually becomes unbeatable.  There are just too many enemies appearing for the firing rate.  There other things that could have been added, but fixing this would have been an quick big improvement.

- Graphics and sound
I need to make the characters more complex next time, but for this LD, I was just happy gameplay worked at all.  I’m going to try some sprites for the next miniLD.  I’d also like to get sounds and music in, but let’s not get too crazy.

- Timelapse
Since I was conserving laptop battery for a part of the compo, I started a timelapse for a couple hours, but I didn’t get to continue it.  Even for that short time, watching your own timelapse is pretty fun! — and it was mostly just lines of code appearing on the screen .

Wrap-up

After submitting, I wished I had gotten more done and felt a little burnt out.  My expectations were a little too high at the beginning.

The feedback is very helpful.  Also, it’s helpful for me to play the other games and read about their development.  I didn’t get to rate as many games as I did in the miniLD, but I’ve learned quite a bit from playing the other games.  While trying to finish up my miniLD 28 entry this weekend (hopefully I’ll post about it later), I’m realizing that it’s a lot easier for me to see which things need to be improved.

I haven’t decided if I’ll finish my LD21 entry yet.  It’s third on my list of mini games to finish, so if I think of a good story + graphics (that can be made by this programmer) I will spend some more time to finish it up.  Here is the compo entry: Escape Run, but no pressure to review, I’ve gotten a lot of good feedback already.

Hmm, this post mortem feels a little long-winded.  Like my ld21 entry, my next one will also get better.

Well, my first LD has come, and is shortly going to be gone once the results come out, and it’s been a good time. I’m already jonesing for the next one, but I feel like I need to document what I’ve learned so that the next time, I can look back at what I did right and what I did wrong. Without further ado, let’s take a look back at JLP.

A link for those who haven’t given it a look.

The Good

Setting goals. I didn’t expect much from myself for my first game dare, but I always had a goal in mind. The obvious major goal was to finish, I simply wouldn’t let myself hit the time limit with code and assets strewn about. Beyond that though, I was always setting up goals on my whiteboard, hitting them one at a time. This gave me a visual reminder of my progress, even if the thing I was working on couldn’t be seen in my game.

Having a clear beginning and end. I often find in my side projects that I start adding features and shiny things without a clear purpose for how it’s taking the player to the inevitable end. With JLP, I knew you were going to get from the ground to the moon, and dodge junk in between. There were no if’s, and’s or but’s about it, and that kept me focused. I was able to add some frills such as the hats that get put on the player at the different height levels, or item drops, but that was only after I had the basic implementation down.

Variety. While I love so many of the LD games out there, the biggest problem I see is a lack of variety. Of course we have constraints, but when you lay down the basic framework for the game, it’s not hard to add some variety. I knew from the start that that would be the death of my game, so I very quickly laid down the groundwork for having stuff fly at you from the sides, then adding the jets and space ships to keep it fresh. Admittedly, this left little time to actually balance the additions which caused some players to find exploits, but for the everyman, it kept the game interesting enough to reach the end.

The Bad

Duct-taped features. The speed ups in my game were implemented in such a hacky way that collidable things would stop showing up at a certain speed. I had a good feeling why it happened, but didn’t allot myself enough time to fix it.  Which leads me to my other issue,

Time management. I mean, I didn’t totally drop the ball on this one, but there were some areas where it shone like the previously mentioned. Some features I had swimming in my mind had to be cut because I overslept, and some times couldn’t resist the allure of Reddit or the very friendly LD IRC channel. I definitely need to be more diligent next time.

The Ugly

XNA. I love this framework to death, but being Windows only with no way to play on the web, and the download requiring dependencies really didn’t work in my favor. Many friends and family couldn’t play because of this, as well as, I’m sure, many people who would have rated and commented. Next LD, I’m probably going to go with Java or Flash, if I ever get around to learning the latter.

Music, or lack there of. I knew this would be a big hurdle from the start, but it hit me harder than I expected. Right after I finished, I started to look in to Linux MultiMedia Studio, and I’ll be working on that for a while. Music is a huge component to games, especially one like mine where in the time between things being flung at you, you don’t have much to do. I’ve never been a particularly artistically inclined person, as I’m sure you can guess by my game’s artwork, so this one will be hard to get around.

Things for Next Time

Recruit a friend! The best parts of LD were when people showed interest in my game. I’m shy enough to admit I like when people take an interest in or admire my work, and I’m sure most people out there feel the same way. Working side by side with someone will allow us to keep each other going by keeping each other in good spirits.

Use a web-deployable language/framework. I already went over this earlier, but it’s really important, so I’ll mention again. The correlation between number of rating and ease of access was easily seen.

Write a warm-up game. It had been a few months since I worked on an XNA game, and I was rusty for the first 4 hours. I had to look at my old work just to remember really simple thing. I need to give myself something like 4 hours before the LD to write a silly Pong clone or something, just to get ready.

Anyhow, thanks for reading. Hopefully you could relate to some of my issues, or some of my ideas helped you consider a strategy for the next game jam. Until then, I wish you all the best. Good luck with the ratings!

[My name is Carlos Leituga and I’m an intern Junior Game Designer / Implementer in a Portuguese company, where I’ve been working on a Hidden Object Adventure for a year now. I was invited by friends to help develop a game for the 21st Ludum Dare event. We are the Make A Game team.]

It was around 11pm when I left my house with a 1 hour trip ahead until I met the yet to be named Make A Game team. Having memorized half of the list of possible themes, I spent the little I could of brain waves keeping my car on the road, and tried to think of quick game mechanics suited for a 72 hour game development.

I was the last of the team to arrive; I met some new faces and joined in on the ready up ritual. There were still 3 hours until the official LD #21 theme to be revealed, so we started throwing ideas around, writing them down on our white boards and linking them to similar themes.

 Look busy guys…

The awaited hour finally came, and the Escape theme was victorious. We quickly (and sleepily) gathered around one whiteboard and started discussing our previous ideas, along with new ones. Among them, the Survival Tetris game was highly praised. For some dumb reason, I went to my computer and searched if someone already had done such a thing. It existed, and in two quite different forms. In one you only controlled a stick figure, and in the other you controlled both pieces and a round character. We were bummed out.

(more…)

So for everyone who wants to rate some interesting games with not that much votes on the final day of voting, I would like to give you some recommendations:

Cosmic Heist – Kevin Wells

Surprisingly precise controls, fast gameplay and an interesting twist (no shooting). I had a lot of fun playing this. You should try it, too. (18 votes)

Escausage – jplur

Great physics game were you control both ends of one or more a sausages (this!). I really had to laugh out loud playing this. (26 votes)

Abandoodle – OddOneOut

Classic jump and run with smooth controls and a very authentic hand-drawn look. Feels like playing a lunch-break scribble. (14 votes)

Meta Abstract Room Escape – foobaz

This one has a great twist. If you are somewhat preserved against this click-around-to-escape-the-room games, like me, try this out. It breaks these kind of game down to basic flowcharts which is quite a funny approach spiced with humour. (22 votes)

Go try them out and give them a vote if you also feel that these games are about average quality and deserve many more votes.

Well, voting is almost over and I am going to one of those post mortem things that all the cool kids seem to be doing!

Before the final theme was announced I wrote a quick one line idea for each of the final themes of what I was going to do for that theme and then I could flesh it out after to something longer and more … game like. For escape I had initially decided that I would do a game similar to cannabalt and then maybe add something to it. Given that this was my first Ludum Dare I didn’t really want to do something that would be over complicated and just end up not finished and deter me from entering again. However as the time came I was discussing with my two chums DuSTman and Shot and I was convinced to try something a little different rather then just clone another game. I was looking through my list of ideas when I saw that my idea for wormholes was: “A game where in you launch a ship through a series of planets with gravity and try to get into the wormhole”. 10% space golf, 90% That seen from whitehole the Red Dwarf Episode where Lister plays planet pool. This could easily be changed slightly to fit the theme of Escape! The idea was set!

Now that I had an idea, it was time to start making the game. Given that the start for me was 0300 (Uk represent!) I decided that I would get an idea and maybe a bit of code done then get some sleep. By 0500 the basic ship and (then) planet code was in place. An hour later and I had added a line to the trail of the ship (Hence the name “Escape Lines”) and tweaked the random placement of the planets, and giving them different sizes and gravity. I then slept and had Red Dwarf on in the background for more inspiration.

Waking at 0900 after an awesome 3 hours sleep, more code was afoot, and by 10am I had multiple ships able to launch to create some pretty patterns. More tweaks and a lot of slacking later by 1400 I was adding “graphics” to the game. Next was the level system, which could have been improved but I did get to at least mention Burnley (The worst place in the UK ) By 1600 I had started working on the music which was terrible but I hadn’t made a game with sounds, let alone music before. This lead to the ability to mute the music as it was pretty annoying after a few seconds. The rest of Saturday was spent dicking around with the music and tweaking or adding to the graphics. (And playing the game, I probably enjoyed making patterns too much.)
I slept from 0200 to 1100, repaying some of that sleep debt from the previous night! Most of Sunday was just tweaking and polishing little bits. At the last moment I added bombs which could destroy an enemy ship and then submitted 6 hours early!

What went well…

Considering this was my first games programming competition I was quite happy with it. I went for the mantra of keeping it simple and it payed off I finished a game rather then being too ambitious and burning myself out before the end and rage quitting.

What didn’t go so well…

I kept it too simple and finished it with time to spare that could have been used to add more features/improvements but Decided to enter it as is. Oops. I also spent too much time messing with the music which in the end was pretty shoddy.

Conclusion

Happy As soon as voting is over I will work some more on a version with tweaks from the feed back received <3

Ps, my entry is here

LD seems to be a very nice opportunity for a game dev to experiment. Since I managed to make a working and frustrating game in 48 hours it seemed like a good idea to enhance and polish it. Now the game is more tactical thanks to future-seeing glasses, your conscience has longer arms and you can grow a binary tree of life.

Original entry

Enhanced version

The clock is ticking down! This is your final chance to play and rate games!

In these final hours, PLEASE give games with a low number of ratings a try. You can use this following link to view a sorted list of all games with the least number of votes:

http://www.ludumdare.com/compo/ludum-dare-21/?sortby=rate_in&q=

Tune in late Monday night (about an hour after the clock strikes zero) for the results.

Hi all,

I1′ve been reading a lot of Batman comics lately and today I had a little time , so I decided to change some sprites and sounds in my LD21 entry: Carol and The Haunted Castle to make it look like a Batman game… this is what I did, hope you like it… you have to save Robin who has been kidnapped by The Joker and… you know the rest.

The game isn’t finished yet and the Batman sprites were made by Pegalulu

Best regards

I guess it’s time for me to do a postmortem of sorts (Tho I’m still working on the game at this point, but I should be able to wrap it up this weekend, you can check the compo and WIP post compo version at my entry page)

First of all, I would like to say that this has been a great experience, and I want to thank everyone for making it possible. So thanks everyone that participated, to the organizers that somehow managed to keep this afloat during the server situation, Adam Atomic for his awesome awesome Flixel Framework, and special thanks to Dogbomb for his terrific “65 Indie Games in 10(ish) Minutes” review, and to Oujevipo for his series of Ludum Dare game reviews.

So without further delays, a screenshot and then The Bad, The Good and a Desition:

Intro Screen

 The Bad:

Actually nothing went bad at all, I wish I had more time during the compo, but I had to attend a meeting on saturday that ate half of the day (I coded through half of it anyway, while nodding hehe), and the compo theme is announced right around the time I’m falling asleep (I’ve learnt that it’s better if I read it, then scribble down some notes and go to bed, instead of working through the night like I attempted last time).

The Good:

There’s just too many good stuff so i’ll break it up.

The theme:
I loved the theme the moment I read it. I had been thinking about non-combat, non-pewpewpew games for a couple of weeks before the compo, and what better theme than Escape to approach indirect conflict? I felt it was perfect.

The tools:
Flash Develop and Flixel are rock solid, I can’t explain how comfortable I feel with this combination.

GXSCC, usually frowned upon by the chiptune community, allowed me to achieve the sound I wanted without needing to learn the many layers of complexity found in a Mod tracker, so I only needed to borrow a friend’s Oxygen midi keyboard and I was set for music.

SFXR and Audacity for sound effects did the trick (plus some coding that make my game sound like it had lots of different samples, yet it only has 5 samples per kind of sound, that are layered and played at different intervals when triggered).

ASESPRITE, for graphics. While not great, it certainly delivered (except the newspaper cover that got made in GIMP because I had no time to dither the gradient by hand).

Pixel Bender Toolkit, my only gamble as I had never used it before, was really simple to develop and implement, really happy with it, gonna look into number crunching with it for my next game.

The planning:
1- Brainstorm, watch references.
2- Write down the concept.
3- Scope.
4- Write a Schedule.
5- Map input.
6- Create a Screenflow Chart.

This took about 4 hours. Screw Excel, Project, Qubity, Wikis, etc… Notebooks, Post Its, napkins and my cellphone alarm clock work just as good, or way better. For this part I took the keynote as some sort of divine commandment and followed the pro style advice to the letter.

After that, I jumped into developing the screen flow, slide presentation style, then jumped into the game logic, and the rest is history.

A Desition:

I really love making games, I really do. Ludum Dare helped me confirm my gut feeling. I love every aspect of it: The designing, the planning, the coding, the art and sound creation, the polishing, EVERYTHING.

I’m already on the path to make this my livelihood, I’m on the process of getting a game design diploma since earlier this year, and because of that I was thinking about throwing my CV around different companies once I got my portfolio finished (I’m a pretty competent 3d modeler). But the thing is that I don’t want to be another over specialized cog in the machine, pushing vertices or voxels around from 9 to 7, realizing other people’s vision.

I’ve attempted to collaborate with other people on game projects, and I’ve failed every single time, vision and consensus do not mix. I got tired of people telling me “no we can’t do that because it’s too hard”, I got tired of people telling me “that’s not the current market trend”, I got tired of ideas dilluting into homeopathic levels to please everyone, and maybe the problem IS ME, but who cares, if I can’t work in groups, what’s wrong with that?

 
I just got to try and do it on my own. So starting tomorrow I’m gonna go fulltime Indie, and I’m flying Solo!

I’ve found my raw sounds still on the phone, and I’ve uploaded them to soundcloud with the intent of posting them, but something came up and.. well.. I’m doing it now

There were two soundtrack ideas, I went with the second as the first sounded too annoying, I’d like to hear opinions on that if there are any. Good choice, bad choice, that sort of thing.

Sound effects and first draft music

What became the music

These then became audacity-ed. The impact sound for example is most of the impact noises above overlayed. And yes, all of these originate in one way or another from an old dusty mandolin.

Play the Game

Well, I’ve spend many hours after the compo attempting to understand why my entry was so unrelaible on the new links in the comments section. I have thus polled 12 people whome I know have various operating systems – we tried:

XP x86 Sp2, XP x86 SP3, Vista x64 Sp1, 7 Home Premium x64, 2 x Ultimate x64, 7 Ultimate x86, Ubuntu 10.10 x64, Ubuntu 11.04 x64 and x86, Windows Home Server 2011 (slowly)

All these are the English variants with the latest links in the comments – I don’t know if anyone got it kicking – but I fail to see the problem. However, since then, the entire library has been scrapped and has been re-written with no dependencies at all – it runs on X11 and WinAPI from the ground up. Period. So next time, its faster performance and you aren’t expected to have a GMA >950 (945SE sort of runs…) with a D3D/Gl capable OS – you just need WinAPI/X11.

PS: For those whose games I reviewed – I was generous

I’ve been struggling to do a Post Mortem for the game I created, Dare To Escape, since right after submitting I kinda experienced a mini-burnout that wore me down alot.
I’ve never done a Post Mortem before, so I don’t really know what goes into it but lets see how this turns out.

The Idea

After reading the Theme I sat down to think of a game idea. It didn’t take long to think about a platformer where your only purpose is to escape and get the hell out of there.
Since I like combining different genres I thought some aspects of so called “Bullet-Hell” games would be a perfect addition to the gameplay.
So I had the idea of you being a little guy stuck in a factory trying to make your escape. Throughout the game you would know more and more about where you actually are and why you where there in the first place. In the end you would escape to freedom, yay!

What went right

Not alot, tbh. The game has many flaws but one thing I think I got right is the art style and color scheme of the game. You see; I suck at creating graphical (and musical) assets. I had to keep everything as simple as possible. It still took me 3 hours just to get the main character and his “animations” (lol!) done. Designing the turrets was not so problematic. I wanted to have different size turrets as standard turrets and unique forms for boss turrets. Bosses were supposed to be the main challenge of the game.
I tried to stick to one colour having one meaning so as to not get the player confused too much. I chose red as the player color since I like the contrast to the black background. Green for everything that was related to static level design, blue for turrets and orange for deadly stuff (bullets/lava). Yellow was stuff that would bring you forward and be interactive in some sense, so that was the colour for keys, locks and the colour for one of the beams of the warpgate, which also had purple; a color found nowhere else in the game, signaling that this gate was special and important.

Other than that I like my Menu system and am kinda proud of it. Also the way I handled checkpoints made me happy.

What went wrong

Oh boy where do I start?
I was so proud of myself when I switched from using my own TileEngine to xTile because xTile offered so much more features and had an excellent editor for maps that supports stuff like animated tiles and multiple spritesheets and layers. The problem here is that all that stuff wasn’t neccessary and I soon learned that the editor was slow as shit when trying to create larger maps with small tile size. The runtime performance wasn’t a problem at all, though. But point stands that I don’t need such a complex engine for such a simple concept of a game. I never used multiple layers, I only have one spritesheet, I don’t make use of all the properties every map, tile, layer, spritesheet or even spritesheettile can have.
And to make matters worse I had to do two steps to create a map. After creating the map in xTile I had to use my own CodeEditor to open the map and add collision information and codes to every tile. Creating maps was awfully slow and the reason the game is so short and gets so hard so fast. There was no time for balance. The Tutorial map alone took me several hours, and that thing is short! My old TileEngine was more than enough for this game…

So here’s the second point that ties in with the first: Balance and Length.
The game has one tutorial level and two others, and one of the others is merely a dev-level where I tested everything. Creating the second level, even though I didn’t have to code anything to make it work, took about 3 hours. This is partly due to the xTile editor being so damn slow and because after creating the graphical part of the map I had to o over it again with my CodeEditor and put in collisions and code. I was able to test it and quickly realized it was way too hard.
For example the level has a long hallway that allows you to only go left and jump. In the final version there’s only one medium turret there and you can avoid it by simple running to the left without jumping or stopping. This part was way…WAY harder when I initially created it. There were 3 small turrets at the other end and you were supposed to time your jumps and movements just right in order to allow you to progress through the hallway. But after 45 minutes of testing I just couldn’t make it completely past them and even after testing using only 2 it was too hard. And 1 was too easy. So I kinda said fuck it I have to end and submit this and put one medium turret there that punishes you for slacking around or doing funky stuff….not really good design.

So I got past the hallway and lo-and-behold I wasn’t able to get to the last sphere to deactivate the bosses… This was 10 minutes before the 48-hour mark was reached. So I just slapped a gratz-and-apology-message on the gate and submitted the game.

The game was not only hard at that last boss fight but it was just plain unfair. Because the bullets those bosses shoot are being sent to random directions…
Rule of game design #1: Do not use RNG for gameplay-critical stuff.
I intended to have real bullet patterns for the bosses of every stage and was just happy with the tutorial and stage one boss to have this random pattern since the tutorial boss was about getting the crystal in between two waves and the first boss was all about getting the crystal before the first wave of bullets even reach you. These two bosses were supposed to teach you that being fast and precise was easier than taking it slow. But I only wanted this mantra to be true for the non-boss parts, so it was a poor decision to put that into the boss parts.
Ofcause I wanted a unique boss for stage 2, thats why the boss turret of stage 1 had “B1″ written on it. I wanted you to assign the shape of a turret with a specific bullet pattern, so when the player sees a turret they instantly know (except when first confronted with them) what will happen.
But when creating “B2″-Boss I realized something: I have no fucking clue how to do bullet patterns as seen in bullet hell games.
Infact I had no idea how bullet hell games are being balanced.
Theres a reason for that: I never played a shoot-em-up or bullet-hell game.
Let me rephrase that and focus more on the bad side of it:

I tried to develop a game in a genre I never played.

Ain’t I a fricking genius? So because of time constraints I have to go the cheap way again and just slap something harder than one turret that shoots in random directions.
And what’s harder than one turret that shoots in random directions? Thats right: Two turrets that shoot in random directions and where bullets come from different directions in general.

The result is just pure unfair. How are you supposed to finish the stage? Answer: Pure luck.

There was only one part in the game where I feel I hit the sweet spot of balance and difficulty.

To get around this part you have to be precise with your movement and not panic and jump around. You have to abuse the bullets player-seeking behaviour and speed to gather them. It takes skill and not luck to get through this part. And the reward is a checkpoint. Everything is balanced and fair. Though ofcause it still is too hard for this point in the game since it’s required the player to master the movement of his character. New players tend to kinda panic around here because they realize only way out is to go up because going down isn’t an option.

Next mistake was adding music to the game. Not only did the AudioEngine sometimes crashed the game instantly, but also with music the game wasn’t more enjoyable.
This is because I used WolframAlpha’s music generator for the music. I only listened to the music for about 30 seconds and then just downloaded the longest version of the song to use. But that lead to some tracks having alot of repeated patterns that disturb the flow of the game and feel more buggy instead of adding to the experience. In hindsight I shouldn’t have submitted the game with audio. I had to submit a audioless version shortly after to replace the version and now my page looks way too filled with links to the different downloads.

Why do I have so many different downloads? Because I never researched how to distribute XNA games. I knew about the two profile-modes you can have with XNA but the thing I didn’t know is that the user needs not only .NET 4 but also XNA libraries installed to start the game. This severely limits the amount of people that can even start the game and thats bad…

And what’s the reason I had so many time problems? Lazyness.
I kept procrasinating writing code and instead spent most of the 48 hours whatching anime and movies that I intended to only play along on my second monitor to have something I could whatch while coding. Instead I got up and watched from afar, thinking I have soooo much time…I completely underestimated the time it takes to create the maps.

What will I do better next Time?

• Not procrastinate
• Use simpler versions of stuff for simple games
• Only code things I know about
• think longer about what I can and cannot afford to implement in the given timeframe

What happens now?

I want to expand on this project and fix the wrong things I did and make it a proper game. I’m currently playing the shit out of every shmup and bullet hell I can find to get a general sense of them and I’m researching how to code bullet patterns and what goes into them. I’ll have to downgrade to my old engine and actually implement the story I planned to tell with the game.
I’ll be working on this game and posting updates over on my Blog. If you go there now you won’t find much about it but as I get time and finish my research I will get back to this game and start posting again so it may be worthwhile to subscribe via RSS to the blog instead of checking it every now and then. On there you’ll also find my progress on how I build the general engine I use for the game.

I’m not sure if I will participate in the next LD. I’d love to but It was such a negative experience afterwards (during the competition I felt great!) that I’m a little hesitant and think I’m not ready for this kind of stuff.

'Web of Flies'

Paul: As you may have seen, James and I both took part in Ludum Dare a few weekends back, where James made Web of Flies, and I ‘Escape from Flatland: An Romance Adventure of Many Two Dimensions‘. It was an adventure of coding, design, learning new things, and crazy shape (James: and spider web!) physics. It was the most fulfilling 48 hour game challenge either of us have done (this was James’ 2nd LD and my 4th), and the resulting games speak to that.

'Escape from Flatland'

In this postmortem, we didn’t really want to make lists of what went right or wrong, so instead we’ll lay out some rules we each felt were important going into the weekend (whether we followed them or not), and then talk about how these aspects affected our games.

Seeing as I’m introducing this sucker, I’ll start first:

Rule 1: Gameplay in 6

This, in my opinion, is the most important rule of 48 hour game dev: have gameplay in 6 hours.

‘Escape from Flatland’ had gameplay in 7 hours (so slightly late), which gave me a huge amount of time to tweak and fix the gameplay within it.

So what is ‘gameplay’ in this case? To me, it’s the core mechanic, that thing that your player will be doing most of the time: whether that’s running and jumping, shooting, answering, or (in my case) splicing shapes. The key here is that you should rush towards the most important gameplay feature of your game.

I think it’s important to mention that you really don’t need to have a perfect grasp on what your game is going to look like in order to get to this first gameplay stage. At hour 7, i knew that the player would be a triangle, and that they’d be splicing other shapes… and that’s about it. I didn’t know what a level would look like or what the player goals would be, but I knew that splicing shapes would be key.

James: So, yeah… I kind of failed with this one. Gameplay in T minus 6 hours?

I guess I have two excuses. Going in, I had no real intention of actually competing (it was the same weekend as PyCon AU 2011, and a dozen other things), so I’d mostly just resigned myself to helping host our little LD party, whilst doing other things all weekend. Of course, enthusiasm is infectious, and I was soon caught up in the action. It didn’t excuse me from my other commitments though, so it ended up being a rather fractured weekend with me dashing off every few hours to a concert or whatnot. Self-sabotage at its finest.

The medium I chose was my other real roadblock. Last Ludum Dare, not being a Flash developer, I decided to write my game in JavaScript, using SVGs for the graphics. I quickly found myself hooking into the SVG’s internals more and more with the JavaScript though, and before long I realised it would be easier to just script the SVG directly. Soon I was enthralled by the idea of a single SVG image being a game, and it became a personal challenge to make it happen. Unfortunately I was a little overambitious (I’d never actually looked at the internals of an SVG before, and scripting them is a bit quirky), so that weekend ended up just being a very fun, very steep learning curve. I was more successful this time around, though there were still plenty of “Aha!” moments.

I also had a lot of trouble coming up with a game idea, so I started out just implementing all the basic stuff that comes free with other development platforms (player movement, translation between world and screen coordinates, etc.) It was only after about nine hours (while sitting in a Schubert concert), that inspiration finally struck, and I raced back to uni eager to write some spider web physics. The idea was deliberately simplistic; I wanted something small and shiny that would show off the unusual medium, and that I could actually get finished. I could always add to it if there was time (and there wasn’t, turns out simple was hard enough ).

Getting to gameplay in six hours would’ve saved my game from the parameter-tuning problems it currently has, but I guess this time round I just a bit too disorganised, and still adapting to the challenges of the new medium.

Paul: And challenging yourself is really important in getting the most out of Ludum Dare, so much so that I’m gonna go and make a new heading…

Rule 2: Challenge Yourself

This is, to me, the most important part of Ludum Dare: it’s an opportunity to try out new technologies and gameplay types, and doing so is incredibly rewarding.

This time, I went into Ludum Dare with two goals: to learn the Facebook Social API and play with the idea of asynchronous co-operation; and to learn the basics of Ruby on Rails while doing it (more on that one later…). Having this goal helped me to focus my work, forcing me to get to the basic gameplay and design quickly so I could attempt the ‘something more’.

More importantly, the social aspects of the game, more than anything else, have given me a plethora of ideas for my other projects. Trying new things and expanding your horizons will help your game design and development in general.

For me, this rule goes hand in hand with another, and seeing as James has already talked about challenges, I’ll move onward to…

Rule 3: Make Trade-offs

If you’re going to challenge yourself, you need to make trade-offs. If you don’t, you’ll find yourself trying to do far too much in not enough time (see my last Ludum Dare game, ‘The Way Home’, where we tried for an art game which combined and synchronized two completely different gameplay modes… it was a bit of a mess).

If something isn’t necessary for your game, cut it or strip it down. Play to your strengths.

One decision I’m grateful I made with “Flatland” was that I wouldn’t put much effort into graphics or sound. Graphics would be all drawn in-game without sprites (and so any interesting effects needed to be emergent from gameplay), and I’d use Wolfram Tones and maybe some effects generated from sfxr (I ended up not doing this). As soon as I made this decision, it engendered a specific graphical and audio style which can (and did) work really well without much effort.

James: Yep, being able to make tradeoffs is really essential. My original gameplay idea was much more complicated – the web was going to be much larger, a single breakage wouldn’t end the game, and there’d be much more of a focus on strategic repair and pathfinding. By the last six hours though, I was pruning away features left and right, and with not enough time to implement the extra mechanics and physics I had planned, gameplay underwent some fairly radical simplifications. It was painful to do, and resulted in a less exciting game, but there wouldn’t have been anything to submit otherwise. Thankfully my running buddies came to the rescue here with their cool, logical advice; it was time to just admit defeat and polish up what I already had.

Paul: That actually reminds me of another tradeoff I made later on in the development. Initially, I’d decided to do all my serverside scripting in Ruby on Rails, which was partly ‘challenge’, partly ‘a single 2-column table will be pretty easy in rails, and probably quicker (even considering I’ve never coded in ruby) than php.’ Which, let’s face it, is true.

What I didn’t think about beforehand was that setting up Ruby on Rails on my computer meant rebooting into osx (my flash dev was done in windows) and wasting half an hour setting it up. What I concurrently failed to think about was that setting up on a server somewhere would probably waste the rest of the weekend. Thankfully, I only wasted 1-1.5 hours on that particular tangent before coming back (quite literally, as I actually left our dev site to do this) and doing php (which made me a little sad, but was thoroughly worth it).

Rule 4: Turn your limitations into features

James: Paul’s kind of already covered this one with his graphical design, but for me, it was the guiding principle in the design of my game. Last LD it quickly became apparent that I wasn’t familiar with any of the standard technologies used in game development, and so I had to work with what I knew. A JavaScript web game quickly morphed into a scripted SVG image, and I realised that this was a rather cool feature in itself – an entire game in a single image! From that point on my lack of Flash knowledge was no longer a limitation, it was the catalyst driving me down an entirely unexpected path. Of course, this time round was different – I deliberately imposed the SVG/JavaScript-only restriction on myself – but it shows how easily even a serious limitation came be turned around into the defining feature of your game.

Obviously this only works to a point though. There are going to be many limitations that are difficult, if not impossible, to dress up as a feature (buggy game logic, poorly balanced gameplay, etc.). But it’s worth a shot, right?

Paul: It’s definitely worth a shot, and to me, it’s rather necessary. If, for instance, your controls are difficult to learn, it can mean one of two things: you need to fix it or you need to feature it (and by that, I mean admit it’s hard and make that part of the challenge, and probably tutorialise it). That isn’t to say that my game’s controls would have been fixed by featuring them (you can only feature so much, and they actually needed some thought put into them), but it’s a good illustrating example.

As James mentioned, my limitation here was my choice to simplify my graphics. Deciding to go simple on the design could have been a huge drawback in terms of look and feel, but then I spied my copy of ‘Flatland’ on the shelf. Suddenly, I had a way of turning this drawback into a feature, by setting the game in the world of Flatland.

And with that, I’ll awkwardly segue into the next rule…

Rule 5: Release, Playtest and Tweak

So I got two out of three of these, so it can’t be that bad, right?

In actuality, I kinda lucked into playtesting my game. I needed data in my database, and so released a half-finished version and asked for people to play it. And got awesome feedback in the process. I then made some of the tweaks from feedback, but failed to get them all (those awkward controls in the game? unchanged since about hour 4).

Now, I should have known better… I am, after all, a huge proponent of playtesting. And I should really have done a release a bit later on when I had a few more levels, to test out difficulty etc. (as I didn’t really polish this aspect, and there was a bit of sloppy level design going on. Also, some playtesting would have made it clear that social aspect wasn’t all that clear).

All in all, I could really have done more tweaking of my game. In the last two hours of the comp, I didn’t really get much done, and a bit of tweaking would have gone a long way (or, you know, fixing the sound so that the music I’d gotten off WolframTones actually looped rather than playing once and then stopping). In my own defence (against my own accusation? this is getting a little gollumish) I’d slept for 3 and a half hours in 2 days and was in a somewhat delirious ‘holy crap I got that much done? that’s awesome! It’s totally finished’ mood (for instance, the idea that the last level might be too ambiguious didn’t actually enter my mind).

In the end, I’m really happy with what I made, but you never forget those couple of things you ‘coulda, shoulda, woulda’ fixed.

James: Well, yeah, I was an all-round failure here.

Releases? There was one. About 10 minutes before the end of the comp.

Playtesting? Um, I checked that things moved?

Tweaking? Again, nowhere near enough. Parameters like the spider speed, fly strength, and web repair rate were never really tweaked beyond their original values, and while that might’ve been okay for what I’d originally planned, it certainly isn’t optimal given the direction I ended up going.

In fact, I pretty much gave up on tweaking entirely. In the last half hour when I had a mostly playable game, I started work on cosmetic improvements (making the spider’s legs moved as it walked), rather than paying attention to the (probably more critical) playability issues. It was an awkward trade-off, but one I’m not really too upset about. I received a lot of positive feedback from friends regarding the attention to graphical detail, so I guess I’m just glad it didn’t go unnoticed.

Paul: Yeah, the moving legs were pretty awesome.

I think we’ve gone through the things we wanted to, so I’ll leave it there. Thanks to all those who’ve given feedback for our games. It’s been pretty amazing to be part of this LD48, and to be two of the (patently ridiculously) large number of entries.

From James and myself, thanks to everyone who organised it (and got the server back up and running!), and bring on LD22.

Since this is my first LD, I’ve been thinking a lot about my post-mortem, plus I’ve been working on “Stranded Again“, that’s going be my enhanced version of Stranded with improvements as suggested by the LD community.  Plus my Twitter Followers count is going up steadily, so I’ve been keeping up the pace

WARNING!  Some minor story spoilers ahead…

The Idea

When the list of theme topics was down to 20 or so, I got out a notebook and came up with single-sentence game ideas for ALL of them.  My idea for “Escape” was:

Escape: You are tiny brown spider, trying to escape from a research lab.

After doing this for all 20, I went back and came up with a list of Actions and Challenges.

Next, I asked myself, well what exactly do spiders do?  Thinking about Actions, I think,  is a good way to create core game mechanic ideas.

1. Catch insects for food
2. Spin webs to stop “bad guys” (bad insects?) from fleeing, or from attacking something or someone else
3. Collect DNA from insects they catch
4. Catch bad dreams
5. Collect nanites, grid-bugs, software bugs?

1. Web is destroyed by… fire, rain, people, wind, other insects
2. Web decays over time
3. Spider dies from hunger, or runs out of webbing

 

 

The Story

Then I took all this and wrote a tiny Story.  Every game, at its core, must tell a Story – no matter how simple it is.  This one I thought was about as simple as I could get.  I didn’t know this at the time, but keeping the Story simple made the programming much easier as well.

Escape: You are a tiny brown spider caught in a research lab.  You can collect DNA from insects.  Collecting DNA in the right sequence gives you special, but temporary, abilities.  There is a girl trapped in the lab too.  The girl is “dangerous” and “different”, but you don’t know why.  THEY have taken DNA samples from her too.

“I can’t leave here without getting them back — I can’t collect them all in time, but I know a little spider who can.”

I actually thought, of all my ideas, this one was  really  s-t-r-e-t-c-h-i-n-g  it to match the theme – probably the worst match-up of the 20 — and the LD community echoed these sentiments, but not in a mean way — the whole community has been awesome.

The Ruleset

Next I started to think about rulesets.  Which came up with this list of rules:

These are the ones I was able to implement:

1. You win each level by collecting all the insects before you run out of web strands
2. Your web strands do not carry-over from level to level, but are refilled when you start a new level
3. You lose a level if you are unable to catch all the insects with the strand allotment you are given
4. Levels can be replayed if they are lost
5. When you lose a level, your strand allotment and all the insects for the level, are reset
6. You will always have at least 1 more strand than there are enemies, but the ratio of strands to enemies gets smaller as you progress in levels
7. The story of the game is told through dialog, that is “unlocked” as you complete each level

1. Change the ball colors and the fly colors so that you would have to jump from ball Blue to ball Yellow to catch Fly Green
2. Create bonuses that you could catch that would change color of the ball you are either jumping from or jumping to in combination with 1 above.
3. Create obstacles that you don’t want to have your web touch — like fire. If your web touches fire, the fire goes back and disintegrates the ball you just came from.
4. Create “safety” bonuses that you can catch — like water. Water and other bonuses could be caught and stored for later use.
5. More of all of the above, but with other opposites. Might be quite challenging to get the right combinations.
6. Mutations! Each bug represents a different DNA code, catch the bugs in the right combination and your spider gets a temporary mutation.

What Worked

Prioritizing the rule-set from the design above helped tremendously.  When I initially came up with the list of rules, they weren’t in the order shown above.  It took about 2 hours to work out all the inter-dependencies between them all.  Each time a rule was identified as a prerequisite for another rule, it got a +1 — the rule that it relied on it got a -2.  When I sorted this list from highest score to lowest score, I had my to-do list in order of functional dependency.  This really worked because at each step of the way I had a “working game”, so I could stop adding features almost at any point in the list as soon as I ran out of coding time — which is exactly what happened.

Creating a schedule in a spreadsheet ahead of time and marking off hours for “sleeping”, “eating”, “family time”, etc…  I had one row for every hour of the compo, and for the most part stuck to that schedule.  My development time went into just a little bit more detail (but not much more) and had rows for “Game Artwork”, “GUI Artwork”, “Sound Effects”, “Music”, “Coding Win/Lose Conditions”, etc…  I also had two hours each day (one in the afternoon, one in the evening) allocated as “DO NOTHING” where I had to get up from my computer and take a break.  That had a HUGE positive impact on my productivity, my mood, and I think I solved a half-dozen coding issues “in the back of my head” each time I did this.  Also, writing down any “hairy” coding issues during the day and then reviewing them before I went to sleep really worked — I woke up knowing the solution

Leaving LOTS of time at the end.  I left a full 6 hours at the end to run final bug-testing, upload my game, ask friends and family to play to make sure it worked, make any last minute fixes, write my forum post ahead of time, write my entry, announcing via all the social media channels, IMing with people about it, etc…  I think those last 6 hours were the most busy and I may actually allow myself more time in future compos.

Using classes for everything.  I have a class for “spider”, another for “bug”, another for “strand”, etc…  I used my UML/OOP books as guides and came up with a complete list of objects I’d need for the game, and then attached all the methods to them as I went along.  This worked exactly the way it’s supposed to and it made the actual coding a breeze (which in total I think was only about 8 hours).

What Didn’t Work

Thinking that GUI programming would be easy.  It wasn’t!  GUI programming ended up taking nearly 4 hours more time than I had initially thought.  And in the final product you can see that there just aren’t a lot of GUI controls to help with gameplay.  There’s a reason why most AAA game studios have entire teams dedicated to GUI programming (even when using a “GUI engine”) — it’s very tedious work.  Unity GUI makes it as easy as it can possibly be, but it still just takes a set amount of time to create all that GUI functionality — GUI systems are inflexible in their time demands.  In the future, I’ll be able to estimate this better I think.

Using the dialog system as a means to control the game progression.  Such a bad idea!  This is where I really fell down in my technical design.  I should have created dedicated and separate classes for “game” (to control the game state) and created instances of a “human” class (one for the male scientist and one for the female scientist).  I realize now that I was so focused on the game mechanics (which mostly involved the spider, the strands, the anchors, and the insects), that I simply forgot about these classes.  I ran into some problems about mid-way through that I solved with a “gameManager” class that contained all the variables and methods to handle the gamestate and dialog… but it was all mashed up together.  In the future, I need to be more thorough with my technical design.

Not leaving enough time for additional levels.  The final product has 6 playable levels (and then a 7th level that can be replayed as much as the player wants).  Seven levels might seem like a lot for a Ludum Dare compo entry, but in my case, levels only took 5 to 30 seconds to solve.  So, all-in-all I had maybe 5 minutes of gameplay — that is IF the player stopped and read the dialog    I should have done those calculations ahead of time to know how many levels I would need to create.  Originally I wanted to provide about 30 minutes of solid gameplay.  So using that calculation, it should have told me that I would have needed 60 or 70 (!!!) levels.  That, of course, would have been a big Red Flag telling me that the gameplay is too easy and goes by too fast.