I will try to join this year. I will use either gamejs or pygame with spyral (can’t decide yet) and GIMP for graphics.

I wasted a whole day thinking about what to write. Finally decided it’s going to be a side scrolling shooter based on a misheard theme: “tin world”. I know it’s a stretch, but the original theme was too awesome for me to take it.

I started late, because I didn’t have a good idea, and I finished early, because I had to do some other things, but for the first time I did my game for the Ludum Dare. It only fits the theme if you misspell it, and it’s even more minimalistic than I wanted — barely a game, to be honest, but it’s done. You can get it at https://bitbucket.org/thesheep/tinworld

The idea is that you are the last human on a world invaded by killer robots — the Tin World. Just shoot as many robots as you can before they get you. Move with arrows, shoot with space.

I will try this time too.

Still trying to come up with an idea, sketching things to help me get in the right mood.

I’ve got fridges, I’ve got mutated tomatoes, and I’ve got a big gun to de-evolve them into submission. Also got inertia and shadows working properly, not to mention scrolling.

It looks a lot like my LD 23 game, except this time I’m going to make all the stuff that I didn’t make back then — real, non-random levels, scrolling, responsive controls, score… Hopefully.

Not much progress, life got in the way. I got the gun to actually shoot the de-evolving ray, and the monsters and fridges to glow when they are hit with it. Now I just need them to actually de-evolve… Then the levels and the score and I can ship it, I guess…

Ok, the game is ready and uploaded, you can see it at http://www.ludumdare.com/compo/ludum-dare-24/?uid=11694
In the end I decided to not include a score — I hate games that have scores, and it’s not a kind of game you play through more than once anyways.

You left your food in the fridges for too long, and it managed to evolve into hostile life forms. You must de-evolve them with your de-evolution gun before they escape and take over the world.

Play De-evolution.

This was my second try at Ludum Dare, and in the end it was very similar to my first attempt, Tin World — it’s a side-view shooter where you walk right and shoot enemies. But it wasn’t supposed to be like that. I spent half a day thinking about a game that would use the theme nicely but at the same time be simple enough for me to make and tweak in the limited time. Nothing. Then I started sketching things to find inspiration. Somehow only guys with guns as simplified monsters were drawn. I posted my drawings here, and somebody suggested a gun that would evolve or de-evolve things, similar to the Portal gun. Then I decided to go with similar mechanics to the last time, only more advanced.

The good:

Graphics. Basically, I used the same technique as the last time, but with some more time spent on the details and more character to the main character. I’m rather happy with the effect — the black-and white, sketchy pictures, with a white outline, animated by moving them around — no frame-based animation. It was inspired by the minipato anime, by the way. A lot of people seem to praise that in the comments, so I will certainly stick to it in the future.

Scrolling. That’s something that I planned for my previous game, but didn’t have time to do. No I planned to have scrolling from the beginning, and it’s there. There are some tricks to keep it very efficient even with limited PyGame options, but I think it works quite fine.

Level. This time I decided that I can’t just randomly throw things at the players — they need to have a level that is designed, so that they can actually finish the game. I really like the feeling I get from finishing games, so I wanted to have it here.

Release. Last time I did some experimenting and managed to package the whole game in a single exe file for windows, and an executable zip file for all the sane platforms. I used the same approach this time, and it worked without any problems — preparing the release took me 10 minutes, including booting an old windows laptop for it.

The bad:

Controls. In my previous game, people complained that the controls worked sometimes, and sometimes they didn’t. After some investigation it turned out that people didn’t realize that they couldn’t move after shooting, while the weapon was being reloaded. I introduced that, because I wanted them to think a little before shooting, to make sure they will have the few milliseconds to reload safely, before pulling the trigger. It didn’t work, turns out players just want to move all the time and don’t want to plan their trigger pulling. Fine.

This time I really made sure that you can move around freely from the beginning. I even added some nice inertia effects to make all the movement super-smooth, and I made it possible to move around quite fast. That was a mistake — people complain about the inertia making it harder to control the character. A second mistake I made — despite the experience from the previous Ludum Dare — the energy gun didn’t feel powerful enough, so I made the player character stop while shooting it. Soon enough I saw my mistake — the very first comment complains about “lackluster” controls.

I think I have learned my lesson: never stop the players from moving their characters.

Difficulty. My decision to have a designed level backfired at me. Or maybe it was just that I underestimated how much work it would be to make it. Anyways, the level is much shorter than I wanted, and because of a last-minute change to the last wave of enemies, the game is insanely hard — almost unbeatable. You seem the last monsters were initially very weak (but lots of them), but then I decided to add some variety, and since it’s at the end, and I didn’t have a debug mode, that part wasn’t tested as often as the others…

Code. In my last game, I used some clever tricks to make all the animations and effects easy to code (I used python’s iterator generators for effects). This time I went with a haphazard approach, just doing random stuff that seemed straightforward. The code is a mess and much more elaborate than I would like, as a result. I will stick to the generators in the future, they work really well for this.

In summary, I’m really happy that I finished a game, but a little disappointed that it turned out to be very similar to the last one. I hope to really get a better idea next time. I will definitely stick to this graphics style and iterator generators, but I will make sure you can always move.

So I started to make the sprites and tiles, and some basic code to display and move them. This time my weapon of choice is love2d, which should prove fun, as I barely know lua. At least it will be easier to make binaries.

This entry was posted on Saturday, December 15th, 2012 at 3:53 am and is filed under LD #25. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

This time we are going to do the Jam, and we are representing our hackerspace, Nigmalabs. Makdaam is going to make sounds and play music, while I will draw and code.

Here’s my desk:

Ah, and the logo for Nigmalabs:

Instant heart attack, with bacon.

So we have almost proper walls, and some furniture, and a professor, and music.
Now I need to work on text display and quests, and then we can start making the plot.

At last, we have a playable game. The plot is very basic, yet tragic.
I’m never working on an adventure game again, the fact that it’s not playable until almost the end is very stressful.

Now the title and ending screens and some polish.

It’s considerably shorter and less involved, than we hoped, but it’s finished, I guess.

This was a jam project, done by Makdaam and TheSheep under the wings of the Nigmalabs hackerspace. It has been a pleasure to be this frustrated. We will not have time on Monday, so we are submitting this now.

Thank you for your attention. We will post a post-mortem when we recover.

Let me sum up how this Ludum Dare went for us this time. We wanted to work together, so we did jam this time — Makdaam did music, sounds and level design, and I made the simple engine and graphics. The things that I’m mostly happy about and think that we got right:

• I used love2d, having only about two weeks of learning it (and of learning lua). This seems like a sure way to fail, but it was actually fine.
• The AdvTiledLoader library saved me a lot of time, and Tiled let us design levels relatively painlessly.
• Using music as a part of the level design seems like a viable strategy.
• The workflow for my graphics is the same that I used in previous Ludum Dares, and it seems to work well, except for tiles, about that later.
• Making the distributions for all the platforms was very easy with love2d.
• I had an emergency plan of adding shooting to the game and turning it into a shooter if anything went wrong, but that didn’t happen.

What went wrong:

• If you are setting out to make an adventure game, make sure you at least have some outline of the plot. We left the plot for last, and it was a huge mistake — we only did very basic and rudimentary things so it can barely be called a game (you can’t even win). Another person taking care of the characters, plot and levels would be fantastic.
• The freehand style doesn’t work too well with tiles. It was hard to make them tile and still retain their rough looks. I also didn’t make all the necessary tiles, so you can see some gaps and inconsistencies if you look carefully.
• Collisions are hard, but fortunately getting them perfectly right is not necessary for the game to be playable.
• Sound support of different libraries varies greatly between different platforms, even with a multi-platform framework like love2d. The game crashed on Windows just because we pre-loaded the sound files into memory.
• An overlay layer is not enough to make top-down levels look right in respect to obscuring sprites.
• Defining the dialogues and quests directly in the map files is a mistake — makes it too hard to see everything at a glance and make improvements. I think that I should have only defined named locations, and have all the plot and text in a separate file that refers to them.
• We didn’t have the free time and any energy left to work on it for the third day of the jam. We could have come up with a real plot and polished it all much more, but we were so completely tired, that we haven’t.

You can play it here.

Some input from Makdaam:

• There’s not enough time
• Learning milky tracker proved to be more difficult than expected
• Sounds and music are not implemented right anywhere
• 1 out of 50 melody ideas can be rendered almost instantly in a tracker without any training
• 1 out of 10 melodies are usable
• sfxer FTW
• Audacity is enough to make your own synth samples with distortions
• none of those samples will be used in the final LD product, so don’t waste your time in Audacity
• prepare for your neighbor getting a new hifi during LD

Tags: postmortem

Just wantedto let you all know that there is a Seven Day Roguelike Challenge this next week (9-17 March 2013), also known as 7drl, wherein you are challenged to write a rogulike game within 7 days. Details at http://7drl.org

Tags: 7drl roguelike

You are hereby invited to take part in an annual gathering of people of all nationalities, genders and beliefs, who are interested in creation of roguelike games. Roguelike games are computer games that are in some aspects similar to, or inspired by, a classic, turn-based, tile-based, text-mode, tactical, heavily randomized, perma-death, dungeon exploration game known as Rogue. You might have probably heard about some of them, such as NetHack, Angband, Dungeon Crawl, DoomRL or ADOM.

This meeting has an informal nature of an unconference, which means that the exact list of speakers and the schedule are going to be decided right there on the spot. All kinds of activities are possible, from traditional talks, through discussion panels and workshops, to game jams and maybe even musicals — it all depends on what the participants think would be the best use of their time.

This is the 5th IRDC, and it will take place on 7-9 June 2013 in at the Zoo Coworking Space, 20 Zwierzyniecka street, Poznań, Poland. Registration is not required, as the event is open, but it will help us to estimate the number of participants and better prepare the venue if you register at http://irdc2013.eventbrite.com/.

More information is available at: http://roguebasin.roguelikedevelopment.org/index.php?title=IRDC_2013

Tags: event roguelike

We are going to do the team jam, with @p_the_wanderer painting some gorgeous graphics, @llanga doing music and yours truly trying to come up with some gameplay that doesn’t suck too much to enjoy the graphics and music.

I have a vague urge to make it a crazy beat-em-up, but obviously it depends on the theme. My weapon of choice will probably be Python and PyGame, as they are tried and tested and I don’t want to risk disappointing my team mates.