Built by Boneidle, with modded blocks made by Boneidle

Last week was focused on the mechanics of the grocer's shop; this week we focused on the mechanics behind the happiness items. Every happiness item now gets three stats. For food items:

• Food value / calories: how much hunger it satisfies
  
• Happiness: how happy the colonist becomes from eating the food
  
• Monetary value: the value that the VAT will be based on.

Potatoes could be cheap, provide little happiness but lots of calories, while spices provide little calories but lots of happiness and VAT.

There is one big slider that applies to all food items; the "rations slider". Here you'll set how much food a colonist will consume in a day. You can "weigh" each food item to determine what part of their diet will consist out of that food type. For example, if bread weighs "10" and berries "5", 66% of their daily calories will consist out of bread and 33% out of berries.

For non-food items, food value is replaced with "how long the item will provide happiness". There are some things we consume every day. Electricity, internet, water. Other items need to be replaced on a slightly longer timescale: toilet paper, gasoline, toothpaste. And other items will last years: clocks, winter coats, cars.

It wouldn't make sense to deliver daily packages with new smartphones (or clocks, for a more historical alternative) to every colonist. But a yearly package with 1 smartphone and 365x3000 calories wouldn't be appropriate either. So the "happiness-time" value will scale the daily requirements to appropriate levels. Imagine you've got 800 colonists and a clock will last 200 days; this means you've got to produce 4 clocks per day. That seems like a reasonable and realistic result.

A lot of work has happened behind the scenes to make these processes reality. Adjusting items, creating new systems, saving the new values, teaching the server how to deal with this. Sadly, nothing that can be easily shared in an awesome screenshot or video. I can't wait until that's the case!


When I was younger, I intuitively thought that my eyes worked as an active system, something like radar. It probably sent something out to scan objects at a distance and report back its findings.



When I started messing around with photo cameras I started researching the subject for the first time. Apparently, the word "photography" was created from the Greek words "photos" (light) and "graphe" (drawing). Photography is drawing with light. To me, photography was creating images with interesting subjects and good composition - I barely knew about the importance of light.

But when operating a camera manually, the fundamental importance of light becomes very apparent. Your camera is basically "catching" light and you have to determine how much you're going to let in for what amount of time. When there's little light available, you've got to change the sensitivity of the sensor.



The image above should be obvious. Sun shines light on flag, light bounces off flag into eye. Eye sees flag. That's how our eyes and photo cameras alike perceive the world. But lots of objects aren't directly illuminated by the sun or a lamp. How does that work?



The sun emits lights in all directions. And when light hits an object, it might be partly absorbed, but it will probably also be partly reflected. Many objects, like textiles, paper and skin, reflect light in all directions. So light is "bouncing" all around us, giving our eyes lots of input to create an image of the world around us.

To simulate this, you would have to calculate every ray of light emitted by every light source and track it through multiple bounces. It's called ray tracing and it's used to generate photorealistic images and videos.

You can probably imagine that this is pretty hard to do for a computer. Even using limited ray tracing in a simple scene in Blender takes ~30 seconds. That's not a problem if you're just trying to render one image, but it's impossible to use it to generate 60 frames per second. That's why CGI trailers often look so different from real gameplay.

The solution that Colony Survival and many other games use is a distinction between direct and ambient lighting. It's the primary thing we notice when looking around in real life. Some things are directly lit by the sun or a lamp and are pretty bright, while all the other things are relatively dark. So that's how it works in-game. All blocks are automatically lit by virtue of existing, whether a light source is nearby or not. If a block is 'hit' by the sun or a lamp, it becomes significantly brighter.

The results resemble real life the most when you're standing outside and the sun directly lights most of what you see. But it's less appealing in other situations. The world is too bright when you're underground without light sources. There's a lack of contrast indoors. Cloudy days are also hard to simulate accurately with this system.

Plenty of modern games try to overcome this by 'baking' the lighting. Lighting is rendered with ray tracing once and saved in a texture. Now people can explore a 3D world in real time with nearly perfect lighting. Here's an example of such a world:

https://youtu.be/Y6PQ19BEE24
Still frames from this video are nearly indistinguishable from real life. But baking has some pretty big disadvantages. The baking results are accurate as long as both the light source and the environment don't change. Both are stable in the video, but they're highly unstable in Colony Survival. The sun is permanently moving and players can change every block in the world. So baking is unsuited for Colony Survival.

But there are other systems we can use to add semi-realistic lighting to Colony Survival. We talked about light hitting an object and it bouncing away in all directions. This happens because most surfaces are pretty rough on a microscopic level.



But that isn't true for all objects. Plenty of objects have relatively smooth surfaces, even on a microscopic level. Plastic, metal, finished wood and wet objects are often quite smooth. This means the light isn't equally reflected in all directions.



Most of it reflects in the same direction. This means the object will look darker from most angles (because less light hits your eye / the sensor), but it'll look a lot brighter from some special angles.

Because we're truly talking about roughness on a microscopic level, it doesn't make sense to simulate this with actual "physical" bumps and indentations. Most games have certain textures that can be used to instruct the software how an item should reflect light. Colony Survival has "specular maps" (they determine how much light the object reflects) and "smoothness maps" (they determine how smooth or rough the object is on a microscopic level). Here's an example in Blender:


Fullscreen

You can view and modify Colony Survival's textures by going to "steamapps\common\Colony Survival\gamedata\textures\materials\blocks". There you'll see four folders: albedo, emmissiveMaskAlpha, heigthSmoothnessSpecularity and normal. We'll focus on the most important textures.




This is the basic look of the block, without reflections. It can be made or adjusted in software like Paint, Gimp and Photoshop. It's pretty straightforward.




This one is more complicated. It consists out of three separate greyscale maps. Instead of choosing the height/roughness/smoothness value with a slider that goes from 0 to 100, it's chosen in a greyscale map that goes from black to white.

Blocks in Colony Survival are simple objects with six flat sides. But when you look closely, they seem to have 3D details. This is done with the height map. We can use it to slightly adjust the height of the block without a big impact on performance. For example, the nails are slightly higher and the center of the crate is lower.

RGB images consist out of three channels: Red, Green and Blue. We put a different greyscale map in each channel to create one colored image: the "Heigth / Smoothness / Specularity" map. Software like Gimp or Photoshop can be used to inspect and adjust different color channels.




The specularity and smoothness maps are meant to simulate lighting effects on a microscopic level, but normal maps are used to simulate bumps and ridges on a bigger scale. Normal maps are made by special software that "reads" height maps and outputs blue-purple images like the one above.

The game's lighting system uses normal maps so that the lighting acts as if the bumps and ridges described in the normal map are actually there. It's a great way of making objects look detailed while they are actually pretty simple.

---

This might seem pretty complex on a first glance, but opening these textures, messing around with them, and checking the results in Colony Survival will quickly teach you everything you need to know. And if you need more help, join the Discord :) More and more people are starting to experiment with the textures and we're seeing awesome results.

For those interested in my Unity/programming experiments, here's my latest project.

Bedankt voor het lezen!

Reddit // Twitter // YouTube // Website // Discord

We shared a lot of our plans for the future in our previous blog, and received a large amount of feedback. Most of it was positive, but there were also some critical notes that are good to keep track of. We'd like to thank you for your efforts and encourage you to keep voicing your opinion! We cannot respond to every single comment, but we do read pretty much everything and we keep them in our mind when making decisions.

Most of the time, I start blogs by summarizing what we've done in the past week, and end them with lots of rambling about diverse subjects. This week, we've spent a lot of time dealing with edge cases, and I'd like to start out by rambling about edge cases in general. Edge cases are problems that arise when something is used in a way that it wasn't intended to be used.

Edge cases in programming are often complex and hard to explain, so I'd like to use a clearer example: race tracks. The basics of a race track are pretty simple. I'm thinking of something like the Top Gear Test Track. Put some tarmac in a field and you're done. If you've got the land and the materials, you could probably build a fun race track and use it with your friends within a week.


I've been thinking about using race tracks as an example for a long time, but had a hard time finding decent images. The new Hitman game perfectly suits my needs in regards to visualizing race tracks!

Okay, so you've built your simple race track and had a fun weekend racing on it with friends. It didn't take a lot of effort. Now you want to host some more serious races and invite spectators. Your friends didn't need to prepare their cars, they drove safely, and they brought their own food and water.

But as you scale up, these things cannot be guaranteed anymore. You need to build pit lanes and garages, and you need to prepare for crashes. You need to build run-off zones, track walls and safe barriers. You need first aiders and firemen.

Spectators bring their own problems. They need places to park. You've got to build stands, and you've got to prevent your spectators from entering them for free. You need security and pay desks, toilets and food stands.



A Formula 1 race only lasts roughly 90 minutes. Most of them don't involve serious crashes. If people didn't crash and if everybody prepared well and perfectly followed the rules, it could've been a very simple event. But that's not how human beings operate, certainly not large groups of them. They do crash. They don't pay if they don't have to. They don't care about the rules. You need to provide them with toilets and food and water. So you have to image and prevent hundreds of edge cases.

That's why hosting a single F1 race costs tens of millions of dollars. Every event is staffed by roughly 150 security officials and 130 medics and doctors. Providing cars with some tarmac is the core of the event, but it is only a very small part of the problems that have to be solved to run a serious event. It's the edge cases that swallow up time and money.


The basics of the happiness system are simple. Certain items should be consumed by colonists and provide happiness. But when actually developing this feature, we ran into a large amount of problems.

• Currently, food is consumed automatically. If certain happiness items are also food items, players will be able to control the diet of their colonists, and provide them with more or less calories. How do we prevent players from 'overfeeding' their colonists? (Solution: food is a separate category with a slider for "total calories")
  
• How do we deal with starvation? Where's the line between "not enough food = unhappiness" and "barely any food = death"?
  
• What if a diet is equally divided between four types but three of them run out? Do colonists consume more of the available food type?
  
• How does Siege Mode work in the new system? (Solution: it's changed entirely and will generate large amounts of unhappiness instead of increasing food consumption)
  
• What if a colonist cannot reach a grocer's shop for his daily "happiness package", including food? Currently, food is instantly teleported into their bellies, so starvation only occurred if there was no food in the stockpile. It should happen for isolated colonists as well now.
  
• Realistically, a colonist that has had double/triple rations for a while should be more resistant to starvation. Does that happen in-game? (Solution: probably not)

These are the kinds of edge cases we're thinking of and trying to solve with good design choices. Individually, they're not very significant problems, but all these cases combined can easily fill a workweek.


Very much work-in-progress

I'd like to end with some relevant quotes from On War, a book from 1832 written by general Von Clausewitz. I am not trying to imply that organizing a Formula 1 race or developing a game is as difficult as war, but he does describe perfectly how things that are theoretically easy are often difficult in practice.

"As long as we have no personal knowledge of War, we cannot conceive where those difficulties lie of which so much is said, and what that genius and those extraordinary mental powers required in a General have really to do. All appears so simple, all the requisite branches of knowledge appear so plain, all the combinations so unimportant, that in comparison with them the easiest problem in higher mathematics impresses us with a certain scientific dignity. But if we have seen War, all becomes intelligible; and still, after all, it is extremely difficult to describe what it is which brings about this change, to specify this invisible and completely efficient factor.

Everything is very simple in War, but the simplest thing is difficult. These difficulties accumulate and produce a friction which no man can imagine exactly who has not seen War.

Activity in War is movement in a resistant medium. Just as a man immersed in water is unable to perform with ease and regularity the most natural and simplest movement, that of walking, so in War, with ordinary powers, one cannot keep even the line of mediocrity. This is the reason that the correct theorist is like a swimming master, who teaches on dry land movements which are required in the water, which must appear grotesque and ludicrous to those who forget about the water. This is also why theorists, who have never plunged in themselves, or who cannot deduce any generalities from their experience, are unpractical and even absurd, because they only teach what every one knows—how to walk.

It is therefore this friction, or what is so termed here, which makes that which appears easy in War difficult in reality. As we proceed, we shall often meet with this subject again, and it will hereafter become plain that besides experience and a strong will, there are still many other rare qualities of the mind required to make a man a consummate General."

Bedankt voor het lezen!

Reddit // Twitter // YouTube // Website // Discord

This week, we've worked on the grocer's shop. It's an integral part of the happiness system. Until now, colonist's only daily demand was food, and it was magically teleported straight into their bellies. In 0.7.0, they'll require a lot of other items to keep them happy. To get these items, they will have to visit the grocer.

The grocer's shop is a physical block that has to be manned by a colonist. As long as the position is manned, other colonists can visit the grocer and get their daily bundle of food and other happiness items.

Instead of letting hundreds of colonists storm the grocer simultaneously, they choose a random moment during the workday for their daily trip to the grocer. It would be dangerous if guards did that, so they visit the grocer at the end of their shift.

The grocer's shop doesn't have textures yet and the system isn't 100% done, but we expect to be able to show you a video next week!

It has been a while since we gave you a general overview of work that has been completed and things that still have to be done. Here's a new rough summary!



I hope we can finish happiness, trading and some unique content per biome before the end of the year. Once those features are done we can start a beta! A form where beta testers can apply will be released here and on Discord in due time.


New systems like happiness, VAT/XP and multiple colonies are merely that, systems. They're a framework on which new content, new items, new recipes, new jobs can be build. Here's a rough sketch for new content.

First period: before 1500

This is where most of the current content is set. Muskets are on the edge of this period, they're early 16th century weapons.

Possible new content that would fit in this period:

• A cook, to turn ingredients into meals
  
• Fishermen
  
• Beekeepers
  
• Chicken coops
  
• Barley, as chicken feed
  
• Olive trees and olive oil
  
• Water gatherers

Early modern period: 1500-1760

I was excited to go straight to industrial tech like steam engines, but we were warned on Discord by players like Aljetab that the change would be too abrupt. So we've been thinking about intermediate tech.

A realistic solution that could work in-game are engineers who can craft printing presses and clocks. The first mechanical clocks were installed in churches in the 12th and 13th century. They were big and often lacked faces or hands. They're not small clocks that could be purchased by colonists as happiness items.

In the 15th century, watchmakers invented spring-driven clocks that are more like modern table clocks. They became very popular in the 16th century.

Printing presses were adapted from wine presses in the 15th century. Like clocks, they became very popular in the following century, printing hundreds of millions of books.

Both technologies seem a perfect bridge between current Colony Survival and more industrial Colony Survival. Their complexity and technology is comparable to muskets, which are already in-game. But when looking at printing presses and spring-driven clocks, the core of the Industrial Revolution is clearly visible.

At the end of this period, a lathe was invented. The importance of this is brilliantly explained in this video:

https://www.youtube.com/watch?v=djB9oK6pkbA
First Industrial Revolution: 1760-1860

The First Industrial Revolution took the complex mechanical machines described above and added power to them in the form of steam engines, and used these steam powered machines to produce important items like textiles. For the first time in history, labor productivity went up dramatically.

This will become highly necessary in Colony Survival, because of the exponential nature of the happiness system. Every single new colonist adds unhappiness to every other colonist, meaning that the now grown population needs more happiness items per capita.


Rough graph to demonstrate the principle described above

To be able to sustain the exponentially growing need for happiness items, you'll need to use new machines. Luckily, these were invented IRL as well. Where the blacksmiths that are currently in-game require a significant amount of time to produce a single metal part, I'm envisioning new advanced machines that can quickly craft a multitude of a single part. This should give your economy the boost it needs.

Second Industrial Revolution: 1860-1914

The First Industrial Revolution barely required any exotic resources. Iron and coal are enough. But we'd like to integrate far-away biomes in late-game tech. Luckily, the Second Industrial Revolution provides plenty of opportunity to do just that. In this period, electrification got started, just like the use of rubber, petroleum and advanced chemistry. It's the age of light bulbs, bicycles, telephones and early cars.

End-game tech: 1914-1945

We'd like to have something special for diehards who build huge colonies, explore the entire world and research all the tech. I'm still a fan of early nuclear technology. On one hand, it is absolutely futuristic, but on the other hand, it's already outdated and a bit "retro". We don't want to add "clean", modern tech, white and shiny with touchscreens and fancy displays. We like older tech that squeaks and creaks, with plenty of switches and nixie tubes. It should be advanced for Colony Survival, but historic for players.

These plans are still rough and can be changed based on your feedback, so let us know what you (dis)like!


Last week, I showed an example of the kind of interfaces I was making while learning how to combine C# and Unity. I made some good progress this week and made a practical interface that's a lot prettier. Warning: not a true countdown!

The basics of interfaces seem easy and clear to me now. I've tried messing around with controlling 2D objects and physics, and it's pretty daunting. But I still remember how daunting simple interfaces looked to me only a short while ago, so I hope I'll pass this obstacle in the same way!

Thanks for reading the blog, and don't forget to share your opinion!

Reddit // Twitter // YouTube // Website // Discord

Fullscreen, an awesome render made by Lordis3D! Not in-game functionality, sadly

Until now, we've put most of our focus on new systems like the new world generation, multiple colonies and co-op. This week, we've turned our focus to all of the new content in 0.7.0: new jobs, new items and new science.

Old systems have to be changed to facilitate unique jobs and science in different biomes. Much of the old content was hard-coded. Zun has been working hard to convert the old systems to flexible and streamlined .JSON files. They can easily be accessed by us, players and modders alike.

The list of things that can be changed in these .JSON files is steadily growing. It's now possible to use them to:

• change the way the world is generated
  
• change how biomes look
  
• change the shape of trees
  
• add or change blocks/items
  
• generate specific complex block types easily (rotated blocks, 'job outlines')
  
• add science
  
• add or change player recipes
  
• add or change npc recipes
  
• add or change npc/zombie types
  
• add or change audio files
  
• add or change localization
  
• change textures
  
• add crafting jobs to blocks
  
• add guard jobs to blocks

We can't wait to see how modders will use this new functionality! While working on these systems Zun has taken care to prepare them for Steam Workshop compatibility, meaning that it should be easier to add workshop support in the near future.



As both gamers and game developers, we have some pretty strong opinions about games and the way they ought to be priced and sold. We're noticing some pretty disappointing trends and we'd like to share our opinions about them.


We believe a great game is a sandbox which players can have lots of creative experiments in. Which doesn't mean every game has to be an open world game; I'd say the description above holds true for a more linear game like Portal.

Such a game is fun to explore within the constraints set by the developers, but it often holds a lot of potential for other kinds of fun. That's why cheats are awesome. We feel they were a lot more prevalent in the past. Who remembers 'rosebud', 'Photon Man' and JUMPJET?

Another way to greatly extend the amount of fun you can have with a game is mods. I've played lots of Third Age Total War. A brilliant game like Rising Storm was developed in cooperation with the modding community. Both Counter-Strike and Day of Defeat started out as mods for Half-Life.

It seems like big modern games are way more hostile towards mods than they were in the past. We feel the decline of both mods and cheats share a major cause: microtransactions. You can't sell XP boosters and swords with +5 damage if players can easily cheat or mod them into your game for free!


They're fine in free-to-play games. I don't mind microtransactions for cosmetic items in multiplayer games. But pay-to-win multiplayer in a paid game is terrible, and microtransactions for important content you already bought are frustrating as well. As soon as a game introduces those microtransactions, the "grind" cannot be trusted anymore.

Many games contain some kind of grind, for XP, money or some other currency that can be spend on perks and upgrades. Grinds can be lots of fun if they're done well and there's a decent balance between time spent grinding and the rewards you're getting. But when microtransactions can be used to shorten the grind, the developers have a huge incentive to make the grind frustrating and annoyingly long. That instantly makes those games a lot less appealing to me.




Good DLC is DLC that could have been sold on a disc. Episodes from Liberty City was great GTA IV DLC, Operation Arrowhead was great Arma II DLC. Both were released a significant amount of time after the full game and contain a good amount of new content. It feels like a decent expansion that you wouldn't mind traveling to a physical shop for.

But when a full-priced game has just been released and it already has multiple DLC packages available, it feels like they're trying to nickel-and-dime you to death. If it's a cosmetic outfit that was available as a pre-order bonus, okay, but if it contains significant amounts of content it just feels like a scam.


We haven't played Red Dead Redemption 2 yet, but it has received a lot of praise and our moderator Vobbert is very enthusiastic. The game has been in development for eight years and it shows, the attention to detail is fantastic.

The opposite is releasing a reskinned, formulaic sequel every single year. $60 + $50 season pass + microtransactions. It feels like a cynical attempt to milk your cash cows. In the end, I don't even believe it really benefits the developers; for every person that is willing to buy the season pass, there might be two who are turned off from the entire game because of the exploitative business practices.

Rainbow Six Siege is a great example of modern, non-exploitative game development. The game is now nearly three years old but still actively supported with events and new content. The community isn't expected to repurchase the game every 12 months. New maps are released for free, new operators can be purchased with in-game money but they can also be bought with euros and dollars. There are no pay-to-win elements.




On every game's storepage on Steam, there are two big colored sentences that show how positive or negative the game has been reviewed by those who purchased it. Every sentence, every image on the storepage can be adjusted by developers, except for this. It gives the community the opportunity to confirm that what's said on the storepage is pretty true and accurate, or that there are big problems beneath the surface.

I notice that I rely pretty heavily on user reviews when making purchase decisions, especially on Steam. It's a very useful system for customers, but it can be painful for developers. You'd rather not have "Mostly Negative" in big red letters next to your title.

In recent times, I've seen big franchises that I had expected to receive negative reviews choose not to release on Steam. Of course there are valid reasons to choose for other platforms, but expecting negative reviews and wanting to hide them is not one of them.

Although it is understandable that developers want to hide negative reviews, it is beneficial for customers that they are prominently visible. We hope that reviews stay visible, and we hope that ours stay positive. Knocking on wood now :)


We expect to keep developing the game into 2020. Those who've purchased the game now will receive all new content for free, but the price of the game might increase to $25 after a big update. We won't add a microtransaction store with XP boosters and science bags available for real life money. We'll keep supporting modders. We're focusing on creating the best game we can make, instead of extracting as much money as possible from gamers. We hope this will be the most successful strategy in the end. It has been working pretty well up to this point :)




In the past few months, I've been learning some basic C#. In recent weeks, I've been trying to apply these skills in Unity. The first steps were pretty hard, but it was a lot of fun when I finally got the hang of it. I'm sticking with simple interfaces for now, instead of more game-like programs, but I'm happy with the progress I'm making. If anyone needs help on how to start programming, join the Discord and @Pipliz me!

What's your opinion on good game development? How should games be priced and sold? Have you got any advice or criticism on how we approach things? Let us know here or on Discord!

Reddit // Twitter // YouTube // Website // Discord

We've made a lot of progress this week. Most changes are minor, but to give you a sense of the scale of what's changing, I'll post the full changelog at the end of the blog. A major change is coop!

A lot of people have asked for shared colonies. With the changes that were made to support multiple colonies, it was relatively easy to add that functionality. There's no UI yet, but there are a couple of new commands to make sharing a colony easier:

• /colony addowner {player} [colony]
  
• /colony removeowner {player} [colony]
  
• /teleportother {player} here

Owners of a colony can see and use the colony's stockpile, place and remove jobs for the colonists of that colony, and select which science ought to be researched. We hope you'll all enjoy it!



Some people missed the rambling in last week's blog. We held a minor, relatively hidden poll on Discord but the results were obvious. So the democratically chosen subject this week is "How do we decide which features we'll work on?".


The one "X" under the first option was placed by me to show all potential options

Choosing features is a tough but very, very important task. We think a lot about Colony Survival, we play and analyze other games, we discuss potential features for hours on end, and of course we listen to suggestions made by our players. We've also watched many, many hours of Colony Survival-gameplay on YouTube. It's very insightful to see how others people approach the game.

When comparing potential features, we ask certain questions about them. We'll only proceed with the feature if all answers are positive. My mind visualizes it in a way I encountered earlier, when reading about the Japanese concept of "Ikigai". Ikigai is your reason for being. Instead of seeing your job, your hobby and 'charity' as distinctly different parts of your life, Ikigai combines all of these concepts: it's something useful that you're good at and that you love, and something you can earn money with. If you've found that, you've found your reason for being.


Kind of stealing this image, it's floating all over the internet, sources are at the bottom

I think "a good feature" can be visualized in a similar way. There are four main questions that must have positive answers for the feature to be considered worthwhile. They concern these aspects:

• Gameplay: a new feature should add quite a bit of it
  
• Development time: this ought to be balanced with the amount of gameplay it adds
  
• Performance: we're striving to make the game run better, not worse
  
• Future: some changes make future changes easier, others make it harder

This results in an image like this:



Every possible feature can be assigned a location somewhere in this chart. The closer is it to the center, the higher the chance it'll be added to the game!

FUTURE
This might be the least obvious part of the graph. An example. 0.3.0 added the science system to the game. It was pretty simple and boring at the time, but it was majorly expanded on and very useful in 0.4.0. The science system is a very important framework for other features, and thus it scored very high with this question.

Other features score pretty low here. Many players would love to see a more beautiful tech tree with a clearer structure. That's a very sensible demand, but it'll make tweaking and updating the tech tree a lot harder. As long as we're still regularly adding new science, the tech tree itself won't change a lot. Not in a way that makes updating it harder, at least :)

PERFORMANCE
Colony Survival works on relatively old and simple hardware, and we'd like to keep it that way. Up to this point, it looks like 0.7.0 will actually increase instead of decrease performance, because of certain optimizations.

A common request is transparency. We've experimented with this for a bit in the past, and it resulted in a significant performance hit. We try to avoid those as much as possible.

DEVELOPMENT TIME
This can be very hard to predict. Some changes are very easy. New "job blocks", new crafting recipes and new guards with different damage/range/reload speed stats can be added in a couple of minutes/hours.

More complex features will take longer. And there's the basic software development problem that's it very hard to predict how long exactly you'll need. You'll often run into unexpected problems. And apart from technical problems, you'll often cause problems in the gameplay even if it technically works. For example, it took us a while to realize that "high happiness costs for big colonies" and "players can start multiple colonies" will result in the optimal gameplay strategy "start lots of tiny colonies instead of developing a big one", which is boring and repetitive. So we had to find the VAT/XP idea to incentivize players to grow their colony despite the happiness costs.

GAMEPLAY
Perhaps it's better summarized as "how many hours of fun will this add". A better tutorial might not really be 'gameplay', but there's a significant percentage of players who quit within an hour, who might've played the game for a lot more hours if the tutorial was better. Hello jacksepticeye.

Better graphics/animations might also result in more hours played, but I doubt someone who has experienced all the content and quit the game after 60 hours will come back for dozens of hours because the colonists walk slightly more realistic. Animation/modeling is not one of our strengths, so you quickly end up with a bad ratio of development time vs. results.



The requirements above might sound terribly restrictive, but they have to be. Suggesting a feature is very easy, implementing it is often very hard. There are many things we'd love to add, but we can only do so much in one month or one year. We have to carefully pick the features we do work on.

There's one extra important thing to consider for 0.7.0: breaking older worlds. It's something we generally try to avoid, so it's a negative quality if a feature requires that. But the new world and the new features in 0.7.0 will inevitably break older worlds. (You can always revert to older branches to replay older worlds!) That means that 0.7.0 is a great opportunity for all these features that break savegames to finally be added! That's one of the reasons why it takes so long.

Last but not least, here's the promised full changelog of the three new dev branch builds that were released this week, to give you an indication of the scope of the changes:

- reworked network code a bit to better handle timeouts/disconnects (without throwing errors like before :upside_down: )
- prevent starting a colony near another colony (both should have unique access to 200 blocks radius)
- moved out some banner settings to settings/server.json (loaded chunks radius, max zombie spawn radius)
- autoremove colonies without a banner (will require some UI to allow moving a banner later)
- probably fixed zombies spawning in safe areas (hard to check with the exlusive access area)
- fixed a bug where removing a specific rotation of the end of a bed did not remove the other half of the bed
- changes sapling trees to grow 1 higher (so the forester can walk through his field if there's any elevation changes)
- fixed steam server 'score board' for the active players list
- removed use of beds/crates outside of the colony radius
code things:
- merged the chunks' data & AI readwritelocks into one
- removed some unused code from IChunkData
- changed OnPlayerMoved callback to also take the old position as an argument
- changed banner/close-player chunk load requests to use some bitarray lookup table thing instead of a queue (so requests are not duplicated, allows loading in a way that makes the terraingenerator much happier)
- changed ServerManager.TryChangeBlock, World.TryGetTypeAt and World.TrySetTypeAt:
-- now take an optional old expected type to get rid of race conditions from seperate read and write actions
-- returns an enum with multiple options instead of a bool
-- updated/expanded the flags enum that controls the behaviour of these methods
-- the "cause/requestedby" argument is now a union struct containing either a player or a colony (instead of only player causes)
- changed OnTryChangeBlock callback to have the same union struct as above
- added OnUpdateAdjacent callback to blockentitycallbacks
- changed block entity's on block change callbacks to use that player/colony union struct
- removed the old ItemTypesServer.OnAdd etc system, replacing it with the block entities callbacks code

known issue:
- blocks that require a solid block below them currently do not disappear if that solid block is removed (i.e, remove dirt below quarter blocks / plants)

- fixed an error when trying to update the steam server score of a player with no colonies
- reworked the chat command class interface a bit (includes a list<string> of "words" so not every command has to split the sentence up itself)
- fixed the "needsbase" check - blocks removed due to removal of the solid block below them (plants, quarter blocks etc) are now removed again, and will be refunded to the player or stockpile if possible
- added a few new commands:
-- /colony addowner {player} [colony]
-- /colony removeowner {player} [colony]
-- /teleportother {player} banner
-- /teleportother {player} here
-- /teleportother {player} {x} {y} {z}
- extracted some code from chat commands into the command manager, so all {player} options now allow either the steamID64 or the name
- multiple owner colonies seem to be working as intended based on initial testing
- fixed the cursor visibility bug (unity undocumented API change, it still says Note that in CursorLockMode.Locked mode, the cursor is invisible regardless of the value of this property. )

- fixed dedicated server wrapper
- allow using the older style +server.world blabla etc arguments to launch the colonyserver (so it works on pingperfect)
- fixed initial inventory for players (untested, woops)
- fixed initial stockpile for colonies
- added icons & names to the grass types, and they should drop themselves now instead of their parent
- added icons & names to the leaves types
- updated leavestemperate icon
- fixed server world loading menu order
- fixed singleplayer world loading menu order

Bedankt voor het lezen!

Reddit // Twitter // YouTube // Website // Discord

Until the end of last week, we were fully focused on the new terrain generation. We released three successive videos without a single colonist in sight. When we finally tried to build a colony in the new world, we immediately encountered problems. The biggest problem was the lack of flat space. We knew there would be less in the new world, but we hoped there would be enough to build a colony that's big enough to unlock builders & diggers.

There wasn't. But instead of changing the terrain generation, we thought we could add "farms with verticality". In real life, farmland isn't often perfectly flat either. Why should it be in Colony Survival? Zun worked on this problem during the weekend and we quickly had results. I think it's both visually pleasing and highly practical!

One of our most prolific builders, Boneidle, used the new world and the new farms to build an awesome castle. We made a video to showcase the new feature and his world:

https://youtu.be/2t07K9_QuBs
With the farms working in the new more hilly terrain, we could test other features. It turns out quite a lot is still broken. This is partly caused by the new save game system introduced with the new world generation, and partly caused by multiple colony support.

In the past, every job and action was saved as owned by a certain player. Crates, beds, colonists and builders and diggers are all placed and thus owned by player X/Y/Z. With the multiple colonies, this isn't true anymore. Each colony has its own stockpile, its own beds, its own crates and its own jobs.

What happens with colonists and jobs far removed from any banner? What happens if you remove a banner? These are all new issues introduced by multiple colony support, and we've got to find solutions for each of these problems.

Apart from issues like these, there's a pretty long list with broken stuff. Crops didn't grow anymore; beds were used for only one night; torches were bugged, and much, much more. It's pretty boring and frustrating, but highly necessary.



While Zun was working on bug fixes, I've been trying to improve my programming/Unity skills. I'm far from skilled, but I feel like I've got a basic grasp of programming and can do some fun stuff with it. It's all text-based though. I'd love to make more visual programs, with a UI. So this week, I've been trying some more complex stuff in Unity.

I've followed the UI tutorial on Noobtuts.com, followed by an attempt to recreate Pong. I can see a lot of possibilities, but I'm still an absolute beginner. It's hard to wrap your head around certain concepts, but I'm sure I'll manage to eventually. I hope to release some fun software of my own design in the future :)

Bedankt voor het lezen!

Reddit // Twitter // YouTube // Website // Discord

We were pretty happy with the continents as shown in the previous blog, but we had also spotted some room for improvement. There was one major problem: a lot of biomes looked pretty similar. It wasn't immediately clear when you had arrived in a different biome.

A good thing was the combination of different trees. In certain areas, there is a mix of pine trees and deciduous trees, and we love how that looks. We suddenly realized we could use this as a solution to our problem of biome distinctiveness! Trees with different colors can make a biome look better, ánd it helps to visually separate the biome from others. Here's a video to show the new look of the biomes:

https://youtu.be/LMaFZ8I2Xg8
What do you think of the changes? Let us know!

We finished the important changes to the world generation this week. We decided to test it by starting a new colony without cheats. It was highly frustrating. Look at this area:



It looks relatively flat, right? I thought it was a great spot to start a colony. But when seen from above, a problem becomes obvious:



There's barely any flat space to start a 10x10 wheat field! I discussed with Zun whether it was easy to add more truly flat spaces, and he answered "no". He quickly came up with a different solution to the problem: allow players to create fields on areas that aren't flat! In real life, there's plenty of farmland that isn't 100% flat. It takes some tweaking, but it should definitely be possible to let players start non-flat fields in Colony Survival. We hope to be able to show it next week!


Last week's blog generated quite a lot of questions, and here we'll answer some!

#Discussions_QuoteBlock_Author

But the card is very small right?

You flew from the south to the north in 1 minute?
That is very small. The map should be 10x that big.

Multiple people complained that the world looked small in the video. I nearly made a video of me walking from the far north to the deep south, but I quit that after I noticed how many gigabytes of footage that would require!

It looked small in the video, because we were using cheats to fly rapidly ánd we were fast-forwarding the video. We can assure you that the world ís big if you're traversing it by foot. If you're still unsatisfied with the size, it can easily be increased in the settings!

#Discussions_QuoteBlock_Author

Looks great, when can we expect to see some sort of alpha/beta to test this stuff?

Modders already have access to the latest dev branch of 0.7.0. We're now focusing on essential features (happiness, unique content per biome, trading between colonies) and will start a beta when those are done. We'll release a form where everybody can apply when the moment is there!

#Discussions_QuoteBlock_Author

i know you probably wont read this but what are you doing for the longevity and replayabilty for the game? it seems once you complete all the sciences that there is not much reason to continue playing and there doesnt seem to be much replay ability since it will always end up the same way?

We did read it :D Many players already spent 20-40 hours on the game, mainly unlocking all the science and building a big colony. 0.7.0 will add lots of extra content, exploration, multiple colonies, new science, and features like happiness and XP/VAT. It should occupy players for a long time! :)


We didn't have much to show in Friday Blog 66 and 67, so I filled them with semi-philosophical ramblings. I expected people to be happy when Blog 68 returned to actual progress updates, but there were actually many people who missed the rambling! I'm glad some of you enjoy it, and here's some more rambling about the things that I've been pondering about.

I've been gaming for roughly 20 years, and I've always thought and talked a lot about them. But now as a full-time gamedev, I'm even more in some kind of "analytical mode" when playing games. In the past month, I bought two AAA games, Far Cry 5 and Forza Horizon 4. While playing, I tried to carefully consider why I wanted to keep playing or why I felt 'done'. It forced me to think about the essential nature of meaningful gameplay, and about meaning itself. And when we're talking about that, we quickly end up with Jordan Peterson:

https://youtu.be/_7poPzW1u-U
In the video, he talks about the yin and yang symbol. One half stands for "order" and "the known", while the other half stands for "chaos" and "the unknown".



It seems obvious why you'd want "order" and "the known" in your life. You don't want to live in a chaotic mess that you cannot deal with.

But it's not as simple as it seems. The white side of the symbol, yang, is characterized as many things. Not only order and the known, but also "masculinity", "day" and "authoritarianism". It is not characterized as good. The black side, yin, is also characterized as the night, femininity and decadence, but not as bad.

Apparently, both sides have a purpose. And it's obvious when you think about it. We might strive towards more order, but we also love the unknown, 'chaos' and surprises. We don't want to do the exact same thing every day. We want to learn new things, do things we've never done before, discover places that we've never visited!

Our lives feel meaningless when we're in a constant chaos that we cannot get a grip on. But our lives also feel meaningless when we have the exact same repetitious rythm, day in, day out.

Jordan Peterson advises "you should construe yourself as the process that mediates between chaos and order". That's when your life becomes meaningful. In one part of your life, you should build order and knowledge, but simultaneously, there ought to be a "frontier" where you're confronting the unknown and learning and doing new things.

I think the principle above absolutely holds true in gaming.
If you're being shot at from all sides, and constantly die random and unpreventable deaths, it's pure chaos. You'll quickly tire of the game.
If you can predict exactly what is going to happen, and you're just going through the same motions over and over again, it's pure order. You'll also stop playing.

A game is fun as long as it can simultaneously give you a feeling of increasing order and knowledge and the idea that chaos and "the unknown" are still present.

These demands are pretty contradictory. As order increases, chaos decreases. Once you've unlocked all technology, beaten the last boss, explored all levels, chaos is 'gone'.

Of course, you can always add new levels and expansions. But I think the best games that people spend the most hours in don't rely on that. Games like The Sims and Rollercoaster Tycoon have complex systems that continuously generate new challenges, and it's not obvious when you've "completed" them. Both games contain many relatively simple and obvious systems, but when you combine those systems, the result of their interactions is often unique and engaging.

We want to do something similar with Colony Survival. We don't have a big team and we don't have fantastic artistic skills. We can't make an epic photorealistic cinematic experience that lasts three or five hours. But we can try to make deep and complex systems that keep challenging and surprising players in the long run. There are already plenty of players with more than 80 hours of playtime, and there's even a sizeable group who've played CS for over 200 hours. We hope to grow those groups in the future :D

Bedankt voor het lezen!

Reddit // Twitter // YouTube // Website // Discord

In many games with randomly generated terrain, there is no overarching logic to the world. If you want to find a specific area, your best course of action is to travel as far as possible in a straight line, and eventually you'll encounter the terrain you're looking for.

While this system has benefits, we've got a different idea. We want the arctic to be in the north, and the tropics should be in the south. If you're looking for those areas, you'll always know in which general direction you should head.

So during the past weeks, we've been working on a system to generate unique, random worlds which still conform to general, overarching rules. The result can be seen in this video:

https://youtu.be/HIjeNA-JCjc
We're very happy with how it has turned out! We'd like to allow people to explore all directions, so there is a "New World" in the west and a "Far East" in the east. These other biomes should have unique resources, to encourage players to explore and settle new lands.

It would be a bit weird if you could build two colonies right next to each other, but on opposite sides of the "biome border", allowing you to acquire all the resources of two biomes in one big "double city". That's why all the "useful" biomes are separated from each other by "useless" biomes.

• You need to traverse the tundra before you discover the arctic
  
• You need to cross the steppe before you discover the Far East
  
• You need to survive the desert before you discover the tropics
  
• You need to sail across the ocean before you discover the New World

To finetune these regions, Zun created a system which allows server hosts to print a map. Here is the map of the world in the video:


Fullscreen

When printing the map above, you automatically print three other maps with data for height, rainfall and temperature. They can be seen here: https://imgur.com/a/z8NBDaq

Nearly all the settings for the new world generation can be easily changed in a couple of .JSON files. The world in the video is 12,000 by 12,000 blocks, but that size can be changed quickly. You can generate a smaller world if you don't like traveling, or you can generate a much larger world if you and your friends need more space. The amount of trees, the height of mountains, the size of the seas, the color of the grass: all of it can be changed, and we can't wait to see what you'll come up with once 0.7.0 has been released!

Bedankt voor het lezen!

Reddit // Twitter // YouTube // Website // Discord

A couple of months ago, I wrote that I wanted to learn to program. The first couple of steps of programming are lots of fun to learn. You learn commands like Console.WriteLine, which allow you to let your computer "speak". Vice versa, Console.ReadLine lets your PC read your input. It's exactly the kind of stuff I expected to learn.

But as I progressed, new lessons started to subvert my expectations. Instead of teaching me new commands that allowed me to try new and exciting things, all the tutorials started to focus on abstract methods used to "organize" your code. That's not at all what I was interested in! I gave up and focused on other tasks.

Subconsciously, I approached programming like it was magic from Harry Potter. I thought experienced programmers, like Zun (the programmer on our team who has written the code behind Colony Survival), just knew a whole lot of "spells". I expected programming lessons to be like magic lessons at Hogwarts, learning a couple of new spells every day.



And at the start, that's pretty much what it will be like. Here's a piece of real, functional code:



When you run this piece of code, a console window will open and ask "In what year were you born?" Type "1993", press enter, and your PC will set "birthyear" to "1993". In the next line of code, it will set "age" to (2018 - birthyear) = (2018 - 1993 ) = 25. The final "Console.WriteLine" will print that age to the screen.

That's pretty awesome, right? It's relatively simple and does something useful. But... it only asks one question, gives one answer, and then it stops. Let's make it more interactive! We can start by asking what the user wants to do. If he responds with "calculate age", we can continue by asking him about his year of birth. If we create a loop with while {} and put the code between the brackets, the first question will be repeated when the end of the code is reached.

New problem: the code is too long to Photoshop onto one scroll. Now we've got to do the dreaded thing that frustrated me so much. We've got to work with "methods". I'll admit that it's pretty useless in this example. But it's crucial in larger projects, so please bear with me!

A "method" is a block of code that can be executed by using its title. So the code from the previous example can be copied to a different location and titled "calculator". When I type "calculator()" in my main code, it'll execute the full block of code saved under that title.


Fullscreen

It's becoming more complex now, but I hope the explanation above makes the basics of the concept pretty clear. There's one last concept I'd like to explain before I come to my conclusion, and that's structs. They're a way to save more complex information in an organized fashion. The basics of a struct look like this:



On the left, a general format for saving "game information" is defined. On the right, an example of specific information that can be saved in that format is shown. The struct isn't limited to one set of data, it can hold many more. The code on the right scroll can be followed by for example:

game Skyrim;
Skyrim.Developer = "Bethesda";
Skyrim.Releaseyear = 2011;
Skyrim.EarlyAccess = false;

A variable like "TimeSinceSkyrim" could be used like this:

TimeSinceSkyrim = ColonySurvival.Releaseyear - Skyrim.Releaseyear;
Console.WriteLine($"Colony Survival was released {TimeSinceSkyrim} years after Skyrim.");

All of these concepts are interactive. Structs can be used in methods, and methods can be used to fill structs. Using these concepts, you could write a more complex program that can sort games by age, or another one that provides users with a list of all games by a selected developer.



Structs can be used inside of structs, and methods can be used inside of methods. A complex program can quickly become an intricate web where everything is connected to everything.

That seems to be the difficulty of learning programming. It's not like learning magic or a foreign language. It's not about learning spells or acquiring a large vocabulary. It's about organizing complexity and understanding abstract connections.

If you're writing your own code, you're the one who has to decide how data is saved and used. You've got to determine which blocks of code will be split into methods, and which won't. Creating a good but complex program requires a lot of thought before the first line of code can be written.

Pretty often, your first plan won't be perfect and you'll learn that you've got to reorganize parts of your code. This is called refactoring. Sometimes code is refactored to prepare the game for new features, sometimes it's done to optimize performance, and sometimes refactoring can help mod developers.

The oldest code for Colony Survival was written in 2014. Since then, Zun has learned a lot. His programming skills have improved, and we've gotten a lot of feedback from mod developers and users with different kinds of hardware. This means that there is a lot of potential for improvement when working with older code. Instead of quickly hacking a new feature into the game by adding it on top of flawed code, Zun has the habit to rewrite older code to make it more useful, more stable and more optimized. It does take more time, but we believe it's worth it!




In the last video of the new world generation, there was no logic behind the location of biomes. That has changed dramatically! There's a cold north and a hot south, with a gradual transition between them. A dry steppe separates the spawn region from the far east. There's an ocean between the main continent and a new continent in the west. Every world is still unique though.

The code behind the terrain generation has been refactored. It's quicker now, and it's possible to change certain settings. Among others, the amount of hills, the "depth" of the world, the water level, the size of the world, and the amount of rivers can be changed.

To-do list:

• A nice in-game menu to change those settings
  
• Some new trees
  
• Some simple rock formations
  
• A simple map (mostly for us, not in-game) to help us fine-tune the continents
  
• Grass shouldn't grow on cliffs

I was hoping to show a video of the latest version of the world generation today, but we've decided to postpone it to next week. The changes above will make it look even better!

For the non-programmers: Did you have the same expectations of programming as I did? Does my explanation make any sense?

For the programmers: Does what I wrote actually hold true in your experience?

Bedankt voor het lezen :)

Reddit // Twitter // YouTube // Website // Discord

Game of Thrones is one of the most popular series on earth, and like many others, we've watched all seasons. Many episodes are absolutely brilliant. But like anything in life, it isn't perfect, and it has received criticism. This week, I was watching a video that criticized the development of a certain character, and when I thought about it, it reminded me a lot of the problems we're experiencing with 0.7.0. I'll try to keep the Game of Thrones spoilers to a minimum!

In GoT, there are two important continents. There's the "main continent", that receives roughly 90% of the attention, and a second continent that gets the other 10% of screen time. One of the most important and beloved characters spends the first four seasons of the show on the first, main continent.

It's great television. The main character is very interesting and entertaining. But the world he inhabits is highly compelling as well. The other characters are complex and have deep interrelationships. There are important and violent political problems with sensible motivations on both sides. And we know a lot about the "background" of the world. We learn about the most prominent religions, we learn how the rich and the poor live, we know about the history of the continent.

Watching our main character interact with this world is fantastic. But in the fifth season, he moves to the 'second' continent. Of course, this continent is also populated with interesting characters and political problems. We do learn some things about that world. But it lacks the depth and complexity of the primary continent. And our "main" character suffers for it. He's a lot less important and interesting on the second continent.

I don't think it's caused by any changes to the character. The actor is still amazing, the character is still very witty. But he's missing the deep and complex world to interact with. Apparently, the second continent is way more detailed in the books, but when converting the story to television, the showrunners had to cut characters and storylines.



With many things in life, returns are proportional to investment. Study hard, and you'll learn a lot. Work hard in the gym, and you'll lose weight and/or become stronger. It's also very often true in game development. We could easily release weekly updates with new cosmetic blocks, new jobs or new items. It's simple to add a new guard that does more damage or has a lower reload speed to Colony Survival. But we're sure that doing that every week will quickly result in bored players and a cluttered game. Developing new and complex features will probably result in a better game, but that takes time.

But it's not always that simple. Imagine you're a car designer, and you and your team have designed a pretty average car. It's good, but not particularly fast. So you spend months or years integrating an engine that has thrice the horsepower of the old engine. You've put a lot of effort into it. But is the car better? Arguably, it's worse. It lacks the brakes, the tires or the safety features to properly handle its new power. You have dramatically improved one aspect of the car, but it has only caused a lack of balance. Now you need to upgrade the rest of the car as well, turning a minor upgrade into a major redesign.

I think the showrunners of Game of Thrones faced a similar dilemma with the secondary continent. It's less interesting, so they spent less time on it. But now the viewers are less familiar with the characters, problems and history of the secondary continent, making them even less interested. It's a tough problem to solve. You need to cut some characters and plotlines when converting a book to a television show, but cut too much and the viewer won't care at all!

In my mind, I imagine a circle - or only a couple of fragments thereof. You can spend a lot of time developing a brilliant engine, but it's worthless if the rest of the car cannot support it. A main character can be very witty and charismatic, but all the effort is wasted if he doesn't have an interesting world to interact with. The engine or the main character is just a fragment of the circle, and it needs other parts before it's "fully round".

In a TV series, a supporting character can be added or removed from a well established situation without changing the "roundness" too much.
In a car, the audio system or the upholstery can be dramatically changed without affecting the "roundness" too much.
In a game, some new (cosmetic) content or complementary features can be added without disturbing the "roundness".

But add a new continent to your TV series, upgrade the engine of your car, or add a significant new feature to your game, and you've "broken" the roundness. While the change itself might be good, the lack of balance might make your product worse. But invest in the other parts of your product as well, restore balance or "roundness", and you might have just taken your product to the next level.



Colony Survival 0.1.0 to 0.5.0 all had some obvious "holes" in their "roundness". It needed more content, it needed the science system, it needed a way to let your colonists assist you in building. Plugging those holes made the game "rounder". But the latest version, 0.6.3, lacks big holes that can be fixed with fun new gameplay like the builders & diggers.

There's one dramatically underutilized thing: the large and diverse world that's barely ever explored and used by players. That's why we'll work on that in 0.7.0. But adding only multiple colonies disturbs the balance. It's not "round", it's just a fragment. You'll need a good reason for exploration as well. And a means of transport.



Separately, these features are useless. Multiple colonies need a purpose, and the happiness feature relies on the other continents. Transport is not needed in 0.6.3, why explore if you can only start one colony and it functions the same everywhere?

This is the reason why 0.7.0 is taking a while. Each one of these features is complex and significant alone, but they require each other to have a purpose. We've thought about releasing them separately, but the more we think about it, the more we realize that's a bad idea. We can't wait to see how those features will interact together!

Two weeks ago, we published a rough timeline that will most certainly change. We're still on track though! For convenience, here it is again:

September: New world generator, continents, new trees
October: Features like trading, multiple players in one colony, happiness
Closed beta starts here, we'll release a form where you can apply to become a tester
November: New crops, jobs and items + airships or boats
December: Finishing things up, patching issues found by testers, polishing, achievements

That was a long, philosophical ramble and I wonder if it makes any sense. Was it actually insightful? Let us know in the comments or on Discord!

Bedankt voor het lezen :)

Reddit // Twitter // YouTube // Website // Discord