Update 0.7.2 is now available for everybody! The biggest change concerns lighting, especially torch/lantern lighting. Torch lag was a frequent complaint. Torches aren’t significantly faster per torch now, but they do cover a bigger area. This means you need less torches per colony, which does improve performance.

Ambient lighting has also changed - it’s dynamic now. The game will constantly analyze your surroundings and determine the appropriate level of ambient lighting. This means caves are finally dark!



Another common complaint was the too much bloom / blocks like sand being way too bright in the sun. This has also been dramatically reduced. 0.7.2 contains a bunch of other simple fixes and improvements like this. For example, you can now activate your ‘player light’ by selecting a torch or lantern in your hotbar. Colored lanterns each have a unique effect! Text rendering in the chat menu has been improved, and there’s now a scrollbar allowing you to check older messages.



For a full list of all changes, see the in-game changelog. Let us know how you feel about the update in the comments or on Discord! Does this fix common issues? Do you like or hate the new lighting? How is the performance? Did new bugs appear?

Bedankt voor het lezen en veel plezier in 0.7.2!

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

PatateNouille's castle with the new lighting

With the new lighting done, focus has shifted to some small but necessary tweaks. The biggest changes happened to the chatbox - it finally has a scrollbar, among other improvements! Here’s a full changelog of this week’s progress:

----------------------------------------------------------------------

• Added "/debug texturecheck" - spawns all blocks that have no mesh but have a texturemapping set around you (requires cheats on)
  
• Added "/debug generateiconmapping {path/to/icons} {path/to/mapping.json}" - generates a types json file filled with overrides for types where the icon file name matches an icon file in the indicated folder (requires cheats on)
  
• Added "/debug generateiconmapping {path/to/albedo} {path/to/emissive} {path/to/normal} {path/to/height} {path/to/result_mapping.json}" - generates a texture mapping json file filled with mappings overriding existing ones where the texture files match files in the indicated folders (requires /cheats on)
  
• Added "/colony printhere" - prints a list of unique colonies overlapping your position
  
• Added "/colony setleader {player} [colony]" - sets the player as the leader of the colony (duh)
  
• Fix mods not being shown in the server browser if they did not have a dll associated with them
  
• Redid client chat box:
  -- Use the new render method for text (no more blurry text)
  -- Add the ability to scroll, and keep some history
  
• Added the ability to scroll to the server interface log, and keep some history there
  
• Added "/teleport player {name}" - teleports you to that player if found (even if offline)
  
• Added "/teleport spawn" - teleports you to .. spawn
  
• Added "/setspawn" - sets .. spawn
  
• Added rotation support for sending positions to the client
  
• Added rotation support to spawn position setting
  
• Saved player rotation on exit & load it back
  
• Fixed trading menu breaking when making a rule with a few added zeroes to the standard billion item limit
  
• Vary chatbox transparency based on how it's opened

----------------------------------------------------------------------

We're testing a private build with a small group of players now. We'll tweak things according to their feedback, and if we don’t run into major issues, we’re planning to launch 0.7.2 next Friday!


The new torch/lantern lighting is pretty awesome :D

As explained before, I’m working to improve my C# and Unity skills, so that eventually I can work at the core of features instead of only supplying parts like models, textures and icons. Last week, I’ve been following Brackeys RPG tutorial. It’s very helpful and I’ve been learning a lot. And it’s really helpful to make me understand what things are problematic in game development - and what things aren’t.

The tutorials explain some very fundamental parts of most games: moving around, interacting with objects, storing stuff in your inventory, equipping and unequipping it. Here’s a short GIF of those things in my little project. But if you’ve got to code these things from scratch, these fundamental things are not easy.

In game engines like Unity, there is not this one single long list of code that determines how stuff works. It might sound silly, but that is how I imagined it! In reality, you can make lots of scripts, and attach them to all kinds of different items. Your enemy probably has his own script, and when he equips a weapon, that weapon also has its own scripts with unique instructions and data. And when the enemy uses that weapon to fire a rocket in your direction, that rocket also has a script that determines how it moves and when it explodes. Last but not least, when the rocket hits an objects and explodes and generates a whole lot of smoke, that smoke is probably also a separate GameObject with its own unique script attached!

As you can imagine, all of these things are related, so all of these scripts have to communicate. The enemy needs to know what kind of weapon it’s wielding, and when the rocket spawns it needs to know the position of the weapon. Etcetera, etcetera. To give an example of a script like that, here’s part of the script “EquipmentManager” in Brackey’s RPG, the tutorial I just mentioned:



This part of the code is called a “method”. This means it’s a special part of code that can be invoked somewhere else, by for example pressing a key or a button on the screen, which then executes all of the code in the method.

The name of the method is “equip”, which makes sense, because the method is used to equip stuff. Between the round brackets is written “Equipment newItem”. This means that the method accepts anything labeled “Equipment” as input, and that input can be used in the method with the keyword “newItem”.

This means that somewhere else I need to have a script called “Equipment”, and that script is used for items like “Equipment Helmet” and “Equipment Sword”. These can now be equipped by calling the EquipmentManager, invoking the Equip method, and entering the name of the specific object, e.g.: “Equip(Helmet)”. When called like that, the method will use the referenced item and its properties wherever "newItem" is mentioned inside of the method.

In the second line of code (don’t worry, I’m not going to do the entire block line by line), it defines a new Int, a number. This new Int slotIndex is set to newItem.equipSlot. This means that the Equipment script contains data called “equipSlot”.

As you can see, all of this code is highly interlinked. On one hand, it’s building a lot of structures to store data. On the other hand, it’s a complex set of interrelationships that modify and transmit that data from one place to another. And in general, these interrelationships are pretty “dumb”. The Equip() method requires Equipment specified in exactly the right way, otherwise it won’t work. This means that changing one little thing in one place might mean having to fix a dozen or a hundred other little things in as many different places.

I hope you can imagine why that can be very difficult to set up and change. The example here is from a very simple tutorial prototype, but “real” games also have to deal with things like multiplayer, savegames, translations, key bindings and mods, making the structure even more complicated.

It’s a high price, but it does come with enormous benefits! Programming scales really, really well. Compare writing 1 Friday Blog vs writing 100 Friday Blogs, walking 1 Mile vs walking 100 Miles, preparing 1 Meal vs preparing 100 Meals. As you’re getting more experienced you might become a bit quicker, but not a lot. Multiply the things above by 100 and the time and cost involved will probably also increase with roughly that number.

That doesn’t have to be true with programming. Setting up the EquipmentManager in the example above takes a pretty long time, but once that task is finished it’s a relatively flexible thing that can handle a lot of content, as long as it’s formulated in the right way. Adding new swords, helmets, shields and other equipment items with varying stats should be easy. The difference between making sure 100 pieces of equipment can be stored, equipped and unequipped properly isn’t that much higher than the cost of doing the same for 1 piece of equipment.


The tutorial world in the editor, with multiple pieces of Equipment on the ground

So, how are all these technical details relevant to you? Well, as you had probably guessed, Colony Survival also contains a whole lot of programming and scripts and complex interconnected systems. Within certain limits, they’re very flexible, and all kinds of parameters can be adjusted or content added with little effort. New items and jobs similar to existing content require barely any effort on our side. On the other hand, some changes that might sound fairly simple would actually be very costly in terms of development time and/or performance.

This is not an excuse to safeguard us against all changes. But you’ve probably noticed that there are some relatively common feature suggestions that keep getting ignored. For most of them, the reason lies somewhere in the explanation above - changing the system to accommodate that feature would just be too costly.
There’s plenty more to write about the practical implications of this. The importance of refactoring, the difficulty with changing the NPCs, etcetera. If you would like to hear more about this, please let us know in the comments or on Discord!

Bedankt voor het lezen :D

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

There's now a reasonably functional internal development build of the game with the new lighting system! As explained a couple of blogs ago, Colony Survival has two lighting values: one for direct lighting and one for ambient lighting. These values change throughout the day - to make sure that sunrises aren't as bright as the middle of the day.

The ambient lighting affects everythings in the shadows. These all had the exact same shade of darkness, whether it was the interior of a house or a deep mine. And this also means that you could track the day/night cycle while in that deep mine: the ambient lighting would pretty obviously change during the day.

The new flexible system analyzes your surroundings and tries to choose an appropriate value based on that. This means that mines are finally properly dark!



Choosing the right values is tremendously difficult. We've got to rebalance the strength of direct lighting with the flexible ambient lighting ánd eye adaptation. We don't want to change the look of the game too much, but of course we'll improve things whenever that's possible. I feel like sunrises and sunsets have become a bit 'softer' - something I mostly like and slightly dislike.



Bloom has been reduced. This is something that got quite a lot of complaints as well, with things like sand being very bright. I actually kind of liked that, so we'll probably rebalance it a some more in the coming days.

Together with the floodfill torches/lanterns, this is quite a big change to the lighting system. Performance has been optimized a lot. Update 0.7.2 is nearly ready for release, but we'd still like to do some minor UI improvements before we release it.



Bedankt voor het lezen!

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

Last week, we've asked you to participate in our survey. Over 400 people did so. Thanks a lot to all of you! The data is very useful, and lots of you left kind words and/or insightful comments at the end :) Let’s jump right into the results.



94.8% of the voters can see the benefits of our current course, so that’s good news. Only a very small minority was vehemently opposed to our plans.



It’s a tight race between satisfaction with the current art style, and a desire for a bit more realism. The opposite of the last option is a relatively popular third: some players would instead appreciate a more abstract look. Only a handful of players want a radical change from the current style, but this group is split between those who want a lot more realism and those who want to go in the opposite direction.

We’ve also asked a complex question about potential methods of monetization. You had the option to agree with multiple options, so you could simultaneously vote for example “very positive” and “contribute”, or “awful”, “cringy” and “would not contribute”. It was a bit hard to understand, but the results are very interesting - and polarizing!



We proposed two methods of voluntary donations: we could set up a Patreon account, or share a PayPal/Bitcoin donation link. Patreon was considered to be way more cringy and awful than PayPal/Bitcoin - yet the amount of people that voted they would contribute to Patreon was a lot higher than the amount of PayPal/Bitcoin-donators.

The price raise had polarized results as well. Out of 4, it’s #2 in the categories “awful”, “very positive” and “would contribute”. It also has the lowest score in “would not contribute” - which is positive.

Merchandise had more positive results than we had expected, scoring #1 in “would contribute” and “very positive” (and #2 “cringy”). We’re going to think about it and see if we can come up with something that would be fun.



The last three options are a lot less likely than the first four, certainly at the current stage of development. They all scored high in the “awful” category.



In general, a majority of players tend to agree with us, so that’s good news. An exception is the third question about the length of Early Access. We got a lot of detailed responses about that specific question. Some players argued that the “Early Access” label has a negative connotation for a lot of gamers. Because we’ve already got a decent amount of content and relatively few bugs, they thought that it would be better to lose that label as soon as possible.

Others argued that taking your time in Early Access is fine, and that the definitive release would lead to a lot of new players, and that it would be wise to provide them with the best, most polished, most impressive experience possible. We understand both viewpoints, but we tend to lean towards the latter.

The last question led to quite the discussion. It would have been better phrased as ”A moderate price with rare discounts is better than a high price with frequent discounts”.
Apart from a discussion about the phrasing, there were also interesting responses about this dilemma. Those who left feedback about this question often shared that moderate prices are more consumer friendly, but that the frequent discount strategy does tend to lead towards more visibility and more revenue. We haven’t had a sale since July 2018, and I think we’re going to take a more balanced approach after the UI updates. When we raise the price to $24.95, there’s room for more frequent 10%/20%/25% off discounts.

The last question allowed voters to input a long written answer. Hundreds took the effort to write useful, kind and often long feedback. I’ve read it all and I really appreciate it! I hope you all know that I read every single comment on every single blog, so if there’s anything specific you want to share, that’s a good place to do so. Of course, we’re also very active on Discord and try to follow Reddit/Twitter/Facebook, but it’s a bit easier for things to fall through the cracks there.



A couple of weeks ago, Zun started working on floodfill lighting for torches/lanterns. He got it to work pretty quickly ánd decently. This week, he tried to apply floodfill lighting to the sun/moon. It has been highly problematic.

Torches only need to keep track of what's happening in ~16 blocks of range. That range is a lot bigger for the sun/moon. If you build a large roof 300 blocks above the ground, that should have an effect on how those blocks on the ground are lit. So every spot in the map has to check countless spots in a long range around it. We're not going to be able to make that work performance-wise in a reasonable timescale.

Zun did think of a feasible alternative. He's working on a system that checks the air blocks in the vicinity of the player. To what degree are they lit by the sun? Do they have a straight connection to the open sky? More air blocks with higher scores translate into a higher ambient light value - this is the value that determines how dark shadows are.

So when you're in the middle of the open desert, the ambient lighting will be pretty strong, meaning that shadows on the side of blocks won't appear as harsh. When you walk into a building, shadows will appear darker. And when you descent into a deep mine, shielded from the outside world by lots and lots of blocks, ambient lighting will be (nearly) nonexistent, making those mines truly dark. That should solve two of the biggest problems that currently exist with the lighting system!

Here's our rough roadmap for the next month:

• We hope to be able to share some great pictures/videos of the new flexible ambient lighting in the next blog
  
• We hope to release 0.7.2 1-3 weeks later, which should include torch/lantern floodfill, improved ambient lighting and some minor improvements to the UI (like new sounds in the main menu)
  
• Afterwards, we want to start working on bigger changes to the UI

Bedankt voor het lezen :)

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

We'd like to start the year with a fresh survey! Answering it really helps us, and "more surveys" was much demanded in the last survey :)

Zun was happy with the look of the new floodfill lighting for torches, so he worked on optimizing the code behind it. He spent most of his time converting the code to Rust. Rust is a programming language that Zun himself will explain here:

[Zun]

Code written in C# in Unity is quick enough for most uses, but it has some trade-offs which limit it from reaching the "maximum" performance similar code can reach when written in a different language. Prime example of this is that C# is compiled to machine code every time you run it and there are strict time limitations on doing so (you don't want the game to take 2 minutes to launch), which limits the possibilities for optimizing. Another "problem" is that the C# environment is not especially aimed at maximum performance, so there are circumstances where the code could be quicker but there is no proper way of expressing what you want to do in C#.

So there are some programming languages more aimed at performance, notably C, C++ and Rust. We're using Rust because the environment around it is much more modern compared to C and C++; building on different platforms is easy with "Cargo", it has built-in systems for testing, it comes with a decent standard library. Unity itself is also developing their own language (Burst compiled C#) to use for this exact use case, but at the time of writing it seems to be somewhat work in progress.

Of course C# has it's merits as well - it is generally easier to write, maintain and distribute. So the usage of Rust will be limited to some small parts of the game that run a disproportional amount of time, like terrain generation and now preparing the data for torch lighting. A relatively straight forward translation of the updated torch lighting turned out to be more than 5 times as fast, which adds up to seconds of processor time saved over many torches.

[Zun out]



Zun is our programmer, and I busy myself with most of the other tasks; writing these blogs, making textures and models, thinking about game/UI design, checking and responding to messages, etcetera. But the current and next updates don’t require new textures/models, so I can focus my energy on other tasks. This week, I’ve returned to learning more about Unity and programming in C#. I’m still not experienced enough to contribute to Colony Survival itself, but I’m getting closer!

I suddenly got inspired to make a simple game about firing a howitzer. Ultimately you’d be firing on distant targets surrounded by targets you explicitly shouldn’t hit. Here’s my progress in five GIFs:

• It’s alive!
  
• Those things shouldn’t be connected
  
• That’s what it should be like
  
• Now with sound, explosions and smoke :D
  
• More smoke, more physics

So our hobby, gaming, has become our work. Time to find a new hobby! ;) And of course my new hobby is very relevant to my job as well: I suddenly found myself interested in building and painting miniatures.

You probably know about these plastic building sets for tanks and planes that you’ve got to assemble and paint yourself. For a long time, I didn’t really see the appeal of it. And then, YouTube started recommending videos of experienced model builders.
https://youtu.be/9qJ6Q-mSaeQ
I was stunned by the results builders could achieve. The plane in the video above doesn’t look like a cheap plastic model, it looks like a true plane with metal parts which has been used thoroughly. And then my eye fell on the next step of the process: building realistic dioramas for the models.
https://youtu.be/4P5GSDNpExQ
I didn’t know stuff like this was possible. Apparently, they’ve developed all kinds of special paints that can simulate mud, leaked fuels, rust and all the other things that affect objects IRL. Combine these with a realistic model and skill, and you get very impressive results. I’ve ordered a couple of models and different paints plus some tools, and plan to be spending my weekend building and painting :)

As I said before, I am responsible for the textures/models in CS, but I’m not a trained (or talented :P) artist. The things I spent most of my time focusing on was learning the technical details of software like Photoshop and Blender. My experience with photography was very useful - I knew a bit about composition, color and Photoshop. But capturing existing landscapes and objects is very different from creating one from scratch, and that’s my job now. Model builders face the same problem, and learning about their approach has already taught me a lot about why objects IRL look how they do.

I expect and hope that practicing with building and painting models IRL will teach me useful stuff that I can use when making digital objects. If you have got some experience with model building, feel free to give me advice on Discord :D

Bedankt voor het lezen!

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

Happy New Year! In 2019’s last blog, we looked back at the history of Colony Survival. Here, in 2020’s first blog, we’ll discuss our plans for the future. They haven’t changed too much since this blog we posted a couple of months ago, but we’d love to talk more about the underlying reasons, and we think we can properly visualize them in a single image now.

Imagine a graph that plots both ‘complexity’ and ‘time played’ for a game. In a lot of games, more complex features are introduced only after you’ve played the game for a while. Think of a shooter which starts with some simple missions with simple weapons and targets, and introduces a stealth mission or guided missiles later on.

A guided missile is obviously more complex than a basic pistol, but how complex it appears to players also depends on the interface. Does the game explain how to operate this new weapon? Or are you expected to press all kinds of hidden buttons and navigate complex menus? The “complexity” measured in the graph is a combination of the actual depth of the mechanics ánd how difficult it is to figure out for players.



Now imagine plotting Colony Survival 0.1.0, the version we released on Steam in June 2017, on this graph. After one or two hours, you could have seen all the content. There was no science system. But the UI wasn’t very advanced either. If you weren’t experienced in FPS and RTS games, you had a pretty hard time learning the ropes. So I’d visualize 0.1.0 on the graph like this:



We got quite a lot of complaints about the lack of content, and we could see why. The next updates all focused on adding more items and features.



0.7.0 was a big overhaul of the game. It wasn’t merely adding things on top of the pile, the early game was overhauled as well. New features like happiness, co-op and trading have given the game more functionality and depth, but they’ve also added extra menus and buttons that aren’t always explained that well and can confuse new players. This is the result in the graph:



Obviously, our intention is not to make the game more difficult and confusing for new players. A couple of months ago, I watched someone who wasn’t really experienced with first person games try the game, and it was heart-wrenching. It suddenly became very obvious how complex Colony Survival is for people who haven’t extensively played first person and strategy games. Our goal is to make CS accessible for persons like that as well. We’re not going to dumb stuff down and we’re not going to hand-hold experienced players - no worries about that! Our three main strategies are:

• Make existing interfaces clearer. For example, the Colony-menu, the one right next to the Happiness menu, is a mess and truly work-in-progress.
  
• Make game mechanics more easily visible. A statistics menu that allows you to track your stockpile, workers and guards. A happiness menu that displays relevant info way better. A top-down menu that allows you to click on job-blocks, colonists and monsters for extra info.
  
• A mission system that gives players a framework for setting up a colony and developing it to its maximum potential. For new players, there would be basic missions like “plant a banner”, “recruit a colonist” and “recruit a berry farmer”, and each would have a description with detailed explanations on how to do that. For more experienced players, there could be missions like “start a colony in the New World” and “recruit 1000 colonists”.

We don’t want to do all of this in one update, we don’t want to make you wait that long again. So expect 0.7.3, 0.7.4, 0.7.5 and maybe more 0.7.X updates with interface updates. All these changes should have a big impact in regards to reducing complexity for new players!



“End complexity” in the graph is slightly lower for 0.7.X than it is for 0.7.0. The sole reason for that should be more intuitive interfaces, we’re not removing features or mechanics!

When the current content is in optimal form, we’d like to start adding new content again. The theme will probably be the industrial era. It should add to the depth of the game with new mechanics like electricity, pipes and multiple-block/multiple-colonist jobs. Here’s what 0.8.0 should look like on the graph:



We think this is the best strategy for the future of Colony Survival. It should make the game accessible for a bigger group of gamers, while simultaneously giving veterans more tools to play with and expanding how long the game can be played for. But of course, we’re imperfect and we might be making a big mistake. So let us know your opinion about these plans!

It was a bit of a weird week, stretched over two decades. We did take some time off, but Zun still managed some very productive days. He's still working on the lighting. For now, only light sources like torches, lanterns and furnaces have changed. I can't wait to see what happens when the sun and moon get floodfill lighting!



Bedankt voor het lezen :D

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

Today is Zun's birthday! He is now 25 years old. He's the one who started the project; he's our programmer and Unity-expert. Without him, Colony Survival would not exist! Feel free to join our Discord, to tag him by using @Zun and to congratulate him :D

Two years ago, we released a video showcasing the progress from the first test versions in 2013 to the Early Access release in 2017. Since then, a lot has happened. We’d love to do a short look back at our own history before we start the new decade.

https://youtu.be/gtRRsLLMXHc
At the start of 2017, we weren’t full-time, “professional” developers - just two guys who had been working on a hobby project. Despite that project reaching its fourth birthday that year, we hadn’t earned a single penny with the game.

But all of that was going to change dramatically. We were nearing the Early Access release, and were looking for testers. A couple of big YouTubers, starting with GrayStillPlays and shortly later Draegast, decided to showcase the game on their channels. Within no time at all, they racked up more than a million views. Suddenly, thousands of people applied to become testers for the game!

Strike while the iron is hot - we decided to release the game as soon as possible. We were very lucky - the game became an instant hit. We were one of the top sellers on Steam. We found a loyal playerbase, who helped us and are still helping us with all kinds of support: finding bugs, making translations, sharing suggestions, developing mods and of course fun and serious conversations about all kinds of subjects.

The game at the release was very shallow. You could unlock all the content within an hour of playing. Buying flax seeds in the shop was the most complex thing you could do. There was no tech tree or other progression system.


The first, primitive iteration of the science system

In the first six months, we released a flurry of updates, picking as much low-hanging fruit as we could. New items, new resources, new guard types, new monster types and the science system. I’m still a big fan of this trailer for the “Christmas Update” at the end of the year:

https://www.youtube.com/watch?v=n-YF948Wrns


Most of the updates in 2017 added new content in the form of renamed and retextured old content. Copper ore was very similar to iron ore, crossbow guards function pretty much just like bow guards, and the tailor is just a reskinned workbench. To a degree, this is healthy game development. But you can’t do it indefinitely. In the first half of 2018, we started focussing on new kinds of content. In January, 0.5.2 added stair blocks. At the end of March, 0.6.0 added builders and diggers. And in June, 0.6.3 improved the UI with for example a search bar in the stockpile and a decent loading screen.

After 0.6.3, we embarked on the long(er than expected) road to 0.7.0. We had very ambitious ideals where we wanted to give players the tools to utilize the entire world, instead of only the small area surrounding their first banner. But that’s a huge overhaul which requires a lot of new features. This problem is explained pretty decently in Friday Blog 66 - "Roundness" in Game of Thrones.
Still, we managed to hit some major goals that year, as the video below from October 2018 demonstrates. We already had multiple colonies per player, updated world generation and vertical farms in there.

https://www.youtube.com/watch?v=2t07K9_QuBs

During the first half of 2019, we had to finish, test and polish 0.7.0. The beta slowly grew from small and closed to big and wide open. Many features that were in popular demand made it into the game back then: trading between colonies (even if they’re owned by different players), co-op sharing of the ownership of a single colony, quality-of-life improvements like auto-recruitment, etcetera.

At the end of July, we finally released 0.7.0. It resulted in a big spike of returning players, new attention and new sales. The Yogscast kept playing the game for many months. The overall response seems to be very positive!

We kept patching small problems and adding small improvements until the middle of September. Then, Zun travelled to Japan for his first big holiday in years. He returned to the Netherlands in the middle of October. He spent six weeks refactoring things behind the scenes, extending mod support and adding the Steam Workshop, allowing us to release that at the start of this month.

We’re very happy with how things are going. Our community is still active and positive, the Steam Reviews are doing better than ever, and sales have been very decent in 2019. But that doesn’t mean we believe the game itself is perfect at the moment. 0.7.0 added all kinds of new complex mechanics and features that aren’t always explained very well. Some of them rely on vague, unclear and ugly interfaces. We definitely want to fix that in 2020!


In some aspects, 2019 felt like a contradictory mix of young and old. In 2017, we really lived in “Emergency Mode”; we didn’t want to disappoint all of the new players and wanted to add as much as possible as soon as possible. Inevitably, things have cooled down a bit; emergencies can’t last forever.

On one hand, Colony Survival feels pretty ‘old’. Since the Early Access release, three full Call of Duty titles and two full Assassin’s Creed games have been released. On the other hand, things feel brand new. Our LLC turned two only a couple of months ago. We’re still only 24 25 and 26 years old, we didn’t study game development or how to run a business, so we’re having to figure that out on the fly. We’re rapidly learning new things about game design, programming and development.

In a couple of days, a new year and a new decade will start. We can’t predict exactly what the future will hold, but we’re planning to keep working on Colony Survival for multiple years. We’ve got many plans to make the game more fun, more beautiful, more complex ánd simultaneously more accessible. When we leave Early Access, we want the game to be as good as we possibly can make it! We hope to be able to look back at this moment in a decade and see it as an awesome starting point - not a high point :D


We couldn’t have done this without you! We’re very grateful for all the support we’ve received. We’re going to forget people in this list but we’re going to try anyway. Many, many thanks to everybody:

• Vobbert. Our first tester, our Head Admin on Discord, our PR Advisor, and our tiebreaker when Zun and I disagree!
  
• Pandaros, Boneidle, Kenovis, Adrenalynn, ImRock, Nach0 and all of the other modders. You’ve made some very, very impressive mods and a significant part of the community relies on them!
  
• Everybody who has purchased the game. We like roofs over our heads and food in our stomachs, and that stuff is pretty expensive here in the Netherlands. Thanks for making it possible to dedicate ourselves to this project full-time :D
  
• PatateNouille, Aljetab, Bilzander, JoeMan, Tjohei, Saphrax, Rain_Shadow, Zeta-Primette, Sirdragonov, Malicious, GLaDOS, Karkess, Semegod, Bog and all the others who provide us with beautiful worlds and a lot of fun and support on Discord!
  
• All the countless other people who’ve supported us in other ways: those who recommended the game to friends or who wrote a Steam Review, those who participated in the 0.7.0 Open Beta, those who voted in surveys, those who left comments - they’re often small acts, but when done by thousands they’ve got a huge impact!
  
• Steam/Valve, for making all of this possible by providing us with lots of tools and solving lots of administrative tasks for us with minimum hassle. We've heard many complaints from professional YouTubers about YouTube's seemingly arbitrary demonetizations and other punishments. We don't have such fears on this platform. It could have easily been otherwise, so we do appreciate what we've got!
  
• You! You must be pretty dedicated to this game if you’ve made it this far into the blog so thanks a lot for that :D

Zun has kept working on the floodfill lighting described in last week’s blog. The system doesn’t work for sunlight/moonlight yet, but it does for torches and lanterns! We’ve got some Work-in-Progress pictures we can share. Ambient lighting is turned off here, making for example the outside look a lot more dark than it's supposed to be. Here’s the first example:


Fullscreen

The overall look hasn’t changed dramatically. Some surfaces are significantly brighter in the floodfill example, and we think that’s an improvement - we complained about the harsh shadows in the last blog.
To get this to work, things like normal mapping also had to be reconfigured. If you open the image fullscreen and look at the details, you can spot some noticeable differences. In general, things feel smoother and better to us, but we’d love to have your opinion!


Fullscreen

Changes are way more dramatic here. There’s way more light leaving the house. It makes sense for light to get out of the windows and door, but the light bleeding through the roof is a bit strange. In general, we like the change, but we’re still tweaking things, and once the sun and moon use floodfill as well it should look very different again! This system should give us more control over light and everything that interacts with it - making things like better water shaders and transparency easier to do.

Sadly, it’s going to take until the next decade before any of this is realized. Luckily, the next decade is in a couple of days :D

Thanks for reading these blogs, we hope you had a Merry Christmas and we wish you an amazing 2020!

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

'Weltenbäume' by JoeMan

This week, Zun started working on an option to change the texture quality settings. All blocks in Colony Survival have relatively high-resolution textures of 256 by 256 pixel textures, and each surface uses multiple textures: albedo maps, normal maps, height maps, specularity maps, etcetera. Players currently don't have a way to downscale these textures, making the game quite difficult to run on very low-end hardware.

Zun’s solution not only supports textures with lower resolutions, but also textures with higher resolutions than we currently have. Of course, I wanted to test this immediately. I added some 2048x2048 pixel textures. We were torn by the results.


Very, very low texture settings

Of course, the high-res textures look very fancy, detailed and realistic. But simultaneously, they do lead to problems. The world of Colony Survival is fundamentally not detailed and realistic - it consists of blocks the size of a cubic meter. Our lighting isn’t realistic either. Is superrealistic textures where you can see every grain of sand combined with unrealistic big blocks and primitive lighting really the look we want?

To quote Jurassic Park: “[they] were so preoccupied with whether or not they could, they didn’t stop to think if they should”. We don’t want to be like that, so we stopped and thought if we really should upgrade to the highest possible resolution textures. It makes it harder to add new textures. Not all players have hardware that can run them properly. Superrealistic textures downscaled from 2048x2048px to 256x256px look worse than textures designed specifically for that resolution. And last but not least, superrealism is probably not the best style for Colony Survival.

One problem with realistic textures is that they highlight how unrealistic the lighting system is. It basically consists out of two values:
-Direct lighting, for the surfaces of the game that are ‘hit’ by the sun
-Ambient lighting, a darker shade for other surfaces (shadows)



It’s a pretty sensible system, but it ignores a lot of real life complexities. IRL, there is no magical “ambient lighting” that equally lights all surfaces in the shadow. Particles of light bounce across surfaces and the atmosphere, ultimately providing nearly all surfaces with a variable degree of light.

When you’re outside in an open field on a sunny day, most of what you’ll see is hit directly by bright sunlight, and shadows all appear to have roughly the same darkness. This is something that Colony Survival can simulate relatively well, and that’s where the game looks best.

But currently, IRL, I’m not in a sunny open field. I’m sitting indoors on an overcast day. The sunlight is scattered by the clouds, and a diffuse light hits my window. Shadows are vague. Items closer to the window are brighter than objects ‘deeper’ into the room. This is way, way harder to simulate in real time. For those of us who don’t have IRL lighting available nearby, I made a render with some realistic lighting on very primitive shapes:



As you can see, there is no clean divide between “brightly lit surface” and “deep dark shadow”. Both lit surfaces and shadows are a lot brighter on the right than on the left. The entire scene looks pretty realistic, despite the complete lack of textures and the very primitive shapes.

Now, compare this to two screenshots from Colony Survival.


This is a sand dune with pretty big height differences. In real life, the lower parts of the dune would get less sunlight than the highest parts, making them a bit darker and accentuating the height differences. None of that happens in Colony Survival. Everything gets an equal amount of sunlight, which makes this screenshot look flat, boring and unrealistic.


Here's another problem. Once the sun gets to a certain angle, a large part of the world is suddenly thrown into the shadows. Because there's only one value for ambient lighting, it's hard to fix this. If we make the ambient lighting brighter, shadows where you'd realistically expect them would be bright and boring. But if you make shadows properly dark, you'll also have to accept the effect in the screenshot.

Some of these problems are specific to voxel worlds. Luckily, the solution might also be possible solely because we're using a voxel world. Calculating more realistic lighting in a detailed, realistic world is very difficult, because the world is complex: you've got to keep track of millions of light particles bouncing through and around small holes, cracks and crevices. But because our voxel world mainly consists out of pretty large boxes, it's possible to write some clever algorithms that keep track of the surroundings when calculating how bright a surface should be. One of these methods is called floodfill lighting, and Zun is currently experimenting with that.

A complaint we’ve often received is the fact that deep, underground mines are so bright. That’s caused by the fact that we’ve got only one value for ambient lighting. Floodfill lighting should completely fix that issue.

The support for high resolution textures will be added in the next update, so modders will be able to experiment with them. For the 'official' version of the game, we believe better lighting is more important and practical than 2K/4K textures. We hope to be able to share the results of our experiments soon!

Bedankt voor het lezen :D

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

'Weltenbäume' by JoeMan

The Colony Survival Steam Workshop has been available for one full week now! It has already proven highly useful. The most popular mod is Pandaros’ Settlers Mod, which has received over two thousand subscribers. In total, there are now more than two dozen different mods available.

Apart from the mods, it’s also possible to share worlds via the Workshop. Only 7 have been uploaded yet, but they’re very impressive. This blog uses screenshots from JoeMan’s Weltenbäume savegame, which contains three huge custom trees that contain all the requirements for starting a colony, like ores and water. But the Workshop also contains Pathros by PatateNouille, the castle visible in the background of the main menu. Last but not least, there is an insane world uploaded by Bog, which contains a colony with 50,000 colonists. Zun has regularly used that world to test performance optimizations :)



Technically, the release of 0.7.1 was the release of 0.7.1.7. We’re now at 0.7.1.10. In the weekend, we were on standby and continuously monitoring reactions to see if there were any significant problems that required a hotfix. There were, so Zun released 0.7.1.8 on Sunday.

To compensate for the busy weekend, we mostly took Monday off. Wednesday we released a bigger patch with a bunch of small changes. Co-op worlds started from a workshop were marked wrong, and that’s fixed now. Translations were updated, a problem that caused freezing was solved, just like another problem that caused some glitching terrain.

Yesterday, 0.7.1.10 was released, which should fix a problem with mods on Ubuntu, and which refactors torch lighting a bit. It shouldn’t make a visible difference, but if it does, please notify us!

0.7.1 did exactly what the plan published a couple of months ago promised. We've discussed our future plans some more, but our 'mental roadmap' hasn't changed significantly, so the linked blog is still accurate and relevant. The plans can still change though, so if you really like/dislike a certain feature in the list, let us know your opinion! And if you want your world to be featured in a future Friday Blog, upload it to the Steam Workshop :)

Bedankt voor het lezen!

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

New items in mods made by Boneidle

The update should be available for everybody right now! The biggest new change is Steam Workshop support. This should make it a lot easier to find, install and update mods and texture packs. It's also possible to upload your savegames to the Workshop!

Straight to the Workshop

Modders have had access to the Workshop for a week now, and they've rapidly filled it with all kinds of new features and items. Some of these mods have literally been worked on for multiple years, like for example the Settlers Mod. There are many mods that add collections of new items. They add things like doors, windows, spiral stairs, new lights, furniture and a long list of other stuff to the game. There's a "Schematic Builder" available, which allows your colonists to build custom blueprints like cathedrals and castles. There are also mods with grief protection and other new multiplayer features. There's plenty of other stuff available, and the list is constantly growing!


Functional monorail and manapipes in the Settlers Mod by Pandaros

For reasons explained in last week's blog, Workshop-savegames work a bit different than regular ones. Instead of appearing in your regular list of savegames, they're available to choose from when you start a new world. This feature was added literally today, so there's not much choice on the Steam Workshop yet. We hope you'll help us change that! We'll regularly check the worlds on the Workshop, and feature them in Friday Blogs and trailers.


More from the Settlers Mod

But Workshop support is not the only change - it's part of a larger overhaul of our mod support. In the past, mods affected the entire game. You had to make sure you did not have conflicting mods, and if you wanted to switch to another mod or vanilla, you had to go to the game files and manually adjust them. It wasn't very user friendly.

In 0.7.1, mods don't affect your worlds until you explicitly tell them to. This means you can switch from a vanilla-world to a world with mods by Boneidle to a world with mods by Pandaros to a world with mods by Kenovis, without ever having to exit the game or fiddle around with folders. That should make it a lot easier to experiment with mods!

In the coming weeks and months, more mods should appear on the Workshop, and we can't wait to see all the worlds you've been working on appear there. We're going to see how the Workshop gets used in the coming period, and finetune things based on that. We're planning to add customizable settings to the mod selection menu, which we want to use for a standard terrain generation settings mod, allowing people to easily change the scale and shape of the world.

When you've tried the Workshop and the new features, please let us know your opinion! What's working well, what isn't? Which mods are your favorite? Nearly all modders have joined Colony Survival's Discord, so that's a way to reach them if you want to praise their mods and give feedback :)

Bedankt voor het lezen en veel plezier!

Straight to the Workshop

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