Archive for December, 2011
Moving along nicely!

Aiming and jetpacking around is great, got the main tiles done, player fully animated (for now) and behold! aliens!

To do:
Particle system, multiple guns, map the cave and populate it, add meaningless greeble and flavor tiles. AI.
I’ll have SOMETHING done but I doubt I’ll finish what I set out to do. That’s fine with me.
Village Bastard – low-tech timelapse
As is now traditional for me, I prefer a more concise, low-tech timelapse. So here it is:
A basic world to walk around in:
![]()
Drawing some landscape tiles and the landscape map:
![]()
Loading a landscape:
![]()
Adding a basic house:
![]()
Adding NPCs to houses:
![]()
Showing house names in the hud:
![]()
Conversations with NPCs:
![]()
Houses crumbling and a smoke effect when houses are abandoned:
![]()
Adding inventory slots:
![]()
Picking up items (mostly buckets):
![]()
Adding a forge as a world object:
![]()
Adding the farmer puzzle:
![]()
Finishing the blacksmith puzzle:
![]()
Adding the doctor’s puzzle:
![]()
Adding Greta, the cranky cat lady:
![]()
Herbert, the dog lover:
![]()
A boring shot, but this was optimising the map display so I could draw huge maps at 60fps:
![]()
Adding roofs over houses, that dissapear when you go inside.
![]()
Doing the title screen:
![]()
The librarian:
![]()
Adding the vignette and noise overlays:
![]()
Spaceman Samotny Timelapse
I uploaded the timelapse of the development of Spaceman Samotny. You can play the game here.
This was fun to do!
Super Smash Lander Suicide Party, Bro? POST MORTEM!
Time for everyone to high-five everyone else.

First Ludum Dare. Had an amazing time. Much thanks to Helloserve (hosting a spectacularly perfect local jam) and FuzzYsp0N (for his unremitting awesomeness).
Things that went right:
Things that went wrong:
I think I’ve made the kind of game that if you know me, or are like me, it’ll be an enjoyable twisted pleasure. But if someone isn’t “in” on the premise it’ll probably come off as silly and disjointed. I had plans to build in a progression loop over multiple plays, but that turned out to be out of scope. As it is (in the 48hour form) it’s weird and maybe funny, but not as compelling as I’d like it to be.
Yet it turned out a lot better than I thought it would be (I’ve never made a game like this). Much thanks to many good things conspiring together.
Game completed!
I may not have been able to put in all the things I wanted to, but it is a game and it has an ending, so I’m pleased with it. The most fun I had was creating the death animation/sound/messages, so if you have some spare time try to get all the different deaths. I’ll add a proper postmortem later, and put up a timelapse when it finished building. And check out the entry page here.
We have a forest, at least!
With barely any time left at all, we essentially have: A little girl walking through a somewhat poorly randomly generated forest. BAM. Is there a booby judging category? It’s as good as ours!
Aims for the day: get the little girl to do a punching gesture when you press space. Add music.
Incredibly optimistic goals: add an enemy to each page of forest, implement retarded combat system.
Almost definitely NOT happening: end room and final boss.
Solved with Head, Post Mortem
This was my first Ludum Dare I participated…
I tried to make a story based, sidescrolling rpg-adventure in 48 hours with XNA – and this idea was totally crap. It was fascinating how fast time can run. I started with the game “Soulaffector”.
Soulaffector
In Soulaffector the player goes into a cursed forest (still without trees… : D) which kills and enslave the humans near it. You pass the forest as a shaman-like warlock and fight the forest by fighting the enslaved skeletons. You got the power of affection (rage (red), fear (violet) and compassion (turquoise)) to manipulate the skeletons. On the picture (top-left) you see, that the player has lot of rage and little fear and compassion. As a shaman he can pass his emotions through the lost souls to manipulate their behavior.
You can click on a skeleton and then on one of the three emotion bubbles. After that, the skeleton’s rage value increases, yours decreases. The skeleton gets a small red light to indicate his added rage point.
Skeleton-Behavior
In the built there are the following behaviors for the skeletons:
- full of rage: dies
- full of fear: dies
- fear greater than the other emotions: stay / stop moving
- compassion greater than the other emotions: attack another skeleton (the compassion cools down so the attacking suffices to kill one skeleton
- rage greater zero and >= the other emotions: the skeleton attacks the player
This behavior works with some small bugs (poorly written code to manage the compassion… sometimes the skeleton ran to a dead skeleton to hit him or just attacks the player).
If the skeletons attack the player, he can’t move (but affect the skeletons) and the screen gets deeper and deeper (until it is black and you lost the game), but your rage increases too, so you can fight back.
Problems
Another possibility to gain new emotions is to talk with others. There are some textboxes implemented with a possibility to answer and every answer increases another emotion – but there are no actors than skeletons. There is no plot too. It is difficult to fight the skeletons without another way to increase fear and compassion, so there should be other ways to increase them too. It is interesting to handle the fight by fearing, enslaving and raging different skeleton enemies.
I needed a lot of time to create the graphics and emotions. I aimed to make lagging animations like in these old films – you know: http://www.youtube.com/watch?v=5yYeZMx1Y7U (1:50, watch it!). I like this style, it is so incredible horrifying : D
For creating it, I drew the skeleton-bodyparts on paper, scanned it and placed the bones in GIMP. Here I need a better toolchain or a simplifying framework part for bone-based animation, easy to initialize.
I kicked some ideas early because I realized that this game is too much work, e.g. to create a camp to rest or a skill system (not to make the player better, just weaken the enemies).
5 or 6 hours left… a new game?
5 or 6 hours before the 48 hours contest ends I was totally frustrated by my game: no trees and if there, an endless repetitive background, buggy fight system (and if it works, I thought, I gets boring), no story or plot, no aim, no well-polished graphics and animations and more…
I wanted to give up and did a pause. After a shower I decided: hey, this was hard work and it is painful to drop it all, but I wanted to submit “something” and so I wanted to create a little game in the remaining time. Crazy but possible.
And yeah, I kicked some * and made a game in fucking 4 or 5 hours. I’m proud that I managed it and submit something, but it is so completely idiotic:
“I submit a game in a 48 hour competition”
“How many hours did you invested?”
“4 or 5”
“Ehm… are you stupid?”
My tutorial for a 5 hour game (or what to do if you fail with time management)
First step: Fast game design: alone => christmas alone => empty room => what to do => shit idea => head meets table => head up => good idea => make a game with an angry guy who wants to break things in his room with his head => great success… or something like that.
Second step: Fast painting: pixelart with gimp – just draw and draw and draw… room => wall-graphic for the bottom screen to show later on top of the playable field (transparency) => main character animation => test-item graphic in an undamaged and a damaged variant.
Third step: Program with C#/XNA and so fast as you can => invite your two best friends “Mr. Copy” and “Mrs. Paste” => it works. I did the interface, the simple logic, ending screen and this stuff, I thought this was the most work.
Fourth step: More and more items drawn and added.
Half hour before Ludum Dare ends I implemented the randomly generation of new levels by putting the items on random positions.
Game Idea
In the game you can run and strike (normal and strong strike, both with sound and a little white blinking). Both strikes have different damage values, range and power cost. Items have health and if the health is away, the item gets destroyed and the destroyed-variant of the item will be drawn on the screen. Left-top you got a red power bar which regenerate. After the timer expires, your score (accumulated damage) is displayed on an ending screen and you can restart the game. A feature here is, that big items like a table have collision, small things like a paper not. They have all an own health value, so you can destroy a letter by one hit and for a table you need some more. To get a high score, you must manage normal and strong strikes, e.g. strong strikes because of low range and high damage on heavy things and the normal strike with his high range for the weak items… some tactics possible like to run through the map to destroy all weak items by the normal strike… my best score was (I thought) 1700 or 1800.
Try to solve the “you are alone while christmas” with your head…
… like I did: solved submission deadline issue with my head : D
Conclusion:
What went right:
- not slept too little or too much
- eat/drink okay
- highly motivated
- had a lot of fun
- I finished a game
- managing a very bad situation (5 hours left and no solid game)
What went wrong:
- poor time management
- no explicit plan
- tried to make a storybased game (even if you have the time, you will probably not have the concentration after the first session)
- to much time for graphics and animation
- my starting project was good (collision checking, simplified drawing etc.), but there is a couple of work needed to make it stable and with solid functionality = better preparation
No links available for my submission?
Although I provided links in the submission, and confirmed them via the edit utility, nothing shows up on my entry….
http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=3494
Superchallenge.
So this weekend was a little more busy than I had anticipated.
Today is my only day off.
Time to get a jam entry finished before the end of today!
How did I Do it?
Monday, December 19th, 2011 9:00 amSo, what is my secret? Or how did he do it? Well, Read on. This log tells about how I designed and created my 48 hour game and what choices I made.
Concept
I started by brainstorming on a piece of paper and with a good breakfast (soup and bread). The brainstorming resulted in a large web of words and lines. Afterwards I started to scrape all unrelated words and lines until a small part was left. From the readable words I picked the best and started sketching. The concept ended up being:
The player is stranded in an unknown world (other dimension?) and needs to get away before he dies from starvation. While doing so he should try to contact others while being annoyed by robots/drones.
Design
The sketching brings us to the game design. I started with a simple sketch and made it into a 3d design tool. The sketch ended up with showing a dessert with a crash landed space ship. The main objective got: Activate the beacon (middle of image). 
But the question remained, how did the player get there? To solve this, the player doesn’t know either, she just wakes up. To give the game more feel about the strange place I created two separate environments. The player would wake up in her own bedroom and once she gets outside the room, there is no hallway but a dessert.

So the level and setting where done, the only thing left was the robots and drones. Trying to keep it simple I choose a floating sphere like drone who float somewhere around. It was time to think about the technical design. I worked in C++ using the tool Irrlicht and Irrklang. So I opend Visio and started to place the objects I had: Drones, Level, Beacon, Player and the scene itself. It resulted in this:

Ofcourse, much is changed during the game development, but note, this is a useful “work to” point. I ended up with:
- Player must survive (he always survives)
- Player must activate the beacon
- Player must keep the drones away by picking them up and throwing them away
- The beacon is activated by clicking on the launch button.
Prototype
I started to develop the things I sketched and put them together into a simple game. The prototype was done before the 18 hour mark. The prototype seemed good but lacked a bit of humor and feeling.

One of the results of the prototype showed that the game lacked humor and that one machine to activate was too easy to handle. The extra things I planned for the game itself became:
- The beacon can be activated after the power generator is activated, activate by clicking on the launch button.
- The power generator is activated by clicking on the launch button.
- The Drones make a noice when picked up
- The Drones receive damage after being thrown, after which they move slower and start to smoke
- Adding more subtitles and “ particles! “
Testing
A very important step! Think about how to test your game before you finish it! I used Visual studio so I was able to do variable manipulation, but, otherwise I would have added cheats. Make sure you can easily test your game on bugs. Watching a story over and over again is awful, settings states and recompiling is bad, real bad. So, make a plan, how do I test the start, middle and end? (without replaying the game every time). I just manipulated the games variables with the Visual studio debugger, changing enumerations and time variables.
The Game
On 22:00 CET I started with the game. The first things added where voices and sounds to the drones, a background music track and recorded some sounds for the power generator. How did I record the sound for the generator? Well, quite easy, taking my microphone and putting it behind my computers fans, lowered the pitch and lowered the speed and viola! Done. In the prototype, the bedroom and spaceship were left without detail, it was awful. The ship had to look broken, to do this I first modeled the ship and when that was finished I broke it. Cutting holes, lines and adding more panels. The advantage of doing so is that you have a good looking ship. Breaking it and adding debris is a much easier process. When the new models where done, I just replaced them in the prototype. The same detailing process is done for the drones, power generator, debris, terrain and the music track.

Submitting
I kept track of 2 folders, one for debugging and one for the release and I setup special defines for the debug and release. Once a debug version was bug free I tried the Release version in the release folder. The source code was placed inside a separate folder. At the end, I was capable of just clicking the source and release folder for archiving them. On monday 02:40 CET ( 20 minutes before the deadline) I submitted my work. Barley before the site went down! Got lucky
Time used: 32 hours Sleep: 15 hours Tools:Autodesk 3dsmax, Adobe Illustrator, paintToolSai, Audicity, Anvil Studio, Visual Studio 2010, D3d MeshViewer, Irrlicht and Irrklang.
Tips and do’s:
- Set up 2 folders, one for a clean release test, one quite clean for debugging.
- Write down the games basics and rules,
- Sketch the technical design
- Build a simple prototype on which you can later improve the games visuals.
- Take regular breaks! Work 60~90 minutes with a small break, like: running through your house, going outside for 10 minutes, they improves your motivation and precision!
- Always make sure to write it down, it makes it easier to decide if its possible
- Chat on the IRC channel with others, use your time and chat later, in small breaks or afterwards.
- Sleep less, when you have less sleep it will lower your creativity, bug tracking and other skills.

Thank you for reading the “How Did I Do it”.
Sorry…
My game is to difficult. It was some kind of parameter that I set just before submitting without playtesting enough ![]()
I think it was the reaction time of the AI that I changed that made it this way.
Ah well, lesson #452 learned this weekend: Always make sure to playtest after each change. Pretty obvious really, but under these circumstances (LD noob) it happened anyway.
I have an improved version available that is much less difficult that I will continue to improve.
BTW, here is also yet another timelapse
Hikikomori post-mortem
It was an awesome weekend. I am looking forward to play your games, here’s mine:
http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=7374
The good
- Got to know flixel and nanoloop but we’re not best friends quite yet..
- Producing the graphics and sprites was loads of fun!
- Participated and “finished”!
The bad
- Game design; didn’t decide on the game mechanics upfront
- Music; need much more practice in this area
The ugly
- Level design, gameplay; since there is only one level and it’s kind of introductory, I don’t know if it even qualifies as a game…
p.s.: the cat didn’t make it.

First LD
I (kinda) finished a small game for my first Ludum Dare. Although it lacks a lot (like music, sound, variation and nice graphics) it was really fun to make this game!
Play my game here: The Wizard Who Stumbled.
I used FlashDevelop, AS3, FlashPunk, Pro Motion and Photoshop Elements. I’m definitively going to try the next LD.
Post n-tm: Courage Quest
I’m getting this down before I forget everything.
I had the explicit goal of doing a content-driven platformer, since I hadn’t gone for that before and it sounded like fun. I hedged this bet by doing a substantial amount of framework building to get the platforming going and to have a rough-and-ready in-game editor. Even so, it was an enormous crunch to complete this game.
Concept
I currently use a model for game design based around language; every game is described as an expressive medium in its own right, with a specific vocabulary and forms of sentence construction. The content of the game suggests possible sentences, compelling the player to engage in conversation as their vocabulary affords. It’s the most successful model I’ve used yet and lends itself to any genre without getting mired in worship of a specific mechanic, conventional structure, or balancing.
For this game I went off to Wikipedia and looked up “Loneliness,” and found a reference to rites of passage. This was a promising avenue since it let me work with concrete elements instead of the metaphysical. The basic idea took shape pretty quickly – some tribal warrior type of character doing various outrageous tasks to prove himself – inventory and a task list were the main elements introduced at this stage. I also included a time limit as a way to cap off the concept with a finite structure, although looking back at it I don’t think that was necessary. The day-night cycle added some extra flair to the graphics, but the details involved in being able to lose the game were a chore and don’t add much to the experience other than to pad out playtime.
Day 1 (6:00 PM-12:00 AM PST, Dec 16th)
I fixed some things in the framework early on and started on a prototype scene, developing my concepts in a text file. The day concluded with bits of graphics work to get my player and some tiles started.
The palette I used for this game is one I had made some weeks ago. It is developed from a very color-theory informed basis, using the wheel to build a heavily coordinated set of hues with a saturate-desaturate alternation through the values, and I credit it for 90% of the look of the game. As I get better at game development as a whole I increasingly recognize that fundamentals are the key to all the involved skills – if you get a better understanding of color and shape, you get better not just at illustration or pixel art, but at graphic design, typography, architecture, etc. Similarly: rhythm can affect speech, music, athletics; and writing tends to tie together most skills in doing this sort of self-reflection. (Coding can be reflective writing, too, if you stop being scared of it.)
Day 2 (12:01 AM-12:00 PM PST, Dec 17th)
Early in the morning I did the bulk of work on backgrounds. Although my framework has both scrolling and flipscreen modes, I chose flipscreen for this game specifically because it let me use a more detailed approach to backgrounds in each scene with less reconciliation at the borders. It also lends itself to better performance which is always a boost.
The waterfall came in at this point; the waterfall is both one of the coolest elements and also the most expensive. I told myself, “wouldn’t it be awesome if the first thing the player did was jump off a cliff and dive into a raging waterfall?” Although I had Pro Motion if I wanted a traditional colorcycle setup, Flash doesn’t support palettized color cycling natively, so I had to come up with a technique to emulate those effects on the spot – and I had never tried doing cycling anims before, although I had studied some of the most ambitious color cycle anims in the world earlier this month. I resorted to four copies of the background and did the rotation by hand, alpha fading one over the next and then swapping. A linear fade gave nasty looking results, but I found a way to overcome the artifact: first I squared the tween value, and then I tuned it some more with a specific exponent factor(my final value was 1.8).
I added in the day-night cycle soon after I had the waterfall in place. I figured that a color shift over the tilemap would look good and would help characterize the backgrounds, even if they didn’t change at all. As it turns out, it was not hard to set up a table with one entry for each hour of the day in game time(the game runs 6 AM to 8 PM – 14 hours game time, 15 minutes real time) and tween a Flash ColorTransform’s multiplier values. Between that, the auto-tiling sets I had made yesterday(this framework has nifty autotiling algorithms – I see room for improvement on more arbitrary uses of tiles though, like what I did on the trees), and the backgrounds, the look was feeling pretty well established. I still had plenty of sprites to work on, though, and the map needed filling out.
As the day drew to a close, I had the task list working, the timer, opening screen, and win/lose working, some sound, and one proof of tasks(pearl diving). I even got the environmental sounds working, which the game massively benefited from. In testing these things the in-game console was a huge help; you lose a lot of iteration time if you have to actually play the game to do anything. The final game has tons of leftover debug commands to tune the colortransform, set time of day, and set task completion, in addition to the map and graphics editing. So much happened all crammed into the later hours of this day that I’ve already forgotten a lot about it.
The last thing I did before I slept was the music. I don’t really like the end result – it starts off with an oppressive, John Carpenter Escape From New York feel, moves to a more contrapunctal style, and then finishes with simple repeated chords and arpeggios. All of those styles have merits; none of them exactly fit the game, in my opinion. However, I did not get a second chance. Ship it!
Day 3 (12:01 AM-6:00 PM PST, Dec 18th)
As on the previous day, I started in with graphics, and had most of my sprites done before my morning walk. One thing I found myself doing a lot, both on the previous day and this one, was to go back and polish completely random things. I did not restrain myself when this happened, figuring that if I had the motivation, I might as well follow through on it. In the timelapse you can see that I did a major revision on the opening screen, for example. The main character also went through four revisions – single color(too low-fi), outline color(too naked), and two revisions of clothing(too neon and then the final, which more-or-less hits my target of reading the outline first, and then the details).
Of course, what really loomed over my head was the completion of the rest of the gameplay. I switched back and forth between the various things to do – making sprites, integrating them as entities, map editing – until I finally hit the point where I really needed to start on more mechanics. If I remember correctly I did the dragon first, then the orange, some of the bird, then the lanterns, the rest of the bird, and then the pickaxe and gem.
The dragon was a scary problem to solve. Any time the character controller changes there’s a potential for massive bugs; fortunately I had had a bit of practice on it from doing the diving mechanics yesterday, in which the controller changes as soon as you touch(or emerge from) water. Those turned out to be more streamlined than I expected, with no actual swimming going on, and the same proved true with the dragon. I knew going in that I would place some entities and make a tweening path for the dragon’s flight to follow. Lack of planning meant that the path steered around the win/lose rooms, which is why the dragon flies up a cliff. After some work I had the player tweening along, and the dragon sprite following. But then the question was what kind of control the player had and how it was integrated; I realized it would be easiest to just add a y value on top of the basic tween y, and move the tween path down to the lowest level in the flight areas. The control turned out stiff but serviceable, and some patching up later, the dragon flight was done. I could have tuned that control to have more acceleration in it…oh well.
The orange was a straightforward addition to the dragon, and the basics of the bird were too – I already had projectile throwing from the framework demo and just adapted that to have a stone and use the inventory system(instead of a bow and arrow, an earlier concept that would have taken more effort). Around this time I finally got all the inventory working. I waited on finishing the bird in favor of the lanterns, though.
The lanterns were simple enough – touch and change animation, do a test to see if all are hit(the framework lets you iterate over tagged entities so this test can be done in a very reliable fashion). They caused a performance issue in that each one has animation callbacks every frame, though. In the final hours I somewhat optimized this so that they weren’t rendering offscreen, at least, but didn’t do anything about the callbacks themselves, which I suspect added a substantial load.
At this point I could see the finish line. I did some environmental sounds, the credits scroll, revised some sprites, got the bird’s flight in, did some more layout work, and finished the pickaxe section(which was again, pretty straightforward – I started from “projectile” behavior and adapted it to be more melee-like – it would have looked nicer following the player but I wasn’t about to care by then).
And….that was pretty much it. I finished with about 1 hour 30 minutes left on the clock, plenty of time to do my uploading and start the submission and documentation process. Later I got some feedback that indicated lack of clarity with dragon controls, so I added up arrow to it(instead of just jump); the LD website was (as usual) blowing up, so the change squeaked into the submission period.
What Went Wrong
Map editing was a bit slower than it could have been – more tool dev needed. Level layout suffered a bit because of this.
Performance got a bit impacted by the end; tuning the framework to let me optimize around flipscreening rules(e.g. making actors disappear when out of the room, putting the anim callbacks on the actors instead of a platforming controller) would help matters.
Some of the later aspects ended up less polished than I wanted as a result of time pressure.
The music wasn’t anything like what I wanted.
Some of the art techniques I used I was unfamiliar with; I could get faster/better at them.
What Went Right
Map iteration was great because it was all in-game.
The console, the console, the console. If you want to debug gameplay quickly, you need one.
The code did not degenerate into an unmaintainable mess, no siree. A lot of this stuff is reusable – and some of it I actually went and reintegrated into the framework base during the jam!
I finished all of that content!
The combination of the palette, the animation, and the environmental sounds really came together.
HaXe and NME were troopers, as expected. My personal stack for HaXe work is probably going to include NME more in the future(instead of my own hand-rolled build system), although I haven’t yet found a way to include SWF libraries seamlessly as in my own builds. Technology is never perfect…
Finally…
Although it was a really tiring, stressful endeavor to do this, I’m struck by the result. I find myself wanting to return to the little world I made. Maybe elaborate on it with a sequel, even. Maybe that’s why people get stuck so much on pixel platformers – for the amount of effort, you can fabricate concepts pretty quickly, especially if you have nice tools to work with.
As always, I credit maintenance of a sound lifestyle for keeping me healthy and sane during the compo. Getting out of the house, getting enough sleep. Taking my vitamins, balanced meals with a side of vinegar. Caffeine in moderation. If I’m going to party, it’ll be around other people, not just sitting in front of the screen. And even doing all that, I’m still exhausted by this, psychologically speaking.
First Ludum Dare… first post mortem.
Hello there!
Submitted yesterday my entry for the compo and you can find it HERE (and rate it, if you wish). It’s called Do NOT Hug Me! and it’s some kind of action/beat ‘em up. This is like the third game ever developed by me and I’m pretty satisfied with the result (and by the overall experience). Unfortunately I did not manage to make a timelapse video, but next time I’m sure I will.
SO.. moving on to analyze what went wrong and what went right.
What went wrong -
- I did not have a clear idea for the gameplay and the mechanics when I started, so I wasted a lot of time changing on the fly.
- The game is pretty short and a bit exploitable.
- The animations are bugged.
- Menu and interface are poor; also the game is not explained very well.
- Learning a tool you never used before during the 48 hours is not a good idea (although that wasn’t a problem).
- Bad time management. “Wasted” a lot of time testing.
- Couldn’t sleep for too much caffeine and excitement (on that I think the caffeine was guilty).
- I finished the game.
- The game is fun (IMHO) and quite original.
- It’s web based so potentially playable by everyone.
- I had a lot of fun.
- Graphics are not so bad.
- Learned a lot.
Post-mortem & Timelapse

I feel like i’ve experienced the exact same scenario as my LD20 :
I started late, trying not to aim too high, but still wanting to add some fancy stuff like XP, ending up at -5 minutes without any thought on level designing.
What went right :
- I haven’t been stucked by any coding issue
- It’s not as ugly as i thought it would be
- I made a batman costume !
- I spent too much time implementing XP, thinking about level scaling, how you would xp… Next time, no leveling
- Consequence of previous point is that i didn’t spent any time on the levels, and that’s what a game usually is, good level design
- Shipping with bugs, i think i stupidly broke my score counter in the last 10minutes, also the level up window is buggy
- No sound
I think i would have finished it with one more day but that would still be an unfunny game based on XP instead of cool mechanics. I’ll try to shape it into something playable in the future.
Let me share my admiration for “Step Off” by intmain, which has basically the same *concept* but is waaaay more fun, cool feeling and awesome graphics.
You can try mine here.
The timelapse:
My thoughts after some sleep (post mortem)
After a hectic last hours and far to few hours to sleep before work today I have gathered my thoughts on the weekends happenings. The first thing I’d like to point out is that I’m EXTREMELY happy that Ludum Dare exists. No other event has been able to push my limits so far that LD does. I’m no pro-developer, but I really feel that I’m getting better, and LD manage to show me my true capbilities.
Good stuff:
I set out to create a survival-exploring game with some type of craft system. I always set high value in good graphics (wish often is a bit of a problem) and when I looked at my sketches I felt confident in the game-idea. My abilities to succeed is a different story. It felt like too much in too little time (like always), but I went with it anyways. And I actually managed to make the whole game! I only had to cut out the tool-system I was aiming for at the beginning. I had too choose between tool-system and content, and the content was lacking as it was. I made the right choice.
Bad stuff:
I let my fiancée alpha test the game, and she thought that you died to easy. I told her that it was because she needed to play it a couple of times before she learned the right tactics. I should have listened to her. Players don’t want to stress when they play a explore-crafting game. The challenge is in learning the game, not learning how to survive. AND the lack of tutorial was a downer. I could have explained the game in a simple tutor-screen, but I didn’t, next time… I should!
Thank you all for a great LD and I hope to see you all next time!
Correcting some bugs !
Monday, December 19th, 2011 8:10 amDungeon Crawler (Post Mortem)
“A Tale of Seven Kittens”
- What went right
1. Time Management
I made pretty much what I set out to make. I know how to manage my time and I know how quickly I work, so set my sights right on the limits of what I knew I could achieve in 48 hours. The game was completed about two hours before the deadline, which left me a bit of time for play-testing and tweaking the pace/balance of it.
In past projects my time has broken down like this: 40% graphics / 25% programming / 20% design & notebook / 10% testing / 5% sound. I think for LD22 the times I spent on graphics and programming were switched.
2. Choice of tools
I used what I was most familiar/skilled with. When deadlines are tight, one should aim to minimize risk by not introducing unknown variables.
3. I saved my energy
I didn’t bother with the warmup, nor did I do any material preparation.
4. Sleep and Food
I worked from about 11am to 1am, taking a 15 minute break every couple of hours, and a longer break for meals. I had slightly less sleep than I normally do, but still comfortably enough.
I made a big pot of борщ (borscht) and baked some черный хлеб (black bread) before the competition started, and this kept me going all weekend. There’s nothing like a bowl of traditional Russian soup to prepare one for a day of hard work.
- What went wrong:
1. 3D Models
I initially intended to make some chunky 3D models for the monsters, but I realised at the end of day one that I wasn’t going to have time to do that, so I opted for flat sprites the same as the collectable objects.
2. Procedural Generation
It works fine, but due to an oversight it wasn’t quite how I wanted it.
3. Room Levels
Some rooms are higher level than others, containing difficult monsters and higher level loot. I wanted some way of indicating what level a room was, either with text above the monsters heads, or text for each room. In the end I opted for room colours which go from cyan->green->yellow->red->blue as difficulty increases. This maybe isn’t as helpful as a number. Room colours were initial random.
4. Particle System
An optional component was a particle system. I didn’t consider this to be important, and as such thought I would add it at the end if I had spare time. I didn’t have that time.
Overall, I am satisfied with the game I’ve made, and I may spend some time improving it over the coming weeks.
Timelapse and Post Mortem
Here is my timelapse video. I forgot to record the webcam stream this time.
I was not inspired by the theme and did nothing other than a few sketches of some of the ideas I had. None were particularly motivating. I ended up just playing other games instead. I started work on this game when I got up on Sunday, about 12 hours before the competition deadline.
I decided on a simple Castlevania style platformer.
Happy with the art, though I would like to redo the character animations. Gimp is not great for animating.
I ran out of time. The gameplay was added within the final hour, and the terrible sound effects in the last five minutes.

















