Colony Survival News

This week, we released the last two 0.7.2.x updates and started working on 0.7.3. The updates contain some minor fixes (check #small-patch-changelog on Discord) and an overhaul of the personal torch. It now uses the same system as stationary torches, significantly improving the visuals. When you’re playing with others and they activate their own personal torches, this will actually be visible in your world! And that includes the colored effects of the lanterns. An example of this can be seen in the screenshot above.

For 0.7.3, Zun has started working on statistics! They should give you a lot more insight into the long term trends of your colony. Which resources are increasing, which items are depleting? The image below is very primitive work-in-progress after only one day of work; the end product will look very different.



Last week’s blog was a long complicated rant about some of the weirder aspects of game design. It got quite a lot of comments - thanks for all the feedback and encouragement! :D So by popular demand, I’ll try to write Into Weirdness II. It’s a complex and fuzzy subject, so be warned: this might get vague.

Zun and I haven’t done any formal study related to game design or development. But that didn’t mean we were completely unprepared. We did have lots of experience with computers and games, including messing around with videos, websites and audio. I had quite a bit of experience with photography and Photoshop, which proved highly useful for making textures. I studied history and have always been interested in the general development of civilization - focusing on long term trends instead of specific kings and generals. We think that definitely shows in Colony Survival.

What this means is that we found useful information and inspiration in all kinds of random and unintended ways. One clear example: Fort Bourtange. It’s a star fort located close to our birthplace and we’ve visited it often. Here’s a photo:

Source

I don’t think I was conscious of the link between Colony Survival and Fort Bourtange until literally five minutes ago. But now that I notice the link, it seems extremely relevant. We’ve spent plenty of time exploring a small historical village surrounded by multiple layers of walls, moats, gates and bridges when we were young. And then we decided to spend years working on a game that’s focused on building a village-fortress with walls and moats. I don’t think these two things are unrelated!

So obviously, inspiration like this is extremely valuable. But you can’t just order a manual that contains pure concentrated 100% Extremely Valuable Game Design Inspiration. You’ve got to go looking for it in all kinds of random directions.

In the past, I was inspired by random places, hobbies, games and TV/movies. In 2017/2018, I’ve barely played any games that weren’t Colony Survival. But in the past twelve months, I’ve played a lot of new games. Not just for entertainment (although that was certainly part of it), but with a deliberate aim to study and learn from them.

One could do this in a very careful and systematic fashion. Make a list of games, make a timetable, play each of them for 25 hours and write a detailed report on UI / gameplay / graphics / sound. But that can get boring and because I did this in my free time, I didn’t want to make it too much of a burden.

So I played randomly and erratically. Ragequitting one game and binging another. So perhaps it became more a study of me than of the games. Why do I want to keep playing game X? Why am I bored of Y? What’s frustrating me in Z? Giving detailed, realistic and accurate answers to these questions is harder than you think! A majority of human decisions and preferences are unconscious, and fully explaining them verbally/consciously is very difficult.

Of course, this mindset can be applied anywhere. We’ve got a lot of options in the way we run our company. How do we communicate, how do we use marketing, how do we build a community, what’s an interesting story, what is a beautiful building, what is great music, what’s a good trailer - all of these questions have relevant answers that would be useful to us. I notice that nowadays, I’m constantly deconstructing a lot of what I see ánd my own reactions to that, and seeing what I can learn from that.

A while ago, I watched a video that I still regularly think about and that seems highly relevant. It’s a one hour talk by Jeff Vogel at the GDC. I didn’t know him or his games, but he’s been an indie dev since 1994 - and has kept his small company afloat that entire period. Instead of promising some Quick Tips to Instant Fame and Wealth, Vogel just talks about his experiences and lets you do the concluding. In some ways, he’s extremely different from us. He gets really demotivated from online criticism, so he barely has any interaction with his community. He releases a game, checks bug reports, fixes that, and goes on to the next game. We work in a completely different way - we read pretty much everything that is directed towards us and even scour the internet for discussions about Colony Survival. But if it works for him - it works! There doesn’t seem to be one perfect way to approach this, with all others paths being invalid. Here's a link to the video:

https://youtu.be/stxVBJem3Rs
So, let’s act like all these things are related and write a nice summary for this. In 2017/2018, the sudden success of Colony Survival was a bit of an “emergency”, and we worked hard to pick all the low-hanging fruit, all the simple improvements that could ASAP boost the fun of the game. Since then, things have started to shift more towards “long term mode”. The emergency is over so we’re establishing a routine. Simultaneously, the low-hanging fruit is gone so we’ve got to build a ladder, allowing us to reach higher than before. Making this transition requires us to go “Into Weirdness” into some areas. Does that make sense? :)

Bedankt voor het lezen!

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

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