Today marks the start of the Perpetual Testing Initiative! In the past, testing has been sporadic, limited and temporary. 0.7.0 is the biggest update in the history of Colony Survival, and it changes a lot. Dozens of technical systems have been refactored, and the update isn't finished yet. We'll need very thorough testing, and once we've set up a group of testers, why end that when 0.7.0 is released? If the testers are willing, they can test 0.7.1 and later updates as well. That's why we call it the Perpetual Testing Initiative, and not "0.7.0 Alpha" :)

We've made a form that you can use to apply to become a tester. Here are the qualifications we're looking for:

• Owns Colony Survival and has joined the Discord.
  
• At least 16 years old (GDPR rules here)
  
• Has played Colony Survival pretty extensively
  
• Good English writing skills
  
• Has time to test the game pretty frequently and to summarize his or her experiences
  
• Has "general gaming experience", can say some intelligent things about gaming in general
  
• Some technical experience
  
• Our group of testers should include a diverse range of hardware and software, for example laptops and gaming PCs, Windows & Linux, etc.

The form consists out of four pages. Page 1 is general terms of service things. Page 2 requests some personal info, like age, location and type of hardware used. The third page will probably take the most time to answer. It asks you to describe some good and some bad games, and what you like and dislike about them. The final page gives you some room to describe yourself and share info of your own choosing.

We're going to be watching the results, and we'll probably select the first batch of testers somewhere around Christmas. Don't despair if you have not been chosen! We need to know how people respond to 0.7.0 without any experience with the update, so we'll regularly need new testers to see how they react when they encounter the new features for the first time.

Testing is going to happen on Discord. "Tester" will be a new role with access to exclusive channels. That's why joining the Discord is a prerequisite to becoming a tester. You'll need to enter your Discord username in the form, and it's very important that you do this correctly. It's our only way to contact you. Discord automatically generates a four digit identification code that makes sure we contact the right person. On the desktop software, it's always visible in the bottom left. In the app, you'll need to press the three horizontal bars in the top left to open the menu where the code is visible in the bottom left as well. Please enter your full Discord name and the four digit code!



If you've read everything above, and you're willing to dive into a half finished, buggy alpha, here's the link to the Application Form! :)




A couple of weeks ago, Equilinox was released on Steam. It's a beautiful indie game made by a very communicative developer, which is scoring an overwhelmingly positive review score (we're jealous!). The game has been in development since 2015 and he's been documenting the entire process in weekly devlog videos on his YouTube Channel.

Equilinox features hundreds of different plants and animals. They've all got their own unique preferences. It starts out simple, with some sheep and grass. To unlock new species, you need to accomplish a diverse range of tasks. Use selective breeding to evolve larger species or new colors. Provide nuts to your squirrels, let fox hunt chickens or harvest honey. Eventually, you'll be running large and complex ecosystems!

We're organizing a contest that allows you to win 1 of 10 free copies of Equilinox. Equilinox is all about providing your plants and animals with a suitable habitat. Up to this point, that has been pretty unimportant in Colony Survival. Working all day and spending their nights in a dark cave with 1000 beds crammed together is not a problem for your colonists. That won't hold true in the Equilinox Contest! To win the game, you'll actually have to display some tender loving care for your colonists. Design a world you'd actually like to live in, make a beautiful screenshot, and post it in the #submissions-only Discord channel. The ten best screenshots win a free Steam Key for Equilinox!

You need to get the "verified" role in Discord before you can submit images. Post a simple message in #introductions or #general and as long as it's not in the middle of the European night, you'll be verified pretty quickly.

Rules:

• You're allowed to post only one submission. You're allowed to remove it and upload a new one when the old one is gone.
  
• Submissions have to be uploaded before Christmas Morning, December 25, 10AM Central European Time.
  
• You're allowed to use mods
  
• You're not allowed to use the 0.7.0 development branch
  
• You're allowed to use Photoshop or similar software to edit the image

An "opposite" contest is also going to be organized. ThinMatrix, the Equilinox developer, is organizing a contest to win Colony Survival keys! He'll upload a new devlog with the required information this Saturday on his Youtube Channel.




Last but not least, we've continued work on 0.7.0. One important new feature is "local servers". We got quite a lot of complaints about the server tool, because it required people to dig in their program files and launch external software. We've now developed a server that can be launched from the main menu! The biggest drawback is that it'll end when people quit the game, but that's not a problem if you just want to play co-op with a friend for a couple of hours.

Work on the happiness feature has continued as well. We're redesigning the entire early game to accommodate the new features. Some new jobs and items that have a high chance of being added in 0.7.0:

• Beekeepers (honey/wax can be used as a cooking ingredient and for wood polish, bow strings, wax tablets and candles)
  
• Olive trees and olive oil
  
• Water gatherers
  
• Fishermen
  
• Cabbages
  
• Chicken coops
  
• Books
  
• Jewelry

So, lots of things to do in this Friday Blog. Apply to the Perpetual Testing Initiative, check out Equilinox and participate in the contest, and let us know what you think about the proposed new content!

Bedankt voor het lezen!

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

Built by Boneidle

Wow, this week went by quickly! I'm finally starting to get a grasp on Unity and I'm very happy with the results I've managed to get. While I was leveling my Unity skills, Zun has continued to work on the happiness feature.

The UI is still primitive, but 'behind the scenes' a lot of progress has been made. The Happiness Menu now calculates a total happiness and the recruitment cost of colonists varies based on this happiness level. The causes of happiness and unhappiness are shown to the player. We added a setting to toggle happiness off.


Work in Progress

Now that the underlying systems are mostly functional, we're planning to add new content next week. We had hoped to get the "colonies with unique content in other biomes + trading" features ready before the end of the year, but I doubt that'll be 100% finished in 2018. Anyhow, there's a bunch of new features and testing them on a diverse range of hardware is always useful. We're still thinking of opening the beta (perhaps alpha is a better word) to the first group of testers around Christmas. It won't be a short, single event: the beta branch will be continuously updated.

We're preparing a form where all who are interested can apply. We're pretty sure the GDPR applies to the kind of data we'll be trying to gather, so we've got to figure that out as well. Short timeline:

• 7 December: today
  
• 14 December: next Friday Blog, probably includes Beta Application Form
  
• 21 December: last Friday Blog before Christmas

A screenshot from this week's game-experiment

When I first started learning programming and Unity, I had set my expectations very low. I would've been happy if I was able to make a half-decent interface by the end of 2018, and a very primitive game after more than a year of experience. But the basics are pretty intuitive, and Unity is a lot more user friendly than I thought on my first try. It's very exciting and I've been pretty addicted this week. Here are three short clips from my evolving prototype:

Prototype 1, when the AI navigation works
Prototype 2, with more weapons, a more walls and a hilarious spawn bug
Prototype 3, moving camera, more graphics effects

At the moment I'm still afraid that applying my current programming/Unity skills to Colony Survival will do more harm than good, but in a couple of months I might have enough experience to work on for example the interface. I'm looking forward to it!

I've gotten quite a few questions about which resources I used to learn these things. Everybody learns in a different way; there are books that were tremendously useful for Zun that I couldn't stand, and vice versa. You've got to find the things that work for you specifically, but this is what worked for me:

• The C# Programming Yellow Book by Rob Miles
  
• NoobTuts Unity UI tutorial
  
• Catlike Coding Unity Tutorials
  
• Brackeys Unity Tutorials

These resources + lots of Google + lots of asking other people (thanks Zun!) will get you pretty far :)

Bedankt voor het lezen!

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

Zun has worked pretty much non-stop since the previous Friday Blog, because he was having quite a lot of fun fixing some networking problems. In the past, connecting to other servers relied on a Steam Networking API. Zun rewrote it in such a way that we're not reliant on Steam anymore for networking. This has the following benefits:

• LAN support.
  
• Connecting to a server goes quicker
  
• A Steam non-public server is truly non-public now
  
• Network packets are now compressed and bundled, resulting in 10-30% less network traffic
  
• Useful preparation for improved co-op features
  
• Solved the biggest problem in porting Colony Survival to non-Steam platforms like GOG, Xbox and Playstation

I'm sure most of you had preferred to see progress on actual features instead of technical behind-the-scenes stuff, but it's pretty important to do this now. It needs to be tested thoroughly, so it should be finished before we start the beta. And because it breaks compatibility with older servers, we want to include in 0.7.0. Updates that break older saves and servers ought to be rare.


Luckily, modders are coming up with brilliant content. The update that we're currently working on, 0.7.0, has significantly improved mod support. Modders are already using these new tools to develop great additions. Pandaros, who started the Settlers Mod, has made good progress on two interesting features.

The first new feature is a 'blueprint builder'. It allows you to choose a blueprint of a specific building and let your colonists build it. Because of a small error, my colonists built their first cathedral sideways, but it's still great to look at! Click here and here to see the cathedral while it's being built.



The second new feature developed by Pandaros is the Colony Management Menu. Lots of players have asked for a menu where they could see how many colonists worked a certain job, and the ability to recruit colonists to or fire them from specific jobs. 0.7.0 gives modders the ability to develop their own menus, and Pandaros developed exactly what was demanded before we got to it ourselves.


Fullscreen

For those who fear that we're going to rely on modders to add content and finish the game: that's not going to happen. We're still committed to making the base game as good as we can, and that does include blueprint builders and better menus to manage your colony.

A couple of weeks ago, I wrote that I initially expected programming to be like magic, but that that turned out to be wrong. Well, I was wrong about being wrong. When you write code, followed by objects moving in 3D according to that code, it does feel like magic. And quaternion does sound like a magic spell! I made my first little game this week and I'm very excited about it. You can watch some gameplay here.


We've currently got automagical crates. Put something in a crate and it will magically appear in the stockpile which can be accessed by any other crate. This means you don't have to worry about transport while building your colony. It doesn't matter how you create your production chain, as long as all jobs have crates nearby. You could mine ores underground, smelt them in furnaces in a high tower moments later, retrieve the metals seconds later in an underground blacksmith and instantly send the new arrows towards your guards.

This does help to keep the game fun and understandable. But it also dumbs down mechanics that could potentially be very interesting. If you actually have to transport items from one place to another, the layout of your colony suddenly has a lot of impact on your production.

It could also make features like small trains that bring items for one place to another relevant. Imagine a train bringing ores from an underground mine to a factory, and transporting metals from the first factory to a different one. I believe this could potentially be a great feature.

At first we were planning to do make the crates more realistic, but we ended these plans when we got feedback that the game was too complicated. We've tried to streamline the early gameplay, and these complaints have pretty much stopped. Now we're pondering about it again. A big update after 0.7.0 could potentially focus on it.

So we'd love to have your opinion! What do you prefer? Easy, automagical crates, or more realistic transport demands that allow features like trains for cargo transport to be relevant?

Bedankt voor het lezen :)

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

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