Colony Survival News

We were planning to release 0.7.1 today, but at the last moment, decided not to. Mod creators have now had ~24 hours to upload their mods to Colony Survival's Steam Workshop, but that didn't give them a lot of time. More mods are expected to be added in the weekend.

Another problem is the fact that the Linux version of the game seems to be broken. Non-Latin fonts cause some issues and are in need of an alternative, and there's a big problem with loading .ogg audio files.

There's also a last feature Zun wants to add before releasing 0.7.1: savegames/scenarios. We'd love to allow people to easily promote and share their most beautiful colonies. We've seen a lot of highly impressive ones. But doing that via the Steam Workshop is slightly problematic.

The Workshop allows creators to update their assets even after they've been downloaded. That makes sense for texture packs, new items and other utilities. But imagine using a world from the Workshop, working on it for dozens of hours, and then losing your progress completely because the creator updated his savegame. That's obviously not ideal.

So we've got to make some kind of system where you can choose "scenarios", custom maps, when you start a new world. If the creator of the savegame decides to update it, it only affects new maps.

We've already seen players make maps that are meant to be played as "scenarios" / challenge maps, with for example a huge tree that contains ores and all the necessities to run a relatively large colony high in the sky. So that's the solution we've chosen, and Zun is working on it now. He expects to have it finished in a couple of days, and that's when we want to release 0.7.1 - combined with a Steam Workshop filled with a lot more content than it currently has!

Bedankt voor het lezen :D

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

The flat world, created by a testmod that will probably be available as a default

This week, we created our very own Steam Workshop page! Screenshot available below. It's only available internally, but it's relatively functional. Integration of the Workshop was slightly easier than expected. A lot of the required settings can be adjusted in default Steam Workshop menus, so we don't need to develop our own UI for them. In our private testbuild, it's now possible to upload mods to Steam Workshop from Colony Survival, and we can also download them into the game again. And of course, another important new functionality is the fact that it's now possible to select only specific mods to use in a world, making it a lot easier to regularly play both modded and unmodded worlds, and to experiment with combining multiple mods.

We've received multiple reports of people who missed the flatness of 0.6.3 worlds. As a result, Zun's testmod is an adjustment of the world generation, resulting in a nearly entirely flat world. We might make this option available as a default mod. For 0.7.2, we'd like to make extra settings available to modders, which will allow us to upgrade the flat-world mod into a full terrain generation customizer.

A release date of Friday next week is a definitive possibility. The Monday afterwards is another option (December 1) or the following Friday. This will give modders the possibility to configure their Workshop pages in time for Christmas :)



To make myself more useful for updates that rely mainly on programming/Unity skills instead of new textures and objects, I've continued to 'level' these skills and I really do feel like I'm making progress. I got quite a lot of encouragement as a result of last week's blog so thanks a lot :D

My little project is far from perfect or complete but I'd like to share some GIFs again:

• Lots and lots of projectiles
• Making custom smoke/explosions
• Crazy experiment

I did run into some persistent shadow issues that we haven't been able to figure out this week. They're most obvious in the last GIF. If anybody knows a solution, I'd love to know!

Finally, the Half-Life Alyx trailer released this week! Here is the video:

https://www.youtube.com/watch?v=O2W0N3uKXmo
It looks like a revolutionairy and impressive experience. The way you can use your hands to grab and manipulate objects and to shoot looks very intuitive. There's one problem that makes us hesitant in regards to VR.

In VR, you can do some limited moving around by physically walking through your room. But my room is a bit smaller than for example Los Santos in GTAV, or the pretty much infinite world of Colony Survival. Which would require you to still use buttons/joysticks to move around, but that might be jarring in VR.

Nearly all of the gameplay scenes in the trailer are stationairy, or at least confined to an area of a couple of square meters. There is no walking through long streets, no climbing stairs, no running through corridors. And in most games, such activities are essential. That might be a coincedence, but it might also indicate that movement is still problematic.

So that makes us feel uncertain about the future of VR.
Perhaps the issue is fixed, and VR becomes as essential to gaming as the mouse, or as color is for movies.
Perhaps VR will create entirely new genres of games, causing regular gaming and VR gaming to coexist for a long time, like flight simulator games that require flightsticks.
Or last and least, VR is mostly a gimmick that will decline in the future, like 3D movies or the Kinect. We'll see! We'd love to have your opinion.

Bedankt voor het lezen :D

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

Our internal unreleased testbuild now has a nice in-game menu that allows you to select and deselect specific mods for individual savegames! There is a screenshot below. The same options appear in both the 'new world menu' and the 'load savegame menu'.

While working on the UI, Zun decided to refactor, optimize and improve some underlying systems. The main menu should work smoother in 0.7.1, and fonts should be rendered more clearly. This work should pay off in the next couple of updates, because we're planning quite a big overhaul for all UI systems.

There are a couple of things we still want to do before we release the update. In the mod settings menu, modders should be able to give a couple of options to players. An example of this would be a mod that allows players to customize terrain generation, to for example change the size of the world or the amount of hills. It would require a couple of sliders that players can use to provide custom input. More mods would benefit from such functionality.

Another thing we've still got to deal with is edge cases. What if someone installs a mod, starts a world with it, and then removes the mod? We'd think a warning would be appropriate.

Last but not least, we need a visual UI to connect the game to the Steam Workshop. We hope to be able to finish that in 2-3 weeks. We can't wait to see how the Workshop will be used! Plenty of mods and texture packs have been developed for CS in the last 2+ years, and many of them add useful functionality or impressive new content and features. Nowadays, they are spread between different GitHub pages and Discord servers and relatively hard to install and manage. 0.7.1 should make that a lot better!



For the reasons explained in last week's blog, I've continued to increase my programming/Unity skills last week. Last week I was working on a simulated ecosystem, but this week I've decided to focus on a more game-like project, with opposing teams of cubes fighting each other. On one hand, working on it felt very smooth some days. I'm starting to understand the combination of Unity and C# a lot better. On the other hand, there were plenty of weird behaviors and bugs I had to deal with and the GIFs I made throughout the week reflect that:

• GIF 1: The cubes track and fight each other properly, but the projectiles are off
  
• GIF 2: Trying to fix the projectiles made them even wonkier
  
• GIF 3: Things start to work more as intended, with the player being able to smoothly place opposing cubes on both sides

After some fruitful hours, I even got the projectile enemies to work! But trying to add a fancy explosion effect ruined the entire project. I tried to redo it in standard Unity instead of the High Definition Render Pipeline, but it looked and worked a lot worse.

• GIF 4: The ugly version with broken explosion effects at the end

There's another exciting thing we learned this week, that should hopefully boost our development output in the future. A company called Quixel has created Megascans, a library of detailed textures that can be easily used in both games and renderers. They've also got related software that helps customize, mix and apply these textures. Here's a video with details:

https://youtu.be/BfbNlk-QCfs
In the past, using this library was pretty expensive, and we were afraid that it might not be as useful in our specific case as we hoped. This week, they released the news that they were acquired by Epic Games. The tools for customizing and applying textures will become free for everybody, and the Megascans library will be free for use with the Unreal Engine. I'm planning to experiment with that in the near future, and if the tools are as useful as they look we might be able to use them to improve the textures in Colony Survival!

Bedankt voor het lezen :D

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

Last week's Friday Blog was written right before the new Steam Library UI dropped. I'm pretty sure we haven't added all the new assets yet, but we did quickly make a design for the new 'card' in the library. The new UI looks pretty good! A change with major impact is the new 'review-request' in the Steam Library. Players get more encouragement to write a review now. This was very noticeable in our review rate. Normally, we hover somewhere between 25-50 reviews per month, with 80-90% of them positive. We're now at 95 reviews in the last 30 days, with a 95% positive review rate! We're very grateful.

Since Zun's return from Japan, he has mostly focused on the "input" part of mods - for example, the ability to select which mods you want to use per savegame, instead of mods affecting the entire game. This week, he has switched to the "output" part. How can players put mods on the Steam Workshop? How can worlds be saved on the Steam Cloud automatically? Apparently, mods can't just be uploaded to the Steam Workshop directly, we've got to make an in-game menu.



The things Zun is correctly working on don't require new models or textures - my specialization. So I've been working on improving my skills with Unity and programming, allowing me to eventually support Colony Survival in more ways. Two weeks ago I wrote something about my own little project, a simple simulated ecosystem with growing grass and cube-rabbits that eat it.

The basics functioned pretty well, but there was a big problem. After ~5 minutes, all of the cube-rabbits started dying rapidly. I struggled for a while to solve the problem and could not find it. Even Zun could not identify the bug. I pondered about it some more (while lying in bed at 1:30AM) and thought of a solution that could help identify the bug.

It did help to find bugs - we discovered that the NavMeshAgent failed right before the cube-rabbits started dying. So we fixed that - and the cube-rabbits still died. We thought the female rabbits might be inheriting the age of their mother - making them incapable of having long lives. We changed the procreation-code, but the same issue kept happening.

Eventually, Zun spotted a very very simple and silly mistake in the code. The only thing I had to do solve the problem, was change this:
if (thisgrass.isProtected == false)
...to...
if (thatgrass.isProtected == false)

That simple error meant the cube-rabbits failed to check properly whether grass still had "foodvalue" left. After fixing that, the simulation (sped up 2000%) looks like this!

The three blue spots on the ground are meant to be infinite sources of water. The grass is their food source. Over time, it grows, but it shrinks when rabbits eat it.

The cube-rabbits are divided into two genders. They both have increasing hunger, thirst and age. When hunger and/or thirst exceed a certain limit, their HP starts dropping. Eating increases the scale of the rabbit to a certain degree, and it restores damaged HP.

When rabbits reach maturity, they get the ability to procreate. Female rabbits can get pregnant and after a couple of moments they give birth to a male or female rabbit. Above a certain age, their HP starts dropping. The color of the 'main cube' is determined by gender+HP, and the color of the tail-cube is determined by age.

It results in a pretty interesting simulation, and it has teached me a lot abouty programming and Unity! It's not relevant to Colony Survival at the moment, but that should change in the future.



A word of our own creation that Zun and I throw around pretty often is "the Day of Defeat - effect". Day of Defeat: Source was the first Steam-game Zun and I owned and we played it quite a lot. Here's some random footage from YouTube. In contrast to many modern shooters with pretty round, open maps and fluctuating spawn points, DoD's maps were pretty lineair and static. While these words often denote something that's negative, it actually had a pretty positive effect.

If your team was doing well, the battle started happening at a larger distance from your spawn. But if you were on the losing side, the reverse happened of course: the battle got closer to your spawn. Which made it easier for you to get there, and harder for the enemy - lessening the consequences of your death, and increasing the consequences of your enemy's death.

This made the battles in the game pretty balanced, even if the teams were not. But it didn't feel like a 'fake' mechanic, some artificial limit like increasing the HP of the losing team. It was a very natural and organic balance. If your team was on a succesful offensive, your weapons were still equally powerful, the stakes were just a bit higher.

The reverse is true in quite a lot of RTS-games, like for example Supreme Commander (a brilliant game that we played again very recently). A player that is marginally better than another player, let's say 5%, sees that same boost everywhere. 5% more resources, 5% quicker development, 5% less losses in battles. These improvements stack on top of each other, and can of course be used to destroy for example the resource gathering units of the other player, completely hamstringing them.



Marginal differences in skill cause exponential differences in base growth, amount of resources and amount of units. Of course, that is fun in some ways, but it also causes massive balance issues.

Of course, Colony Survival is not a competitive multiplayer game. But we believe the same effects are still very relevant. On one hand, players need to see that their choices have impact, and it's fun when things stack and increase and cause massive advantages. On the other hand, players also want a challenge - when they have 10 colonists, when they have 100 colonists, and also when they have 1000 colonists. To continuously keep providing overcomeable challenges, for new players and for experts, for small colonies and for large colonies; that's pretty difficult.

We often had this discussion in regards to the happiness system. Of course, players need to be 'punished' when they fail to keep their colonists happy. But a failure to provide enough happiness items is probably also proof that the colony isn't doing too well. We could easily make it so that colonists start crafting less and less when they're unhappy, but that would result in even less ammo/food/happiness items, causing an inevitable collapse. That's why we decided to mainly penalize progress: make science slower and the recruitment of new colonists more expensive.

To us, "the Day of Defeat - effect" means a game should become a bit easier when you're on the brink of collapse, and it should become more difficult when you're doing very well, without giving players the impression that their choices don't matter (your weapon does more damage? Nice, we're going to add an equal amount of extra HP to enemies). It's a difficult balance to strike, but a highly important one!

Bedankt voor het lezen :D

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

Work on mod support has continued. In the unreleased dev build, it's now possible to have multiple mods installed and to select specific ones to use per world. This makes it a lot easier to switch between modded and unmodded worlds, and to combine multiple mods. At the moment, this functionality exists only in the server, we've still got to add new UI elements to the regular in-game menu.

Zun did a couple of highly technical things this week, but.... they're highly technical. It's important but hard to explain. But there is something else we've been discussing for a longer time, and we think we can decently explain that!

We're always listening to our community, but there are common suggestions that we seem to ignore, or at least, that we're not working on. The steps that an idea has to go through to be implemented can be pretty difficult. We think it can be best explained by a concept of three filters, or three 'lenses', that all 'distort' an idea and affect the end result. Here are these three filters/lenses:

Fullscreen


It's easy to notice when something is wrong. It takes less than a second to conclude that a car, or a house, or a painting is ugly. It's equally easy to conclude that something tastes bad. But explaining why exactly something is ugly or wrong, and detailing which steps would fix the problem, is a lot harder. Why a specific individual subjectively likes or dislikes something is a very complicated subject, and it's hard to communicate about it accurately.

So a lot of feedback that we receive is pretty 'raw' and relatively unspecific, and it takes 'processing' on our side to figure out the exact problem and potential solutions. For example, in update 0.4.0 we added quite a lot of content to the science system. Players kept suggesting a hierarchal tech tree, something you'd see in games like Civilization. We were opposed to that, because it would make the tech tree harder to change, and it's going to need a lot of change before we leave Early Access.

It took us a while to realize that we had to do some interpreting. We should not have read it literally as "the game lacks a hierarchal tech tree". We should have understood that it meant something like "the current science system is unclear and it should be more intuitive". We spent a couple of hours working on it, we added clear labels and separations between different categories (available, unavailable, completed) and we applied a black-and-white filter to unavailable science. Since that update, the "hierarchal tech tree" suggestion has all but disappeared!

Source


During World War II, using airplanes for mass bombing was a relatively new strategy. Lots of bombers were shot down, and engineers tried to optimize their survivability. They analyzed where bombers were hit when they returned from bombing missions, and were considering to add armor to these areas. These areas can be seen in the image above. Pretty smart!

Until statistician Abraham Wald thought about it. It's hard to aim accurately at planes flying at high altitudes with 1940s tech. All parts of the plane were probably hit pretty evenly. But a direct hit to the cockpit or the engine would have a much more catastrophic impact than a hit to the edge of a wing. Critically hit bombers would not return to allied territory for a thorough damage inspection, so only bombers hit in less important areas would be included in the analysis. This is called 'survivorship bias'.

So Wald gave the opposite advice: don't add armor to the areas that seem to get hit all the time, add armor to the areas that always seem to be unscathed! They are vital to the survivability of the plane.

We have got to keep this advice in mind. Only a small minority of players writes reviews, leaves comments or shares their opinion on Discord. These are the "survivors" that we notice - but how many were 'shot down' somewhere along the way? People who would've loved the gameplay but were turned off by their first impressions, people who tried the game for an hour but didn't "get it", people who happily played for dozens of hours but don't care about blogs and surveys. How different are they from the people who "survived" to the survey or Discord?

In recent surveys, "better tutorials" received a very unenthusiastic response. A large majority voted for the "low" and "very low priority" options. We believe it's too easy to conclude that a better tutorial is indeed not that valuable. Those players who would have most benefitted from a tutorial are probably the ones who have the lowest chance of sticking around and participating in surveys.

So we've got to keep in mind - who is giving comments, who is answering the survey, and to what degree do they reflect the audience we're trying to reach?


Every feature has a cost. In development time and in performance. Both are limited, so we've constantly got to weigh whether what we're doing and choosing is worth the expected improvement.

How much development time something costs can be highly unintuitive. Some things that are very easy in real life are very hard in tech, and vice versa. If you want to give the walls of your living room a different color, it will take many hours of work in real life while a similar task is often accomplished in seconds if you do it digitally. The best chess players of the world have been consistenly losing to computers for more than twenty years, while a four year old child is still better at holding a conversation than the most advanced Artificial Intelligence of 2019.

Zun has pretty much written a custom engine for Colony Survival. I'd say it's highly optimized: it can run on pretty old hardware, and you can have lots of colonists and monsters without lag on regular hardware. It's highly flexible and easily customizable in certain areas, while it's rigid and limited in others. Some things that seem easy aren't, while other things that seem hard, aren't either.

One special technical complication for Colony Survival is the server/client split. When you're joining an online server that somebody else runs, you're only using the client. If you're playing a singleplayer world, the game sneakily launches its own server in the background. But a lot of things that you'd expect to be relatively simple, are actually separated between a client component and a server component that have to communicate between each other. The client is relatively dumb - it doesn't even know whether a colonist is part of your colony or not, nor does it know where a colonist is going. It just waits to receive that info from the server. We're considering to add such info in UI elements and tooltips, but the server/client split requires us to add additional steps: first the client has to ask the server, the server has to process the request and send information back, and then the client has to handle that information.

So this adds another layer of complication. An idea can sound brilliant and be widely appreciated by the entire audience, but if we don't expect to be able to get it work decently within a reasonable timeframe, we've got to ignore/postpone the idea...


We hope this makes clear how hard it is for a random suggestion to become the thing we're working on, especially if it's a big feature that requires a lot of development time. I struggle with the exact same problem: I'm pretty sure at least 4 out of every 5 suggestions I make is shot down by Zun and/or Vobbert :) But the fact that we're not working on your exact suggestion doesn't mean we're not listening - we're constantly monitoring how people react to both in-game and potential features and callibrating our priorities accordingly. So please keep sharing your feedback, it's valuable and definitely influences the direction of the game!

Bedankt voor het lezen :D

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