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

Lens One: Interpreting your Experience

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

Lens Two: Checking Relevancy to Target Audience

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?

Lens Three: Technical Difficulty

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...

Conclusion

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

[ 2019-11-01 09:53:02 CET ] [ Original post ]