Hello everyone. This was a fantastic Ludum Dare for me and I wanted to share a postmortem for my game, NanoBot Adventures. All in all, this was a pretty good game jam for me. 

Here’s a link to my game:  http://www.ludumdare.com/compo/ludum-dare-23/?action=rate&uid=4263

The Good

Using Legos to build my NanoBot sprites worked out really well. My sons love playing with Legos so while I worked on the game, they built an army of little Lego robots. I picked my favorites, setup an impromptu white backdrop and used my cellphone camera to take pictures of them. I wanted the graphics in the Viewport to have a bit of a grainy, pixelated look to them so I took the original images and in Paint.Net I cut out the white backdrop, saved the file as an extremely low-quality JPG, reopened the file and cut out the white background so I had a transparency again and resaved it as a PNG. This process worked out so well that I will be using it again in the future.

Another good thing was my HTML5 canvas framework. I wrote it a few Ludum Dares ago for the Escape theme and it has served me well. I use JQuery for the UI pieces and it has a very basic Update/Draw game loop. I am planning on sharing it on Github in the near future once I get the basics for music/SFX put in as well. Follow me on Twitter (@mattperrin) or follow the #LD48 Twitter tag and I’ll put it up there.

Another good thing was that my local community of game dev friends (www.clevelandgamedevs.com) really came together for this event. We had a LD kickoff event at a local start-up incubator and collaborated for a few hours Friday night together before splitting off. To keep in contact with each other and show progress, we setup an IRC channel that was used all weekend long. Seeing my peers working helped keep me committed and interested too.
The Bad

I still haven’t gotten sound or music working in a LD game. I tried with this one but I couldn’t quite get it to work properly. I used Caustic on my Android phone to create a chiptune-esque drum and bass song. When I connected my phone’s headphone jack to my laptop’s microphone jack, I either got an ear-splitting loud feedback tone or a barely audible recording of the song. Caustic has a song export feature that I used to make an OGG file but when I tried to get it looping in my game it wouldn’t play. After all of those headaches, I decided to skip trying to do sound all together and focus on some UI polish.

I never got around to adding power-ups or boss fights. I had wanted the exploration of the “tiny world” to be a bit more dynamic. Visiting the Capacitor Forests, Resistor Swamps or LED Ruins was supposed to trigger dynamic events like boss battles, upgrades or NPCs with storyline clues. I ran out of time though and only the basic quest of “Find the broken CPU Chip” were completed.

The Ugly

The Draw calls I use to make the minimap are extremely inefficient. Instead of having a global frame counter and incrementing across the pixel color arrays for each TerrainGameObject I instead have individual frame counters in each TerrainGameObject that are incremented during the Update call. For the glowing circuit traces, I used the X coordinate of the tile to offset the pixel color arrays so that’s how I get the shifting glow effect. Kind of cool to look at, horribly executed by me. The reason I went this way was because as part of the boss battles I was going to have the minimap change to become more “alive” as you beat them. LEDs would start glowing again, resistors/capacitors would generate more circuit traces.

I should have added arrow key buttons to the UI instead of relying on only the keyboard arrow keys. I could have then added Touch Events to those buttons allowing for the game to be played on mobile/tablet devices as well.

Issues with sound and my family took up way more time than I intended. I used Chronolapse to make a timelapse of my work and the amount of time lost dealing with squabbling kids or just “being a Dad” are clearly shown. I’ll be posting this video sometime this week (I’ll share on Twitter) . I think I maybe only got to spend 20 hours or so on the game as a whole.

If I had hair I’d be ripping it out right now. I was so happy when I finished my game, felt like a huge weight was off my shoulders. Those hours upon hour of coding finally produced something fruitful. I breathed a sigh of relief…

And then it happened. People found bugs in my game. I was disheartend, that euphoric high I had after completing my game came crashing down… I franticly searched my code to see why these bugs existed. Then I saw my mistakes… the simple rookie mistakes I had made… man I wanted to kick myself in the ass, how could I have made those stupid rookie mistakes!

So I have some advice for you all, two words. BETA TEST, BETA TEST, BETA TEST!

Test everything! I cannot stress this enough…

Seems I need to update the “What I’ll do better next time” with this tidbit of information.

- I will test everything in my game to make sure everything works the way I intended it to

-KunoNoOni

Well, we finished. Barely. With 5 minutes to go I was making a build and realized there was no game icon so I quickly let my artist know, she tossed one in the dropbox, and the build finished with two minutes before the deadline. Our finished game is called “Aqua Wars”.

CLICK HERE TO PLAY THE GAME!

WHAT WENT RIGHT?

The art. The artist for our group was Kiki Snell and I usually have her doing the art for me whenever I do game jams. She did a great job and threw together this awesome little timelapse video to show her progress…
http://youtu.be/vRduXqTZ3CA

WHAT WENT WRONG?

It took far to long for us to figure our our idea and gameplay. I had a few ideas for some of the themes but wasn’t expecting Tiny World to win. We kind of came up with a rough plan and fleshed it out as we went along. With past game jams I’ve had more time to focus but I was gone from my house until Sunday afternoon and was just able to do a little bit of coding with my laptop. Once I was home on Sunday we made a lot of progress but then I had work all day Monday and only a few hours to make any finishing touches. The next time I plan on taking off time from work and putting aside the entire weekend to completely devote it to making a better entry.

We started tossing ideas around as soon as the theme was announced and had an idea for making a city building sim type game but base around a microscopic Sea Monkey type creature. That idea didn’t really stick for long but we had already gotten a decent amount of art for an aquarium type setting so we kept going in that route. For the first 24 hours we didn’t really have much down as far as gameplay went. We thought maybe something like a Tamagotchi where you would just care for the fish, but that sounded more like an interactive screensaver and we wanted something a bit more fun. We ended up turning the assets we had into a sort of tower defense type game. You guide a small school of fish around, clicking other types of fish that appear to attack them, and buy more fish, feed your fish, and buy plants for the aquarium. I’m not sure I’d really call our game a success, even though we finished I think we could have done something better…

Its been 17, almost 18 hours since I have submitted my game for judging. I must say Its been a whirlwind weekend, staring at the same room for 48 hours, listening to the same songs over and over again. All while try to create a game based on a theme that I downvoted twice! And to make matters worse I ran out of BACON! But I did it, I complete my game within the 48 time limit. I will try to recall the past 48 hours in as much detail as I can rememeber.

Friday – April 20th, 2012 – 5:30pm

I arrive home from work, feeling really good about doing the Ludum Dare tonight.

Friday – April 20th, 2012 – between 6 – 6:30pm

After changing out of my work clothes into something comfortable and milling around the house, I sit infront of my PC at play Legends of Grimrock, while waiting for my TV shows to
start.

Friday – April 20th, 2012 – 8pm

I stop playing and go watch some tv, while watching the IRC chat on my phone. Yes I have an app for that…

Friday – April 20th, 2012 – 9pm

The theme is announced! Tiny World! Tiny World? What the heck and I going to create with that theme?

Friday – April 20th, 2012 – 9pm – 11pm

Finish watching my last TV show and start thinking about a game to create with this Theme. After some thought, I come up with what I believe to be a good game concept. Let me give you the premise.

I decided to do a vertical shooter, with enemies that shoot back at you, huge bosses, power-ups and rockin’ music. Hey we can all dream right But we’ll get into that in a few minutes

Friday – April 20th, 2012 – 11pm – 1/1:30am

With my idea fleshed out on the whiteboard I begin with the art. Once it is compeleted I head to bed to begin coding early Saturday Morning

Saturday – Sunday night around 8ish pm

This is mostly a blur of coding, failures, rethinking, more coding, successes, more coding, tweaking, optimizing, some sleeping and finally a complete game!

So that was my weekend, how was yours

Now we come to the part of the Post Mortem where I tell you what went right, what went wrong, what I learned and what I’ll do better next time. So without further ado, play that funky music white boy!

What went right:

1. thought up what I believe to be a great idea for a game based on the theme. At first I didn’t like the theme, but this was a snap judgement. Once I really sat down and thought about it, I thought of all sorts of great ideas. I do have to say I found thinking up a theme for this LD was a lot easier than the last one (LD22).

2. Since I had a really good idea of the direction I wanted to go, the Art flowed much easier. Usually I have a hard time with the art as I’m not artistically inclined.

3. With only a few setback (to be explained below) coding was pretty much a breeze. Hey when in doubt, make a boolean

What went wrong:

1. Remember when I said this “I decided to do a vertical shooter, with enemies that shoot back at you, huge bosses, power-ups and rockin’ music.” Umm… yeah this didn’t happen. I had issues with collisions while the map was scrolling. Issues getting the enemies to shoot, issues getting the bosses to shoot, no power up and sub par (at least for me) music.

2. Hmm, I guess those are all the problems I had. Oh yeah, one more thing… I ran out of Bacon.

What I learned:

1. I’ve used Flixel for a little over a year now, but I have to say I’ve never created anything so indepth as the game I created this weekend. I learned a ton about this framework and about FlxGroups in general that I never knew before.

2. I learned I need a refresher in math. Might have to hit up Khan Academy in the future.

3. I learned a lot about game design, about how adding small effects can really bring your game up a notch or two graphically.

What I’ll do better next time:

1. I’m thinking about creating a bunch of functions for things I may want to do in future games.

2. I need to gain some more knowledge in game design

3. I’d like to get better at pixel art, like pick up some tips or tricks to make my art stand out.

Well that’s it. Another stress-filled, fun-tastic, 48hr coding jamboree completed. Can’t wait for LD24! Before I close this Post Mortem, I want to give a big round of applause to all the people who coded a game this weekend for the Compo and to those people who coded/are still coding a game for the Jam! These games didn’t exist 48 hours ago and for no more than bragging right, we all decided it would be fun to create a game based on a theme chosen by the community this weekend! Simply WOW!

-KunoNoOni

I’m from Germany, so Ludum Dare started 3:00. I got just 2 hours to sleep and waked up at 3:00… I heared many people say, that sleeping first is better – I would get up again at 3: You are totally excited and in these 48 hours there will be some sleep (I had 6 or 7 hours after 24 hours Ludum Dare elapsed).

I finished my game NO SPACE. Here is a gameplay video:

What went right?

What went wrong?

(more…)

It was a very non-standard decision to program my Ludum Dare as a Ruby on Rails web app, but the game I ended up with is incredibly feature-full and remarkably complete — which is not something you can often say after 48 hours!

Fish Tank Commander features:

• Multiplayer, turn-based tactics game (similar to Advance Wars…or chess!)
• Four exciting unit types: The Speedy Seahorse, the Tanky Turtle, the Brutal Betta, and the Cheap Goldfish.
• Elo ranking system (like in professional chess) and XP earning for each game. See how you rank!  Challenge people of your skill level!
• Built-in map maker and a voting system
• Notification system lets you know when it’s your turn…or when your opponent concedes! (Coming soon after LD: Optional notification by email.)

Tools Used:

• Ruby on Rails and JavaScript
• Sublime Text 2
• Photoshop and GIMP (turns out Photoshop sucks for pixel art)
• Twitter Bootstrap
• Git, Github, and Heroku

What Went Wrong:

1. Discovering that none of my several available web servers were running Ruby 1.9+ and being unable to upgrade them. I ended up having to sign-up with Heroku to do the hosting, but this was indirectly good — see below.
2. The AJAX interface for moving the units can be a little laggy. Unfortunately, there wasn’t enough time (and expertise) to develop a WebSocket solution — this will come after Ludum Dare is finished.
3. Not enough time for me to play the game, so some good balance tweaks only became obvious to me after the deadline when I could get in a few matches.
4. Not enough time to implement the several pages of additional features the game deserves! Especially automated matchmaking and email notifications. Hurry up and finish voting so I can improve the game!
5. The battlefield doesn’t look quite as much like an aquarium as I had hoped. It needs some kind of border around it that looks like fish tank walls.  One art please.

What Went Right:

1. Really knowing my programming language. In LD #22 I used Unity 3d, which I’m not very experienced with.  But I use Ruby on Rails every single day for work.  This was still a learning experience as I don’t use RoR to make games, but it meant that I didn’t have to use documentation as extensively (just occasionally to check parameter ordering for complex functions).
2. A great schedule. Just as with LD #22, my plan was to use Friday for ideas and a skeleton/outline of the app, Saturday for core gameplay, Sunday for “fluff” like finalizing the art and adding auxiliary features. Despite complaining about not having enough time to do everything, I actually did much, much more than I thought would be possible in 48 hours.  I think that midway through Saturday I felt that I had enough “game” to have been satisfied with submitting then.
3. Working with Heroku.  I’ve been wanting to play with this sort of dynamic, cloud-like hosting for a while and I finally got the opportunity to do so.  Even the the fact that I wasn’t able to use my existing (and therefore effectively “free”) hosting is going to be a boon, as I’m feeling more motivated to complete all the features I want to make a very professional product.
4. Good, high quality food at the ready. I made a pork roast on Friday night and had plenty of pre-washed spinach, lettuce, and other vegetables ready to go.  Saturday and Sunday morning started with a huge breakfast, and I made sure to consume a lot of high quality food the rest of the day. It kept my energy levels high.
5. Going for walks. It only took me 10 minutes to go around the block, but the four or five walks I took throughout the weekend were great for recharging my batteries.

What Went Awesome:

1. Streaming the whole thing and having hundreds of my YouTube viewers keep me motivated (and provide me with a to-do list of feature requests that will keep me busy for the next year).

Once voting for LD #23 is complete, I’m going to get back to work on this project and turn it into something really, really amazing.  I can’t wait.

http://fishtankcommander.com/

Thought i’d write the post mortem while everything is fresh. =)

“Men not wearing hats” is a game about what happens if you take what you want with force, even if the people at the receiving end is small, both in size and power.

What went right

Story: It was quite hard to think up anything original about the theme. The first thing that came to mind was to either make something on a cellular level, or make the game about “an intestinal journey”. Starting a few hours late i browsed through the ld updates and realized that my initial ideas werent so original after all. I started thinking about other themes, but was a bit lost. Then it dawned on me. I need to get into the “emo-indie-mood”!

When in the “emo-mood” i quickly realized that the game should be about the exploitation of africa and the middle east. I made a quick sketch that displays the player and his world. The initial idea was to make the player take oil and diamonds from the tiny people to either side of him to power his factories.

Tech: Im quite pleased with the usage of lua to control the flow of the game. Resources have their own scripts, as do players and other avatars. I also quite enjoyed working with an component based system which allowed me to add scripts, animations and other things to various game objects without loosing myself in oop hell. =)

Graphics: I like the water and the platforms.

What went wrong

Story: The goal was that the player should be able to be nice by taking diamonds/oil, converting them into gold and then returning them to the men not wearing hats. And, you can do that (there is a bot with a red cross on it). The only problem is that they don’t care, which makes the game unwinnable and always results in a massacre. Come to think of it, this is what happens in the real world aswell?

Tech: Even though some things were a success, others were not. On the evening of the last day some of my physics components suddenly assigned themselves av friction value of “infinity” – which is a ery large number and made the game grind to a halt. However, i did not realized that this was the problem until a few hours later when i tried to rebuild the world from scratch a third time.

Music: I actually made  a song in FL studio, but when exporting it it seemed to have gotten lost on my harddrive, and i was not wise enough to save my work. So, no music.

Time: I was foolish enough to thing that having a 5 month old daughter would not affect me. I does, and if i had realized this in time i would have cut the scope of my game into half. I still managed to spend ~22 hours on the game itself but thoose hours did come at a prize (which i’m about to pay).

Graphics: The first placeholder graphics was stuck in place until the very last minute, and some even made it into “production”. Taking a break in the middle of the dare to work on graphics will be my approach the next time, because nothing is fun about creating walkcyckles during the last hour. *argh* =)

Testing: I played through this game for the first time this morning, after submitting it. I was allright i guess, but tweaking could have made this game nice.

Conclusion

Overall everything feels ok during the circumstances that were. It is the most complex game i ever built on an ld, and it should play on more than my own machine. I had forgotten how though an LD can be so the next time i’ll try to add “mental preparation” to my toolchain. =)

Please vote and comment! =)

Thanks all who voted and competed along with me! It was fun and exciting to finally join Ludum Dare, and I can’t wait to join again for the 10 year anniversary!

Once again, I’m going to honest (and critical) and try to make this mega-post interesting!

PLAY THE GAME HERE

My goals for Ludum Dare 22

• Before the competition started, I had some goals in mind that I wanted to make.

1. I wanted to make sure “Fun” was the best category, so that people could replay the game, and have a good time playing.
2. I wanted the gameplay to be smooth and the animations smoother.
3. I wanted to beat Notch in at least one category (knowing how hard that would be).

What software I used

• Unity 3d Game Engine
• Blender 3D Modeling Software
• Pixlr Photo Editor
• Cfxr Sound Generator
• Unitron Script Editor
• Garageband Music Creator
• Text Edit Text Editor

How I made the game

• I quickly had come up with an idea for each of the most likely themes before LD22 started. My theme for “Alone” was a game where you would be sometimes alone, and then all of a sudden, you would be crowded with people.
• After the theme was announced, I decided that the game would be first person (the easiest of all the persons) and that you would have to fight your way through endless hordes of cubes (the easiest of default shapes). You could only see the cubes when your glasses were on, but if you weren’t in a shaded zone when your glasses were on, you’d start burning. This was a way to keep the player moving, and a way to make them constantly nervous.
• I worked on the player controls and LockCursor, etc. But the gameplay does not complete a game. I needed an enemy. One that would appear only if your glasses were on.
• I whipped up a cube model and texture and soon came up with this:

• Whoo Hoo! Now I have a cube!
• Next I worked on making the cube look at the player, and then having it disappear when the players “glasses” (A semi-transparent plane) were off.
• By now my Unity Scene looked like this:

• Soon I got Health implemented, and then it started to look like a Test level.
• I kept at it, knowing it would soon look like a game.
• The cube could soon move towards the player, and deal damage at close range.
• The first “Shaded Zone” was created, (using a Trigger) and the player would not take damage while inside it.
• I worked on making the zone a little prettier, and expanding the floor plane. I added a skybox, and changed the ambient light to near black.

• All along I had been slightly working on a music track, but now I decided I needed to finish it.

• The level was extended, the cube had a spawn code and could replicate itself, and the textures for walls and the floor was created in Pixlr.
• I created a variety of sound effects in CFXR like jumping and enemy death noises (my favorite).
• I worked on making an in-game tutorial, by timing when the music starts with the same time that it tells you that there is no one there.
• The menu was easy, all I had to do was come up with a name and choose the font, and soon my game looked legit. (Sorry for the lack of photos here)
• I asked my friend if he could play a test version on his computer (a windows) and I’m glad he did. The font I chose was bugging out on his computer, so I changed it to something else, and it worked fine.
• Now I knew my game was compatible on Windows AND Mac

• I created another music track for the menu, a helicopter to go to as the goal, and a stats screen so you could try to beat your own score.

Rating Other People’s Work

• I specifically rated the games that had the fewest ratings and tried to give most of them a fair, solid score.
• Mostly I gave 3.0s when I thought something was average.
• For a few people that put little effort into it, I had to give some 1.0s.
• I was sad that Notch had not really implemented the theme and pretty much made a different version of Minecraft. (Most likely this was just because he wanted to, or he felt like it.)

How people rated my game

• I can thank my friends, family, and Ludum Dare community for playing the game and enjoying it, especially DontBeNoobish‘s Gameplay Footage:

• I was proud with how my game turned out compared to most of the other entries.
• People mostly liked the audio and innovation of the game, but there were a few things I could’ve made better (More enemies, options, etc)

The Results!

• Coolness – 52% Bronze medal | At first I thought that the bronze medal meant third place, but then I realized Coolness didn’t have the same rating system. Oh well, it was still good to see that my playing of all those low effort games went to good use!
• # 40 Community – 3.55 | Wow! Community? I didn’t realize I was that popular! I guess this rating makes sense because of all the excited posts I made with links to this game. I did a LOT outside of the game (Time-lapse, post mortem, gameplay video, tips)
• # 108 Innovation – 3.20 | Good, people liked my idea of the sunglasses and whatnot!
• # 113 Mood – 3.20 | I think the music accomplished the overall feel of the game.
• # 118 Audio – 3.00 | Once again, the music, but also the enemy death noises made this count.
• # 113 Theme – 3.33 | Well, you are sometimes alone…
• # 202 Humor – 2.29 | I wasn’t even going for this (other than the ReadMe) so I have no clue how it ended up higher than overall.
• # 323 Graphics – 2.67 | Although mine was one of the few 3D first person games, I guess people didn’t really like the low effort GUI and enemy textures.
• # 435 Overall – 2.50 | Oh no! Overall score seemed like an important one…
• # 487 Fun – 2.06 | Really? This was the category I was focusing on, but yet it got a 2.06! Yes, I guess I did better than almost half of everyone else, and I’m not complaining, but this ended up at the bottom of the list, when I had worked for it to be the top.

Comparison To Notch

• My goal was to beat Notch in at least one category, and it turns out that was too easy:

• I ended up beating Notch in 7 different categories!
• A comment on the community rating: Last LD, Notch won third place (if I recall correctly) in the community category, but now he received a #49! And I received a #40! So after all the years Notch has spent on Ludum Dare and Minecraft, and the entire fan-base he collected from the Top Computer Game Of 2011, I was able to receive a better score than him from 3 weeks of posting on Ludum Dare!

I send out a huge thank you to all who rated my game (yes, even those of you that got me that horrible “Fun” score) and hope to join again for LD 23! Please remember Rob Productions again for next Ludum Dare, and you can expect a post-compo version coming in time!

Links:

TIPS ON MAKING A UNITY GAME

POST MORTEM

TIMELAPSE

THE GAME AGAIN

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.

[My name is Carlos Leituga and I’m a junior Game Designer / Implementer in a Portuguese company, where I’m working on a Hidden Object Adventure for a year and a half now. So here I am again, creating a game in 72 hours with the Make A Game team for Ludum Dare #22. ]

As we were packing our stuff after making Eggscape, someone said something in the lines of “Let’s do this again in December!”, and since that day in August we’ve been talking about participating once more in Ludum Dare.

As the final week till LD #22 began, we followed the theme voting closely, coordinated our votes and shared the possibilities of each theme that interested us. Having learnt a lot with LD #21, we were confident that this time everything would work out better, even with two fewer members.

(more…)

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

Ludum Dare 22 Post Mortem
December 2011 – Game: Fernands War.

Pre-compo prep.
Last year I found out about the Ludum dare competition and was really interested in doing something, unfortunately I didn’t have the weekend totally free to commit to making any real attempt, but I managed to crank out a tiny little endless runner in a couple of hours and catch some of the live recordings (Notch’s one mainly). It was interesting to see the fruits of every-one’s labours, and the community spirit here is really inspiring.
So as I hadn’t managed to make a decent attempt last time, I had planned to jump in properly for LD22. In preparation I had made all the necessary requests for that 48 hour period to be free and started thinking about the tools I would use to make the game.

Physmo is a 2 man team, I do the art and design and @physmotone is the chap with the coding skillz. We had talked a bit about entering the jam as a team but were struggling to both get the time off we needed so I planned to enter solo. This meant coding the game myself; I am a programmer but I’m certainly no game programmer so I realised this would be tough. I’m sure Tony would be shocked by all the fundamental coding mistakes I made while making my entry, stuff he has the experience now to avoid, but I learned a lot doing this, especially about the architecture of making a game, the game states, resource management etc – all that tricky stuff we can take for granted sometimes.

In the week before the theme was announced, I decided I would choose Java as the language, and Slick2D as the graphics library for drawing the sprites (It also does a great job of loading graphics, sound and level data.) I’m not a java programmer but it seemed close enough to C++ to be easy to pick up, but mainly I wanted something that would be multi platform with the vague possibility of embedding in a web page (this didn’t happen). I didn’t know what kind of game I’d be making but assumed it might need level data, and I had heard of a map editor that was supported by Slick2D called Tiled, so I downloaded that and made sure I knew the basics of how it worked. In the prep week I didn’t find as much time as I would have liked to do actual prep but I did get a few hours to find some java tutorials and create a small test application that demonstrated loading and displaying sprites, loading and playing sounds and reading a Tiled level. I didn’t want to waste much of the 48 hours being stuck on some trivial problem like not being able to draw a font to the screen so I investigated the font libraries too (Angel code fonts I think it was). I had the small test app running, the final thing on my list of prep was to actually package the program to be runnable on other computers.
This was a couple of days before the announcement and I could not for the life of me package this thing properly. Eclipse is the IDE I was using and it’s pretty complicated if you don’t know it, and I had no idea about how to create Jar packages (which is what I needed to make the thing runnable). I tried every combination of including the platform specific .dll files, the library .jars for Slick2D and LWJGL, and did a lot of googling for the problem. Fortunately (?) many novices seem to have a problem with this step, and in the end I reluctantly tried using another app to package all of the files up into a fat jar, which worked. i say reluctantly because even though it worked in the end, I still don’t have a good understanding why it didn’t work and why it does now, but hey, it works! This was a real problem just before the compo started though. If I couldn’t find out how to package the game, there would be no point in working on a game. I would heartily recommend anyone taking part in a time limiting game creation competition to build a full app end-to-end before they take part.

The graphic and audio tools were to be Photoshop, SFXR (of course) for sound effects and Audacity in case I needed any sound effect editing. In the end I did install audacity in the final hour to tweak the ship thruster sound effect but that’s all.

Announcement
I’m in the UK, so the announcement came at 2am our time. The plan was to stay up for the announcement, have a think about it and then get some sleep.
The theme is announced. “Alone”. I stare at the screen for a few minutes. My first thought is, “Well at least I won’t have to code any enemy AI”.
At Physmo we have a folder full of crazy game Ideas and prototypes, but we have never really considered a thrust style game. I used to like thrust style games though, and I though it would be within my skill range to make a good attempt at one. Quite soon after the announcement I had come up with some ideas for a decent plot – I wanted to have some narrative in the game that would be explained as you play and I really wanted to have a good twist in there too. I had my general story Idea and style of game I wanted, I could now sleep (and secretly hope to come up with good ideas in my dreams).

Oh, this post mortem is going to be a total spoiler for the game, so please play it first if you intend to… I’ll give you a couple of minutes, just watch out for the spinning sawblades, the collision on them is a bit saucy.

For the plot of the game, I wanted the player to have unwittingly done something really terrible. This idea made it into the final game but was very scaled back. The initial idea was that you would be flying a ship around a room with some kind of reactor in the middle, there would be a cage full of energy capsules milling around that you would have to pick up and drop into the reactor. At some point you would realise that this is not the true reality of the situation, the reactor is actually a horrible mind controlling alien, the energy capsules are really other human members of your crew and the alien has tricked you into feeding your crew to it.
This was the plan until the end of day one, I didn’t think I would have time to code the mechanics for all this, the switching level graphics, picking up and dropping the crew etc, so at the start of day 2 I decided to change it slightly so that you were a security guard of a mining colony, who was going mad. It seems like at first you are being attacked by aliens, but as you progress through the game you can read log files that gradually explain that the aliens are really just the colonists, and by the end of the game you will be alone, having killed them all. It’s nice to end on a cheery, up-beat note.

It was time to start programming. But first I went to my trusty Photoshop and drew some sprites: A yellow ship, some bullets, some white splodges to use as particles and a simple tiling foreground and background tile sprite. The spaceship made it into the final cut of the game with no modifications as I quite liked it. NOW it was time to start programming! First I needed some classes to represent the ship, bullets and enemies. That’s what the game needed, they are an integral part of the game. You can’t have a game without them. That’s why, like an idiot, I spent the first couple of hours making some pretty particle effects.
Ok, Basic particle engine created, I now really HAD to start creating the game objects. I found a nice tutorial about creating game entities, and then creating generic behaviours that could be inserted into them, this seemed like a cool Idea and one I had never tried before so I gave it a shot (I’ll try to link to these tutorials and things at the end of the post). After stealing the code to create the framework of the entities, behaviours and renderers, I derived my own object classes for them, starting with the players ship movement code. This was easy as I had used some basic maths like this a lot in some processing toys I made a while ago. It’s useful to know so I’ll write it out here:
Horizontal Thrust = sin(ship angle of rotation) * force;
Vertical Thrust = cos(ship angle of rotation) * force;
So everytime the thrust button is pressed, I add these values onto the ships velocity on the x and y axis. Every time through the game loop, I add the velocity vector to the ships position, and that moves the ship. And at the same time I dampen the ship’s velocity by multiplying it by a number slightly less than 1.0 (0.98 or something). That reduces the ships motion over time and eventually makes it stop in a pleasing way.

Ok, next big problem. In my processing (processing is a simple java-like programming language) experience, the main loop is locked to a certain frame rate, but in the Slick2D framework it isn’t. This means the loop runs as fast as it possible can – maybe hundreds of times a second – but it will vary from computer to computer and will vary depending on how much is being drawn on the screen too. To handle this, the update loops are passed in a variable that represents the number of clock ticks that occurred since the last update, and using this I could feed it into all the motion equations. Essentially, every calculation that results in something moving on screen needs to be scaled down by the number of clock ticks, so that the movement is nice and constant. I forgot to do this to the scrolling routine though so sometimes the scrolling can be a bit slow if your machine is struggling. That’s a bug but would be easy to fix.

I now had a ship swishing around the screen nicely, with lovely particles firing out of it’s bum (and me making “woosh” sounds) so I flew it around the screen for half an hour thinking how awesome I was to have achieved such a thing. Next I needed some background to be drawn. The Slick2D libraries can load and display level data from Tiled map files, although they couldn’t handle (as far as I could tell) drawing level sprites scaled up, but it was quite easy to parse through the loaded level file, find what tile is at what location and draw it scaled up myself. I got this running surprisingly quickly (well it wasn’t very complicated) and then added some scrolling offset code, and voila! I had a ship flying around a scrolling level. Flying right through the walls though. Next step was to detect collision on the walls, so I wrote a routine that given a point in the game world, would find the foreground level sprite, and check if the pixel was filled or not. It worked and that is the basis of all the collision in the game. To collide the ship off walls, I check around 10 points in a circle around the ship to see if they are touching a solid part of the background. If they are, i calculate the vector from that point back to the centre of the ship and add that to the ships velocity, I was amazed that this works but it resulted in some pretty solid feeling collision (I was worried that the collision would be awful in this game) so maybe this is what real collision is based on.
I created some simple behaviours for the player bullets that I reused for enemy bullets (The entity system worked well here) then I added some basic enemy types. I regret not having the time to make the enemies do more, but in the end I just had static enemies that varied in the speed that they fired bullets at you and the number of shots it would take to kill them.
I added a lot to the game in the last half day, as the main mechanics were there. Different sprites for the enemies, more particle effects and the log file objects that can be picked up. Some trivial looking things took more time than expected, for instance displaying the log file text on screen and making the rest of the game pause while it was displayed. At this point I realised I would have to start thinking about game states, so I changed the main class to be a state based game state using the Slick2D libraries and created another state for the main menu screen, then worked on getting this to transition back and forward and make sure that the player could die and the game would switch back to the main menu. This is something I wish I’d thought about a lot more at the start as game states are a tricky thing to to if you aren’t used to it.

Panic was setting in in the last few hours of the 48, there was a lot to be tidied up. The collision between bullets, player ship and enemies was quite off so I modified the renderers to display the collision box and that helped me track down and fix the issues there. One big problem that I regret not fixing is that the hit-boxes for the circular saw blades is a square, not a circle and this makes for some really unfair deaths in the game. I realised I had no time left to fix this so I modified the level to move the saws and give the player more room to move around them, still it’s disappointing to get unfairly killed by them.

The game was looking quite finished, all the log files were placed and the end could be reached, but it was quite hard, so at the last minute I made the players health slowly regenerate over time. In the last half hour I feverishly added a lot of minor details: The player health bar, more particle effects for killing enemies, more sound effects and a dodgy system for playing the ships thrust sound. Panicking further, I played through the game one more time and hit the build button to build the final Jar file, and opened slick jar (i think) to package it up into a runnable jar file. With minutes to spare I clicked the Jar file and it seemed to work, phew! Opened my web browser, and went to www.ludumdare.com …… wait a … WTF .. oh MAN! Why is the site not working! Through lack of sleep and burnout I thought all was lost, I refreshed the site and still nothing. Thinking that all was lost, I gingerly climbed onto the window ledge, and, oh wait, the site loaded! Wheee! Well, at least, I saw a message from the site saying they would accept entries for an hour or two after the closing time. I eventually uploaded the game and could relax, but those last few minutes leading up to the deadline were some tense minutes let me tell you.

In closing this rather rambling post, I did enjoy the experience. I think I made a decent, complete game that I hope you enjoy playing – it’s quite short. I’ve learned a lot about what should be prioritised next time, and I feel like I was part of something big and crazy

Please try it, it’s called “Fernands War” http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=5349

We have a full game called Mos Speedrun too, for iPhone and Mac/Pc, you might like it.

Thanks!

Nick

@physmo

http://www.physmo.com

For my entry I made a little point-and-click adventure game without the clicking.  If you haven’t already, you can play it here.

What went right:

Music – going into this I was fairly certain that I would be using some sort of chiptunes generator, but when the theme “Alone” was announced I figured there was no way I would get a chiptunes to work with the mood of being alone. I had given up on music within the first hour of production, but at the end of Saturday I got a little tune in my head, nothing fancy but it just might work. Sunday morning I got out a guitar and found a microphone and started recording just to see if I could make something. What I ended up with may not be fancy, but I like it and I think it is definitely better than silence. Though, since I went with live music I don’t think I should have used sfxr to generate sound effects, I think they kind of clash.

“Just do it” Attitude – When the theme was announced, I was at a loss for ideas. Fearing I would just give up if I didn’t do something, I started drawing a little sprite protagonist. After seeing him walk around I thought “he needs to be crushed by a tree.” The act of starting something allowed other ideas to flow and created a game for me, all I had to do was finish it.

I'm about the get crushed. That's what went wrong.

What went wrong:

“Just do it” Attitude – By just starting right away without a plan, towards the end I had to start hacking things together in order to make them fit. Not having a plan before hand meant that I didn’t realize just how many assets I had to draw (as you will see, I’m terrible at drawing assets). And the code it cobbled together and held there with duct tape. I found myself writing the same thing over and over because the base class wasn’t created properly because I didn’t really know what it was going to be used for. Had I started with a decent plan I might have saved enough time to put in a small tutorial.

Theme – I was all prepared to create a tile based platformer and was hoping the theme would present a neat mechanic that could be used in the game. But when “Alone” was announced, all that went out the window. I was at a complete loss for ideas and nearly gave up right there. I actually wrote down several ideas for the themes from round five, but “Alone” was one of two that I couldn’t come up with a decent idea for. In the end, all I had was the vague idea “environment for the enemy” and I tried to make the best out of it.

Lack of instructions – If you watch the timelapse you may be able to see that there was an “Instructions” field in the main menu all the way up until about an hour before the end of the contest. I had intended to include just one screen explaining what type of game this is, what types of interactions the player has with the world, what clickable objects look like, and a hint to where to find the kitten. In retrospect, this really shouldn’t have been cut because without prior knowledge it isn’t obvious at all what the player can and can’t do.

This is what the instructions were supposed to look like

Lessons Learned:

Take time to make a plan – I think next time I will dedicate the first hour to planning out what I’m going to do

Have completed basecode – There were still many things missing from my base code, like collision detection and a way to do fade outs. I didn’t want to look up anything while in the contest as it would waste time, so I made due with what I knew how to do at the moment (and that is why screen transitions are screen wipes).

Be strict about friends/family not bothering me – In the middle of Sunday I was called away by my family by what I expected to only be an hour which turned into five. Whenever I look at this game now I think what I could have done with those five hours.

All in all I learned a lot from the LD22 weekend and look forward to participating again. And please, if you haven’t, could you play and rate my game.

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!

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 !

Ah, finally got this out of the way. Was dragging my heels on this post-mortem as I didn’t feel like I had made any significant mistakes this time around, so there wasn’t a ton to reflect on. However, I haven’t had a ton of comments on my entry. So hey, if you’re in the festive spirit, give the gift of criticism!

In between zooming around from NS to NB this past weekend, I knocked out a Ludum Dare game. Neat little randomly generated retro style platformer. Posting this both on the Ludum Dare site and my own blog. So LDer’s enjoy an expository preamble!

Click to play

Preamble

So if you’re unfamiliar with Ludum Dare it’s an online, solo game development competition. They release a theme and you have to develop a game using that theme in a forty-eight hour timeframe.  A large list of themes is created and after a few rounds of voting , the list is culled to a dozen or so final themes to vote on. After the final round of voting is complete, the theme is released and a sleepless, hectic weekend begins. I was rooting for “Randomly Generated” to be selected as the theme and was already salivating at the prospect of making a roguelike.

Over the last few years the only games that really stick out to me as being actually fun and life destroyingly addictive were the new wave of roguelikes. Spelunky, Transcendence, and The Binding of Isaac have taken a mostly inaccessible genre and made it almost casual. If a player can get over how masochistic these games are, it really scratches their drive for mastery. There is nothing that can foster that “Just one more turn…” effect better than these games. But I digress, this is a subject worth a post all on its own.

Spelunky was a harsh mistress

The weekend of this Ludum Dare coincided with a friend’s Christmas party I few hours away. I didn’t want to lose six hours driving back and forth so I opted for twelve hours by train. After packing everything for the trip I settled in and waited for the theme reveal. “Alone” ended up hedging out Randomly-Generated by a few votes.  Even though I was bummed over my pet theme losing, I figured I could still work Randomly-Generated into my concept. What I roughed out, was that you were a monster created by the government, you wanted to escape their pursuit and be left alone. I pegged the gameplay as a platformer with randomly generated level sections. I wasn’t sure about combat and mechanics but I was hoping it’d grow organically throughout the competition. My main goal was to produce something playable that had some random level generation in it.

(more…)

I made a post-mortem for my game, “Ghost Town”.

You can click this link with your pointing device to see it!!

My entry for LD22 (ISOLATED ASSAULT) was somewhat of a wave survival game, getting harder with each death, until you reach the goal, the escape chopper.

I had a lot of fun, and, after being my first time, I will most definitely do this again.

Here’s the “Proper” Post-Mortem:

How I Spent My Time

Timelapse here if you want to take a look.

Basically I came up with an idea while I was making the game. I had already pretty decided it would be first person. And also I had pretty much decided the enemies would be cubes. (Just to make it easier on myself)

I didn’t particularly like the theme, alone, but it was better than kittens.

Mainly I worked on getting the character movement to be as smooth as possible, that’s where most people messed up, to make the game fun and re-playable. I tried to make the sword animations as hectic as possible, just to make it look a little more stylish. I made the wall and floor textures 8 bit and repeatable. I made the music overdone, with a lot of instruments (using garageband) and very complicated. I did this because I remembered all those 2d games with catchy music but terrible graphics.

I implemented the theme by having enemies appear if you put on sunglasses, but disappear if you take them off. The catch was that in the sunlight, without sunglasses, you burned. So you had to find shaded “safe” areas to take off your sunglasses and regenerate health, while the enemies disappeared.

The sound effects were done in CFXR (I especially like the enemy death noises). The language I used was Javascript. The game engine was Unity Indie. The 3d modeling software was Blender. This cannot get any simpler.

I chose these programs because, well, they were free, and also because they’re proper towards making an indie game.

What I Learned

• The smoother the gameplay and character movement, the better
• Sound is a very important part of game development
• Don’t over-complicate things, keep your main code in as few scripts as possible
• Particle effects make the game seem more complete

What Went Right

• The music was mostly catchy and was repeatable
• The gameplay was smooth and the sword attacks blended together well
• The implementation to the theme (being alone, only when your glasses are on)
• The sound design was okay, especially with the enemy deaths

What Went Wrong

• There should have been more enemies
• The enemies should have been easier to fight
• There should have been more things blocking your path
• There should have been better GUI controls and being able to change the mouse sensitivity
• The level design should have been worked on better
• The game should have been longer

All in all, I think I did an okay job, maybe not the best, but it was fun enough to please my friends, and good considering the amount of time I had. (Less then 48 hours, more like 30, I had to go to some places)

Try it out here.

The last man on Earth sat alone in a room. There was a knock on the door…

Play It | Rate It

Origin

When I heard Alone was chosen as the theme, a set of bizarre ideas immediately appeared in my mind. I really wanted to explore about the feeling of being alone, about the psychological effect of it. Also, I had read The Knock recently so I wanted to explore more about that subject.

Development

The tools I used included:

• Adobe Photoshop
• Adobe Lightroom
• Adobe Flash
• Flashdevelop / ActionScript 3
• as3sfxr »
• Aviary »
• A standard Digital Camera
• Some burned papers
• A friend (lol)

The art is rather simple, I took some photos of my house and I asked a friend to model for me. We did some shots of him walking, but because I lack equipment (tripod, marks, etc) the result looks a little bad. I did my best to correct the photos in Photoshop. The room is a part of my house, that isn’t even a room, but I couldn’t take a picture of a real room because the camera angle was too short. I applied Exposure and Posterize to all the images.

The programming was done entirely in ActionScript 3, using some features of my own library, but the vast majority was to be made from scratch. I used Flashdevelop because I’m really fast with it… Just press Ctrl+Shift+1 and it’s like magic!

What now?

I think I’ll work more time on this game. I’ll add more puzzles, make an easy mode, add language support, and maybe more rooms to explore, or explore more about the story. For example, what happened upstairs?

This was my second time on Ludum Dare, and I think it was a really good experience. I don’t think there’s something that went wrong, maybe next time I’ll add more features to my framework, like effects, sound support and embedding support; but at the end I managed to do what I intended to do.

Good

• My zombie! I’m really proud of my ugly zombie. Yes, I spent a lot of time on it and it isn’t good art by any standard but I don’t care. It was worth it to see it “alive” in my game
• I only realized that after I was done but I kind of made the game I wanted to do for December 2010′s LD. Except then I had found myself making an alien instead of the zombie I had planned to do and then gave up before I had gameplay anyway. So it’s like I tied up a loose end.
• The jam. If not for the jam I wouldn’t have been able to finish my game and the LD would have just ended in bitter disappointment for me.
• My trusty ZBrush was awesome: sculpting/painting the zombie was the most fun part of this LD, Blender was also great for animating it.

Gray Area

• Making the low-poly retopology took more time than I thought. I tried TopoGun which I had just bought a few days before the compo and never used.  That added a few hours of work but then TopoGun worked really well for generating the color and normal map from the sculpt.

Bad

• I missed the compo deadline and had to do the jam
• I was generally not very fast. Lack of concentration maybe? Everything seemed to take just longer than it usually would.
• I spent the same amount of time on the environment than on the zombie and yet it really doesn’t show.  I just wasted time noodling with bits cut from my original hallway model and just made a mess and had to restart again. It was a time sink for no reason.
• Simplistic gameplay. I wanted to make the game more about stealth.
• I still suck at using Modo. It’s a great software I have no doubt of that and I mostly knew how to use it. But somehow I still find myself struggling against it every step. I don’t know how to explain what it is exactly. It’s weird and it’s probably just that I lack the practice to have the right instincts but it’s really annoying when trying to speed model and everything reacts in a slightly unexpected way and I keep having to undo and try again. I’ve got to spend more time using it.
• Still no time for particles effects. I put them on my priority list for this LD and still neglected them.

Time use

• Code: 11.2h (includes setting things up in Unity)

• Model: 9.3h
• Texture: 4.7h
• Animation: 3.5h
• Sound: 2.4h
• Level building: 7.6h (half of it wasted on a discarded version)
• Sleep: 24h
• Doing other things: 3.4h
• Misc: 5.5h (probably 50% actual work the rest being posting WIPs, chatting on the IRC channel, etc)

• Total spent on zombie (including sounds, code, etc):  15.5h
• Total spent on the environment/level (incl. medkit props and ambient soundtrack): 15.4h