"After the seas have disappeared, you must fight for control of the last remaining source of water, the clouds"
This is the dev log of the game Cloud Storage by Jez Whitworth. A turn-based settlement building simulation set in a dry, desert world where water is the last remaining natural resource. Harvest the moisture locked in the clouds to upgrade and trade with other players to advance your settlement and increase your chances of survival.
The functionality of the latest version is close to how I want it, so now my attention is turning to the artwork. The video that originally sparked inspiration for this game featured scratch built settlements located in a desert world and I would like to continue this theme in Cloud Storage but mixed with a sprinkling of steampunk perhaps. I've been looking for asset ideas and have spent time designing a selection of game's tiles. Can we all take a moment to appreciate these tile designs that I'm put together. It's amazing how much a bold outine improves things.
After a long couple of weeks, the completed interface looks like this, with samples of gameplay being featured in the latest video devlog below. Not all the tiles have been designed yet but the majority have. As this version has started out as a Triple Town clone, I've replaced the bears with blimps and it actually works really well. This then set me up perfectly to develop the whole battling the skies idea.
As work progressed with the game, two things were becoming apparent. Feature creep or scope creep was, well, creeping in and with more idea being added the game was starting to take on features of a game I used to play about 10 years ago. I was going down the route of upgrading tiles if multiple buildings were placed next to one another, resembling the game mechanics of the much loved Triple Town. This has now resulted in my reassessing this project's approach.
The project is now going to be split. I'm really pleased with what's been achieved but it is beginning to present me with a few difficulties. The first is that the isometric view is causing problems when placing tiles behind buildings that have already been place in the foreground. The second is that the building upgrade mechanic is so bloated as it tryies to accomodate the board view, it's becoming a real headache. Therefore I am shelving v.2 with this intention of polishing further and turning it into a relaxing settlement building game with no objectives other than to build. This is how my brain mostly works, always refining and producing different path. This is also how I'm able to build a collection of templates and game engines to use on future projects.
As for Cloud Storage, I would still like to incorporate the multiple building matching system along with a 2d view to get around the isometric problems. So I've been playing a lot, and I mean a lot, of Triple Town lately to try and get a good understanding of how the game operates.
It turns out there is more to Triple Town than meets the eye. The first part was to look at how the random tiled landscape is generated. Previously I have created a clean board to play on and peppered it with stage furniture such as cactus. This is going to be more complex and it's taken me a great many attempts to generate random tiled landscapes that fit together through a combination of 16 different tiles.
Now begins the hard part, trying to disect the logic behind the tile matching. I have spent hours going through the game, making notes along the way. There are plenty of guides online to help with people who play the game but I wanted to try and work it out for myself, as this way I would gain a better understanding of the mechanic.
And after many, many late nights I have something working. Little bugs crop up from time to time, mostly after a great deal of play time, but I'm so happy and a little relieved that I have a randomly generated landscape that utilises a matching tile mechanic to upgrade settlement buildings. The best bit of all is that it's a top-down, 2d view, eliminating most of the issues I've been having with an isometric view.
I've been working on the artwork for the game and looking at how best to do free up more screen space. The labels displaying the water tank and population variable values have been replaced with two simple meters that run alongside the board.
There are a great many positives coming out of this rewrite. As I mentioned previously I find it rather relaxing just to switch off and build with the random tiles that are present to me. As I now have an engine that when I pass in the assets it will produce a simple builder game. This will make it really easy for me to make little spin-off construction games in the future.
The rewriting of this game features on my latest podcast Finding Space. Put the kettle on, grab a biscuit and have a listen by clicking the below link.
The great rewrite! The decision to rewrite the game has allowed me to plan the structure better as I'm able to cherry pick everything that was good in version 1 and better plan in this version. The rewrite has also resulted in a better project plan. For this update I am planning on concentrating on the following:
I put together a random selection of shapes with the intention of evolving them into proper buildings later on. Once these were in place a basic tile delivery system was written that presents the player with a single item tile at a time and does this in a random way. I am dreading revisting the logic I penned in the notebook for this system, it is what broke everything in version 1 and forced this rewrite as a result.
Despite it only being a basic prototype, it is strangely satisfying just placing the random shapes onto the board. I have been able to plan a better method of recording each piece placed on the board, with each piece's ID stored in a single array. This array is in constant use as the board is continually scanned, allowing the pieces to be better managed in real time. With everything managed as a single array, I plan on utilising this when building a method of saving and loading player-built maps. Loading in an array, the board scan function can then pick it up and rebuild the board. It is also the same function that handles the resetting of the board too. One function taking on three roles - probably the most efficient thing I've ever written.
The tiles are currently delivered on a random basis and so I've cautiously started to pen the algorithm that will deliver each tile based on certain criteria. It is this that is going to take the most time and one that will require constant tweaking, so the framework for this will need to allow for corrections to be made easily. Anyway, here's the first video devlog covering the project so far.
There has been quite a lot of progress made on the game. I have invested time in developing the UI as well as bringing in the other buildings into the menu and applying the logic that allows certain buildings to only be placed if particular criteria has been met (see the notebook from previous updates). I have also been experimenting with the style of the game and would like to try and replicate an IKEA style when it comes to drawing out the pieces. It was actually playing a game called Sparvagn that sealed the deal when it came to the IKEA look. This simple train game looks so beautiful.
After playing Dorfromanik I wanted to explore the concept of making it turn-based, with the game presenting you with a single item at a time to place on the map. The problem is that the tile delivery has to be logic driven in order to allow the game to continue being played. There is no point in presenting the player with a tile that cannot be played, so to the notebook I went and tried to flesh out the logic for the tile delivery.
To cut a long story short, this did not work at all. In fact, it properly broke the game's code and although I religiously keep backups of everything, I'm now wanting to take the lessons I've learnt, along with the style and UI design concepts and start again. I read a number of devlogs and this would appear to be a more common occurence than I initially thought, so I'm not alone. What I've achieved so far is by no means time wasted, it gives me a solid foundation in order to build the game again.
So I have a rough concept of the game. Thoughts now turn to the environment and map the player will be playing in. I've played a great many settlement building games lately, for research purposes you understand ;) (Try out Dorfromanik by the way) and I think playing the game in an isometric view works really well and is a nice nod to the old world building games that I used to play. I've also been giving some consideration to how the player will journey through the map and have gone for a simple 2x2 grid system to start with, with players unlocking new areas of the map as they progress through the game.
I had an idea for the initial cloud harvester the player has access to at the start of the game. This will raise its cloud catcher up into the air before retracting it to decanter the collected moisture. From here on in I am going to use simple place holders as the game evolves to make sure the mechanics are working before investing any real time in building aesthetics. I have track building and cloud harvester placement (sort of) working with a few basic rules whereby buildings can only be placed alongside a dirt track. Idea - What if the dirt track was a railway track, collecting water from the harvesters and depositing it at a central water station?
The main aim of the game will be to keep alive and expand a population through careful management of settlements and water harvesting. I've been trying to work out the mechanics of the game and how each building depends on previous buildings being built. Different combinations on buildings in a settlement will affect the water harvesting rate, the survival rate of colony and how quickly settlement technology can be advanced. This is a really interesting insight into how similar building games are produced and I have a great appreciation for them as a result.
Taking inspiration the other games I've been playing, I think it would be a good idea to add another layer of complexity by restricting the use of some of the building blocks. Presenting the player with a single card at a time but doing it in a calculated way to ensure the game can continue play (and not offer a building card that cannot be played) would be a great idea to consider later on.
Episode Two - Learn to Take Breaks and New Projects
Inspiration for games come in many forms, I usually use the weekly game jams to help get the creative gears moving. This is great for short blasts of game making but for a longer build I needed to look elsewhere and it wasn't long before something of interest came my way. I'm not sure how I came across it and it took me a while to track it down again but this short video of an animation really got me thinking. I love the idea of some planes fighting for resources whilst others are trying to better the situation. Wouldn't it be great to include similar dilemmas and situations in a game of survival.
To the sketchbook! There is always a slight sense of embarrassment when I first start sketching out a game idea and I'm not sure why this is. Maybe I'm comparing my doodles to other developers who have shared some of their sketchbook pages and admired the quality of their art even in their early stages. One thing's for sure though, everybody has to start somewhere, including me. Below are some of the initial sketches I made for the game as I looked at putting together a game set in a world where water is the most valuable commodity with the player harvesting moisture from passing clouds in order to survive and support an expanding population.
The dynamics of how someone in dry, desert world interacts and survives in such a climate. Trading with NPCs or other online players is an idea that really appeals and one that is worth exploring later on.
I initially thought about generating an infinite map for the player to level up and explore. The sketching out of this idea has made me realise that this maybe a little ambitious. This way of generating a random, infinite world that was the same on every load took me down some interesting avenues, including sitting down with a couple of maths teachers in order to got through how to generate such a thing. I was going to try and use the same mechanic for the weather system.
Level progression will be done through upgrading the player's technology in order to farm moisture better. For the basic levels, technology is operated manually with incentives to spend valuable currency on upgrading to automation, freeing up time for the user to explore the desert world. Moisture can be traded for parts and goods. I really like the idea of a messaging system between players in the form of a mail carrying blimp.
Episode One - Talking About Game Development in the Arcade Workspace
Copyright 2021, Rocket Games