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.


July update on my projects

It looks like this month I can spend some more time on coding and stuff for my games. Additionally, as my Raspberry Pi arrived last week, I have some extra motivation to make my pygame based games run on it.

Bottlecolonies running on the Raspberry Pi.

The latter is not as easy as I thought initially. With its rather limited hardware the Pi provides quite a challenge for my game Bottlecolonies to run in an acceptable speed. So I started profiling and optimizing my code which is quite an interesting experience so far.

For example, I was able to make blitting my number font three times faster by removing an unnecessary surface copy in every call. With that success I will continue to search for bottlenecks in my code to remove them. On a standard PC I wouldn’t even have noticed.

This is the hardware I’m talking about. Runs Linux.

There is a second project I haven’t forgotten yet, which makes most of the traffic on this blog. That is my Experimental Gameplay Project prototype “Infinite Floating Islands“. The prototype has been made in less than a week and was quite buggy but has over 100 downloads so far and I really like tha basic idea of it. (Just for comparison, Bottlecolonies’ postcompo versions, which are much more “finished”, have a cumulate download count of about 15)

I tried to remove the bugs of the prototype by heavy refactoring but haven’t gotten that far actually. So it looks like I have to start this again from scratch to make it stable and expand on the idea.

Still extremely buggy.

So that’s it for now. Expect some more regular updates on this blog about those projects.

Working on the post-compo version of Bottlecolonies

I’m really happy with my entry for the actual Ludum Dare event. The game itself feels very consistent and the feedback is very good so far. Hence I’m actually working on a post-compo version of the game. It is in open beta at the moment and shall become a free puzzle strategy game for Windows, Linux and maybe Mac PCs.

I will post development updates on this blog with some spare additional posts on the Ludum Dare site.

Here is a link to the game’s page.

And to give you an impression of the newest map in the game:

Bottlecolonies – A post mortem

— This is a cross-post from the Ludum Dare Compo page —

So finally I’ve found some time to write up my impressions of the past Ludum Dare event. As ever it was a big pleasure to participate and I’m really impressed with the sheer amount of games being made and the overall quality which feels a little higher than the last times.

Now about my game “Bottlecolonies” which you can play here.

The good

  • I finished everything I planned to minimally have in the game in time.
  • The creation of a windows executable with py2exe worked immediately this time, thanks to experience from past Ludum Dares.
  • I’m pretty happy that I really took my acoustic guitar to make ingame sound and music.
  • I managed to make a game with quiet a consistent style and feel due to the hand drawn graphics.
  • I’m totally happy with the game I’ve made. With my third LD this time I noticed how much my self-organisation and the outcome progressed from event to event.

The bad

  • I totally underestimated the effort even to record only a small music track with a real instrument.
  • There are still some small issues that could have been solved within time (especially some sort of marker where one builds).
  • To solve the challenges stated in the levels requires more training and strategic thinking than I expected. It’s the standard issue that usually the developer himself is the most experienced player of his game and tends to make it too difficult.

To sum it up

You can see I’m really glad with my LD entry this time. I’m very confident now with my tools (especially python/pygame) and know roughly how much time different steps in development needs and what I’m able to achieve in 48 hours. I think that is the most valuable experience you get from an event like this.

Already put a marker for positioning in the post compo version.

Additionally the reception of my game has been quite positive. Hence I’ll put some more effort in a post compo version which shall at least include:

  • A marker for the building position (done)
  • Additional music (one new track already recorded)
  • More levels
  • Highscores of past plays

As I’ve already written two teasers for this post mortem I’ll stop here and just give you a visual impression of the development details:

From first prototype to post compo – with handdrawn graphics and self made guitar music.

Want to try and rate ?

Background Facts and Future Plans

In this post I want to give some background information about the Experimental Gameplay Project February entry “Infinite Floating Islands“. These will cover some of the unrealized ideas and features of the game and some technical background. Additionally I will sketch some possible future plans what to do with my proof of concept.

The basic idea

The idea to make a 1,5D sidescrolling game for the infinite game world theme came quite early. I thought more about technical limitations of an infinite game world than game mechanics in the first place, so a 1D approach where the player only can travel left and right seemed appropriate.

First mockup of the game.

I had a very clear idea how to implement storage of the world data to make a persistent game world. This was supposed to be procedural seed-based with an additional data structure for the actual state of the world. The sketch for the save looked like that:

list_of_islands: (local_seed, id, global_x, local_x, y)

The coordinates should be saved for faster access in minimap creation. Every other attribute of the islands could be re-generated based on the seed with the island’s seed saved for faster processing. Unfortunately I didn’t manage to implement any saving of the world data within the week of the challenge.

Missing features

Aside from saving the world there were some other things I initially planned to implement during the development week. The most important one would have been some sort of local biomes so that the player would reach different areas while travelling. These areas would have a different randomized setting for the procedural world and island generation with alternating sets of sprites and background colours. I think this would have made the exploration way more interesting.

Additional missing features are more of a visual nature. One should have been an open cable car to travel, similar to the one on the mockup above.

Future features

Thinking about expanding the game idea I have some more features in mind to make this into a real game.

  • Dungeon exploration (one or more persistent dungeons/caves can be found on the island)
  • Warring NPC faction which the player can help or sabotage
  • Economy
  • Resources becoming more and more sparse the further the player travels
  • Skill-based RPG on the player’s character with three different win conditions for the game (master huckster, master archaeologist, master schemer)
  • No direct fighting

Reception of the prototype

At the time writing this there have been 55 downloads of the game archive. I didn’t get any direct feedback by now but this number is quite impressive for my personal context. For me personally this one week challenge was a great experience about how far I can come within these constraints. So I’m quite motivated to expand this game idea which brings me to the final part of this post.

Next steps

Admittedly the actual release of the game prototype is quite buggy. I plan to remove the bugs which mainly were caused by dirty coding under time pressure. Additionally I’d like to add distinct areas the player can reach while travelling. This improved version I would like to post to a broader audience for some feedback (TIGsource forums for example).

At least this bug is already sorted out.

Let’s see what will evolve from the Infinite Floating Islands.