Home | Email | Twitter | Instagram


Cloud Storage

"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 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:

IKEA aesthetics

Tile delivery system

Wiping the board clean

Game save

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