Colony Survival News

Zun's colony that he built in the past week

Zun and I are pretty big fans of logic, rationality and research. Before committing to something, e.g. a diet, exercise, buying a product, we're used to doing a decent investigation. What are the "rules" of weightlifting? What are the best and worst food options, and why?

Of course there's a debate about these subjects. But there are still very important truths out there. Having some muscles and endurance is good for your metabolism and hormonal systems. Deadlifting with an arched back is terrible. Processed food with lots of added sugars and fructose aren't good for you.

I've got a background as a historian, Zun mostly has programmer experience. These are pretty rational and constrained fields. It's very clear when the performance of a code has been optimized - or when it has gone in the wrong direction. Napoleon didn't use tanks or weaponized dinosaurs; the Romans didn't have an electrical grid or airplanes. You know the direction in which you want to go, and you know how to get there, you've just got to do the work.

For a large part, this still holds true for Colony Survival. We've got a relatively clear idea of where we want to go, and there are standards for success or failure. There are some 'rules' in regards to which games are good and which aren't.

But parts of the job are pretty vague. We're not making a product with a clear purpose like "transport persons/goods", "provide shelter", "generate energy" or anything like that. We're producing "entertainment". And where stories have to be engaging and theater productions have to be visually impressive, games are... weirder. It's perhaps closest to a puzzle. Although solving the puzzle is the goal, this shouldn't be an easy straightforward task. Having to put quite a lot of time and effort to overcome the puzzle is a big part of the appeal.

Now, if you get a bit disappointed when we describe Colony Survival as a puzzle game: I understand you completely, I'm not a fan of explicit puzzle games either. I love a good challenge, but it needs to "dress up". Crusader Kings could probably work as some kind of "pure" puzzle game where you've got to fill an abstract map with your color with some clever maneuvering, without any historical theme. But a big part of the fun is imagining that you’re a royal family that’s marrying, scheming and backstabbing their way to power, wealth and fame.



In fifteen years of time, roughly our youth, we went from Wolfenstein 3D (1992) to Call of Duty 4: Modern Warfare (2007). Wolfenstein was an experiment in 3D graphics and severely limited in all kinds of aspects. In CoD4, everything was possible. Loads of enemies, crashing helicopters, nuclear explosions, multiplayer. Now, I don’t want to insult CoD4, it’s very impressive in lots of ways. But this stunning technological progress might’ve also led to some wrong ideas about good games. The value of a game can’t be measured in the amount of polygons, the size of the explosions or the length of the cutscenes. Ultimately, it’s 100% subjective. A theme that might fascinate one person might repel someone else. Something that’s difficult to solve for one person might be very easy for another. One person might like the fact that it’s easy while the other hates the lack of challenge. One and the same person might be interested in a challenge some periods of the year or times of the day while preferring easier games the rest of the time.

The sane answer might be to look for averages, to appeal to majorities, or to look at what’s popular. That might be wise to do when you’re selling for example a house. But here’s the catch: every house is unique by the virtue of its location. If you want to have a home with size X in Manhattan or near that awesome forest in the mountains, there’s only a limited amount of options. But that’s not true for games. We’ve got to compete with tens of thousands of different games, and they’re all infinitely available - Portal is not going to run out of copies this year.

So if we’re going to do the sensible, average thing that appeals to majorities, we might be in direct competition with dozens or hundreds of similar games. This turns things around: the sensible thing might be to do the insensible, to do the thing that nobody else does, so that we can fill a niche that has been underserved.

And if this isn’t problematic enough, here’s the next weird thing to deal with. This entire industry is brand new. Videogames themselves are still young, but large scale digital distribution has barely reached puberty. Ten years ago, I was still prowling through the streets, moving from store to store to find good deals on videogames on discs. My current PC can’t even play discs and I haven’t missed that feature once. The fact that games can be continuously updated with new content instead of having one specific release date is a massive revolution and we don’t know how it plays out yet. It’s been less than three years since Steam was “opened for the masses”. We don’t know what the industry will look like in 2025 or 2030 - yet it’s what my mortgage (end date: 2049, four years post-singularity) depends on.

For a long time, we’ve been looking for the ‘manual’ of ‘objectively good’ game development. Now we've realized that there is no tried-and-trusted in this industry. Everything is constantly changing and there’s no perfect metric that can be trusted 100%. The best game isn’t necessarily the one that makes the most profits, or the one that has the most views on YouTube, or the one with the highest Metacritic score. Whether the Early Access labels helps or hinders us, whether free updates, DLC, a sequel or an in-game market for skins and other cosmetic items is the best option for long term revenue: nobody knows the answer with any definite certainty.

With this lack of clear, objective rules, we need other sources of guidance and inspiration. There’s a lot I could write about that, but this blog is already getting quite long! If there’s any interest, I’ll gladly continue the rant in a future blog :)




One week ago we released 0.7.2! Luckily, it has caused no serious problems. Thanks to some helpful players on Discord we did figure out that the new handheld lantern colors didn’t match the actual lantern color. This was fixed in a hotpatch released Saturday evening.
Since then, Zun noticed some other minor unintended effects and offsets in the lighting that were fixed in 0.7.2.2, released today.
Apart from that, Zun has done lots of playtesting and we’ve been thinking about how to start implementing the planned UI changes. We’re looking forward to making it a lot more streamlined and intuitive!

Bedankt voor het lezen :)

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

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