Posts Tagged ‘Post’

Ancient Adventure Post Mortem and Time lapse

Posted by (twitter: @GaTechGrad)
Friday, September 2nd, 2016 1:33 am

This post mortem was originally posted on my site at

I really pushed myself to the limit for this Ludum Dare 36 game development competition. Looking back at the length of time for all of my live streams on YouTube, I calculated that I spent over 22 hours of development time over two days for this event.  Since there is no voting or rankings this time, I felt more encouraged to do my best work since my game will only be played by those who genuinely want to play the game.  The game that I developed is called Ancient Adventure, which has gameplay based on classic adventure style games.

The premise of the game basically came from some of my discussion points on the latest episode of the Knoxville Game Design chat podcast, which I am a frequent contributor.  On that podcast, we discussed Anodyne, and I made several points about how they got the classic Zelda formula wrong.  The following is a list of some of the points that I made, and how I implemented those in Ancient Adventure.

A “compass” upgrade showing where the key items are located.

I created a compass item, which I call the all seeing eye which displays on the mini-map the location (in red) of all of the collectible artifacts.  With the mini-map for this game, I tried to make my map more intuitive, by having all of the rooms grayed out initially, and the rooms that the player has visited in a brighter shade of gray.  The player’s current position is highlighted in green.

Keeping with the ancient Egyptian theme, I used the classic eye hieroglyphic.  It’s the eye that is a popular tatoo and similar to the mage symbol in World of Warcraft.  After some research, I found that this is actually called the “Eye of Horus”, which is a symbol of health and protection.  The full myth of Horus can be read on Wikipedia.  Ironically, the Eye of Providence, which is depicted on top of a pyramid and on the back of the United States dollar bill, has nothing to do with Egyptian mythology.  Using this theme made me wonder why there are relatively few games and movies based on Egyptian mythology, since there are numerous games based on Norse and Greek mythology.  The only game that comes to mind is Age of Mythology, which is actually based on a collection of ancient religions.  There seems to be a lot of untapped material in Egyptian mythology which could be made into games.  In the English language, we named our planets based on Roman gods and the days of the weeks based on Norse gods.  The best known reference to Egyptian mythology in our culture is probably the Steve Martin King Tut sketch on Saturday Night Live.  I wonder if Egyptian mythology has been written out of our history because the culture was overly oppressive, using slavery to build pyramids to their gods, which was at odds with the Abrahamic religions (Judaism, Christianity, and Islam).  I will admit that I would have never made a game based on ancient Egyptian culture, if it had not been for the “Ancient Technology” theme for this Ludum Dare.

The point of gathering collectibles.

I used the Egyptian Ankh as the ancient artifact that must be collected to become the supreme being.  It is a quick and simple objective and story, but it is at least something that gives a little exposition of the game.  I just had in my mind one of the typical gods from Egyptian mythology, who has the head of a dog-like creature and the body of the human.  Since there were many Egyptian gods, collecting these artifacts would turn you into the “supreme being”.  It’s not a very noble objective, but I think it’s something players can wrap their heads around, since many ancient myths are about gods fighting each other to become the strongest and most powerful.  Again, after some research about the ankh, I learned that it is actually a symbol of life.  So if I had it to do over again, I probably would have made the ankh the symbol used for the health meter (i.e. “hearts” in Zelda) and made the collectible something different.  In this game, the health meter is represented by a bird creature (at least that’s what I intended it to look like) which was used in many Egyptian hieroglyphs.  The important thing was to have a symbol which was symmetric, since I intended to split the icon in half to represent a half unit of health remaining.  Unfortunately, I didn’t have enough time to represent half health units, so I just doubled the number of full health units.  Under the hood, the health value is just an integer anyway.


ancientadventure002I tried to ensure that all of the collectibles were spread evenly across all of the rooms.  The right side of the map is heavy on ancient artifacts.  This is balanced by having the staff upgrade on the left side of the map.  It is possible to gather the artifacts without getting the staff upgrade, but having the upgrade makes completing the game much easier.  Also the all seeing eye item is in the first room to the left, making it an item that should be picked up early in the game to assist with finding the ancient artifacts, which is the primary goal of the game.  I put the all seeing eye in the room to the left, since players of the classic Zelda game are accustomed to starting out left being a dead end.

How to tell if you have collected all of the required items in a level.

Below the health meter, the number of ancient artifacts (ankhs) the player has collected is displayed.  The icons are initially displayed as blacked out, which reinforces to the player that there are eight to collect.  As the items are collected, they are filled with the purplish color that I decided to use for the ancient artifact item.  For the pickup in the game world, I used the same two rotating spotlight effect again, which looked really nice in my game Kitty’s Adventure.

Weapon attack swinging animation.

In classic Zelda fashion, the player starts with no weapon and is defenseless until the player picks up a weapon.  In this game, I decided to make the player’s weapon a staff.

In the early stages of development, I spent more time (about 5 hours) than I had desired on getting the staff swinging, collision detection, and animation working.  I had to decide if I wanted to animate the staff swing in Blender or the Unity Mecanim interface.  I decided to go with Mecanim, and I found that the benefits to be great, because the Mecanim animation also animates the capsule collider and all of the children objects with it.  Since I had a light source added to the end of the staff, the light source moves with the swinging staff, which is a really awesome looking effect!  The major issue that I had with Mecanim was moving back to the idle state after the swinging animation was completed.  I set a Mecanim boolean value to start the swing, but there was no way to set the boolean back to false after the animation completed.  The swing animation would just keep repeating.  After looking at some Unity Mecanim tips, I learned that a Mecanim trigger (different from a collider trigger) could be used instead of a boolean value, which would set the animation state back to idle after the attack animation completed, which solved my repeating swing animation problem.


By default, the staff had a mass value, which would cause enemies to be deflected when it.  It was a nice effect, but it would also push the player back slightly as well.  I made a design decision to set the mass of the staff to zero to eliminate the recoil effect on the player.  I think it may also reduce the possibility enemies getting pushed into the wall.

In Blender, I modeled a simple staff with a gem on top.  There is one upgrade to the staff, which doubles the attack power.  The enemies that normally take two hits to defeat are killed with one strike.  The upgraded staff is a simple texture swap and a change in the color of the light source.  Originally, I had the standard power staff using a green colored gem and green light, and the upgraded staff as a blue gem with blue light.  However, I thought the blue color was too close to green and it didn’t show up very well, so I changed the upgraded staff color to red.

One check that I had to add was to not populate an item that has already been picked up in that room.  For the ancient artifacts, I had to keep a list of the rooms that had collected artifacts.  If the room number is in the collected artifact list, then an artifact item should not be instantiated in that room.  The same goes for the staff pickups.  If the player’s staff collected boolean is true, then don’t instantiate a staff pickup.  If the staff’s power has been upgraded, then don’t instantiate the staff upgrade.

The purpose killing enemies.

In Ancient Adventure, the player is forced to kill all of the enemies in a room to proceed.  Once the enemies are defeated, the doors are lowered which allows the player to proceed.  The number of enemies remaining is determined by taking the child count of the EnemyGroup Unity GameObject.  When the room is setup, enemies are always assigned to the EnemyGroup GameObject by using the SetParent method on the tranform property of the enemy GameObject.  If it is equal to zero, then the method which lowers the doors is called.  One problem that I came across is that this led to the door lowering method being called on every frame after the enemies are defeated, which caused problems with the door sound effect being started on every frame.  To resolve this, I had to create a boolean value which tracked if the door lowering method had been called, so it is only called once when the enemies are defeated.  The door sound effect was created by me flipping the pages of a book over my Blue Yeti microphone, and then lowering the pitch in Audacity.  I was impressed with how much it sounded like a huge slab of rock being lowered into the ground.

When the door is lowered, the Exit GameObjects are accessible.  These are simple GameObjects with cube trigger colliders.  When the player triggers it, then all of the child GameObjects under the Room GameObject are destroyed, and then the GameObjects for the next room are instantiated and parented to the Room GameObject.  The player is moved to the opposite side of the room, to give the illusion of transferring to the adjacent side of the next room.

One problem the Exits originally presented was that the enemies could go through them (because it is a trigger instead of a standard collider).  Since I wanted to keep all of the enemies inside of the room, I added the doors, which had a regular cube collider, which kept the player and enemies inside.  I had to move the exits back one unit outside of the room (determined by the exit row or column), because the player could still trigger the exit when touching door.

Another problem with wall colliders in general was enemies getting stuck in walls.  In my code, I had it so that when an enemy collided with a wall, it would make a 180 rotation on the Y world axis, and then start moving the other way.  However, the enemies were still getting stuck.  After some debugging, I realized that after the enemies did the 180 turn, they were still getting a collide event on the next frame.  Therefore, I had to wait until the OnCollisionExit event was called for the enemy on the wall, before I would accept another OnCollisionEnter event.  There is still a small bug that occurs sometimes, when the enemy collides with a wall, and then immediately turns, placing them in a direction where they can not exit the wall.  The enemy turn behavior is defined in a separate Playmaker FSM, which is independent of the wall collision FSM.  Usually, after a few turns the enemy will eventually be put in a direction so that it can exit the wall.  Again, the chance of an enemy turning during a wall collision at the same time is fairly small to being with, but it is noticeable when it happens, which would lead to players thinking that the game is buggy.  Sometimes it seems like gamers put every tiny glitch (whether it be game breaking or not) under a microscope.

Currency system.

While I was developing the game, I had so many ideas that I eventually had to write the down in a text file, and I ranked them from most important to least important.  The currency system was a fairly low priority, but I was able to add a gem display value and have the enemies sometimes drop gems when they are defeated.  I used the Blender gem generator to make the gem meshes, which turned out a lot better than I expected.  The way the light reflects off of the edges looks almost too perfect.  There are two classes of gems which add 1 (green) or 5 (blue) gems to your total.  The gem dropped is based on the strength of the enemy defeated.  Unfortunately, I didn’t have time to implement a shop or things to buy with your gems, so it is purely there as a score value.  The gems dropping when an enemy is defeated, along with the health drops, also give more of a purpose to killing the enemies.

What could be made better?

There is really no elegant way to do a 2.5D Zelda clone.  If you do a completely overhead view, then you are only seeing the top of the player’s head.  If you do an angled view, then there are issues with things popping in that should be outside the player’s field of view.  There have been many articles written about this, with one solution being an overhead view with all of the items rotated at an angle.  I decided to use the angled camera, and I just use a camera fade when the character enters another room.  With the angled camera, to keep the realism, all of the rooms would need to be instantiated in the player’s field of vision, which would not be very efficient.  Also, it would be presenting the player with more information than they need to see.  The player should only be focused on the current room.  One possible solution may be to create very tall walls around the room, to keep them from seeing outside of the current room, which would keep the realism.  Another option would be some sort of fog around the room, which would prevent the other rooms from being visible.

I defined all of the rooms in text files, which are assigned as text assets.  Walls are 1’s, doors are 2’s, enemies are lowercase letters, and item upgrades are uppercase letters.  Using text files makes creating the levels fairly simple in a text editor.  The file contents are parsed using the string Split function and the resulting strings are looped over and read as character arrays.  Ideally, these text files should use a better format such as XML, but that would increase the size of the level files and the bulkiness of using an XML parser would probably not be beneficial for load times.  Alternatively, the level definitions could be turned into bit strings, since each cell can only have a limited number of values.  However, it would make it much less manageable, since it wouldn’t be editable in a text editor.  The bit string level definition approach would be good for an online version of the game, if the level data was variable and had to be passed between client systems.

Since the character model was created in Blender and the staff swing animation was created with Unity Mecanim, the arm and staff don’t always line up properly during the swing animation.  I could try to resolve this by recreating the character model swing in Mecanim as well, so that the arm properly aligns with the staff.  Trying to animate removable components on a character model has been a problem that I’ve had that I’ve never found a good way to solve.

There really aren’t any Easter eggs in the game, but there were some subtle influences from other media.  On the Game Over screen, the maniacal laugh was a reference to the game over screen from Zelda II: The Adventure of Link.  On the game completed screen, I tried doing my best Val Kilmer Iceman impersonation of his Top Gun “You are still dangerous” line.  Some of the room layouts were obviously influenced by the dungeon designs in the original Legend of Zelda for the 8-bit Nintendo Entertainment System.

Overall, I was satisfied with the game that I developed for the Ludum Dare 36 competition.  Since I have a solid core engine and gameplay, I plan to develop this game further and release the game on various platforms.

Ludum Dare entry

Play at


Posted by (twitter: @avaskoog)
Wednesday, August 31st, 2016 1:34 pm

Post mortem sounds depressing! And wrong—the game just came into being, did it not? c; Here’s something about our two-player explosive hockey game (Pucketeers of Atlantis) post jam, at the very least!

Do begin by having a peek at the game to have an idea of what we’re talking about in the first place!

View post on

Go play here~


What is it?

Let’s begin here and now. The final game we submitted for the jam. Well, you can see above. It’s a two-player game, primarily intended for gamepads, where each controls a team of three characters to battle it out in the rink.

The twist: a periodically exploding puck, and little item boxes that pop up from time to time that can be grabbed in order to be activated when the player is holding the puck (two of these were implemented: one making time go slower for everybody except the current pucketeer, and one making everyone else fall over, both offering a momentarily opportunity to go straight for the goal).

What is it not?

It is perhaps not the best take on the theme, ancient technology. The idea was that the puck and hover boots and items to pick up and some of the characters (robots) were supposed to be ancient relics of long forgotten Atlantis, but that is admittedly a stretch in the first place, and it’s not exactly evident in the game itself, but needs to be spelled out.

What could it have been?

The final game that you now see wasn’t entirely planned as such from the beginning. The original idea was “(J)RPG hockey”, and there were all sorts of wonky ideas floating around, including turn-based elements, strategy, stats and very exaggerated features of all sorts, as well as closeup one on one sequences when dribbling or tackling.

Not much of that stuck around, partially due to time constraints, partially due to reconsiderations of what would be fun to play, but at least the characters still look kind of like those of early Final Fantasy games (no time for proper human modelling, sorry!).

What can it be?

Extended! Brushed up! Packaged. Networked? There are currently some considerations to do a little more work on this game beyond LD, making it more fun, perhaps allowing a third team on the field at the same time, and perhaps even some rudimentary online play.

Who knows? Such projects have a tendency to blow up and not happen, but it’s a fun thought, and there will probably be some experimentation at the very least. We’ll see!



Soulshifter Post-Mortem

Posted by (twitter: @ToastedGames)
Tuesday, April 26th, 2016 11:44 am

(I had to look up what “Post-Mortem” meant because I was so confused at all the blog posts with it in the title. You better be grateful!)

Soulshifter is a game about killing enemies and stealing their forms (sounds morbid, I know). The enemies come in waves out of portals, and you must survive a set amount of waves (based on difficulty) to win. But that’s not all Soulshifter is. Soulshifter is a game about competition, about teamwork, about challenges, and about new experiences.

Me, Erik and Justin worked harder on Soulshifter than on any other game we’ve ever made. I programmed things that I had no clue how to program before we started. Justin made fantastic art in a style he had never tried before we started. Erik learned he was a way better musician than he ever thought he was before we started. We learned that we were a better team than we thought we would be before we started. Soulshifter, and by extension, Ludum Dare did and meant so much more to us than we ever thought it would.

Of course, we didn’t get everything we wanted into the game, but when has anyone ever began a Ludum Dare and finished with everything he wanted originally plus all the things he thought up along the way? We got a game we were happy with in the end, a solid base that could, and will be easily expanded in the future. We got a game that we were proud of, too.

The feedback we’ve gotten has been so wonderful, and everyone  has been so nice. We honestly can’t thank you all enough. Even if you left us a bad score, you will have shown us what we need to improve on next time, and we’re just as grateful to you too. We’ve had so much fun playing other people’s games, also, and it’s just made us feel even stronger that Ludum Dare is a great community of people that we want to meet and compete with every single time it runs.

TL;DR: (What a nasty word, how about this:) To summarize, our time last weekend and the following days after was amazing, we all enjoyed the competition, and all of you, the community. We’re happy with what our game became, and you’ll definitely see us next year. Happy game design,

– Ben, and everyone else at Toasted Games.

Yggshroom – Post Mortem

Posted by (twitter: @ghen92)
Thursday, December 17th, 2015 3:13 pm


so, first time make a post mortem, as my understanding post mortem consist of what i learn and what can i improve, so lets get to it, writing this at 2:45AM!

first thing first, sorry for any grammar mistake :)

Yggshroom is my second LD jam entry, and automatically my second compo entry, if i look back, theres quite lot of improvement that i made from back then, especially on graphical/aesthetical side, and also i learn a lot from my mistake and comment from the game page

i made this game in about 30-ish hours with all the asset, and the longest time i take is for searching the Game Idea, even thought it looks simple and very silly, believe me, i waste lot of time to think about that :))

What i like from the final result :

  1. I like how at the end it well put together, i honesly at first didn’t think that the obstacle, the generator and stuff will work, but in the end they almost complemented each other, adding additional difficulty yet not feeling too gimmicky/artificial
  2. The visual, even tho some of the sprite kinda rough and not fit the majority sprite very well (especially the mushroom) its mostly my mistake to resizing the sprite without consideration and to draw some sprite in 32×32 canvas and most of them in 16×16.
  3. In the end the game end up like i want it to be, it fit what i imagine/planning in my head, and that makes me quite happy

What i dislike from the final result :

  1. I still use music generator, i know its probably not a bad thing, even LD themself encourage to use them, but still, some music just didnt fit very well, its so “bad” that i need to turn the volume very low on the main game, i hope for next LD i can write my own music
  2. I chose the wrong font, not a mjor mistake either, but really bugging, WTH am i thinking when chosing that font in the first place?, my game using pixel art style, why i chose smooth font? *sigh*
    so, the real idea i chose that font is because i want to show/point up the Norse theme, because…well, Yggshroom itself i taken from Yggdrasil Tree which is from norse mythology, so….yeah
  3. The game too short, yup, this one of my problem too, at first i thought that my game got a reasonable lenght for a compo entry, BUT after played some game, i just realize that my game very short and lack of variation, i need to do better next time
  4. lack of variation, theres quite of people complaining about this, and i whole heartedly agree with them.


What i learn from LD34?

well in the end, i was under-prepared, and my game not polish really well, i was too short thinking about the whole idea and slip up the game variation design, and i’m too “overproud” of my work that i’m not using remaining hours to polish the game up.


Theres lot of room i need to explore,learn and re-learn, and hopefully i can “grow up” and make a better game at LD 35 on April (i think…CMIIW 😀 )

so, this is the end of my post-mortem jam, i don’t know if i even do this correctly lol

heres link to my LD34 entry if anyone want to try it : Yggshroom

hope you guys can join on next LD too :)

Post-Jam: Added a fancy health-bar

Tuesday, September 1st, 2015 12:34 pm
We didn't managed it to draw and code a fancy health-bar in time.
After some complaints about that, we decided to make one "Post-Mortem".
here you go:

screenshot new healthbar


If you haven't played our game yet, your can do it here.
We had a lot of fun this Ludum Dare and we hope you also have fun playing our little game.
Feel free to rate and comment, we appreciate your feedback.



Post mortem for Videogame Hero

Posted by
Thursday, September 11th, 2014 3:36 pm

Post mortem for Videogame Hero

Thats the game:


This was my fourth time participating in Ludum Dare, I think it’s the first time I write a Post Mortem.

I really liked the game I’ve made.

It took me like half an hour of thinking to get to my idea for the teme. I was sure I could do everything I wanted in time for the 48 hours compo. I decided to begun what I knew it was going to be harder to do: the Platform section, and then I would move on for the second harder (The racing section), then all the other 3 sections I knew would be easy to do. Then I’d add the hub to connect all the worlds and code the energy bar / energy recovery system (But I’d already “prepare” the worlds I was coding to work with all this). I actually had first thought about changing worlds by pressing F1-F5.. then I though about an animation screen showing your “hero” moving from one world to another, like in a map… and then I thought “Hell, why not make the map a playable part of the game?”, and that’s how I came up with that hub.

Then for the first 3-4 hours, I worked on the basis for the Platform section. And boy, how I’d like to be able to draw. Someone made a nice comment about the graphics for the game, but I must admit, I have absolutely no drawing skills. The main hero in the platform section has just 2 frames of animation, and still it took me like 2 hours to draw its animation properly (If you can call that “proper”).
I finished the base for that world and went to sleep. What I had was the main hero moving and jumping properly, the blocks being generated at random, the arrows being shot at the player the way I wanted (And getting faster as the game goes by – there’s a “global” clock counting the gaming time, so difficulty raises as you keep playing). There were moments when the blocks would appear too far and there was no way to reach any blocks, but I was going to fix that later, as I needed some sleep.
In the next day, I had a big problem at my house that took me around 6-8 hours to solve. This took a lot of development time, and I ended up removing lots of features I wanted to have in the game. I just rushed to code the base of every world, make everything work, and then I’d add features as long as I could before the deadline.

For the base of the game, what really gave some headaches was finding a balance in the platforms spamming so there would be *always* a way to keep moving up without having to fall down. I think I did this very well, but I am not 100% sure there aren’t moments where’s just impossible to keep moving up. Also the racing part, I wanted to have some AI with the CPU cars, they had to be able to make turns and avoid each other, but it was getting so hard to make it work properly that I just added the possibility of they blowing up if they touch each other or the track, and left whatever of the AI I had already coded in there. It was not a bad decision at all IMO. The shmup, DDR and brick-breaker sections gave no problems at all and everything went very smooth there. Then I coded the hub, added the power ups on each section. On each world you need to make a certain amount of points to make the power up to appear. I had alredy written down in a paper a way to make each world energy to be recharged on at least 2 worlds. I then quickly coded the “world travel” screen… I wanted to do something different, I coded a routine in like 2 minutes, and the effect was actually differnt from what I wanted… and way cooler. So I kept it like that.

Then I went to add all features I wanted in each section. Like I said, I had less time for coding than I thought I would have, and I had to cut a lot of stuff. What’s really funny is that I think the game is actually *better* without most of those features, since they would make the game more complicated and less fun to play.

The features I wanted to add and I didn’t:

Platform Section: Bricks that would span spikes from time to time and hurt the player. Springs that would make the player jump higher. Bricks that would appear and dissapear from time to time. (This would make the game harder for no reason)

Racing Section: Cars that would move left and right to make the game harder. (Again, it would just make the game harder for no reason)

Shmup section: A proper boss fight (it would kill the flow of the game)

Brick-Breaker: Power ups like enlarge your paddle or triple balls. (Now those could be nice additions I guess)

Hub section: A random power up that would recharge every world energy (I thought this would be pointless really)

What I *actually* managed to add in the last 4-5 hours.

Platform Section: Moving platforms. (I *really* wanted that, and it was the “later-feature” that took the longer to do, as I had to make them work together with the spamming of normal bricks and not make stuff appear on top of each other and break everything)
Racing Section: Background scenery (They look crap, but make the game more alive)
Brick Breaker and DDR sections: Nice background animations (I actually loved the DDR background animation).

I then wrote a music very quickly on Ejay, added some sound effects for the game, and I spent the last 90 minutes trying to balance how often the power ups appear on each world so the game didn’t turn impossible to soon but also couldn’t be easily played forever. This was really hard to do and I don’t think I did it properly, but giving the development time, I was pretty satisfied with how I managed to do it.

In the last 10-30 minutes for the deadline I saw a bug with the track in the racing gaming “dissapearing” in the bottom of the screen. I had no time to fix that, so I just draw a big green rectangle on that spot on screen and called it a day.

The Platform section ended up being to hard, the player slided too much with inertia, so I fixed that on a pos-compo and the later HTML5 version.

I’d like to balance the way power-ups appear on each level, as its clear some levels are easier to mantain than others, and I know most people avoid the platform level as much as they can, because its harder than all others. This could be fixed, but other than that, I am really satisfied with the game and I personally love to play it.

If you read all this and haven’t played the game, I hope this sparks some curiosity and you go check it out. It’s playable as a Windows EXE and on HTML5 Web Browsers :)

Dreamonaut – Post-mortem

Posted by (twitter: @hbocao)
Friday, August 29th, 2014 9:14 pm

Hello there!

Be careful! Non-native english speaking person. :)

This is my fourth time participating, but still a newbie in game making. Since my second time I was not alone and with each edition, the team grew one member. We discussed after we finished, but this is my personal analysis

This time we made a game that looks like a beat ‘em up and shoot ‘em up crossover gameplay-wise with a simple message. The game is about a girl that fights her problems in her dreams and is called Dreamonaut (check it out and give us some feedback).

The good

Graphics: for the first time we had someone with real talent to do the art. Well, it really paid off. I think the games looks real good. Although it’s the first time of Dyoni making art for games, he did a freaking awesome job. I can’t praise him enough.

Mood: last game we did for LD, we had one sound effect and one very short song loop. This time we spent a good portion of the time to find and record some effects and ended up using different ambient sounds and set of songs. I think we did a good job combining graphics, music and effects to create the right atmosphere for the game.

Planning: last time we planned, but didn’t discuss the game design too deeply at the start and we payed for it at the deadline. Too many rushed decisions. This edition, we planned almost all the game before starting and we keep taking notes and expanding every level and cutscene with dialogs and all. We write it down which sounds would sound cool and all. This helped so much when we needed to cut some things off. Best thing we did, for sure.


The bad [luck]

The spider: Saturday, evening. Fernando, one of the programmers, forgot his toothbrush and went to the nearest mall to buy one. When he got to the car, there was a spider inside, and it got away when he tried to kill it. Goosebumps.

The car crash: While leaving the garage, the door (which closes automatically very quick) scrapped his car roof. :(

The internet is down: the internet went down and we struggle to commit and download the code (we’re using Visual Studio Team Foundation for it). This also prevent us to check some Phaser and Typescript examples.

The Sick: I woke up very sick on Sunday. Freaking sinusitis. It really hit me. I had fever late at evening and needed to go home at 9PM. I didn’t even got to my everyday work on Monday.

The Dead Battery: Monday, 3 AM. The rest of the guys kept working late on Sunday until they decide that some of them could still work on through Monday. When Fernando went to his car, it didn’t started. The battery was dead. Yup, poor guy. They all slept over Filipe’s house and at 7AM, Fernando’s father came in and helped them out.

The ugly

No knowledge: we didn’t even saw line of Typescript code before and just two of us played with Phaser before. This almost ruined us. We lost a huge amount of time finding how to do stuff in Typescript or how things worked in Phaser. Don’t get me wrong, the tools are awesome, but now we understand the value of the warm up weekend.

Gameplay: It is way too simple. We planned to do many things, but we got stuck with problems cited above and, of course, lack of talent/experience. We planned to do different attacks for the main character on each level, powerups to change the game even more, much more enemies with different set of skills, more boss epicness (like the last one would shoot “confusion bullets” that would invert the controls). But we needed to rush to finish it in time. It’s a shame.

PS. Till this day, the spider is nowhere to be found.


Warp Ryder Cup Postmortem and Timelapse

Posted by (twitter: @Mach60KAS)
Tuesday, August 26th, 2014 5:20 pm

4 Ludum Dares down, many more to go! I managed to “finish” my “game” within the 48 hour window this time, and I didn’t stress out anywhere near as much as I have for previous events. I’ll take that as a sign of consistency. As always, I’ve learned so much over the course of this past weekend and I’ve had a great time to boot! Anyhow, shameless plug for my own game here to accompany the obligatory postmortem.


Tools and Software

  • Sublime Text 2 was used for all JavaScript / HTML / JSON / CSS once again. Thankfully, I had enough common sense to not use it for map editing this time around.
  • Adobe Photoshop CS6 was used for all graphics, sprites and tilesets.
  • Tiled was used for map editing and design.
  • PxTone was used to write any audio.
  • Firefox Nightly and Google Chrome for testing.

What Went Right?

  • Experience in programming. Over the course of the past year, I’ve been programming far more regularly – so I’ve noticed myself writing far, far less mistakes and being able to more efficiently debug those I do make. Naturally, this means less time stuck in a rut, moping over the sorry state of my code!
  • Having past code and engine work to refer to. Having past examples makes for a great starting point to start working while you come up with any ideas, and allows you to iterate on the design of any underlying systems. Besides, I always love coming up with better solutions to problems than I could have thought of before!
  • Swapping over to a dedicated level editor. I have no idea how I got by manually editing a CSV list of tiles last year and calling it ‘level design’, but Tiled was a breath of fresh air. The JSON export is probably the single greatest feature I’ve ever used, and the interplay it has with JavaScript is far more intuitive than interpreting XML. Being able to actually draw levels was a godsend as well, I have to say I’m never going back from using Tiled after this.
  • Once again, Canvas and JavaScript were great choices. Apart from differing support between browsers, I love the ability to put up a single version of my game that most people should be able to run. Couple that with JavaScript’s ease of use and you have the perfect game jam toolkit.

What Went Wrong?

  • I kinda lost my drive to work on the game for a while. Unhappy with the state of my game at the time, art and gameplay alike, I lost most of my drive to code for a large portion of Sunday. Had I not done that, I could have implemented a few more features before the deadline (including, you know, scoring). Urgh.
  • Cut features lead to seemingly meaningless design decisions elsewhere. Considering the game features only golf as far as gameplay mechanics are concerned, having to walk around everywhere seems rather stupid. Unfortunately, I didn’t have time to implement any enemies or aliens, or even proper entities so little artifact design choices are littered everywhere.
  • Harsh choice of palette. As much as I enjoy working with limited colour palettes, this time I had an awful lot of trouble coming up with graphics that weren’t trash. Ideally, I should have created far more colourful structures around the map to help create contrast and allow the generally flat blues of the asteroids and walkways to stand out more.
  • Sprite design? Still not my cup of tea.

Stuff I Enjoyed

  • Working with new tools and file formats. Although it took a little while, working with new programs like Tiled was a very interesting experience, and I’m certainly glad to have spent some time working it out! It was fun integrating someone else’s map format into my own engine, I’ll admit.
  • Painting nebulae for backgrounds. Photoshop’s ability to map an image to a given colour table was amazing, and allowed me to go wild with a nice set of brushes on my tablet while still keeping in my 8 colour limit thanks to automatic pattern dithering etc.
  • Writing music, for once. It was kinda meh, but I totally do not regret writing some music for a change. I have enough oddly silent Ludum Dare projects as is.

Thoughts for Next Time

  • Be more positive. I really need to not get too hung up over the current state of my game, knowing full well that additional time and effort will almost always make it better in the end!
  • Pick a colour scheme, but don’t be afraid to deviate. Sometimes, 8 colours can be just a little bit too stifiling.
  • Reel in my ambition. I hate having to cut features as the deadline draws near, but at the same time I still like seeing my original idea transform and evolve as compromises have to be made over the event.
  • Come up with a more ‘fluid’ game idea. I love fast movement and freedom in games, so I want to make something far more unbounded next time.
  • JavaScript forever. Seriously, you can’t make me use your fancy ‘engines’ by this point.
  • Consider time management. Then again, I never really benefit all that much from excessive planning and so on. So this probably wouldn’t be all that good for me.

Again, if you’ve spared the time to read through all this then thank you very much! This is more for myself to crystalise any knowledge I’ve gained for surviving game jams, but it’d be even better if this ends up helping any of you folks out there. Now, get back to rating all those games!


Villager Post-Mortem

Posted by (twitter: @Zazanxors)
Tuesday, April 29th, 2014 9:04 pm

I’d never entered a Game Jam until now, and I”m happy to say it was great! I’ve never had so much fun developing, and never, ever been so productive either! I was slow to start, but towards the end I was rushing due to the time constraint; 529 lines of Javascript, 72 lines of HTML, 151 of CSS for a total of 752 lines of code in 72 hours. May not be too much to some, but for me, that’s a huge record!


Despite only hearing of the jam 9 hours before it began, I got a pretty good start! I got stuck for an idea for a while, just barely managing to get one before Saturday, and prepare a basic template with which to build the game on.

After that, the rest of the next day was spent preparing the first few features. Getting the actual text input done was actually one of the easiest parts, since I was re-using code I’d developed recently in another unreleased game of mine with the same thing. After that, I ran into another design halt as I tried to figure out what I’d do for the left side of the screen, such as whether I’d use buttons or pure text input. Once I got over that (took about an hour alone) I added the first four resources, the day system and the first few commands.

Results of Saturday

Results of Saturday

Sunday started off pretty good – I had a decent plan going; finish off the game’s features, then work on story and polish tomorrow. As for finishing the features, I didn’t end up managing that, though I did get most of it.

Throughout Sunday, I managed to add village professions to help automatically generate resources and take some of the difficulty off, added a little ‘exhaustion’ mechanic to prevent gather-spamming, add the ‘time’ command and put in the resource stats, all the while attempting to tackle a strange bug thought I fixed that I still don’t understand.

Sunday's outcome.

Sunday’s outcome.

Monday was definitely hectic. I spent the better portion of the day implementing upgrades – something I hadn’t originally planned on adding at all – and then another half hour to slowly find out why this suddenly didn’t work, to find variables I forgot to change when I refactored some code earlier.

After finishing upgrades, and spending even more time on adding more info for the professions, I finally got to work on the story and add a win condition with 3 hours left til’ the Jam ended. After some quick designing, I ended up deciding to change the story from it’s original direction. I first had decided the end would involve you finding the villagers to actually be cultists, and to run away after discovering one of the terrible rituals they held, but instead settled on something subtler, although the ending ended up no less sudden.

Three hours remaining.

Three hours remaining.

After rushing to fix a few bugs that were discovered with the ending and add a Favicon, the game was submitted and complete.

I’m actually really surprised with the outcome of the game, and very happy I managed to complete so much of the original idea – and then a little more! Better yet was seeing the first few comments on the game, which were surprisingly positive! I ran into a bump with hosting, but this was easily resolved by putting a mirror up on Google Drive.

Things that went well

  • Keeping the idea to something I could handle – This was stretched a little bit, with me barely finished before time was up, but I nonetheless managed to keep the plans to just the right size for me to get everything done and still put out something good.
  • The chosen language – I picked HTML5 because I’ve got some pretty good and recent experience with it, having worked on two incremental games before this, so I was able to get to the game quickly and easily.
  • The outcome – I am very pleased with what I managed. I never thought I’d be able to pull this off in 72 hours.
  • Getting sleep, eating well and going outside – I actually took more walks outside than I usually did, and took regular breaks to get away from it, kept fed and got plenty of sleep each night, which I think played a good part in making the end result what it is.

Things that didn’t go so good

  • Planning – I didn’t really get too much of a chance to do it very much, what with having only 9 hours of awareness that the Ludum Dare was even going on – a lot of which was spent wondering if I’d even join.
  • The story – What with it being more last-minute, I wasn’t able to flesh it out as much as I would’ve liked.

Suffice to say I’ve had a whale of a time doing this, and am ecstatic I decided to join. I’ll most definitely be here in August to do it all again!

Villager can also be found here, if you’d like to play it:

LD27 Postmortem: Game of Throttles

Posted by
Thursday, August 29th, 2013 2:47 pm


Well, our first Ludum Dare Jam is behind us now, and even though it didn’t quite work out we still managed to gobble together something (almost) playable, or hopefully atleast enjoyable.

I was really disappointed that I couldn’t make the physics work and so I upgraded the game to use Box2D (my second venture into Box2D programming, first was yesterday!) and guess what; it makes things almost too easy! Here is the link to a (windows) build that is much closer to the vision we had in mind when we set out to make this game. Hopefully we can take the things we learned and apply them in Ludum Dares to come!

What went right:

  • The story. We came up with something that fit with the theme and was at the same time quite enjoyable.
  • We knew our tools. No extra time was spent learning our tools. It might’ve been useful to grap Box2D earlier though when things started looking pretty grim regarding the gameplay…
  • We managed to make something, even though it wasn’t anything special!
  • The art got a lot of praise in the comments so I guess that went alright.

What went left… I mean wrong:

  • Scheduling. I left the collision code for the last day along with polishing and minor additions, bad choice since I hadn’t really done any complex / physically (somewhat) accurate collisions before. Maybe I also overestimated my capabilities.
  • Planning. Especially the gameplay should’ve been planned more thoroughly, and we should’ve tested the basic gameplay ideas more to see if it would be any fun.
  • Testing. While writing this post a friend of mine spotted a bug in the intro / outro. Just because I have seen the intro working many times already doesn’t mean it won’t break when the code is altered.

Ludum Dare 27 Post-Mortem

Posted by (twitter: @@BendotK)
Tuesday, August 27th, 2013 1:00 pm

I just finished writing my post-mortem about Wappansai!, my first Ludum Dare entry ever,  at my blog here:

Thanks to everyone for the amazing experience, this was awesome and I’m definitely going to do it again!


Post Mortem – The Ten Ten Seconders

Posted by (twitter: @r_tapeloaderror)
Tuesday, August 27th, 2013 6:37 am

So, my second LD resulted in my first entry. Not bad.

What went right

Personally, I liked the theme. I’m always one to take it more as a game mechanic, so this one was pretty clear while offering a fair number of choices.

I had the game done after the first day. This gave me the second 24 hours to polish, draw, compose and add new features. I spent several hours obsessively tweaking numbers until I could win about 50% of the time, which seemed fair.

What went wrong

After tweaking for hours the girlfriend and I cooked dinner, watched a movie, and killed a bottle of wine. That in itself is not wrong, not at all. I thoroughly recommend it. However, it sort of put the idea of “The game’s done, I could add some graphics and music but would I be really happy with them and there’s another bottle of wine in the fridge oh stuff it let’s just relax” into my head. I need to be more committed. ^__^

Also, despite basing my entry on the engine code for my previous attempt, there was still a fair chunk of tech to write. I mean, if I knew I was going to do a shooter no matter what the theme, I should have written a weapon class ready, right?

I picked a stupid size for the screen (1280×720). Next time, I check it on my laptop before submitting.

Lastly, the browser variance got me. I developed in Chrome, one of the more forgiving browsers, but when my first comment was “It freezes in Safari 6 on a Mac” I thought I’d better check it out. Horrifyingly it ran in NO other browsers (except Opera, which uses the same V8 JS engine as Chrome). Hurriedly researching and fixing a combination of transform, keyboard and audio problems got it running reasonably in all browsers except Safari, in which it still runs at 3-4 FPS instead of the 60 FPS of everything else. Post-compo (and therefore not in the entry version) I’ve played around with different methods but nothing has helped Safari. I also don’t have a Mac, so I’m limited to version 5.1.7 (the latest version on Windows) which doesn’t implement requestAnimationFrame, which is the recommended fix for buffered frames – although that’s not the whole problem. >__<

Still, I'm pretty happy all told. Javascript seems to have stayed in my head despite neglecting it for eight months, and the game itself is pretty fun. If you like bullet hell shooters, you can play it on the web right here, please let me know what you think!

Aaand see you all in four months. 😉

Demon Infiltration – LD27 Post Mortem

Posted by (twitter: @zekyonD)
Monday, August 26th, 2013 10:52 am


Play here

This was my third LD and I can say that has been the best.
Why? because I think I had create a good game in less than 48 hours, but even so, I’m not happy with the fact that I made it using Game Maker. Ok, the use of Game Maker isn’t anything bad, don’t get me wrong, but I was learning java and libgdx since three-four month ago and I wanted to check my knowledge in this LD.

Why I didn’t use libgdx then?, I had not time, this was a weekend very evenful and the priority was create a good game.

Well, here is my Post Mortem:


What went good?:

  • Graphics and gameplay since the first day

The gameplay was very easy to program, only a basic platformer with an stealth system, basically if the enemy is looking right and the player is near of his right, he kill the player instantly.
And the graphics palette is of 6-7 colours in total, what made more easy the process of design.

  • I’m learning a lot about GML functions

This was my second time using Game Maker and I was a bit lost. Even so I kept forward and I learned a lot about it


What went bad?:

  • Bugs, a lots of bugs

I thought that my game had less quantity of bugs, but no, it had a lot, so I spent all the day of today fixing it.
I think now the game works properly, however, it surely has some bugs waiting to be fixed, so if you find one, please let me know.

  • Few levels

As I say before, I had not enough time for dedicate to the ludum (only the nights) so the levels was reduced in number, only three of six planned in the start.

  • In my opinion, bad theme

Seriously, what kind of theme is 10 seconds? I hate be a hater (excuse the repetition), but was one of the worst themes in the votation, “Death is useful” or “You must leave it behind” would have been a lot better.
10 seconds is nearly to obligate to create a game that hurries you and I hate that type of games :/.
At least have been better than “minimalism” ¬¬

  • My english level is ridiculous

Yes, and because it I commit some typos on the game. I would apologize to all the people who is leaving their eyes on this text. Seriously, sorry.

Thanks for read!


Postin’ my mortem (and timelapse)

Posted by (twitter: @piece_o_ham)
Tuesday, April 30th, 2013 9:09 am

The MinimizeArt entry page is here.
Ludum dare started for me at LD23 – Tiny world. From then until now, I have learned a lot and my games have improved. For one, I was actually proud of what I had made and my game was actually kind of fun. Before I continue, let me show you a timelapse.


Although my game was better this time around, not everything went perfectly.

What didn’t go so well
Messing around – I spent a great deal of time just sitting there, looking at what I had done. I would get something done, and I would just keep looking at it instead of coding.

Important things last – I didn’t do things in the right order, I ran out of time to make more levels (which is mostly the fault of #1). I should have added sound sooner in, made more levels, etc. Then the other stuff would have been a breeze.

What went well
Code – In the past my code was really sloppy. I just did whatever worked. But this time I stopped to think about my code. The end result was much nicer.

Lighting – This was actually the first game I’ve made with lighting, so it’s kind of a good thing.

Game was hard and fun – In the past, my game were about as fun as coding a Graphics driver in Assembly, and they were never hard either. But this time I actually enjoyed playing it.

So that is how my Ludum Dare went.

Mini Postmortem of “You are, A Shadow”

Posted by
Tuesday, April 30th, 2013 8:53 am

Thought I should write a small post that will help people understand the theme/logic of my #LD48 entry

The game by itself is intentionally not self-explanatory.
I see couple of people getting back to me trying to reason about some design “suggestions” :) … some were really good, and then some made me feel that people are thinking in a quite different direction / not thinking at all.

So here’s what I’ll do mysteriously help all confused gamers :)

Explaining some design with FAQs.

Q1. The game doesn’t have much controls and is confusing.

Did I forget to mention tough choices? No I didn't.

Did I forget to mention tough choices?
No I didn’t.

A1. Meant to be so. The theme was “minimalism”
When I thought of the game design, I thought of vagueness and scope for making people think when they play the game. Everything converges when scores are shown.
Yes, I could have made a big 5 stage coin collecting platformer, but that’ll be out of theme and nothing new to experiment.


Q2. I did not select the Red Girl but I still got % on perverted scores

It's not wrong to be attracted to sexy dressed girls, now is it?

It’s not wrong to be attracted to sexy dressed girls, now is it?

A2. Those are just one of the places where I want people to think. On a second thought, you should be thinking all throughout the game.
I was kinda serious when I wrote this in game description.
“You are supposed to make “choices”, which sometimes are difficult than a “RedPill vs BluePill” question in real life! ”

So here’s my question to you, WHY do you think choosing the red dress girl would mark you as a pervert, but the purple dressed girl will not?
What is wrong you are attracted to skinner/sexily dressed girls? Is it really wrong?  It’s a choice and a personal preference IMHO.
The girl in red dress could be a very kind and good human, while the girl in purple dress could be shady. Who knows?

These are not meaningless messages friend.

These are not meaningless messages friend.

The other problem here is people are trying to “assume” some stuff about the algorithm behind it but are fixing their thoughts to a linear assumption.
The algo is complex.. it considers stuff from real world.  What could be an act of kindness in a particular level, will be a goofy choice in another.

So “Think”.


Q3. The sounds are too loud
A3.  Yeah I’m terribly sorry about that. My bad.
Laptop speakers aren’t that great.. although I  tested my sounds at 100% volume while mixing.. I still hear less :)
Point noted and will remember that for my next game. Thank you :)


Q4. Any tips on how to play the game?  In other words how do I fake it to make scores look clean.

What game?

What game?

A4. I am not going to tip anyone on how to fake it :) , but yes I can help to reach a point where you can make ‘clearer’ decision on whether to fake it or stick real.
Here’s my mysterious way of helping you guys.. remember 3 things while playing the game
1. Watch the level “name”
2. Level ‘name’ is a ‘situation’/’time’.
Evaluate the both choices along with the level name.  It’s not just about choice1 vs choice 2 .. its choice 1 vs choice2 vs levelname.
3. Think a lot.. get real life decisions as examples to help yourself . :)

I’d be happy to answer any other queries you might have.
Please leave your valued suggestions in comments :)

For now, I’m gonna go and play games of other participants and earn some more knowledge.
Signing out.

Wait for me guys!

Posted by (twitter: @IvanDonat)
Thursday, April 25th, 2013 12:35 am

This is going to be my first Ludum Dare.

Software (for the game):

  • Unity
  • Paint.NET
  • Gimp
  • Blender
  • Audacity (+ mic)

Software (for streaming and timelapses):

  • Open Broadcaster Software
  • Chronolapse


Wish me luck 😀

[cache: storing page]