Colony Survival News

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