My first Ludum Dare/Game Jam was a success! There were definitely bumps along the way, but we’ll get to that in a minute. First of all the game I ended up with (Play it here!). You have a fleet of AI controlled ships fighting an enemy ship, but the problem is that your ships aren’t all that “intelligent”. So whenever they malfunction you have to complete a minigame or quick time event and fix whatever went wrong. As the game goes the events come faster and faster, and by the end an event is happening about every second. Now that that’s out of the way, here’s what all happened and what I learned.

 

 

Bad Stuff

• I had a game idea about one hour after the theme was revealed. In it you controlled the traps on a Meat Boy style level and had to stop the heroes from getting through. This was going well until about 12 hours later when I realized the game had a ton of problems, the biggest one being that it wasn’t fun. It also was going to take more art than I was willing to make and I hadn’t set anything up right so adding in new traps and whatnot was a pain. So I completely scrapped the idea and started fresh. More on that in the good part.
• The game gets repetitive fairly quickly. I feel like a lot of LD games fall into this trap, but mine kind of shoves the repetitiveness into your face. I had originally planned for more events to be in the game, but I ended up with only 4. This was partly because I lost that first day to the first idea, and partly because by Monday I was completely burnt out. What I have now is basically a cleaned up version of a single day of work, even though I had plenty of time to add in probably two or three more events.
• The game is incredibly hard. I’m sure you all know how hard it is to balance a game, especially in the span of only a few days, but I don’t think anyone besides myself can beat this game. I tried to balance it so I could beat it easily, which would mean that anyone else should be able to just barely beat it or just barely lose on a second attempt (It’s supposed to be hard, but not this hard). Apparently that thinking was completely incorrect. So the lesson learned is 1) find playtesters and 2) make the game to the point where you find it too easy and then make it easier.

Good Stuff

• Despite losing that first day to a different idea, I still ended up with a solid and complete game. I attribute this mainly to Unity. I only started seriously using it about a month ago, and it still amazes me how simple it makes everything. So the lesson to learn from this is if your game is no good after a few hours don’t be afraid to scrap it and start again. If you’re working on a game you don’t like then you aren’t going to have any fun and the game is going to suffer because of it.
• Again, Unity. I’ve talked to programmers before who don’t like it for one reason or another even though they’ve never even touched it. There’s no way this game would be anywhere close to what it is without Unity.
• I actually had next to no planning when it came to the final game. Once I scrapped the first idea I had another one that did involve controlling AI ships, but not anywhere close to what it is now. So I started making that new idea by making some planets and making a bunch of flocking ships. Then I accidentally made the ships move way too fast and they started zooming around the planets and bouncing off the side of the screen. That gave me the idea for the “Gravity changing” minigame (Even though it makes no sense) and the rest of the game was born from there. If there’s a lesson in this it’s that even if you don’t have a solid idea just start making something. Inspiration will come from somewhere.

 

So that’s my thoughts on the weekend. I’m incredibly happy with how the game turned out (Again, you should totally play it here) and look forward to the next Ludum Dare. Now to get back to playing everyone else’s awesome games!

Gameplay – Mars level

Right:

• Graphics. At first it didn’t look very well, but then we’ve managed to get pretty graphics with help of the Blender
• Music. Composed by team member Drahosh, I find it to be very addictive. You should certainly play it with sound unmuted.
• Level design. First levels are simple, later it gets challenging and then really hard. I had lot of fun myself trying to beat my own game.
• Level backgrounds. You are flying over real Earth, Mars or Moon. Just try it :).
• Game code. Coding this game was fun, but seeing our 4000 lines of code working is even better, especially if things work like they were meant to.
• To sum up: Really almost everything. You should play it here: http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=13839

Wrong:

• Sound effects. Sound files are there, but I didn’t manage to get them working on time.

What’s next:

Android port is on it’s way. And there will be Android post-compo (opensource) in Play Store soon. We will add some more features and redesign levels to make them playable on smaller screens of Android devices.

PS: Feel free to play around with xml files in res/levels. And if you come up with something cool please mail it to me

 

I hope everybody enjoyed this LD as I did, and I’m really looking forward to the next one!

 

Shadow Possession contains a goat!

Click here to view my LD entry.

Or click here to go directly to the game.

 

This post contains a few spoilers (sorta), so I suggest playing before you read on.

 
Phew!

---

What a hectic, fun, stressful, and exhilarating weekend this was. I’ve never participated in a Jam before, nor have I ever actually completed a game, or made something beyond the game I’m still working on.

That first game has been (slowly) in development for almost a year now, so the idea of creating a game in a weekend was very appealing to me. Almost like a “right place at the right time” moment for me, as I’ve been struggling to have the motivation to continue development on my first game. Turns out that LD was exactly what I needed.

All the lessons and techniques I’ve learned from working on that first game really helped me create Shadow Possession in the short amount of time I had. I’ve also learned that if I can make 8 decent levels in 60 hours, there’s no excuse for my first game having only 5 levels in 9 months! It’s been a good wake-up call.

 
What’d I miss?

---

I have a good list of things that I didn’t have time to get into the game.

Off the top of the list: more sound effects, an increasing difficulty curve, and new rules/additions to the mechanics.
 
Sound

---

Sound is something I always had in mind as I developed Shadow Possession. I imagined “darkness-y poof” sounds when you would flip and land, a “searing, burning” sound when you were hit with light, and the appropriate sounds when the lights begin to flicker on and off. They really would have added to the atmosphere, yet I simply ran out of time. A few more hours probably would have been enough, as I had gotten footstep sounds into the game, so it was only a matter of having the time to find the other appropriate sounds I needed. Fixing nasty bugs that appeared in the last hour or two took priority, unfortunately.

 
Increasing Difficulty/Additional Mechanics

---

I had wanted the difficulty in Shadow Possession to eventually start escalating, after the player had time to learn the mechanics I continued to introduce. I set the flow of the levels in a calculated way – You learn to flip before you learn that light hurts, you get used to avoid light to continue before you learn that some lights have switches, and so on. The final level in SP should hint at what I wanted to do next with the mechanics – mobile lights via people/creatures/machines/whatever made sense. My plan was to have some AI that would wander in certain areas, and if the spot you with their flashlight, they’d chase you. They’d be either random strangers or perhaps friends of “The Gentleman” (the guy whose body you possess). I also wanted to make the light kill you quicker (and perhaps not push you out as much), but balancing the difficulty with that would have taken more time, so I went for more of a timing approach.

 
The Result

---

Despite not getting more sounds and menu in, I’m still very pleased with what I turned out. It was a lesson-full, motivating experience to take part in. I’d like to compete in the next LD again, and do something with procedurally generated levels/content. I’m not sure what takes longer – hand-crafting levels, or letting your systems do that for you (and working out the bugs), but I’d like to take a crack at it, as I’ve never done proc gen before.

 
The Future

---

If you liked Shadow Possession, look forward for a new version in the soon future. Now that I can take my time and really give it some finesse and challenge, I’d like to see where the game can go. I plan on setting deadlines to self-motivate like I did for the Jam, so development won’t take years. I won’t try and estimate a release time this soon, but I plan on seeing what I can do in a week or two, and take it further as needed.

 

All in all, I feel a good kind of different from before I participated. A pretty tired kind of different, but a good one nonetheless.

Tags: 2D, as3, flash, Flixel, ld25, post-mortem

UNLEASHED – Son of Kracken title screen.

Play the game here: UNLEASHED – Son of Kracken

So it is with a bang and not a whimper that I end my second Ludum Dare competition entry!  I always like to wait a few days before I do a post-mortem like this.  I need the time off, need to rest my eyes and my ass (sitting in my crap computer chair really wears me out), and take my mind off it for a while.  Now, I feel like I have a good grasp of what I was doing, what I hope to accomplish, and what I could have done differently.

You are free to take a look at my previous entry if you want to get a glimpse of a project done wrong.  I was determined to not make the same mistakes as before.  I knew first-hand that I needed to do a lot more planning, even if it was only a simple design document with some concepts and strategies lined out.  I also knew that I wanted to use a pre-existing engine for my development.  I tried rolling my own the first time and it added a dozen layers of complications – unnecessary complications.  I was also determined to finish the damn thing – have a start, a finish.  Have some sounds and understandable art assets.  I think I did just fine this time around.

The entry I give you this year is called Unleashed – Son of Kracken.  It was Friday night, and I was halfway through the Hobbit when I remembered that the voting should be in.  I checked my phone, and was sad at first.  You are the Villain?  Not the theme I was hoping for, but whatever.  I sat for the rest of The Hobbit and thought hard about a game.  Nothing came to me during the movie – but the breakthrough came during the drive home.  I was listening to the XM radio in my car, and the word ‘Sea’ was in the title of the song.  That got the juices flowing – the sea…pirates!  Sea monsters!  The Flying Dutchman!  I started on an idea dealing with the Flying Dutchman, but then came around to being a sea monster terrorizing the ocean deeps.  The Kracken myth soon followed – and the popular line ‘Release the Kracken!’ right on its heels.  So if your father is ‘Released’, what does that make you? UNLEASHED!

ULEASHED – Son of Kracken Instructions Screen

Once I had the idea, much more started falling into place.  I had the skeleton of an idea, so I started writing.  I thought about sending ships to different ports, having a large world for you to explore, and having pirates to fight.  Some ideas I originally had were five or so types of boats of varying strength based on the island you were near.  This idea was abandoned in favor of all islands being relatively equal in the beginning.  I documented all this in a one-page document – the most crucial part of the process.  I am a ‘learn by doing’, so when I type something it gets wedged in my mind much more firmly than just remembering it.  Documenting the process was the best decision I made.

Once the concept was in place, ImpactJS took over.  Before, when I rolled my own engine, I had to deal with collisions, drawing, levels – all the sticky stuff.  Not this time around.  ImpactJS is an EXCELLENT engine for javascript/html5 development and I’d recommend it to anyone.  Well worth the $100 license fee.  I was able to get a prototype up within an hour, with a simple sea creature roaming an ocean with nothing in it.  With the built-in level editor I was able to get the islands and spawners in place quickly as well.  In fact, because of the power of the engine, I was able to spend the vast majority of the time on game balance, art, sounds, and other aspects.  With my first go (LD 24) I spent so much time on an engine that I didn’t have much time to work on an actual enjoyable game experience.  Using a pre-existing engine, and a robust one like ImpactJS, really accelerated the process and allowed me to focus on the game mechanics.

UNLEASHED – Son of Kracken Gameplay

Mechanically speaking, the game is a little bit too easy.  Cannon balls don’t do a lot of damage, the spears are relatively simple to deal with, and the Merchant Marine that you face doesn’t cause much trouble.  The ship difficulty curve is also kind of wonky – when a ship leaves the map, its spawner gains a level and allows more powerful ships to spawn.  The ships also have a tendency to get stuck on islands (as do cannon balls and your acid spit).  On a much more positive side, mechanically the game is quite sound.  Attacking and being hit feel good (to me), and movement has a definite ramp-up feel to it.  You start quite slow but within a few minutes you can overtake anything on the sea.  I like using the ‘Dive’ ability to dodge cannonballs, and using the ‘Acid Spit’ ability to fire back.  The ‘Vortex’ is crazy powerful.  The game does technically have an end goal – once you kill 100 ships, the Hovering Dutchman emerges and challenges you.  When you defeat him, you have ‘won’ the game – but with the power of the HTML5 spec (LocalStorage!) I am able to give you a persistent character.  Even if you die, your stats remain the same so when you start over you have your same character as before.

UNLEASHED – Son of Kracken Gameplay Screen 2

What would I do different if I could do it all again?  To be perfectly honest, I’m not sure what I would change.  I documented my game before I started, giving me a good road map of where to go.  I used an existing engine to make my life easier, and make the game better.  I have little to no artistic talent (as far as drawing/pixel art is concerned), so I am happy with the sprites I was able to produce.  I really like how I used my voice for a lot of the effects, and am also happy with how that turned out.  If I were more talented or a better Google-r I could have provided some pirate-y or naval music.  I also would like some more decoration in the islands building, and the sea.  Additionally, more ships, some sea life, and more stuff going on in-game would improve the experience.  All of those things were clamped by time (and my sanity – I needed sleep!).

What does the future hold for Unleashed – Son of Kracken (if any)?  I really like the concept of the game and how it plays.  It doesn’t take a might stretch of thought to see it implemented on mobile platforms (using AppMobi’s Direct Canvas acceleration).  The game also lends itself to simple mobile controls (especially touch).  With some time I could also improve the assets.  It’s always been a dream of mine to see a game of mine in the app stores, and seeing people playing and enjoying my game.  I might see if I can’t take this a little further, polish it up a whole lot, and try it out!

 

Thanks for all your reviews and comments!

See the entry here.

Good – why you should try the game, look at the source, and what I recommend for your next game
1) Learned about SFML.
2) Game was, I think, fairly pretty, which I wanted to do regardless of theme.
3) I wanted to make one of those surreal Ludum Dare game experiences. Given that more commenters thought the game was artistic than frustrating, I’ll call it a success.
4) Xsplit (free streaming software) works on computers with worse specs than the minimum requirements. I tried Flash Media Encoder, but it requires ManyCam or similar to present your desktop into a webcam as well. I also tried Open Broadcaster Software, I can’t remember why it didn’t work out, but I’d want to use it in future because it’s open source. I met a Ludum Dare buddy while streaming, so it’s good for networking. Also put a description above your stream link — I’m pretty sure I got the 1 viewer (aforementioned buddy) because I put “C++” and “SFML 2.0” in my comment on the streams post. I also implied that I’d be up for explaining what I was doing, which I really was.

Bad – What to improve on next time
1) Remember that at the start of the competition, the theme is posted on Twitter, not the site itself.
2) Use SFML only for what you can’t do yourself — treat it as a very thin wrapper to OpenGL, an event poller (and remember to turn of key repeat), something that gives you an audio callback, and a window maker.

I’m interested in playing some local multiplayer games tonight. I’m aware of these:

http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&q=multiplayer

But if your game isn’t in that list please tell me about so I can play it!

Post-Mortem // Play and rate it here

How could someone justify ending the world?

That was the question I wanted to answer. So I told a story indirectly, using personal narrative, correspondence from other people, and cold, scientific descriptions of doomsday scenarios.

To keep it from simply being a “click here to read more” game, I tried to make it emotionally difficult to progress. This led to the decision to start at the end, then have the player go back in time. The emotional weight would come from the scale of devastation, the local impact, and letters from other people (pleas, threats, news) that would show different perspectives on your actions, and also inform you of the past that brought you to the point of being a messiah of the apocalypse.

That chart was in my head as I wrote the narrative, which I did first. Then I settled on a graphical look (super 16-bit) and created a setting that would be part of the story: a location that showed the effects of latest disaster you enacted.

Here, you can see the final stage (which is played first), compared to stage 2.

Each stage has a visible change. I think that’s one of the things that really worked out well.

There’s a glowing square in each scene. That’s a “memory” of the previous stage, showing how things used to be. This interactive object lets the villain provide some context and commentary, while serving as the “gate” between stages. This is probably the weakest part of the design, as the player has to walk around and touch things to discover how to unlock it. But once they figure it out, it’s the same each time.

There are two computer consoles in each scene. One shows the effects of the previous disaster:

The other shows the impending disaster, giving you the option of activating it (sending you forward in time) or disabling it forever, which can end progress (“this is how it ends”) if you decide to abandon the memory forever. Here’s the Acid Ocean activate screen, which would be seen in the stage following the one with the result:

Finally, there are the Letters, which provide external perspectives on your actions, as well as insights into your personal history (including the dark events that turned you into what you are). There are a few one-offs, but I use several recurring characters to show progression. Here are two letters from the President, in reverse chronological order:

I’ve heard the colorful letter from the Fisherman’s Union of Anchorage Alaska (after you’ve acidified the oceans) is a particular favorite.

Ending progress by disabling the doomsday device AND closing the memory gate — thus stopping progress forward or backward — was supposed to trigger a narrative explaining what happened next, which would have further justified you moving forward. But time, alas. She’s a monster.

I hope I get enough feedback and votes to justify putting that in the game, giving everything a coat of polish, and posting it online for a few bucks. But even if that doesn’t happen, I feel a tingly sense of satisfaction at a story well told.

Thanks for reading. Merry Christmas.

-ted

Tags: post-mortem

So here’s my timelapse for my game!

The beginning is code and placeholder but it starts being fun with some sculpting at 00:55! 😀

Tags: timelapse

A little bit belated, but here’s my postmortem for Cruel Cruel Dastard (play and rate it here)

Things that went well

Recording my own sounds: 

Usually when I’m working on jam games I tend to make heavy use of free sound libraries (such as freesound.org) and content generators (such as bfxr). Since the main Ludum Dare Compo disallows use of sound libraries, I decided to give recording my own sounds a try. It turns out recording sounds was actually a lot easier than I imagined (and also a ton of fun).

Under normal circumstances, I might have spent ages searching through a free sound library for a train sound. While recording my own sounds, all I had to do was record myself blowing into paper and then tweak the result in Audacity to get what I wanted. Everyone who plays the game seems to love the evil laugh I included as a victory noise. That thing is basically just my own voice sped-up and it only took me about a minute to make, so I’ll definitely be recording my own sounds more in the future.

Re-doing the controls halfway through:  

When I started making the game, the idea was that it had a simple “click to place things on screen” control scheme. To build a large amount of train tracks, the player would have to place each piece of the track individually and switch to a different shape every time the track turned. To illustrate, here’s a screenshot from the game on day one:

notice how each shape has its own menu item

If this sounds like a terrible and tedious control scheme to you, well you’re right! About halfway through the competition, I decided to scrap this scheme and make a much more intelligent track building system that allows the player to lay tracks or re-route existing tracks just by dragging their mouse across the screen. Even though it took a good chunk of time to implement, I think it was a pretty good idea, particularly since it’s now much easier to build tracks in the game than in my level editor.

still have to choose pieces by hand

Practicing Art Beforehand:  

I was using the Make Pixel Art web app for making my art. I like this program because it’s really simple and it has super useful “lighten” and “darken” tools that I can’t seem to find anywhere else (if you know how to get the same thing in photoshop or gimp, please tell me).

Of course, it’s simplicity has some drawbacks, such as not being able to easily constrain the size of your drawings. Fortunately, with a week of practice beforehand, I was able to get past these problems via silly solutions such as creating “frame” templates.

Things that didn’t go so well

No Time for Levels: 

Hey look at that! I kind of mismanaged my time for this jam. My original intention for the last day was to do some basic polish, make a few designed levels to introduce the mechanics (complete with tutorial text), and then build a procedural generation system for making the game more of an arcade style puzzle game (like tetris) rather than a deterministic puzzle game (like a rubiks cube).

If that sounds kind of over-scoped to you, you’re correct! I was still adding polish on Sunday when I looked at the clock and realized I only had one hour left and no levels to speak of yet. It didn’t help that my level editor wasn’t fully set up yet either.

In the end, I had to scramble all ten of the levels together in less than 20 minutes, which basically meant I got the tutorial levels in and not much else. Whoops!

Poor Prioritization: 

Part of the reason I ran out of time on Sunday was definitely due to poor prioritization. There are a bunch of mechanics in the game that are either not explored fully or not properly implemented at all (such as the rope mechanic). I think if I had done a better job pruning these ideas down to only about two or three basic mechanics (say, laying railroad tracks and dynamite), I wouldn’t have run out of time towards the end.

Also, certain pieces of polish that would be essential for a larger release–The “undo” button in particular–might not have been really necessary for a 48 hour game, particularly one as short as this one, so I might have benefitted from focusing more on the core gameplay.

Playing it “Safe”:

One of my goals for this weekend was to create something fairly polished that I could easily expand upon for a bigger release. In practice, this meant that I discarded a bunch of ideas during the planning phase that were a lot more experimental or interesting because I wasn’t sure I could expand them into something worthwhile in only 48 hours.

Of course, this means I ended up designing a game that was distressingly similar to games I’ve made in the past. While this isn’t necessarily a bad thing (plenty of people riff on the similar concepts several times before moving on), I think I could have benefited from going with one of my wilder ideas.

Another game with 3×3 explosions

I think I still might be able to differentiate this game from some of my previous work by implementing the “arcade mode” which I didn’t get around to, so I’ll keep updating as I do post-competition work on it.

That’s about it. Thanks for reading!

 

 

Park to Park screenshot

Here’s how my LD25 compo entry, Park to Park, came to be.

Concept

I had three basic game ideas lined up that could be made to fit a number of themes. I woke up early Saturday morning, checked on my phone what the theme was, immediately picked this one, and had a fully formed idea before I’d even finished my shower. There would be an evil businessman who wanted to turn a lovely green into an ugly parking lot. Of course there had to be protesters, so why not make them the ultimate symbol of love that is the hippie? The goat just fit in quite naturally. I’m not sure where this all came from; inspiration is an unpredictable mistress.

Coming up with a title was harder, but because I don’t like changing titles halfway, I just cut the knot after ten minutes and went with Park to Park.

Programming

I’m very familiar with the technology (HTML5, CoffeeScript and CSS3/SCSS), but programming still took longer than I anticipated.

I initially thought I could get away with really simple collision detection, but it didn’t work out so I had to make it more sophisticated. Somewhere along the line, a bug crept in that occasionally causes an enemy to miss a boundary and walk off the screen. It’s very rare and I couldn’t reproduce it, so I finally submitted with this bug still in.

Someone also found a bug where you can divide the playing field into two disjoint regions, by “skimming” along the opposite edge and then looping back. This is not good for your score, so this is not exploitable, nor does it crash the game in any way, but it’s still weird. I should have started pouring concrete as soon as the tape touched the edge of the concrete, rather than waiting until the villain has his feet back on safe ground.

From my previous games I learned that people like to compete against themselves, so I added a scoring system and a hiscore list. The list is saved using HTML5 local storage, which I’d never used before, but it turns out to be incredibly simple (it’s basically just a hash map, though it only stores strings).

For sound, I reused the technique from my previous game Cytosine, downloading base64-encoded WAV files and programmatically creating <audio> elements using a data url. It’s far from efficient, but quite effective.

Another problem with programming was — again — the music. How hard can it be to make HTML5 audio loop gaplessly? Pretty hard. I ended up having two <audio> elements, starting one when the other finishes. After the weekend, I got a bug report from someone saying that both were playing at the same time… For next time, I should probably research libraries to make this easier.

Gameplay

As usual, I didn’t take enough time tuning the gameplay and difficulty level. From the comments so far, it seems I got it mostly right by pure luck.

My biggest mistake was that I didn’t know my genre. I based this game on a game I used to play on Windows 3.1 whose name I could not remember, and I didn’t hear of its ancestor Qix until after the weekend. If I had known, I would have added the enemies from Qix that creep along the edge. This would force you to move and make it impossible to sit and wait indefinitely for the right opportunity, and make the game much more tense and exciting.

Graphics

This is the aspect I’m most happy about. I had a lot of practice lately using Inkscape for another, somewhat bigger project that I’m working on, and got a lot of inspiration and courage from Chris Hildenbrand’s excellent blog 2D Game Art for Programmers. Add some rudimentary but effective animations, and I’m quite happy how the look of the game turned out.

It’s really too bad that the characters end up so small on screen, and moving so fast. It’s hard to see the flowers on the hippie’s robe and the weird rectangular pupil of the goat (really, those guys are scary up close), and the hearts on the underwear of the businessman when he’s stripped for a split second before he gets wrapped in his own tape.

Getting all the tiles right and lined up for smooth edges of the concrete (except in some, ahem, corner cases that I later discovered) took quite some time, and with hindsight I should maybe have selected a simpler approach (like masking in code) to make it look good.

Later additions to the graphics include the logo, and the lines on the concrete of the car park. As there was no entrance, I just made the arrows point in a circle. I suppose it’s a metaphor for the futility of industrialist progress, or something. Maybe. I guess.

Sound

For my first two Ludum Dare entries, I used Bfxr. For this one, I wanted more natural-sounding effects, so I used my webcam microphone instead. With no practice at all, it turned out I’m a lousy foley artist.

The “win” sound is me playing a scale on a tin whistle, sped up and pitch-shifted downwards. The “lose” sound, lacking real construction tape, is the crumpling of a plastic bag with some effects applied to it. The goat and hippie sounds are just my voice shifted up and down, respectively. The popping sound for placing the tape is me popping my cheek like this (well, almost like that). I did the “pouring” sound by shaking a bottle of water; that one worked out particularly well.

All sounds were recorded and edited in Audacity, which was also a first for me. Maybe it was my inexperience, but I think that’s one of the worst designed, erm, hacked up user interfaces ever. But it works, and it’s free, so I shouldn’t complain.

Music

Some people like the music, some people hate it. If you are in the latter camp, feel free to turn it off! The melody is a pastorale for two wind instruments by J.B. de Boismortier, entered by me into LMMS.

Since I’m not good enough at music to play anything myself, I had to find a tune that would work reasonably well when played mechanically by a computer. The harpsichord sample fits well with that, as harpsichords naturally have relatively little room for expressivity. The problem with LMMS’s harpsichord sample, though, is that it seems to be off-key, or at any rate it would sound awful together with any of the other samples like flutes and organs. That quite limited the options to make it sound interesting.

Chrome

By which I mean, intros, endings, menus and the like. The win/lose screen is just some basic HTML and CSS with a CSS3 transition applied to it. I had this idea of making it into an official-looking letter, hence it is exactly the ratio of a piece of A4 paper, but that didn’t really work out.

I had some images in my head of what the intro screens should look like, but didn’t get round to them, so you fall right into the game.

On IRC, Cryovat (much concrete beauty be upon him) mentioned that he was disappointed at the lack of a game over screen after winning, so I spent the last two hours scaling up the villain’s image, pulling him apart, and animating the parts with CSS3. I won’t spoil the effect; if you want to know, go and play for yourself!

Tags: postmortem

I’ve been looking forward to this.

So I have to list the stuff I did well, stuff I didn’t, And goals.

What I did well.
-Made an actual game
I had been making games for a while before this, but I’ve always been kinda scared about releasing it. I decided to take part and I’m glad.
-Zombie AI!
I made my first AI! I’ve made stuff like moving platforms or goombas and what not but never something which thought for itself.
-I actually finished it.
It has a beginning, middle, and end.

What I didn’t Do well
-Rushed
A lot of levels where made in quite a panicky state and I felt I could have tried harder.
-Buggy
Zombie AI is very buggy.
-Story
It ends very abruptly and doesn’t really touch on the theme. I had very little time on my hands and I felt I should get the mechanics down before anything.
-Game maker
Game maker isn’t a bad thing; It’s just I’m bored of it. I like programming when It can keep me interested and Not frustrated.
I originally planned to do it in AS3 and Flashpunk, But FlashDevelop kept crashing and time was scarce, so I resorted to Game maker.

I had fun, And hope you did too. See you next time!

If you haven’t yet, you can rate the game here.

This has been one of the best experiences in game development since I started roughly 1 year and a half ago. I made my first completed game at the last Ludum Dare, and while I was excited about it, seeing how much better I’ve gotten at art, programming, design, and sound in just a few short months is extremely motivating. Anyway, here’s what went down.

What Went Right:

• The biggest thing I was able to do for myself this time around was choosing an idea with a scope that was reasonable for me. I had never done a game remotely like this, but choosing to do single screen levels, with very simple, but understable mechanics helped a lot. That’s not to say I did everything I wanted to (I obviously wanted more than one enemy type), but I was able to get a game that was fun to play by midway through saturday afternoon. From there, I was able to really start added to the core experience, like sounds, UI, End game splashes and stuff. Not only keeping with a reasonable scope, but defining what was core to the experience was crucial.
• While my game doesn’t look great, I’m very happy with the amount of progress I’ve made in this area over the last few months. If you played my last entry in August, I think you’ll agree. Midway through the contest, I actually redid every sprite using a new pallete, and since I’m not totally sure how to use the color replacer in Photoshop, I ended up doing each one manually with the fill tool. It took more than an hour of time, but I think the results were well worth it. In the end, my game isn’t pretty by any means, but I would say that there is at least a consistent style throughout.
• My wife can play it! Since I started making games, this has sort of been the litmus test for whether a game is approachable or not. My wife not only picked it up and played it, but kept playing for upwards of thirty minutes (she wasn’t very good…). I don’t know if anyone else has ever experienced it, but this is one of the most satisfying things that happens.
• Finally, I think I did a much better job of selecting my tools. I had learned to program exclusively in XNA up until a month and a half ago, and was tired of having to package my games for windows only and with several dependencies. Now I can build games much faster, with a more powerful tool, and I’m also able to easily package them to platforms that other people can actually access them on. Being able to export to web is huge for me, since I can get people to play them, even outside the LD community. Seeing that hundreds of people have played my game is super cool!

What Went Wrong:

• Like everyone else, Time. This time of year is full of Christmas Parties, Graduations, and Graduation Parties. In all, I was probably able to spend about 15-20 hours on it total, but I would have liked to get another five or so in. I had to cut back on the ambitious number of levels I was planning to put it, as well as the new enemy variants and environments. I’m not sure if this should even count as a “what went wrong”, since having no time is kind of the point.
• Music. I was able to get full sound effects and music in this time around, but I spent at least 3 hours (as much as 20%) of my development time making a 30 second loop. I ended up with ok sounds, but I wish I could have found some more flexible tools. inudge.net is great in a pinch, but the variety in instrumentation is definitely lacking. I’ll definitely try to find another solution before the nest LD comes around. Ultimately, the problem here is that I didn’t have a firm enough plan going in.

I’m sure there’s more to share, but that probably plenty for now. I had a ton of fun, and I’m actually really happy with my final product, all things considered.

 

This may not be the place to post this last bit, but it’s been on my mind the whole time I’ve made this game:

I think it would be cool to work with someone (or someones) else for the next LD. I’ve done all of everything for all of my games, LD and otherwise, and I think it would be a  good experience to learn to work with a team on something. I feel like it would be really beneficial to start exposing myself to other peoples ideas and styles, not to mention possibly make something better than I could on my own. Sadly, I think I may be the only game developer of any kind for a 500 mile radius around my house. I know I’m not an unbelievable programmer yet, but if any artistic people want to give it a shot next go round let me know.

Please join me today on my stream at 6 pm PST (-8 GMT) on 12/18/2012 (about three hours from now).

I will play your Ludum Dare game or one requested, just as I did during previous relax streams.

Tags: game, livestream, stream

So, it’s been two days since we submitted our game, Sky Pirates, to the Ludum Dare. Here’s just a little bit of information:

Users Before: ~20

Users Now: 42 (Our game is the answer to the ultimate question…)

 

Battles Before: ~10

Battles Now: 269!

 

This is really cool We’re glad some people are enjoying the game.

Hey everyone! 😀 I’m Joe, artist for Green Pixel’s games and for our first Ludum Dare entry: Dr. Vile in The Greater Good! I did the art and my friend and Green Pixel’s programmer, Rich, did the programming so we’ll each be writing a post-mortem of our experience.

First off, congratulations to every who participated in Ludum Dare 25! Whether you finished what you wanted to finished or not, think of how much more you have now than what you had before you started! 😀 I had that mindset going in and even if we didn’t finish in time, I would have still had art assets and we still would have had a foundation to build something out of. Thankfully, we did finish and now, not only do we have a great foundation to continue to build on, we have a game that people seem to enjoy! Thank you to everyone who’s played and we greatly appreciate your awesome reviews!

I’ve never worked on a project that had such a short timeframe. To all you 48-hour devs, kudos to you! I can barely tie my shoes in the time it took you to make a game! Right when we found out the theme, Rich and I immediately started brainstorming. From aliens to meteors to Mayans, we eventually decided to go the mad scientist route. And, thus, Dr. Vile was born! We gathered all our gameplay ideas and then I opened up Photoshop and went to work 😀

I drew inspiration for Dr. Vile’s look from all the mad scientist cliches out there. Lab coat, crazy glasses, disheveled hair, etc. It was tough fitting everything into a 16x16px sprite while keeping it discernible but I think I managed! He looks like a mad scientist, right? 😀 I also drew inspiration from a character in my webcomic, The Pocalypse, named Doc. Doc is also a mad scientist and I’m sure you can see the resemblance!

After I created Dr. Vile, I created the world around him. I usually work in one .psd for our game projects so I can keep everything together and keep everything in line with the theme. Here’s what I ended up with 😀

There may be a few things missing (like Dr. Vile’s computer assistant, Lexe) but that’s pretty much everything in the game! This simple (and small!) art style let me work with the time constraint while still being able to create as much “things” as possible. One important thing that I’ve learned from past game projects is the speed of my work, depending on the style of the game. This personal knowledge was invaluable in estimating how much I could get done in 72 hours 😀

Another extremely important thing for this project – and all projects, big or small – is how well Rich and I communicated. We’ve been working together for about 5 years, from a larger company to an indie studio to an at-home business, and knowing him for so long has created a great sense of communication 😀 I think that there’s nothing more important than that when you’re working in a team. For this project, it was crucial that we remained on the same wavelength because, obviously, art and programming are not the same. Rich let me know what was needed and what wasn’t and I prioritized my art list accordingly. I could have put Dr. Vile’s laboratory on the top of my list yet it wouldn’t have made it into the game. Imagine the time I would’ve wasted on a big, fancy laboratory if we didn’t communicate effectively!  And, while we both had the same overall vision for the game, the finer details had to discussed so we both knew exactly how the game would look and work 😀 I regularly send images like this to Rich to make sure that I’m on the right track:

It was a super fun 72 hours and I look forward to doing a Jam again! I wouldn’t have done anything differently and I’m glad that I now know that we can create something pretty cool in so little time! 😀

We are planning on expanding the game so stay tuned for updates (we’re hoping to add crafting, more weapons, more locations, more everything)! Follow us on Twitter @GreenPixelDev  and feel free to visit http://www.greenpixel.ca and check out our other projects 😀

Thank you again for playing Dr. Vile in The Greater Good and if you haven’t, play it now and give us your feedback!

Also, keep an eye out for Rich’s post-mortem!

Tags: post-mortem, postmortem

That’s right. I completed my game. Yesssss. 😀

Tools Used:
– Unity 3D
– 2d toolkit
– Photoshop
– git
– bfxr.net

High-Level Summary:
I think I paced and scoped appropriately this year. After the theme, I scoped out the game in the beginning few hours, as something that I could complete within about 15-20 working hours. I started with the most important work first (set up a build, linked in packages), then the hardest work next (minimum set of art), moved into the core mechanics (programming), then to polish (audio, bug fixes).

Time Breakdown:
11.35hrs -> Programming
05.10hrs -> Art
02.97hrs -> Public Relations
02.24hrs -> Project Management
01.95hrs -> R&D
00.57hrs -> Audio
00.39hrs -> Design
—
24.57hrs -> Total

Great job everyone! I’m excited for my next jam (GlobalGameJam) coming up in January!
Play and rate Bret here

After Ludum Dare it would be easy to just game the rating system and ‘rate’ 100 games every night. However, I prefer to give each game the same amount of time I would hope others would give mine.

Let’s be honest, most entries are not replay-worthy, but replay value is the utmost important factor. Let’s also be honest: Games with outstanding graphics get more and better ratings across every category. I think that’s a shame because replay value is what makes the all-time greatest video games so legendary. Replay value really aught to be the second-to-top category, just under overall.

So here’s a list of games I’ve played so far that made me want to play again, and in some cases again and again. In my mind, these games fit in the true winners circle.

Trolls: Where the Sun Don’t Shine

I found myself wanting to get a higher score, to push myself. It’s amazing how such a simple title can be so addictive.
Click here to play

Plane of Misery

Although the timing is short, this game is a real gem. I couldn’t stop laughing at the mere premise of the game, and the gameplay itself was fun. Okay I admit the puzzle timer was way too fast but that didn’t stop me from trying this game over about 10 times.
Click here to play

Heroes are so Annoying!

Okay, so when I beat the game it was over; No more replay value. However, it took a couple tries to get it right. If only this title had random dungeons, I would sit here and play for hours.
Click here to play

Of the 43 games I’ve played and rated, these three gems are the only entries that made me want to play for longer than 5 minutes.

Good job.

Article at csanyk.com/rants

Tags: Bad Puppy, csanyk, Design analysis

> Play/Rate/Vote/Comment
> Time-lapse here: http://www.youtube.com/watch?v=LnqqZIqjIdA

The Theme & My Idea:

In truth I had a very specific goal coming into this Ludum Dare weekend. I wanted to prototype a mix of game mechanics and see if it was compelling. As long as the theme was fairly generic I figured I could make it work.

The theme “You are the villain” was announced as I was leaving work. I like timing the theme announcement time for when I’m not at a computer. I had an hour long commute to think through what I wanted to do.

My initial concept was a serious topic, but this fell apart early Saturday afternoon. What emerged was a tale about a cat.

Writing:

Another goal I was hoping to accomplish this weekend was to get my fiancee (Melinda) involved in writing dialog trees. We’ve been trying to get traction on our own game idea for a long time so this presented a good opportunity to put a fire under our asses to figure out a usable workflow. One of the first things I did Friday evening was write out a template in Google Docs including a sample dialog tree. The thought was that Melinda should could edit this doc, I could copy and paste into Chat Mapper, then export to XML for use in the game.

This workflow worked… pretty good! Melinda was able to follow the template well. Copying and pasting into Chat Mapper was quick. And the resulting XML files were usable almost immediately. What I didn’t account for was game dialog logic being so foreign to Melinda (she is not a gamer). I’ve played so many games with dialog that I can just see the underlying structure. It was difficult for Melinda to write without fully understanding how it would flow in the final project. Thankfully it took me literally minutes to turn her dialog into gameplay so she could see it in action and adjust accordingly. Rapid iteration saved the day.

The original scope was 3 stages each with 3 characters – so 9 dialog trees total. Final game had 1 stage and 3 dialog trees which was plenty of content for this jam. Melinda learned a heck of a lot about dialog in games and I learned a hell of a lot about explaining these systems. I’m considering ditching Chat Mapper for a simpler text-only file format. While the time it took to copy and paste into Chat Mapper was negligible, I quickly found that the tool might be too cumbersome to rapidly iterate on a text-heavy game.

Technology:

For the first time in 3 years I didn’t use Flixel for this Ludum Dare. In September I started learning Starling and have been building my own helper classes. This was my first completed project with this codebase. Things… mostly worked. There were a few very broken things that I came across that I had to just design around. I’m not a framework programmer by any stretch so I’m impressed when any of my code can be reused.

At this point I’m not sure if I’ll continue developing my own codebase much more or if I’ll just wait and either adopt Flash Punk 2 fully, or just parts of it.

Graphics & Sound:

I feel like I barely got to really polish the game and as such I had to make due with some fairly awful graphics and sound. Certainly for (my) Ludum Dare standards they are fine, but they just don’t come together as nicely as I’ve managed in the past.

Design Goals:

As stated, my primary goal this weekend was to test out several game mechanics and see how they played together. I originally covered the Platforming/Random RPG Battles in Abarrane (LD 19). These worked well together. For Fluffy, I wanted to try out my idea for a dialog “mini-game” that relied on stats that you’d build in combat. This came together pretty good, although I was incredibly nervous for most of the weekend. Essentially I was juggling 4 distinct gameplay mechanics during a 48 game jam. I honestly didn’t feel like I gave any of them the love and attention they each deserved. I was most worried about that intangible “glue” that holds these things together and until late Saturday I didn’t think this game would come together as well as it did.

Overall:

Was this my “best” Ludum Dare entry? No. But did I achieve many of the goals I set out to achieve? Yup. Ludum Dare’s are all about learning and practicing my craft so just participating is rewarding for me. Having a game I can show others after the weekend is just a bonus.

 

Rob:  the thief

 

It’s Nathan this time, I thought I should write something since Brad wrote and streamed everything else.

Summary

We didn’t have our sights set too high for the competition. I am in college and I just finished my final projects on the 13th after pulling a couple all nighters so I didn’t get much time to prepare. Our main goals were to come out with something playable. We also wanted to learn a lot about game dev in general and game dev with Java + Slick2d. We are happy to announce we accomplished those goals.

Brad and I have never really worked on a project together before and we are both first time Ludum Dare participants, it was a great experience for both of us on the collaboration aspect and the 72 hours without proper personal hygiene aspect.

Personally I had never worked on a single repository with the same person before, I was new to conflicts when merging so that was great to learn.

On a final note overall it was a great time, we generally completed our goals. We were hoping to finish  something with more substance, such has sound in the game, a bigger map with more obstacles, enemies, etc, but we are happy with the result.
All we have up right now is the source, however we will soon be adding a jar and hopefully an applet.

What went wrong

•  Not enough time was spent preparing before the competition started.
•  We should have familiarized ourselves with the Slick2d Library more before starting
•  Got less completed than we hoped
•  Did not get to implement sound into the game

What went right

•  We learned more than we originally thought we would
•  We got a rough prototype completed
•  We were able to stream the process, and take snapshots for a time-lapse video (coming soon)
•  Built a lot of reusable component based entity classes

What’s next

• Build more from the prototype, add more of a level, change the art, add sound, etc.
• Refactor and fix the bugs that exist currently due to the shortcuts we had to take to finish on time.