Ludum Dare 22:

While Isolated Assault was huge success in my eyes considering it was my first Ludum Dare game, and by the scores it received, I’m struggling to come up with a Post-Compo version. You see, I’m just not feeling the motivation to work on it. Every time I sit down, I just feel, “Wow, this is old.” It’s like one of those projects I just gave up because I had no motivation for it.

That’s how it went with Dunnet (My most worked on game), and with my First Person Shooter (My first professional game), and with all those projects I started but never got around to.

Currently my Unity Project Folder looks like this:

Where “Abandoned” have been worked on for a while. I could always go back to the “Abandoned,” but I haven’t, and why should I?

My Problem:

I need a due date on projects.

Some people can never get work done knowing there’s time management involved. For me, it’s the other way. Knowing that there’s no time to procrastinate, and that there’s a reward for finished, I can get a lot of good things done.

I also have problems focusing on one idea and getting it implemented quickly. All of focused ideas I have are too complicated even for top-notch game companies.

Therefore, Ludum Dare was perfect for me–it gave a theme for the game and a deadline. I now know my best work will probably come from future LDs.

Will there ever be an Isolated Assault 2?

Not now. And probably not from me. Anyone familiar with Unity (That means you, reader!) can take my Isolated Assault Source files, and add some new levels, as long as I receive credit.

I have no motivation whatsoever to make an Isolated Assault 2. All my ideas were expressed in the first one. You are a guy. That fights cubes. That wears glasses. The only thing added to this game would be gloss.

Will you participate in LD 23?

Of course! Ludum Dare is the best way to manage time and get good games squeezed out!

Will you stop asking yourself random questions?

Never!!!!

Now I ask you, do I stick with deadlines for making games, or do I learn to get around them?

Do I use Ludum Dare to create all my of my work?

For some reason, I need some sort of reward/time limit for everything I make, because that’s just how I work.

Either way, I’ll obviously still be doing LDs, and I can’t wait for LD23!

Guess I’ve procrastinated long enough, here are my thoughts on my LD#22 entry Moving Day.

Statistics

These are probably pretty typical stats for games that don’t generate much buzz during the rating period.  I tracked my clicks using bit.ly and so far the source code has only been downloaded 6 times, total game clicks of 111 and total timelapse views of 144.

I also posted a link to facebook late at night, but that link saw very little traffic. I’m guessing it got buried in the flood of posts and most people saw it in the morning when they couldn’t play a flash game. I don’t think my social network made much of an impact on the statistics… it would be better to post such things just as work is letting out in your target location. The demographics were also interesting, you can see how this is really a global community:

What went right

• I’m pretty pleased with my tool selections. FlashDevelop + Flixel has been fun to learn and I was able to come up to speed fairly quickly.
• Inkscape saved the day for graphics as I quickly realized that I lacked the skills to make decent animated frames with pixel art. I’m pretty satisfied with my run animations.
• Recording a timelapse was actually pretty helpful for me. When you  get into the zone it is easy to lose track of time, the timelapse helped show me that the time I spent browsing was really pretty trivial when compared to the time I spent prematurely tweaking gameplay.

What went wrong

• I spent too much time tweaking gameplay before implementing randomized game levels. I usually get stuck obsessing over gameplay in my other prototypes and I’m glad that Ludum Dare forced me to go beyond that but I still wasted way too much time here.
• The innovative part of my game was supposed to be a physics-based gliding system that let you trade speed for jump height. I spent many hours tweaking these equations with a static game level and that work was basically wasted once I replaced the static level with randomized one.
• Animating the death scene was also pretty tedious. I should have learned how to use a tweening engine before the compo.
• Last minute bugs. I ran into a randomized null pointer error in the last hour of development… which was solved with a comically stupid hack: while(x==null) x = randomobject();

Next time around I’ll make sure to implement basic gameplay, levels and a win/loss condition before spending time tweaking any specific parts.

Eyes of the Exorcist was made as the first collaborative effort
between six strangers from who met through the San Diego Game
Developer’s Meet-up Group. The team consisted of 3 programmers, two 3D
artist, and one 2D artist/musician. We spent the full 72 hours of the
Jam in the living room of one of our member’s home. On a whole it was
an incredibly fun learning experience.

What went Right:
* The Location – Caryn and her family were gracious enough to let 5
strangers take over their living room for the weekend. Sharing ideas,
sketches, and code face to face was far more productive than a more
technology based solution.
* Concept Voting – Once the theme was announced we brainstormed for a
while but had not reached a consensus. We agreed that main proponent
of each idea would do a final pitch, then we would vote on all the
ideas. Voting was handled by anonymous paper ballet. Each participant
wrote the numbers 1-8 next to each of the eight ideas. Eight indicated
their favorite idea and one was the least favorite. Each idea’s ballet
score was added up, and we picked the one with the highest cumulative
value. This process allowed all of us to air our ideas, and choose one
that we could agree on.
* Team Energy – Working face to face and having other people depend on
your output brought about a tremendous energy among the group. Two of
us had participated in prior Ludum Dare’s as individuals. We both had
far more energy and drive working as a team than our individual
experience.
* Using Unity – We used Unity for game development. We were able to
take advantage of the input, GUI, character controller, particle
system, and camera components that unity provides. This saved us a
great deal of time not making basic game control objects.
* Art Asset Naming Convention – Despite using Unity for our project
our artists used the Unreal Engine’s naming convention to organize the
art assets. This naming convention allowed us to keep track of who was
working on what, and what stage it was at.
* Division of Labor – Since our team was comprised of programming and
art specialists the programmers could focus on the scripts while the
artists could focus on the art.
* Food – Prior to the start of Ludum Dare the team acquired a large
quantity of sushi, sticky rice, tea, coffee, and chocolate covered
banana chips. We were able to graze off this bounty over the course of
the contest and only had to go out for food three times.

What went Wrong:
* Ambition – When we selected our initial concept we voted on the idea
that we felt would be the most fun game, not what we could complete in
the time limit. This concept involved a spooky ghost town, two
different vision modes, multiple attacks, power ups, inventory items
and a leveling system. In retrospect this was way too much for a Ludum
Dare.
* Lack of Documentation – We kept verbal and mental track of what
features we wanted to implement and in what order. As development
progressed new features were added to the list, but there was no clear
indication as to which features were vital to the build and which were
nice add-ons.
* Tool Familiarization – Since this was our first collaborative
project the artists and programmers were not familiar with each
other’s tools. As such we spent valuable contest time figuring out how
to get art assets into the game. Also we could not utilize the
artist’s time to do level design due to their unfamiliarity with the
unity editor. These things should have been resolved prior to the
start of the event.
* Lack of Leadership – We did not have one person in over all control
of the project, and instead spent a lot of time debating amongst
ourselves over the proper course of action. Also we were unable to
incorporate some of the art assets since the programmers were too
focused on programming tasks.
* Lack of mile stones – We had an idea of what we wanted the end
result of our project to be and when it had to be done. We did not set
time limits on the intermediary steps to get to that final goal. There
were two attempts to have working builds by a certain hour, however we let
both those deadlines slip trying to get it to work perfectly instead of
Kludging together something so we could move on.
* Wasted time on Kitty – One of our team members (Wilson) was insistent on
getting kitty bonus points and wasted valuable time creating scripts
for an NPC cat that did not do much for the end game experience. This
feature was cut from the contest build and all that time was wasted.

Conclusion:
Ludum Dare Game Jam was an incredibly fun learning experience. Working
as a team kept us incredibly motivated. Sadly we bit off more than we
could crew and the end result suffered for it. We now have a better
idea of each other’s capabilities and what can be accomplished in 72
hours.

Having been away and sick I didn’t get a chance to write this, but I’ll do so now(with a little over 24 hours to spare)

Let’s get started then. Not with the beginning, that’s what is expected, let’s go for a random order.

“A form of monotheism” a silly name, thought of in the last 30 minutes as a better-than-nothing name. It surprisingly works and fits the mechanics of the game. You’re an exterior force with equal control over everything in the game world. You can chose sides, be impartial, have some work for the benefit of others and so on.

The original idea was to have the player be some fellow that clones himself amd tweaks said clones to accomplish some end (repopulate the planet, fight off aliens/ zombies/ in-laws) but someone already  had that idea. Can’t remember who.

The second idea was to make a platformer and beat the theme into it with a stick. Since I forgot to make a platformer framework before the compo, I decided that’d take too long so I dropped it.

Back to square 1.

I wanted the player to start with one individual, and have the ability to spawn more and breed a populaton.  That took too long, so I ended up spawning a whole bunch right from the start.

Species and similarity

What you’ll notice is that creatures are divided into specias: humins, cats, rats, and llamas (the llamas were supposed to be centaurs but I gave up on that) . Each individual also has an empathy-o-meter/ similarity-rating, the color under them. The more you interact with an individual the more that changes. New creatures get one based on their parents.

Breeding and killing

Creatures of different genders and the same species will produce an offspring if they are similar enough AND one or both of them are assigned as breeders. This is mostly to avoid population floods encountered in early testing.

You might wonder why breeding and killing are in the same subcategory. Because they both depend on similarity. If two creatures are too dissimilar they’ll want each other dead(regardless of species). If you keep a similar population confined and breeding you’ll notice that eventually they’ll start killing each other to keep ‘strange’ ones away. Much like history isn’t it?

Social commentary much?

Yes. The only time when you can be sure things won’t be killing each other is when there is only one left. Hence alone. After I finished the game I was left disgusted. I unwillingly made a game about racist intolerant cartoony critters that strip the land of resources and kill eachother because the color under their feet is different. You know: like real people. The relative accuracy of my ‘simulation’ was even confirmed by someone who actually bothered studying these things.

Anyway

The good is working with processing and making html5. A lot easier than I thought.

The bad was not getting to add sound effects, which I knew how to do, and making a cheap hack to loop music. Uneven distribution of resources and a lot of other gameplay and balance tweaks.

The achievements: The end game, when you have a single individual left, a single species left, or one individual of each species. A total of 7. I don’t think anybody got any.

Want to give it a try? knock yourself out:

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

It’s been a while since the coding portion of the compo, but I think that this will give me a better perspective on the overall picture from the weekend, rather than focusing on the details of it.

My game is“Alone In Space”

Last time (LD21) I did an iOS game. In the process, I spent a lot of time on just the boilerplate to get it working, and then the final product was only playable by people who had the iOS SDK. or a week later by only people with iOS devices.

The timelapse for this one covers the overall flow of creation, as well as the order that I made things.
Alone In Space — Timelapse

What went right

This time around, I decided to focus on game physics/feel before entirely fleshing things out. I think this worked out well for me, because it meant that I would end up testing the physics every time I tried out a new feature I had added; giving me time to hone it a bit more, making it more fun and playable.

After doing a mini compo with some friends; creating a clone of “Asteroids”, I realized a few important things, which I believe I got right this time around. First of all, I got ship physics that “feel” good. The ship has a nice bounce and pep to it that makes it more fun to play. Secondly,

The design of the ship was originally going to be more like this: But due to limitations, it ended up the way you see it. It was only then that I realized that with a very little bit of tweaking, it would look like a kitty. So I went with that. Blue Cat Ship!

This was my first time using an image file as a “map”. Once I got the first one in, it was trivial (sort-of — see below) to add more levels, just by drawing them up in a paint program. It made it very easy to add location-based features to the levels. A+++ WILL DO AGAIN!

I originally wasn’t going to display the map on the board, but after having it up for debugging, and my wife mentioning that it would make it more fun, I left it on there, just tweaking the display a little, to be more “finished” and less “debuggy” ;

I really like the way my “lightning” effect looks. The quick solution on how to accomplish it was spot-on, but my effort was clumsy. (see below)

What went wrong

I wish I had more time for level creation, or at least didn’t have to futz with multiple paint tools to figure out one which would work. I just assumed that Pixelmator would work fine for me, but it was too cumbersome to use for this project. I fell back on Grafx2, which I’d never used before, after Deluxe Paint failed me. Now, i’ve set up Deluxe Paint 3 for MS-DOS in a Boxer/DOs Box, so that’s ready to go for next time.

3 levels i think gives you a good idea about how it works, but isn’t really a “complete” game… whatever that means

As always, I could have used more time for balance. I knew that I wanted to have 3 gauges; red, green, and blue… I’m sure I could have worked out some other concept other than “food” and the way it affects the other two is… weird. I admit, that wasn’t thought out very well.

The Processing IDE is good, but once you get a lot of tags, it gets in your way more than it helps. I think I should have put similar classes all in one .pde file each, rather than one .pde file per class. The software engineer in me wants to have them separate, but the HCI designer in me wants them joined. heh.

Lightning. I spent a stupid amount of time to get the lightning working. I think this was mostly stubbornness on my part. I knew a way to make it work, but I just kept on having misstep after misstep… and after a while, I had devoted so much time to it, I HAD TO finish something just so that the time wasn’t wasted. I ended up coming up with an implementation that I think looks pretty cool.

Summary

In all, I think I did pretty well this time, considering time restrictions (helping care for a 2 year old, other family stuff). I’m happy with the accomplishment, and happy with the game as it is.

Just a note, this is my first LD/Game/Postmortem. Thought you would want to know.
Here is a link to the entry
When I decided to enter this LD I knew it was impossible. I cant make a game in two months much less two days! But since it was a challenge and a lot of people were doing it, that motivated me into trying. Even if the result was a cheap, I wanted to participate anyway.

What Went Right

1. The Idea
   I decided to go for the simplest, most exploitable but also fun concept that fitted the theme(barely, but what can you do about that?)
2. The Tools
   About the tools, there werent many tools. The game was written in C#, using OpenTK for pretty much everything. The graphics were done in some icon drawing program, the audio was done in Sfxr. And the readme file, which absolutely nobody has read, was done in notepad.
3. The Graphic Assets
   The player, the zombie and the bullet sprites were done in about three minutes. That helped a lot later in testing. The city tileset however, took a little longer, but also went pretty fast, mind you its mostly copypasta. The icons, for zombie and brain counter, took a little longer. Since they were larger than the rest and a little more detailed. But that also went pretty quick and the result was fairly good.
4. The Graphics “Engine”
   I used OpenTK, and so OpenGL. The first thing I realized about making the graphics engine is that, I dont have time to make a graphics engine. So, pretty much everything in the game is rendered used the good old immediate mode. Which I love, by the way. For the tilesets and sprites, since they were divided into a grid, I used a single method to render a individual tile from a texture. There was no need for scaling or rotation, pretty much everything was shifted and drawn. For the font, which was just the numbers, there was another method to convert integers into graphics. Pretty simple too.
5. The Zombies
   I admit, at first they werent “going right”. Their “AI” was pretty much forcing then into running straight into the player, and so they all got in the same spot at once. Not very nice. But then I added a little randomness, instead of running straight into the player the zombies run straight to a random point around the player. And in case the player isnt near them, they go after a random point around themselves. I am actually amazed it works so well.

What did NOT went right

1. The Audio Assets
   If there is one thing I learned about sound effects last year is that no matter how cool they sound when played once, when you start playing them 100 times per minute they sound completely different. And because of that I had to keep hitting sfxr export button like crazy. Clearly, I had not time to begin thinking in music. I have no music talent, so there is no way that would have happened. They ended sounding good in the end, or rather “fitting”, because the game looked pretty pixely and the sound effects sounded right for it.
2. The Audio “Engine”
   Ok, I’ll be fair. I never put audio in a single program in my whole life, not even sketches of games. So I had absolutely no idea how to do it. I was even considering not putting it at all. But then I saw that OpenTK also wraps OpenAL, then all I had to do was some shameless copypasta from the audio loading example, about twenty lines, mind you. In the end I got the audio working. I also learned that audio is a lot more problematic than textures. I didnt need any texture class but for the audio, I needed it.
3. The Collision Boxes
   There are none. The collisions are hardcoded, as pretty much everything else is. The main problem with the collision is that the bullets were passing right through the zombies. That was not good. Also, most of the time zombies would stand right before the player and do no damage at all, this still happens when there is only one zombie, but I’m talking about 20 zombies right in your face not chewing your brains off. Thats just wrong. The first fix I could manage was randomize the bullet direction. Then I realized I couldnt do that, because they would go way off the aim, since I was using integers for positions. The solution for bullets was then just placing the start point around the player and not the player center, that would make it easier to hit zombies that were just a pixel off your aim. The city collision is pretty simple, because the whole city is a single boolean array, I just had to divide the position of everything to know whether there was a building there or not.
4. The City
   The whole city, every one of them, is just an abstract grid of buildings that look like a bomberman level in more ways than one. To give some variation I added a random generation factor, that nobody has ever noticed. Turns out the random generation isnt very random, but it works anyway. The city itself is a boolean array, so to make the city graphics I actually have to check each of the four corners of everything and decided in a if-else hell which tile to render. The good thing about this is that I didnt need to design any levels, the bad part? I needed to code a thing that makes levels. And this was the single thing that took MOST of the development time(no joke).
5. The Difficult
   So, you are a blue guy with a gun that shoots red bullets in a violet city filled with green zombies. All you got to do is kill them, how hard could that possibly be? Very hard, apparently. The game only has 10 levels with hardcoded difficult parameters. But nobody seems to beat all of them. Level 6 is the average or so it seems. I also can get to the level 10, but not past it. The bonus level, after the level 10, is there. I know it because I cheated tested the game. In case you are asking yourself “How can I make my zombie game so difficult like yours?” here are a few tips: Make more zombies, make your gun weaker, make the zombies regenerate faster(yes, they do regenerate!), make they bite stronger, make the player brains regenerate slower. There you have it.

The Best Part: I made a game.
The Worst Part:  Not many people played it…
The Also Best Part: THE ONES WHO PLAYED ENJOYED IT! YEAHHHHHH!/strong

Here’s a very late postmortem for my game Leave Black Alone. To be honest, I’m surprised at the fairly positive feedback I’ve been getting, considering that I’m not really too fond of it.

The Good:

• Choosing to use Game Maker. I know a bit of Java, but it would’ve been a nightmare for me trying to make this with it. I’ve spent enough time with Game Maker that I found the coding to be fairly painless.
• The idea, because I think it’s fairly original take on Alone, even if the story was just sorta pasted on towards the end.
• For the most part, I managed to stay focused on the game.
• Getting someone to look at the game from time to time. If not, I might have kept my original graphics, and they would’ve scorched off your eyeballs… Instead, I made a simple and somewhat more pleasing color scheme. My tester also caught one or two bugs that I wouldn’t have known about otherwise. Also, there wouldn’t be a hint button if my tester hadn’t had so much trouble with the puzzles.
• Getting lots of sleep on Saturday, even though I wasn’t very tired. I felt exhausted later on Sunday even with the extra sleep, so I imagine it would have been even harder to actually finish the dang thing.
• Finishing the game! This was my very first LD ever, so I’m really happy that I managed to finish.

The Bad:

• Sound. If you’ve played my game, you’ll notice that the sound effects aren’t that great and there’s no music to speak of. This was my first time ever really messing with music and sound, and it shows. I used bfxr for sound and pxtone for (attempted)music, but I hadn’t ever used bfxr before. Next time, I’ll need to practice making music and sound a bit.
• The level design process. Game Maker’s room editor is nice, but it would’ve helped to setup a small level editor , especially later on Sunday when I was scrambling to make levels. I also didn’t really know what to do with all the elements of the game, which is why I kept adding new stuff even as the last level loomed.
• The tutorial system. I like it, but my tester hardly even looked at it, despite the fact that it’s the only place with any instruction to speak of. If you rate my game, please tell me whether you used it or not.
• I used collision detection for everything, when I really should have used an array. This came back to haunt me later, when I desperately tried and failed to fix a horde of weird bugs regarding the powerups. In the end, I had to design around them, and I hated that. If you see an off center powerup, you know the cause.
• The win screen and story screen. I thought it would be cool to try messing with blender to make a cool win screen, but instead it took quite a while and produced a pretty terrible result. It would have been simpler for me to use the gimp and drawn it. As for the story screen, it was just a tacked on extra, and I really should have either put a little more time into it, or not had it at all.

This is a very short post mortem about my entry Loot Alone.

Good Points

• I developed more than 22 games (as a contract developer), but this is the first time I took part in Ludum Dare and managed to submit a game to the competition! This was one of my 2011′s goals.
• First time I ever did graphics for a game. All the games I worked before were done by hired artists. I could say I was always scared of doing art, and doing these graphics lighted up a flame inside me, that now wants to make me a better artist.
• I came up with the idea in less than an hour after the competition started and I may consider of taking it further and making a commercial game from scratch with this idea.
• When doing 2D with Unity I always used a 3rd party commercial library. Since I took part in the competition I had to come with a solution by myself, so I ended up learning how to “do 2D” in Unity without external help.
• I liked the concept of a linear comics-style navigation I made.

Bad Points

• I worked only 8 hours, I didn’t use the available 48 hours. For this reason, my entry can not even be considered a “game”. Let’s consider it “an interactive short animation“.
• Due to the short amount of time worked, I didn’t manage to make all the scenes: there are 3 scenes; being 2 playable levels and an animation one. The initial plan to make the game “complete and playable” was to have 6 scenes. So we have 3 scenes that are out.
• The rocket cat was meant to be controllable, so you could kill the dragon.
• In the 8 hours I worked, I coded for only 2 hours. That means there are bugs, mostly on the messages system.
• My lack of knowledge in Unity for 2D without a 3rd party library left some bugs on the graphics, mostly due to scaling.
• The linear comics-style navigation can be confusing, since you can end up going to the wrong side.

Other than that, I had a lot of fun, and I’m feeling fulfilled for completing one of my 2011′s goals: take part of Ludum Dare

Hello! I am static_boy123 and I just wanted to share my experience in my first LD, and first game, with others:

I found out about this competition last year when Notch(The maker of Minecraft) entered Prelude of the Chambered, I immediately said to myself,  ”I will do this next year.” So now I did it, I entered in my first, but not last, Ludum Dare.

I was watching tv one night when something popped into my mind, the Ludum Dare. I checked the website to see when it was, two hours. I ran to my computer and started memorizing my basic -5 file- library inside and out, after an hour I was able to repeat most of it from memory and the rest, thankfully, wasn’t needed. So I waited the longest hour of my life hoping the theme would be kittens.

Once the competition finally started I cursed everyone who voted anti-kitten, opened up handy dandy Visual Studio, and got to work. I typed out what I remembered of my library only two classes, but I was able to make a bunch of edits to one to make a new class. I had lots of trouble starting and coming up with ideas for what to do, but I did the basic things, like changing the screen size and creating the controls for moving.

After an hour of sitting and thinking I had an idea, a game that is more based on story than game play, but still has game play. I sat down and started, I added in textures, added a way to shoot, and realized just how inexperienced I am when it comes to game making.

Coding was crazy, I had tons of road blocks; bugs, bugs, and more bugs. I had to go into untraveled land to create the game, and I also spent plenty of time in well worn territory. Overall my game was very fun and frustrating to make, but it was well worth it.

Now a list of what was good and what wasn’t:

Good Things:

• It was fun
• I learned a lot
• I coded in XNA which I am very comfortable in
• Everybody was very supportive of my first game
• I am happy with my work
• My coding works
• Others enjoyed my game
• The ultra great graphics game “Real Life” didn’t distract me that much

Ludum Dare #22 was my third consecutive time participating in Ludum Dare. Reflecting back on my past entries I can see clearly that each time the quality of my entry improves.  This time was no different, you can play my entry Alone In Space… here and be sure to submit and check out the Leaderboards here.

What was left out: (but I wanted in)

> More resource types, I wanted you to be able to gather gas from the nebula’s, that would have been worth more than ore.

> Two more types of asteroids. As it is you have no control over whether you mine metal, or Ore. I wanted different asteroid types to allow you to hunt down just Ore, or just metal.

> More Dialog, as it was I wrote the small bit of introduction dialog within the last hour of working on it, to try and set the scene.

What went Wrong: (I’m still  a pessimist)

> The length of the game, is too long for the type of game. It takes around half an hour to upgrade the ship so that you can easily defeat the waves of enemies. I wanted it to take around 15 minutes to upgrade, and defeat the waves.

> The difficulty is to hard. I didn’t get the enemy ship AI quite how I wanted it, I wanted them to fly side by side, but instead they stack up on top of each other. There are also some cases where they fire more shots than they should be able to. They should be able to fire four shots at a time, but there are times when eight or more are fired.

> I wanted the mini-map to show incoming ships, and the location of the drone (used to trigger the enemy ships) but it was causing an error that made the game unplayable. I changed it to show you the location of the station, as well as the location of asteroids (after you pickup a kitty).

> The graphics, they are almost how I wanted them, but I never had a chance to revise them. I wanted to add some lines to the ships and space station to imply joining pieces, and curves. I’m also not happy with the particle trail for behind the ships, its not that its wrong, its just not what I pictured.

Too Many shots...

What Went Right:

> The music and Sound effects. Although the mp3 don’t loop correctly (I’m not sure how to make them loop, or what format will loop. I still felt the music was a success. I used GreaseMonkey’s script to generate the .it files, then converted to mp3 using VLC. For sound effects I used sfxr, and though the sound effects added to the game.

> The Gameplay was how I intended for it to be, I wanted you to have to venture out from the station to mine, and in doing so you would find the kitten, and the drone. As I mentioned before I wanted the game to play out faster, but that would be achievable with more control over what you collected, so you could earn more money from one load.

> The Leaderboard/ Online High Score table, I had most of the game finished before I decided to add in the highscore table, but I’m glad I did. It add a sense of achievement when you set the highest score, for all to see. I just wish I had the time to add an in game viewer for the leaderboard.

What Comes Next:

I plan to continue with Alone In Space… I want to work on a revised version and over the coarse of a month create a more polished game to release. I’ll be blogging about the progress on the 1 Month Game Website. I will probably start the revision next week. Off the top of my head the revision will include everything mentioned in the What Went Wrong section, as well as more levels, and anything else that I think of while working on it.

Alright!  Finally got around to doing this post.  This is going to an extended look back at the development process of One of a Kind, which you can download, play, and rate here.  It’s going to be a lot of walls of text, so if you want the shorter, regular port-mortem with “what went wrong vs what went right”, you can instead read this post.

That said, onto walls of text!

(more…)

Participants of Ludum Dare 22 were asked to fill out a survey on their experience. A whopping 747 people filled out the survey.

Thanks for taking the time to fill it out!

I love this enthusiastic and supportive community.

Here are the results (click to zoom).

(more…)

This is my postmortem for my Ludum Dare 22 entry, Sat-E. You can find the timelapse over here.

The Good

Motivation

I was really motivated for this dare and it showed in the game and outside it. It’s super hard to make a game in only 48 hours but this time it went pretty well. My previous attempts went okay, but there were always something lacking. This time the game feels a little bit more finished so I’m going in the right direction.

After the game the programming motivation continued and with it I’ve been improving my small fast prototyping framework I use when making games. I got a lot of ideas on improvements during the weekend so that’s great.

The feedback

I was moderately happy with how the game turned out, it didn’t contain everything I had envisioned after all, but I got a ton of positive feedback anyway which is wonderful! It seems like some thinks that my game is good and there’s nothing better for your game making confidence than a bunch of flattering words. I’m even considering developing the game more, maybe spending a couple of days here and there on it during a couple of months when I have the time?

I learned a lot!

The best way to learn something is just to do and it’s still true. I’ve found a bunch of ways to improve and shorten my code, I’ve made an “infinite” space constructed by individual chunks and that game physics != real physics. Awesome.

Game design is a pretty fascinating creature. Sometimes you give it your best but the resulting game isn’t funny, other times you think your game is shit but then you get comments on your “amazing” game! This time I was certain the game was crap, a neat idea wrapped behind a boring gameplay but turns out it maybe wasn’t that boring after all?

I got this comment:

“Also the fact that when that happened the game didn’t simply reset, I lost my money but not my items,
literally stopped me from rage quitting. Bravo”

My thougts? Wait that’s a bug! Hmm…

My girlfriend

Of course as I live together with someone it’s quite hard to devote an entire weekend, plus the extra time before and after, with my computer. Veronica handled it wonderfully well and she was very supportive which means a lot to me and it helped a ton.

The Bad

The music

There’s no music but I had grand plans for making music for the first time ever! It failed hard though. Which brings me to the next point…

Not familiar with the tools

I used my own framework for the game, which is fine, but my last game with it was in May 2011! Which is a looong time ago. I was a bit (a lot) out of practice with this whole pixel arts thing. And of course I had never used LMMS to make music and that didn’t happen. I was short of time and it was too big of a deal to start it with the last minute.

Not enough time

Even though I had the whole weekend planned for the dare and I skipped practice on Sunday I was still short on time. I’m not really sure why though. I made a pretty simple game, not a lot of art and I generated sound with bfxr which took no time at all… The reasons really must be:

1. Not enough practice.
2. Unfamiliarity with the tools. Correlates closely to #1.
3. I’m bad and LD is hard.

When I see all these amazing games I’m reminded on how much better other game makers are. I need more practice and I need to make more games. I should enter the next dare, enter the experimental gameplay project and just make more games.

And let’s face it: Making a game in 48 hours is frickin hard.

The Ugly

The art

Oh god… I suck at making art. Let’s just leave it at that.

The code

There’s a lot of bad and wrong in there, it works but it’s not pretty. In fact, it’s ugly.

The gameplay

This is a tricky one. I thought about placing this in the bad section as I didn’t find the game very pleasing at all. The beginning was too slow, the ending too long and there wasn’t enough incentive to continue flying through endless space I thought. But I got a lot of positive comments and reactions which is wonderful! I don’t fully understand why yet so I’m tagging the gameplay as ugly. After all the gameplay wasn’t like in my dream…

Ending thoughts

Before entering the competition I’m always nervous but high spirited. That feeling is always crushed during the weekend and when I finally get the game done and uploaded I think it’s the worst game ever. Luckily I’m greeted with positive feedback and that was the case this time again. Maybe they are okay, not super of course, but simply okay.

This time the dare came at a time where I felt I haven’t done anything meaningful for a long time, it’s just school, little programming and no game making. Now after my spirits are high and I can face a new year with many more games to come!

Until next time, cheers!

Since the weekend forced me to take a break on my review series, I have decided to take this chance to sit back and think about how the LD22 weekend worked out for me.

Maze Explorers was not the first time that I tried to make a computer game, but it was the first time I managed to ¨complete¨ my effort. I can thank the 48 hour deadline for that. I feel that after completing this LD, something clicked on me, and game making is not something as mysterious and arcane as I thought it was. I hope this means I can turn my ideas into real games more often in the future.

Now for the obligatory ¨what worked¨ and ¨what did not work¨ lists:

What Worked

• Having friends test my prototypes mid game: I had some very awesome friends test my prototypes as I submitted them, and provide me feedback. Some of the most important suggestions included: A highscore feature, zooming in the game area when the light radius was limited, and making sure my tiles were colorblind friendly (<3 colorblind friends).
• Having a Ludum Dare ¨partner¨: In terms of motivation, I was lucky to have entered the LD with a friend of mine. We were constantly IM´ing each other, talking about bugs and landmarks, and just ranting. It gave me a sense of duty — he was putting effort on it, so I´d better put some effort too! I´m sure I would have procrastinated a LOT if not for him.
• Deciding my theme/game design quickly: After the theme was announced, I sat on my sofa and did not leave until I had the complete game on my head. I found a kinda interesting, not too ambitious idea. Years of programming/Dungeon Mastering helped me keep the scope of my game reined in. I managed to complete about 90% of the planned features for my game, and even to sneak a few more in. Even when it looked like a stupid idea, I stuck to my guns and kept going on.
• Familiarity with the Language/Environment: I have been working with Java and Eclipse for a few years (although only in the realm of scientific computing), and even though I did learn a new thing or two, this familiarity helped a lot.

Thanks for reading so far! I hid the kitten easter egg pretty well, so here is a hint: there is one control key in the game that apparently is not useful for anything. You need that key to find the easter egg!

What did not work

• Unfamiliarity with Game Programming: This goes without saying, but I spent too much time figuring out things like “which class I should store my resources in”, “where to call transitions”, “how to properly program my tile engine”, etc. I was reinventing the wheel way too many times.
• Unfamiliarity with the game library: Related to the previous one, even though slick2D is a pretty simple and straightforward library, I think I spend the majority of my time peering through its class documentation. Finding out how to change the size/color of a font was a pain. Luckly, this means that next LD I should have more time to spend on the game itself.
• Making Levels: A large part of the theme tie-in in my game depended on level design. Levels should have at least two solutions — an “alone” solution and a “with company” solution. Unfortunately this means that designing levels took quite a while for me, and I only managed to complete 5 levels before the deadline. Fortunately, having the player try for the best score increased playability a bit beyond just beating the 5 levels.
• Sound: Sound and Music were always my weak point. I know nothing about sound terminology and technical aspects, and I wouldn’t even know where to begin to try and make some music for my game. sfxr helped me a bit with the sound effects, but I ended up botching the synth voice effects: its volume is too low, and either you can’t hear them, or the stepping sound effect gets too annoyingly high. I need to practice this a bit before the next LD. Suggestions for programs to make music out of thin air appreciated.
• Environment: My environment was far from optimal. I didn’t get enough good food, and ended up eating too much junk food (I had enough water, though). Also, even though I divided my 4 virtual desktops well (net/docs/programming/resource-terminals), a second display was sorely missed.

What now? There are many things that I didn’t manage to finish in my game: Transitions, a few more levels, music, something to fill the bottom of the screen, background screens. There are also some things that the reviewers (thanks!) asked for: better sounds, not getting stuck with a companion on your back (thinking about it, we don’t really need this for the game to be hard).

I might make a post-compo version with the above, for the sake of completeness. On the other hand, I might keep the game as is, for archiving sake, and move on with trying to make some new games to get more practice with the gaming library and with game coding in general.

Thanks for reading, and make sure to try out Maze Explorers and tell me what you think about it

Cheers,

What went right:

• Finding an idea: I woke up early (LD started at 3 a.m. for me) and just looked at the final theme voting results. Then I pondered about possible games while staying in bed, which proved to work quite good.
• Programming: Even with a bug that took me 1,5 hrs to solve I was quite happy with my programming.

What went wrong:

• Time: With my wife and child being around and some not LD realated evening activities, time management became a problem. I had to cut almost all features I planned and keep very simple with the graphic and leave the music out.
• Motivation: Due to the ideas I had at start and the time restrictions I got more and more frustrated running out of time and realising not to make the polished game I would have liked to. So I had some moments where I thought about quitting the compo but am quite glad afterwards I haven’t done so.

Related to the last point, here is a comparison between what came out and what I planned:

LD 22 entry

Mockup with planned features.

So what did I learn?

It’s worth continueing even when you want to give up.

Play and Rate!

So I made an ego-adventure-story-cat-experiment called 5 DAYS. Allow me to recap.

What went right

Graphics

Creating graphical assets is a time-consuming task, so I immediately dropped it and only concentrated on stuff I could efficiently produce. The current style is a nice trade-off between detail and costs.

Level-Design

I started this thing from the ground up on tiles, which allowed me to make changes and updates right till the end. Having everything based on clean tiles also meant I could easily add objects, like the lamps, which effortlessly clamped into the architecture.

Intro

I /love/ the intro. This is the closest I have ever come to a cut-scene, and even now it’s completly gameplay, not a video.

The original idea had everyone dying in a scripted explosion, while the player could do nothing (but walk around). Having the player actually kill the reamaining crew (be it by accident, admittedly), would only further compel her to save the cat.

The cat

Your only companion is a cubic cat (no time to model, as mentioned above), which is aptly named Boxy. You have to feed for it to survive, but doing so will deplete your own ressources.

Title-Cards

The game starts with a cold open right in the action. The title is only seen after the first room, and then perfectly sets up the story.

My original title was ALONE. After the player would have watched his friends die / kill them, she would be ALONE. But because the name would probably be overused, I changed it to 11 DAYS. Eleven turned out to be too long, so I shortened it to 5.

I love how the title 5 DAYS becomes a chapter-card, turning into 4 DAYS, and so on. I contemplated putting the title at the end (Hot Fuzz/The Dark Knight-style), but only few people would see it then. I guess this doesn’t work in games.

The only downside of this title is that I already made a game called 5 Days in Charleroi. I was already trying furiously too get the gameplay to work, so this didn’t even occur to me . Oh well.

Timelapse

The video went alright. If you comapre it to my previous ones, you’ll notice I frown a lot in this one.

Music

Instead of composing my own background-music I was forced to try out Wolframtunes, where I found some interesting ambient-tunes. I was able to reverse-engineer those, and created a fitting soundloop in comparatively little time.

Also notice how the sounds picks up after the title, further signalling that the game has “begun”. Nice effect.

What went wrong

Initial idea

This was actually my first idea, but I classified it as “way too ambitious”. I had some others, but none of them impressed me as “stuck with a cat on mars”. So I begrudginly started, planning to either switch to a new project a few hours in, or use what I would have built in that time to make a smaller version.

I had a crisis after 8 hours, when I decided this was too big, and tried out other ideas. „Lone asteroid in space“ I actually started, when I realized switching to that would be even more work. It was quite a dilemma. I (not crying, completely manly) went back with further resolve to finish this project (in a manly way), and soldiered on.

After 32 hours everything then came together and started working, which lifted my spirits, and caused the classical game-design-high.

Gameplay

I noticed near the end that I unable to create the payoff every time. If the cat dies very early, the player will have a lot of food, thus eliminating the conflict and creating a boring game/ending. Typing this I realize I could’ve built it so that the reserves will adjust. ARGH THIS WOULD’VE BEEN PERFECT

Then there is the thing that re-playing it offers little incentive, as the gameplay already was rather un-action-y, expecially should the player die. Even a nightly checkpoint wouldn’t have worked, as resetting the player each death would reail-road them to the „desired“ ending, which is strictly against my principles.

There things stem from the initial idea, and show how much I tried to fix this issue but ultimately failed (see timelapse).

No pointer/cursor/crosshair

Here’s an important thing: We are a lot better at playing games than the average player, especially at playing our own games. It didn’t even occur to me add some sort of crosshair/targeting-thingie, as my aim was always spot on. This stuff you only realize after one day not playing it.

All in all

Although this had a very bumpy ride, I believe it was a succesful experiment. Those who actually manage to get through to the end all agree, calling it „amazing“, „brilliant“, and me a „meany“. On Kongregate this is already my second most-played game, Ludum-Dare-ratings are doing well, and I even got a review.

Play here | Entry-page

-Matthew

My first thought when I read the theme was “exploring an old house alone, at night”. I played too much “Alone in the Dark” in my days… And I wanted a similar game, but in 2D. So I choosed the “survival horror” genre.

What went right:

• Programming tools: I had no problem with the usual write-build-compile-play-debug workflow
• Chronolapse was very good for the screen capture (see timelapse here)
• I was more focused than the last time
• It was really fun!

The Planning

The planning for the game started ahead of time. There were 2 things I wanted to have set in stone before a theme was announced, and that was a genre and a name. I wanted to pick a genre that could easily be tailored to any kind of game, but the one I chose far ahead of time was a Metroidvania, mainly because I have a project on the backburner that is a metroidvania, and if I can get a similar kind of game out of my system, I can feel content with keeping my planned project on the backburner for a long period of time (in order to work on my main project at the moment, which is an RPG). The name was something I also really wanted to lock down. Last time I wasted about 30 minutes near the end coming up with a name, which I felt wasn’t a good use of time for the competition. This time, I pegged down the name Arzea ahead of time, with the intention that if something better came to me while working on it I would change it.

When the theme was announced (thank goodness it wasn’t randomly generated, that was one I just wasn’t feeling in the mood for, and would have required me to change my genre I believe), I immediately started planning out various parts of the game. I chose to go with a magic theme, since I wanted something different than I’d done before, and in the process I also started thinking up story elements for “Alone”. In the end I interpreted it as being the only one of his kind in a place overrun with monsters, but it seems most people interpreted alone as being a single entity. The main character had always felt kind of alone being that he was different than others, but being thrown into an unknown world made him feel even more lonesome than before. I feel I didn’t get a chance to tie very much story into the game, but I felt that it was definitely one of the better areas to skip for time.

The Process

Once I had the basic gameplay elements and story pegged down, I dived straight into art. I went with basic dirt and grass tiles, and just went on instinct for how they should look. I was very happy with how the first draft turned out, and there was very little modification after that. By choosing a magic theme, I was able to magic a wizard main character which was a big plus, as it let me keep things really simple with the hat and robe. I also ended up drawing some objects that I didn’t have time to fit into the game.

Once tiles were done I dove into the map generation code. I wanted to keep it quick and easy, so I decided to autotile pretty much everything, and just draw the top tile layer with a single color. I had seen a neat effect with backgrounds in other games (my biggest inspiration was Level Up!) so I did something similar which worked really well, as it was also very easy to autotile. My tiles ended up tiling extremely well (I was incredibly surprised at how well, since I hadn’t put any thought into it while drawing them) which made it really easy to quickly map up a world.

The movement and jumping were very familiar as I’ve done a few platformer games in the past. I think my jumping ended up feeling a bit more floaty than I would have liked, but overall it felt pretty tight to me. Once that was working, I added my first spell, the fireball. This time around I was able to quickly add particles, and the particles were one of my favorite parts. It was fun working with the colors to make the particles look neat against the background, and I also liked trying to make unique particle effects for each spell. Once the fireball had particles I moved onto adding the other 5 spells I had planned. This was long and tedious, but I managed to work through it without losing my motivation, and was able to move on.

After that I added some very basic enemies, and then expanded the world. From there on out it was mostly adding small things repeatedly, such as keys and doors. I worked all the way up to the deadline, but in the end I felt the game was polished and complete, even if not as complete as I had originally envisioned.

What Went Right

Planning – I feel my planning worked out well. I saved time on choosing a generic name and genre before hand, and putting all my thoughts down into a document before I dove into coding game me a good linear track of what I needed to work on. I wasn’t stuck figuring out what spells I needed in the middle as I had planned it all out from the start.

Art – The art wasn’t something I was expecting to go so well, but even with my very limited pixel art skills I was able to come up with something quickly that I was extremely happy with.

Genre – Since I had been wanting to work on a metroidvania for some time, choosing to do one gave me a lot of motivation. However, there was a downside in that I really did want to do a full fledged metroidvania with all the bells and whistles, and when it came down to it, I had to strip it down to a very basic form in order to make the deadline.

Tools – Using flash with flixel was again a really good choice, as I now have a year and a half of experience with it under my belt, so I could focus on making the game rather than fighting with the language.

What Didn’t Go Right

Tweaking – There were some bugs and some tweaks that really needed to be fixed for the game to feel less tedious. For example, there are some problems with the spawning logic, so sometimes thing don’t spawn properly (which is very important when that thing that didn’t spawn is a boss). Also, the respawn way turned out to be buggy in that things would respawn as soon as they were off screen if you kill them. These are the first things that will be tuned/fixed for a post-competition release.

Scope – While I feel I did a much better job than last time of limiting the scope of the project, I still had intended quite a few other features that didn’t even have a chance of making it in (pause menu, map, achievements, spell swap popup). In the end I felt I was able to cut things that weren’t essential and it still felt very complete, but I would have liked to have more.

Performance – If you have a low end computer (I managed to test with my netbook right before the deadline) you may have problems with playing. I was surprised at this, but I didn’t get a chance to look into it before the end of the competition.

Theme – While I thought I had hit the theme much better than the last couple times, it turns out that it wasn’t quite enough.

What Comes Next

I’ve already begun working on expanding the game for a post competition release. I want to include some of the features that I had to cut for the deadline, along with expanding the world to be much bigger. As a comparison, here are the original competition version worlds, and the expanded world (not yet finished):

I’m probably not going to put too much work into it, as I would really like to get back to work on my current main project, but hopefully it will feel much more balanced and fun before I release it!

Here are the links to the game:

Play/Rate The Game:
http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=4155

Watch The Timelapse:
http://www.youtube.com/watch?v=WcFZQaoMdCM

Read The Journal:
http://www.ludumdare.com/compo/category/ld-22/?author_name=arkeus

Thanks for reading, and I hope you enjoy the game!

Ahoy all!

Last weekend I made a compo entry called Castaway.

If you speak French, you might want to read my lengthy writeup on Les Forges. Else, here are the traditional bullet point lists :

What went well

• Using familiar tools (custom framework, FlashDevelop, HaXe, Photoshop, Reason, etc.)
• Using project management techniques and tools. I used Asana to handle my ever growing todo list and a mini scrumboard for tracking bugs. Pictures at the end of this post.
• Recording custom sound effects. This was my first time and I’m very happy with the result (especially since it didnt take long). Picture below.
• Testing. Two friends came on Sunday evening and played the game again and again to spot bugs. They were the one writing the scrum post-it and it was very useful.
• Chronolapse. Making a timelapse took no effort and I love the end result.

What went not so well

• Theme. I did not think long enough of the theme and started working without a clear idea of what my game would be.
• Time management. I spent too much time working on animations and art assets instead of making content. Look at this 8 frames walk cycle : . This is wasted time, lots of it.
• Balancing. The game is way too hard ; my testers thought it was funny because of it but I should have considered this as alarming.
• Oops. A critical bug that crashes the game on slow computer was shipped in the compo version. Maybe the test configuration should include a slow computer too.

Pictures

Asana

Bug tracking scrumboard

Sound design tools

Even though my game is way too hard, too short and unforgiving, I’m still happy with what I did. I am satisfied I made some art and music that were not 8bit/chiptune over the course of the weekend and more importantly, I had lots of fun. Next time, I will NOT make a sidescrolling platformer, that’s my objective.

Thank you all for reading/playing/rating !

“But I don’t want to go among mad people,” Alice remarked.
“Oh, you can’t help that,” said that Cat: “we’re all mad here.”

So, Harry hosted a Ludum Dare jamsite in Melbourne, inviting game developers around the area to spend 48 hours cooped up in his house to make games. Here’s an account of the fun and chaos that ensued!

What went right:

• Going out and brainstorming before anything – give a chance for ideas to grow / ferment
• Being in the same room provided motivation and staved off the loneliness
• The epiphany couch (which doubled as Luca’s makeshift bed)
• There was always something to playtest, and the instant feedback was useful
• We all got semi-appropriate amounts of sleep

What went wrong:

• Pepper flavored cup noodles. Imagine noodles and pepper in a plastic cup. Yeah.
• Getting lost to the shops several times thanks to Harry’s navigation
• Temperature and computer cord control in the room was not great
• Canine interruptions; the dog would occasionally enter the room and chew on wires
• Didn’t record anything down, making this post-mortem more difficult than necessary