Today I have made just little progress on my game for Experimental Gameplay Project and OneGameAMonth. At least I’ve decided for a name: “Growstruct”. Also I’ve detailed the game mechanics and made some first sketches for the buildings to construct. They will definitely not look like the buildings in the mockup from yesterday’s post. They’ll be smaller and more greyish. Finally, I made a new project in FlashDevelop. So I’m not that far away from writing the first lines of code ;).
Mockup of May Project
Started with gamedev today, but haven’t written a single line of code yet. I just made some basic sprites and a mockup of the main screen of the game. The trees will grow by themselves and you can construct tree-buildings that will have an impact on the three resources. These resources will influence the growth of the trees.
Sounds confusing? Yeah, I’m still not sure about the main game mechanics. But the game will look similar to that mockup.
The plan is to make a Flash game with HaxePunk.
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.
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.
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.
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:
global_seed 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).
Let’s see what will evolve from the Infinite Floating Islands.
Infinite Floating Islands
And it is finished!
After a week of regular evening game development, my entry for the experimental gameplay project’s February challenge is finished. You can download a windows executable here (Unzip and start ‘island.exe’):
Infinite Floating Islands
[Update:] Here you can find some background information and future plans for the game. [/Update]
This is rather a proof of concept than a real game, but I am quite happy with the basic concept. There is potential to make more out of it.
When algorithms fail
As you can see on the screenshot below, the first test in creating new islands on the fly caused the connector algorithm to fail hard. It’s to late today to investigate this problem any further. As my personal deadline for this one-week challenge is in 23 hrs and as I am going to sleep now, chances are rather bad to get this game finished as intended. Nevertheless, I will try to fix these issues tomorrow.