Category Archives: Postmortem

Ludum Dare 29 – In the Black – Post Mortem

Background I had the distinct joy of participating in Ludum Dare 29 this past weekend! It was my 6th year doing so and I had a really great experience. The theme was Beneath the Surface and I made a game called In the Black–which ended up being very different from the kind of games I’ve made […] Continue reading

Posted in banjo, games, ld29, Ludumdare, Postmortem | Comments Off

AVOIDAL Post Mortem

Play AVOIDAL Gameplay Trailer (watch me score 1.5 million points!) Watch my TIMELAPSE Play the LD48 Official Compo Version of AVOIDAL Play the Original LD48 Compo Version I had a lot of fun this Ludum Dare! After missing the past few it was good to participate again for sure. I’ve never done one of these [...] Continue reading

Posted in actionscript, as3, avoidal, competition, Flash, gameplay, games, ld18, ld48, Ludumdare, Postmortem, prototype, timelapse, trailer | Comments Off

Postmortem: Pfff (LD12)

This postmortem covers my experience with the 12th Ludum Dare 48 hour game competiton, which took place on the weekend of August 8-10 2008.

Final post

Timelog

 

Summary

The Tower came out as the result of the 2nd round of theme-voting. A somewhat less abstract theme than the last couple of times. Not necesarilly bad, but I do usually prefer the abstract themes.

My initial idea was to let the player use a grappling hook-thing to climb a tower. However, the physics of this gameplay urned out to be too much of a headache to get working as intended. Which was demotivating, seeing as I didn't come up with any alternative/better ideas.

So after struggling with implementation problems of the physics, I decided to simply ditch the whole thing; idea and all. Luckily this was still early in the competition, so this decision was not going to have as big of an impact as continuing struggling would have had. However, being left with nothing re-usable, I had to get inspired and get an idea quickly. A short walk did it for me. Because it was windy, I got the idea of pushing crates off the rooftop of a tower/skyscraper by controlling/drawing the wind.

I decided to run with that. Good thing I did too, considering that the wind gameplay was surprisingly easy to implement. As a result of this decision I had the main game mechanic completed mid-day 1.

 

 

What went right

Ditching idea that went bad

I'm pretty certain that I saved my spot in the list of entrants because of my choice to ditch the first idea i went with. I think I would have wasted an entire day+ simply on tweaking physics variables.

Controls

The mouse controls came out very intuitive, and made the toy easy and fun to use.

Toy

Supported by intuitive controls, and combined with proper rigid physics, the wind mechanic just worked.

Sounds

All sounds in the game were created by me simply blowing into my microphone, and they just sounded right in first go. Who knew wind sounds could be made so easily.

 

What went wrong

Requirements

I almost don't want to include this again, seeing as it's always in this list. But as usual, this competition is not suited for heavy use of Microsoftian technologies.

Presentation of concept

After completing, it has become apparent to me that the concept of the game did not come out very clearly. Which means I could/should have presented it better.

My intention was to let the player use the wind-toy to explore the content and while doing so discovering achievements. But since there were no "prizes" for discovering/completing these, it did not come through very clearly that this was the whole idea of the game. Also, I implemented these achievements way too late in the process (end-day 2) and as a result i ended up with a minimal amount of them. There simply had to be more to support the concept.

Sleeping

When day 1 was coming to an end I decided that I didn't want to stay up too late. I thought i'd rather go to sleep early, and be fresh and lucid the following day, than staying up pushing code.

My plan didn't go too well, though. I was literally twisting and turning for a good couple of hours before finally passing out. My mind was simply not able to turn off because I didn't relax, by watching tv or whatever, prior to hitting the sack. Made me a bit cranky the following day.

 

 

 

Conclusion

I'm quite satisfied with my work this time around. Sure there's a bunch of stuff I could have done better. But let's face it, there always is. I had fun. I got stuff done. What more can you want?

 
Continue reading

Posted in Postmortem | Comments Off

Postmortem: Pfff (LD12)

This postmortem covers my experience with the 12th Ludum Dare 48 hour game competiton, which took place on the weekend of August 8-10 2008.

Final post

Timelog

 

Summary

The Tower came out as the result of the 2nd round of theme-voting. A somewhat less abstract theme than the last couple of times. Not necesarilly bad, but I do usually prefer the abstract themes.

My initial idea was to let the player use a grappling hook-thing to climb a tower. However, the physics of this gameplay urned out to be too much of a headache to get working as intended. Which was demotivating, seeing as I didn't come up with any alternative/better ideas.

So after struggling with implementation problems of the physics, I decided to simply ditch the whole thing; idea and all. Luckily this was still early in the competition, so this decision was not going to have as big of an impact as continuing struggling would have had. However, being left with nothing re-usable, I had to get inspired and get an idea quickly. A short walk did it for me. Because it was windy, I got the idea of pushing crates off the rooftop of a tower/skyscraper by controlling/drawing the wind.

I decided to run with that. Good thing I did too, considering that the wind gameplay was surprisingly easy to implement. As a result of this decision I had the main game mechanic completed mid-day 1.

 

 

What went right

Ditching idea that went bad

I'm pretty certain that I saved my spot in the list of entrants because of my choice to ditch the first idea i went with. I think I would have wasted an entire day+ simply on tweaking physics variables.

Controls

The mouse controls came out very intuitive, and made the toy easy and fun to use.

Toy

Supported by intuitive controls, and combined with proper rigid physics, the wind mechanic just worked.

Sounds

All sounds in the game were created by me simply blowing into my microphone, and they just sounded right in first go. Who knew wind sounds could be made so easily.

 

What went wrong

Requirements

I almost don't want to include this again, seeing as it's always in this list. But as usual, this competition is not suited for heavy use of Microsoftian technologies.

Presentation of concept

After completing, it has become apparent to me that the concept of the game did not come out very clearly. Which means I could/should have presented it better.

My intention was to let the player use the wind-toy to explore the content and while doing so discovering achievements. But since there were no "prizes" for discovering/completing these, it did not come through very clearly that this was the whole idea of the game. Also, I implemented these achievements way too late in the process (end-day 2) and as a result i ended up with a minimal amount of them. There simply had to be more to support the concept.

Sleeping

When day 1 was coming to an end I decided that I didn't want to stay up too late. I thought i'd rather go to sleep early, and be fresh and lucid the following day, than staying up pushing code.

My plan didn't go too well, though. I was literally twisting and turning for a good couple of hours before finally passing out. My mind was simply not able to turn off because I didn't relax, by watching tv or whatever, prior to hitting the sack. Made me a bit cranky the following day.

 

 

 

Conclusion

I'm quite satisfied with my work this time around. Sure there's a bunch of stuff I could have done better. But let's face it, there always is. I had fun. I got stuff done. What more can you want?

 
Continue reading

Posted in Postmortem | Comments Off

Postmortem: Shaky? (LD11)

This postmortem covers my experience with the 11th Ludum Dare 48 hour game competiton, which took place somewhere around April 2008.

Final post

Timelog

 

Summary

Been a while since this took place, and I totally forgot to write down what happened back when I could actually remember it. So this post-mortem will be rather short. These things work better right after completing the game, but I just don't want to break the order of my posts! ;)

The theme resulted in Minimalist, which I would consider to be a rather abstract theme; that is, something less tangible than say BOATS. I totally dug that theme since I felt it was incredibly open for anything, and also invites for creating something very simple. However, simple also means you should probably aim for something stylistically beautiful rather than something fancy. Which can be hard to achieve.

 

            

 

What went right

Freshness

Gameplay was new and interesting, with the huge upside that it worked on any arbitrary 3d model. Meaning that it was easy to just add more content fast.

Simple presentation

The gamescreen was stylistically minimal and just displayed a score, and the actual model. It worked great, because the game was, in fact, totally simple and minimal – which happened to fit the theme! Whoa!

 

What went wrong

Muzak

I have never had a knack for creating music, and I have pretty much no clue which tools one should use. But this time there was a LD member who had created an easy-to-use retro music creation tool, so I thought i'd try and make something.

Unfortunately it turned out that I should probably just stay away from trying to create music. Forever. The tracks I made were really horrible and ear piercing :)

Camera

I attempted implementing an arcball camera, but it just didn't work out for me. I never got it fixed, so the camera control on the final build were totally inverted and just not intuitive at all. The game would have been better off without it.

 

 

Conclusion

Bring the next!

Continue reading

Posted in Postmortem | Comments Off

Postmortem: Shaky? (LD11)

This postmortem covers my experience with the 11th Ludum Dare 48 hour game competiton, which took place somewhere around April 2008.

Final post

Timelog

 

Summary

Been a while since this took place, and I totally forgot to write down what happened back when I could actually remember it. So this post-mortem will be rather short. These things work better right after completing the game, but I just don't want to break the order of my posts! ;)

The theme resulted in Minimalist, which I would consider to be a rather abstract theme; that is, something less tangible than say BOATS. I totally dug that theme since I felt it was incredibly open for anything, and also invites for creating something very simple. However, simple also means you should probably aim for something stylistically beautiful rather than something fancy. Which can be hard to achieve.

 

            

 

What went right

Freshness

Gameplay was new and interesting, with the huge upside that it worked on any arbitrary 3d model. Meaning that it was easy to just add more content fast.

Simple presentation

The gamescreen was stylistically minimal and just displayed a score, and the actual model. It worked great, because the game was, in fact, totally simple and minimal – which happened to fit the theme! Whoa!

 

What went wrong

Muzak

I have never had a knack for creating music, and I have pretty much no clue which tools one should use. But this time there was a LD member who had created an easy-to-use retro music creation tool, so I thought i'd try and make something.

Unfortunately it turned out that I should probably just stay away from trying to create music. Forever. The tracks I made were really horrible and ear piercing :)

Camera

I attempted implementing an arcball camera, but it just didn't work out for me. I never got it fixed, so the camera control on the final build were totally inverted and just not intuitive at all. The game would have been better off without it.

 

 

Conclusion

Bring the next!

Continue reading

Posted in Postmortem | Comments Off

Postmortem: Dick Chainey (LD10)

This postmortem covers my experience with the 10th Ludum Dare 48hour game competition, in which I won a Silver Pelly in the Technical category.

Summary

The theme for the competition ended up being 'Chain Reaction'. This wasn't really one of my favourites, in fact, it was amongst the themes that I wanted the least. I think my dislike towards the theme is pretty apparent in the final result, as it doesn't feature traditional "chain reactions" as seen in most of the entries. Taking that aside, the "game" (quotes because it's more of a toy) turned out pretty good I think.

As soon as I discovered the chosen theme I began the hunt for ideas, and just like most of the other entrants I tried hard to think in different directions than what had already been done (match3, boomshine). From the get-go I knew I wanted to do something in 3D, simply because I figured most entries (if not all) would be 2D. This was a silly decision, considering the gameplay I ended up with would have translated very well to a 2D setting, and would have saved me a bunch of time which could have been spent on polishing. But anyway, having it 3D allowed for a couple nifty little features.

It didn't take long for me to decide that I was going to use spring physics in some way or another. But knowing what a pain it is to implement and use springs, I knew the usage had to be something really simple. I honestly don't remember the idea I initially went for, but somewhere along the road, while implementing the physics, I discovered how fun it was to swing this snake-like structure around using the tail as a wrecking ball of sorts. With this discovery I figured I might as well do something with that.

 


        

 

There were lots of possibilities bundled with this discovery, like for example I could make it a fighting action game where you use your tail to bash down enemies, with possible chain customization included. Or, you could use your tail to collect stuff scattered around on the playing field. As said, lots of possibilities based around it simply being fun to control the motion of the tail.

I guess it's true that games are emergent.

Ultimately I ended up with a game about "snake-like creatures using their tails to bash a ball around a soccer field in hope of hitting the opponents goal" that had close to nothing to do with the initial idea. (Which I don't even recall what was by now – I guess it wasn't very good!)

 

What Went Right

1) Score counters (numbers on playing field):

I'm really happy about these, and they were really simple to implement!

2) Chain/Snakes:

I still find myself enjoying swinging them around, so these were a definite success.

3) Mouse/Gamepad controls:

The mouse control scheme is probably the one feeling most "right", and is quite easy to control, in my opinion. Same goes for the gamepad scheme.

 

What Went Wrong

1) Distribution/Requirements:

This competition is generally not very friendly towards microsoftian technologies, thereby making distribution a living hell for anyone using them. I knew this beforehand, having participated before. I chose to use them regardless as I feel much more confident in the use of them which makes me able to produce stuff faster.

2) Multiplayer only:

This was a bad decision, but I did not feel I had the time to figure out a decent AI solution for the enemy opponent. Even now there's no obvious solution that pops into my mind when thinking about it, so even though it was a crippling decision it was probably the right one.

3) Springy goals:

Waste of time and effort. The springy goals are often not even noticed, and has zero impact on the game-play.

4) Keyboard controls:

They suck. Nuff' said. Unfortunately, as far as I know, there's not really any way of having keyboard controls that feels right for this game.

 

Conclusion 

It was a very good competition this time, and it went very well for me. I produced a whole lot of stuff during the competition, and ended up with a nice little multiplayer toy that I had some fun playing.

However, the game did not really make great use of the theme, and in a similar fashion did not present any new and awesome innovative game mechanics. Another downside is that I tend to end up with half-games; that is, games which lack polish (menus, game states, help screens/information) and are therefore basically just toys.

 

"Use the Tail, Luke!"

Continue reading

Posted in Postmortem | Comments Off

Postmortem: Dick Chainey (LD10)

This postmortem covers my experience with the 10th Ludum Dare 48hour game competition, in which I won a Silver Pelly in the Technical category.

Summary

The theme for the competition ended up being 'Chain Reaction'. This wasn't really one of my favourites, in fact, it was amongst the themes that I wanted the least. I think my dislike towards the theme is pretty apparent in the final result, as it doesn't feature traditional "chain reactions" as seen in most of the entries. Taking that aside, the "game" (quotes because it's more of a toy) turned out pretty good I think.

As soon as I discovered the chosen theme I began the hunt for ideas, and just like most of the other entrants I tried hard to think in different directions than what had already been done (match3, boomshine). From the get-go I knew I wanted to do something in 3D, simply because I figured most entries (if not all) would be 2D. This was a silly decision, considering the gameplay I ended up with would have translated very well to a 2D setting, and would have saved me a bunch of time which could have been spent on polishing. But anyway, having it 3D allowed for a couple nifty little features.

It didn't take long for me to decide that I was going to use spring physics in some way or another. But knowing what a pain it is to implement and use springs, I knew the usage had to be something really simple. I honestly don't remember the idea I initially went for, but somewhere along the road, while implementing the physics, I discovered how fun it was to swing this snake-like structure around using the tail as a wrecking ball of sorts. With this discovery I figured I might as well do something with that.

 


        

 

There were lots of possibilities bundled with this discovery, like for example I could make it a fighting action game where you use your tail to bash down enemies, with possible chain customization included. Or, you could use your tail to collect stuff scattered around on the playing field. As said, lots of possibilities based around it simply being fun to control the motion of the tail.

I guess it's true that games are emergent.

Ultimately I ended up with a game about "snake-like creatures using their tails to bash a ball around a soccer field in hope of hitting the opponents goal" that had close to nothing to do with the initial idea. (Which I don't even recall what was by now – I guess it wasn't very good!)

 

What Went Right

1) Score counters (numbers on playing field):

I'm really happy about these, and they were really simple to implement!

2) Chain/Snakes:

I still find myself enjoying swinging them around, so these were a definite success.

3) Mouse/Gamepad controls:

The mouse control scheme is probably the one feeling most "right", and is quite easy to control, in my opinion. Same goes for the gamepad scheme.

 

What Went Wrong

1) Distribution/Requirements:

This competition is generally not very friendly towards microsoftian technologies, thereby making distribution a living hell for anyone using them. I knew this beforehand, having participated before. I chose to use them regardless as I feel much more confident in the use of them which makes me able to produce stuff faster.

2) Multiplayer only:

This was a bad decision, but I did not feel I had the time to figure out a decent AI solution for the enemy opponent. Even now there's no obvious solution that pops into my mind when thinking about it, so even though it was a crippling decision it was probably the right one.

3) Springy goals:

Waste of time and effort. The springy goals are often not even noticed, and has zero impact on the game-play.

4) Keyboard controls:

They suck. Nuff' said. Unfortunately, as far as I know, there's not really any way of having keyboard controls that feels right for this game.

 

Conclusion 

It was a very good competition this time, and it went very well for me. I produced a whole lot of stuff during the competition, and ended up with a nice little multiplayer toy that I had some fun playing.

However, the game did not really make great use of the theme, and in a similar fashion did not present any new and awesome innovative game mechanics. Another downside is that I tend to end up with half-games; that is, games which lack polish (menus, game states, help screens/information) and are therefore basically just toys.

 

"Use the Tail, Luke!"

Continue reading

Posted in Postmortem | Comments Off

Postmortem: Planet-Turn-Kill

This post
will be the first of, hopefully, many postmortems on the games I prototype. I
will focus on things that went wrong, and things that went right.

This game
takes places entirely on a planet, and you, the player, have to either save or
destroy the people roaming the surface from the evil asteroids that are on a
direct crash course with the planet.

 

 

Inception

The idea
for this game was kind of a forced result of my obsession spherical game worlds
– i.e. games taking place entirely on/in a sphere. Since I had been messing
with spheres for some time, I had a bunch of ideas in mind that I wanted to
implement, quickly.

For actual
game-play I thought it might be fun if the only interaction the player had with
the game was controlling the rotation of the sphere. This way the player would
be able to basically choose where the asteroids would land, at least until the
amount of asteroids became larger at which point some prioritizing would have
to happen.

What went right

I really
think I nailed the theme with the small hills on the planet, the expanding
shadows on the surface and the comical look that the building has to it. Imagine
this with a classical tune looping in the background, and some horrifying
screams from the people on the surface whenever they get crushed – I think it would
be a perfect a fit.

 

 

Besides the
visuals, I have learned a bunch about using a sphere as the game world. I
seriously think there’s a ton of potential in such a world, at least, I have a
bunch of ideas I want to try out sometime in the not-so distant future.

What went wrong

Starting
out, I figured that the toy (the main
game-play mechanic) would be simple to implement, and since it looked great on
paper I did not give it any further thought that it might not be any fun in
reality. Turned out it really wasn’t any fun.

The time I
should have spent on re-thinking the toy was “wasted” on writing code that
mapped a height-mapped terrain onto the planet surface, and some AI for the
roaming dudes. These things were obviously both lovely things to have
implemented; however, their loveliness was hidden due to the frustration of the
actual game-play. It is hard to appreciate such things as a player, when the
game is working against you.

 

 

Another game-play
issue became apparent quite quickly during development; how to keep an overview
of the situation as a player. This issue had actually been dealt with on paper
by placing shadows on the surface of the planet as reference points for where
the asteroids would hit.

This solution was great both visually and game-play
wise. But, now imagine that asteroids keep spawning on the opposite side of the
planet. You will never see these unless you navigate around using the camera.
How could this issue be handled? Well, the carebear solution would be to simply
not let anything spawn in places the player cannot see. This however, opens
another set of issues – couldn’t the player just keep buildings/people
somewhere out of sight? The whole game might become way too easy this way.

Conclusion

Ultimately,
this process has been a good experience. I have gained a bunch of knowledge,
and, most notably, learned the importance of developing on the core mechanics
prior to, literally, ANYTHING else.

As a
closing note, I’ll say that I remain confident that this idea could be
successful given more creativity and time. For now, however, it’s time to do
something else.

Continue reading

Posted in Postmortem | Comments Off

Postmortem: Planet-Turn-Kill

This post
will be the first of, hopefully, many postmortems on the games I prototype. I
will focus on things that went wrong, and things that went right.

This game
takes places entirely on a planet, and you, the player, have to either save or
destroy the people roaming the surface from the evil asteroids that are on a
direct crash course with the planet.

 

 

Inception

The idea
for this game was kind of a forced result of my obsession spherical game worlds
– i.e. games taking place entirely on/in a sphere. Since I had been messing
with spheres for some time, I had a bunch of ideas in mind that I wanted to
implement, quickly.

For actual
game-play I thought it might be fun if the only interaction the player had with
the game was controlling the rotation of the sphere. This way the player would
be able to basically choose where the asteroids would land, at least until the
amount of asteroids became larger at which point some prioritizing would have
to happen.

What went right

I really
think I nailed the theme with the small hills on the planet, the expanding
shadows on the surface and the comical look that the building has to it. Imagine
this with a classical tune looping in the background, and some horrifying
screams from the people on the surface whenever they get crushed – I think it would
be a perfect a fit.

 

 

Besides the
visuals, I have learned a bunch about using a sphere as the game world. I
seriously think there’s a ton of potential in such a world, at least, I have a
bunch of ideas I want to try out sometime in the not-so distant future.

What went wrong

Starting
out, I figured that the toy (the main
game-play mechanic) would be simple to implement, and since it looked great on
paper I did not give it any further thought that it might not be any fun in
reality. Turned out it really wasn’t any fun.

The time I
should have spent on re-thinking the toy was “wasted” on writing code that
mapped a height-mapped terrain onto the planet surface, and some AI for the
roaming dudes. These things were obviously both lovely things to have
implemented; however, their loveliness was hidden due to the frustration of the
actual game-play. It is hard to appreciate such things as a player, when the
game is working against you.

 

 

Another game-play
issue became apparent quite quickly during development; how to keep an overview
of the situation as a player. This issue had actually been dealt with on paper
by placing shadows on the surface of the planet as reference points for where
the asteroids would hit.

This solution was great both visually and game-play
wise. But, now imagine that asteroids keep spawning on the opposite side of the
planet. You will never see these unless you navigate around using the camera.
How could this issue be handled? Well, the carebear solution would be to simply
not let anything spawn in places the player cannot see. This however, opens
another set of issues – couldn’t the player just keep buildings/people
somewhere out of sight? The whole game might become way too easy this way.

Conclusion

Ultimately,
this process has been a good experience. I have gained a bunch of knowledge,
and, most notably, learned the importance of developing on the core mechanics
prior to, literally, ANYTHING else.

As a
closing note, I’ll say that I remain confident that this idea could be
successful given more creativity and time. For now, however, it’s time to do
something else.

Continue reading

Posted in Postmortem | Comments Off