New Twitch streamer aggregation implemented (#FuckTwitch) due to Twitch's API issues (more info on my Discord )
Name | Colony Survival | ||
Developer | Pipliz | ||
Publisher | Pipliz | ||
Tags | |||
Release | 2017-06-16 | ||
Steam | 19,99€ 15,49£ 19,99$ / 0 % | ||
News | |||
Controls | Keyboard Mouse | ||
Players online | 324 | ||
Steam Rating | Very Positive | ||
Steam store | |||
SteamSpy | |||
Peak CCU Yesterday |
| ||
Owners | 100,000 .. 200,000 +/- | ||
Players - Since release | +/- | ||
Players - Last 2 weeks | +/- | ||
Average playtime (forever) | 1424 | ||
Average playtime (last 2 weeks) | 638 | ||
Median playtime (forever) | 2201 | ||
Median playtime (last 2 weeks) | 638 | ||
| Public Linux depots | Linux 32-bit [97.57 M] Linux 64-bit [96.17 M] | ||
LINUX STREAMERS (0)
 Some people missed the rambling in last week's blog. We held a minor, relatively hidden poll on Discord but the results were obvious. So the democratically chosen subject this week is "How do we decide which features we'll work on?".  The one "X" under the first option was placed by me to show all potential options Choosing features is a tough but very, very important task. We think a lot about Colony Survival, we play and analyze other games, we discuss potential features for hours on end, and of course we listen to suggestions made by our players. We've also watched many, many hours of Colony Survival-gameplay on YouTube. It's very insightful to see how others people approach the game. When comparing potential features, we ask certain questions about them. We'll only proceed with the feature if all answers are positive. My mind visualizes it in a way I encountered earlier, when reading about the Japanese concept of "Ikigai". Ikigai is your reason for being. Instead of seeing your job, your hobby and 'charity' as distinctly different parts of your life, Ikigai combines all of these concepts: it's something useful that you're good at and that you love, and something you can earn money with. If you've found that, you've found your reason for being.  Kind of stealing this image, it's floating all over the internet, sources are at the bottom I think "a good feature" can be visualized in a similar way. There are four main questions that must have positive answers for the feature to be considered worthwhile. They concern these aspects:
This results in an image like this:  Every possible feature can be assigned a location somewhere in this chart. The closer is it to the center, the higher the chance it'll be added to the game! FUTURE This might be the least obvious part of the graph. An example. 0.3.0 added the science system to the game. It was pretty simple and boring at the time, but it was majorly expanded on and very useful in 0.4.0. The science system is a very important framework for other features, and thus it scored very high with this question. Other features score pretty low here. Many players would love to see a more beautiful tech tree with a clearer structure. That's a very sensible demand, but it'll make tweaking and updating the tech tree a lot harder. As long as we're still regularly adding new science, the tech tree itself won't change a lot. Not in a way that makes updating it harder, at least :) PERFORMANCE Colony Survival works on relatively old and simple hardware, and we'd like to keep it that way. Up to this point, it looks like 0.7.0 will actually increase instead of decrease performance, because of certain optimizations. A common request is transparency. We've experimented with this for a bit in the past, and it resulted in a significant performance hit. We try to avoid those as much as possible. DEVELOPMENT TIME This can be very hard to predict. Some changes are very easy. New "job blocks", new crafting recipes and new guards with different damage/range/reload speed stats can be added in a couple of minutes/hours. More complex features will take longer. And there's the basic software development problem that's it very hard to predict how long exactly you'll need. You'll often run into unexpected problems. And apart from technical problems, you'll often cause problems in the gameplay even if it technically works. For example, it took us a while to realize that "high happiness costs for big colonies" and "players can start multiple colonies" will result in the optimal gameplay strategy "start lots of tiny colonies instead of developing a big one", which is boring and repetitive. So we had to find the VAT/XP idea to incentivize players to grow their colony despite the happiness costs. GAMEPLAY Perhaps it's better summarized as "how many hours of fun will this add". A better tutorial might not really be 'gameplay', but there's a significant percentage of players who quit within an hour, who might've played the game for a lot more hours if the tutorial was better. Hello jacksepticeye. Better graphics/animations might also result in more hours played, but I doubt someone who has experienced all the content and quit the game after 60 hours will come back for dozens of hours because the colonists walk slightly more realistic. Animation/modeling is not one of our strengths, so you quickly end up with a bad ratio of development time vs. results.  The requirements above might sound terribly restrictive, but they have to be. Suggesting a feature is very easy, implementing it is often very hard. There are many things we'd love to add, but we can only do so much in one month or one year. We have to carefully pick the features we do work on. There's one extra important thing to consider for 0.7.0: breaking older worlds. It's something we generally try to avoid, so it's a negative quality if a feature requires that. But the new world and the new features in 0.7.0 will inevitably break older worlds. (You can always revert to older branches to replay older worlds!) That means that 0.7.0 is a great opportunity for all these features that break savegames to finally be added! That's one of the reasons why it takes so long. Last but not least, here's the promised full changelog of the three new dev branch builds that were released this week, to give you an indication of the scope of the changes: Sunday - reworked network code a bit to better handle timeouts/disconnects (without throwing errors like before :upside_down: ) - prevent starting a colony near another colony (both should have unique access to 200 blocks radius) - moved out some banner settings to settings/server.json (loaded chunks radius, max zombie spawn radius) - autoremove colonies without a banner (will require some UI to allow moving a banner later) - probably fixed zombies spawning in safe areas (hard to check with the exlusive access area) - fixed a bug where removing a specific rotation of the end of a bed did not remove the other half of the bed - changes sapling trees to grow 1 higher (so the forester can walk through his field if there's any elevation changes) - fixed steam server 'score board' for the active players list - removed use of beds/crates outside of the colony radius code things: - merged the chunks' data & AI readwritelocks into one - removed some unused code from IChunkData - changed OnPlayerMoved callback to also take the old position as an argument - changed banner/close-player chunk load requests to use some bitarray lookup table thing instead of a queue (so requests are not duplicated, allows loading in a way that makes the terraingenerator much happier) - changed ServerManager.TryChangeBlock, World.TryGetTypeAt and World.TrySetTypeAt: -- now take an optional old expected type to get rid of race conditions from seperate read and write actions -- returns an enum with multiple options instead of a bool -- updated/expanded the flags enum that controls the behaviour of these methods -- the "cause/requestedby" argument is now a union struct containing either a player or a colony (instead of only player causes) - changed OnTryChangeBlock callback to have the same union struct as above - added OnUpdateAdjacent callback to blockentitycallbacks - changed block entity's on block change callbacks to use that player/colony union struct - removed the old ItemTypesServer.OnAdd etc system, replacing it with the block entities callbacks code known issue: - blocks that require a solid block below them currently do not disappear if that solid block is removed (i.e, remove dirt below quarter blocks / plants) Tuesday - fixed an error when trying to update the steam server score of a player with no colonies - reworked the chat command class interface a bit (includes a list - fixed the "needsbase" check - blocks removed due to removal of the solid block below them (plants, quarter blocks etc) are now removed again, and will be refunded to the player or stockpile if possible - added a few new commands: -- /colony addowner {player} [colony] -- /colony removeowner {player} [colony] -- /teleportother {player} banner -- /teleportother {player} here -- /teleportother {player} {x} {y} {z} - extracted some code from chat commands into the command manager, so all {player} options now allow either the steamID64 or the name - multiple owner colonies seem to be working as intended based on initial testing - fixed the cursor visibility bug (unity undocumented API change, it still says Note that in CursorLockMode.Locked mode, the cursor is invisible regardless of the value of this property. ) Wednesday - fixed dedicated server wrapper - allow using the older style +server.world blabla etc arguments to launch the colonyserver (so it works on pingperfect) - fixed initial inventory for players (untested, woops) - fixed initial stockpile for colonies - added icons & names to the grass types, and they should drop themselves now instead of their parent - added icons & names to the leaves types - updated leavestemperate icon - fixed server world loading menu order - fixed singleplayer world loading menu order Bedankt voor het lezen! Reddit // Twitter // YouTube // Website // Discord |
