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.