Gardener Post Mortem

The technology behind

This Ludum Dare I only could spend one day for making a game and I wanted to try out a new technology (HaxePunk). Usually that’s not a good idea for a time restricted jam, especially with restricting oneself even further.

Working with a new language and library worked surprisingly well. Tuning down the scope of my game probably helped, but Haxe seems to be quite a convenient language to work with. The HaxePunk library was a great addition to have quick results, as most of the basic engine stuff necessary for my game was already in there.

gardener_screen04For creating some ambient background sound for my game I had a nice idea: As it is finally spring now in Germany, I wanted to record some spring sounds, like birds. I did this with my phone, which worked pretty well. Unfortunately transferring the file into Audacity did something very strange to the sound and it was too late to figure out how to solve it. That is the reasons the bird sounds seem more like from a jungle than a mid-European garden.

What’s that game about

As mentioned, I didn’t have the full 48 hours, so I had to come up with something really simple. The basic idea has some resemblance to my LD23 game Bottlecolonies, but this time with free placement and only two different colors. This makes the gameplay probably a little boring quite soon.

Can you spot the similarities?
Can you spot the similarities?

The idea is, that with each new planted flower, the existing ones will grow through different stages. If there are negative influences around (potatoes, mushrooms, different kind of plant) and surpass the positive ones (same kind of plants) the plant will decay. Additionally, a feature implemented quite late, the mushrooms will spread for a while. So goal and strategy of the game is to place the same kind of plants close to each other, block spreading of mushrooms and avoid the negative stuff around your seedlings. The rhythm as how the two different plants are seeded is quite simple. Each three plants it will change. You will win the game if there are enough grown plants and will lose if there are too many decayed ones.

What went right

  • Getting the idea (I already had this idea in my mind for OneGameAMonth for the theme “spring” and it also fits the LD theme)
  • Fast progress with a new tech (I’m surprised by myself how well I got into HaxePunk)
  • Making a Flash game (a lot more plays than usually with a Windows standalone)
  • Finish in time (was a long evening, but I did cut the features early enough)

What went wrong

  • Making the background sounds (as mentioned above, and took me some time to mix the few recorded sounds to not be to repetitive)
  • Player feedback in the game (A lot of people mentioned it: an indicator for the placing position and some feedback what will seed next would be great; I agree)

So all in one, I’m quite happy with my entry.

Go play and rate

One Game in March – Colorblocks RogueLike

Quite late, but just within the 96 hrs grace period, I finished my March entry for OneGameAMonth. This game is a very simple roguelike without real graphics.

CRL_screenThe gameplay is pretty straight forward. Just click on an arrow on the top of the screen to progress, click the monster to fight, or click the brown treasure to open. You can only advance if a room is cleared and there are empty rooms on your way.

There are four colors to find which also serve as your stats. Yellow improves maximum health, blue regeneration, red is for damage and green prevents some damage.

Enjoy!

Beatbeat Arena

I’ve finished my second game for OneGameAMonth and this time even one day before the month ends ;). This game is sort of an arena bullet hell shooter. My initial plan with it was to make a game where the automatic shooting of bullets matches with the rythm of the music (as the theme suggestion in February was “music”). In the current state, this feature is rather a minimal electronic beat. So you can get the basic idea but it isn’t as nice as I’ve planned.

You can find the game here!

BBAAnother thing I didn’t implement is control with a gamepad. This would probably make such kind of game much more fun to play, so I will eventually add that feature later. Other things I can imagine to add are:

  • Increase the rate of bullets appearing with the escalation in a level (by collecting dark green blocks)
  • Add more sound effects and guitar made sound effects instead of the bfxr ones
  • Add a two player mode
  • Increase screen resolution to full HD for console like play on the TV
  • Add some particle like effects
  • More variations in enemies and their bullet types and directions

As you can see, there are still a lot of things to improve. Nevertheless I’m pretty happy with how the game came out. The development time was rather short (about 8 hours at all) as I recycled my game Watercolor Wheel Evolution that I’ve made for Ludum Dare with my 3 year old daughter (Just noticed the old game’s name is still displayed as the window title).

I even kept the evolution mechanism for the level progression, so if you come to playing more than one level you will eventually notice slight differences in player and enemy behaviour due to strange evolution effects.

One Game A Month, January Game and February Plans

Finally I found some time to write a blogpost about my participation in One Game A Month. To start with, One Game A Month is quite an open (rulewise) experience point based community motivator for game devs to make one game a month (as you probably guessed by the name).

I started quite early in January, as I had a vacation and some spare time for gamedev. But after one and a half week my enthusiam slowed down a lot as my spare time faded away pretty quickly. So all my initial plans to make a really interesting first game got crippled real soon. I was inspired by the theme and tileset suggestion made on the One Game A Month page and wanted to make a game with portculis including game mechanics based on Conway’s Game of Life. It should have been sort of a puzzle/action clicking game where you prevent a fire from spreading in a fortress by throwing buckets of water at it. Additionally you can open the portcullis by hitting a lever with a stone (if there is no fire around) which will add a lot of extinguishing water once in the game’s level.

First try at the level design. tiles are in place.
First try at the level design. tiles are in place.

Barely in time I managed to implement these basic mechanics (you can find the game here) but I couldn’t fulfil my plans to make multiple levels, nice graphical effects like steam appearing if you add water to the fire, and sound effects. Especially not having the time to add multiple levels bothered me a lot cause I wasted quite some time implementing a routine to load levels from an xml file at the start of the month.

This is how the final game looks like.
This is how the final game looks like.

To conclude my January attempts: Am I happy with my game prototype? Not that much. It does work as planned but isn’t that much fun to play and doesn’t look as good as I would have liked it to.

Have I learned something? Yeah definitely. And I guess this is the most important part about that One Game A Month challenge. I could improve my skills in storing level design in a file and load it into the game. Also I made some additional experience about how much effort different things need to get implemented and how much time I can spare in a month for gamedev.

For doing my second game in February I am comparably late to start. Again I am inspired by the suggested theme – music – but already know that I won’t finish my initial plan and idea. But nevertheless I am going to make a small game in February (mostly by converting an old one). So this is what I’m at:

  • Take my Ludum Dare game “Watercolor Wheel Evolution” to convert it
  • Record some handmade guitar music and sound effects
  • Change all the graphics to fancy colored rectangles
  • Try out to implement game control with a gamepad
  • Make it into an topdown arena shooter with autofire on and rather stupid auto-firing enemies

Even this is probably to much to acomplish. I will keep you updated what will come out of this.

What I’ve been at in November

To be honest, I didn’t put that much of my spare time into game development in November due to mainly two reasons:

  • My children
  • DOTA 2

Yeah, that’s unfortunately right. I got into playing this MOBA – never tried a game of this genre before – and basically wasted a lot of my spare time in November to it (It’s pretty good from a gamedesign/balancing perspective but also with a pretty steep learning curve). Anyway, that game inspired me to try something out which is more gamedev related.

For some time now I wanted to give modelling in Blender a try. And since there is the possibility to create some nice visual equipment stuff for DOTA 2 I even had an interesting test case. So I decided to make something for the hero Lich. In the picture you can see the progress I’ve made so far.

Technically interesting from the gamedev perspective is how Valve’s Source engine interprets different shader masks. That is what is still missing in my specific case – to author the color channels of the two shader masks to let the engine now where reflective, etc. material is.

Blender itself was not that difficult to get into. Not as difficult as I’ve read and heard beforehand from different sources. So I can put this experience under some gamedev progress at least :).

For painting the textures I also invested some (little) money into this tool:

Do you spot the dust? Yeah, haven’t used it for one or two weeks :(.

Quite a great tool for precise control in painting stuff digitally. This also comes in quite handy for future gamedev projects fitting the hand-painted style of my prevoius games. Finally what am I up to next?

  • Finish that DOTA 2 equipment, just as a test case (and to get something done with this)
  • Learn some new tools for gamedev (Unity 3D, or Haxe NME) by making a new game
  • Continue development and finalize my game Bottlecolonies

Expect some more updates in December.

The game I didn’t make last month

So there was an interesting topic for last month Experimental Gameplay Project, which was “time manipulation”. I have joined EGP once with the infinite floating islands prototype and it was a lot of fun and also quite successful regarding download numbers of the prototype.

Hence, I planned to join this contest again anyway and the theme was great. An interesting idea formed in my head which I’d like to sketch in this post. Unfortunately, due to time constraints and me being not so certain about the precise gameplay of the idea, I never made the game. Nevertheless the concept feeled pretty great so I want to share my thoughts on it so far. Maybe I will make a game out of it one day.

Basically, for making a game with the theme time manipulation you have to overcome the linear concept of time. Good examples for games that use this as a mechanic are Braid, for sure, and Sophie Houlden’s Rose and Time.

For this contest I wanted to make some sort of strategy game. Not as ambitious as Achron but with some small similarities in the mechanics. My target platform for this game was flash and/or mobile which makes for a rather small and streamlined game. This also suits the time limit of one week development time.

The basic idea for my game was to besiege a planet with four space stations during an overall time cycle that covers the whole development of a civilization. The player can manipulate the time by switching the planet to a specific era which will consume time manipulation energy. This energy is identical to the time left to play this level. So with every time switch you will reduce your time left to beat the game. The space stations are constantly firing shots at the planet. The player can switch the frequency of this shots which will also consume energy.

Quick sketch of the visual appearance and basic concept.

The development of the planet depends on the impact of the shots. It makes a difference at which era how many shots have reached the four different sectors of the planet. The basic mechanic for that is:

  • Each sector builds specific military defense buildings depending on the impacts before that era
  • These buildings can be destroyed by the impacts
  • Impacts in the neighbouring sectors have an effect on the military buildings of this sector
  • The more impacts, the more buildings are built which makes the sector stronger against future attacks
  • (An additional idea was to add different terrain features which have an influence on the sectors. This would help to make differantiated levels.)

To make this concept work, the whole timeline of events will be calculated with every impact depending on what has happened so far in the different ages. The player interactions at any time of the level are:

  • Choose the current era
  • Change the frequency of shots at the planet

To finish the game, the resulting state of civilization is calculated when the time has run out. Additionally I planned a visualisation of all the eras after each other at the end of the game. A winning strategy would prevent sectors to grow too strong too early but also prevent being to late with the bombards.

While writing this post I noticed that this seems to be a concept more complicated and not as matured as I thought last month. I don’t know if the mechanics would work as intended and make any fun. But events like the Experimental Gameplay Project are totally the place to make a prototype to try it out. Right now the theme is “vegetation” so if you want to try out some crazy experimental gameplay ideas, why not over there.