rihapat

🌟HIGHLIGHTS🌟 STARTER PACK Starting resources and other important stuff for bargain price! Can be purchased only ONCE per account. This pack is based on our players' feedback and is an ideal choice for starting players who want to enjoy a little boost to the start of the game. https://store.steampowered.com/app/2904300/Ylands__Starter_Pack/ SUPPORTER PACK The most exclusive and top shelf cosmetics for the biggest Ylands fans who want to support the game's development. Entry to a special Discord "Supporter only" room is included in the pack. Not a member of our Discord yet? Click here to join now! https://store.steampowered.com/app/2904310/Ylands__Supporter_Pack/ INTRO For months we evaluated what should be showed off more and now it's going live! New players can get a better taste of what they can experience in Ylands from the very beginning. The time to invite your friends to play Ylands (or reset your progress) is now! New Assets STARTER PACK: Avatar's Tropical Frame SUPPORTER PACK: C.A.G. Admiral Costume Noble Wave Emote Avatar's Baroque Frame C.A.G. BENEFACTOR title ADDITIONS Added: New playable Intro where player will be introduced to C.A.G and main features of the game. FIXED [YLD-51838] Fixed: Story: Players lost progress from Elmwood outpost. [YLD-51621] Fixed: Editor: All damage immunity / No player vs player damage check boxes are wrongly checked in Game settings. [YLD-51083] Fixed: Editor: On Invulnerable Hit event does not trigger for invincible players. [YLD-50834] Fixed: A handbook memory leak that would occur upon changing the active session (leaving a game into the main menu, changing a server etc.).

Ahoy Ylanders! All of the beautiful melodies that accompany you on your adventures in the world of Ylands are here for you now. Purchase the Ylands Original Soundtrack by the composer Varhan Orchestrovič Bauer on Steam! Going out to grab some groceries? Put on the dungeon music (aka Memorable Mysteries) and feel the thrill of a golem lurking around the corner on the streets of your own town! Changing a lightbulb or fixing a shelf? Casually Crafting or Building Blueprints are the songs for this occasion! But be careful, you might start to see polygons if you give in to that feeling too much. Facing an aggressive person on the street? Don't forget to change the song on Hostile Hyena and remember, if you manage to gain a certain distance, they'll leave you be! The time to bring adventure to your everyday life is now. Get the soundtrack here: Ylands Original Soundtrack on Steam (steampowered.com) Track Listing: Adventure Awaits - Bohemia Interactive, Varhan Orchestrovič Bauer Serene Sunrise - Bohemia Interactive, Varhan Orchestrovič Bauer Casually Crafting - Bohemia Interactive, Varhan Orchestrovič Bauer Building Blueprints - Bohemia Interactive, Varhan Orchestrovič Bauer Propeller Pack - Bohemia Interactive, Varhan Orchestrovič Bauer Evening Encounters - Bohemia Interactive, Varhan Orchestrovič Bauer Very Vague - Bohemia Interactive, Varhan Orchestrovič Bauer Hostile Hyenav - Bohemia Interactive, Varhan Orchestrovič Bauer Memorable Mysteries - Bohemia Interactive, Varhan Orchestrovič Bauer Naval Navigation - Bohemia Interactive, Varhan Orchestrovič Bauer Underwater Universe - Bohemia Interactive, Varhan Orchestrovič Bauer Quirky Quests - Bohemia Interactive, Varhan Orchestrovič Bauer Lazy Life - Bohemia Interactive, Varhan Orchestrovič Bauer Interesting Idea - Bohemia Interactive, Varhan Orchestrovič Bauer Kind Kerfuffle - Bohemia Interactive, Varhan Orchestrovič Bauer Gloomy Ghosts - Bohemia Interactive, Varhan Orchestrovič Bauer Fluty Flute - Bohemia Interactive, Varhan Orchestrovič Bauer Diving Deep - Bohemia Interactive, Varhan Orchestrovič Bauer Terrorbird Terror - Bohemia Interactive, Varhan Orchestrovič Bauer Omnious Omen - Bohemia Interactive, Varhan Orchestrovič Bauer Random Rest - Bohemia Interactive, Varhan Orchestrovič Bauer Just Join (Already) - Bohemia Interactive, Varhan Orchestrovič Bauer

Ahoy Ylanders! With update 2.2, those who started a new game (or reset their progress) can experience a new introductory scene before arriving at the starting island. Let's discuss why it was added and what it brings to Ylands. One of the biggest challenges for free-to-play (F2P) games is retention. Many players try them out, but only a few stick around long enough to make a significant impact. Casual F2P games, like shooters, puzzles, and match-threes, have it easier. They can showcase their core gameplay almost immediately after the player starts the game for the first time (despite clicking through countless popup windows). For a game like Ylands, this is much more complicated. Up until 2.2, you started with nothing and very little to do besides picking up items. You picked grass, sticks, stones, and flint. These were your first minutes in the game, and based on this, you decided whether to give it more time, which could turn into hours. The math is simple: more new players playing the game equals more effort put into improving the game for everyone. In update 2.2, we added the Tech Tree and Handbook Quests. Suddenly, you can clearly see what you can achieve and how to get there. There's always something interesting to do. However, this doesn't entirely solve the problem I mentioned earlier. For the new player, it's more like a promise that there are some great things ahead and that the game becomes much more fun and interesting once you get past the "gathering phase." What we wanted to do was give players a taste of how great it is to have your own ship, explore various unique places, and do it as soon as possible. This is why the short playable intro scene was added. Based on the numbers we've seen, it seems to be working. More new players are finishing the subsequent tutorial than before, and they are staying longer. Knowing that this works, we can safely proceed to the second phase of the Intro scene operation - releasing a vastly improved and polished version of the intro scene. We believe this will give new players even more reasons to invest time in the game, discovering its unique and complex nature. This new version of the intro scene, featuring sailing, underground exploration, and more sailing, should become available in about a month or two. Have fun and stay classy, Ylanders!

Ahoy, Ylanders! You may have noticed we do a lot of competitions on Discord. Well, this time we have something extra special for you! Have you met Ros Bobb? Doesn't it feel sad how he is just standing there in the open, his paintings getting washed away by the rain, so he has to repaint them every day. Well, now you have a chance to save him. We want you to build a house, a studio, a stall, or anything else for Ros Bobb and we will add it to the game! How to join: Join our Discord: https://discord.gg/ylands Look at the rules in #competition_announcements Submit your beautiful entry and get a chance to get your asset in the game and win 1000 Coyns. We are most excited to see what our creative community can come up with. And Ros Bobb? Ros Bobb is eagerly waiting in the rain for your help. Stay Classy, Ylanders!

Ahoy, Ylanders! Have you ever wondered how feedback works and what goes on behind the curtain? Some of you are in contact with our beloved community manager, Anna, who keeps communication with you. When you write in-game feedback, Anna sifts through all the messages and forwards any unreported bugs to our QA team. Feedback is sent along with the Adventure save of the game from when you submitted the feedback and log files. Often, it's like a detective job, scouring log files for anything suspicious, especially related exceptions or errors. Thanks to this process, we can progress in our attempts to reproduce reported bugs. HUNTING Some issues are obvious, like visual glitches such as bugged icons of assets. However, often it's not that easy, and we may spend hours trying our best to reproduce the reported bug. In cases where reproducing the bug isn't straightforward, we use Unity tools to import data from log files sent with the feedback to our characters. This helps us see the issue from your perspective, allowing us to piece together the mystery. This tool is valuable, especially because a bug might only be reproducible with your data, aiding programmers in potential fixes. Additionally, it helps us consider scenarios of what happened, better enabling us to understand the situation. Our character, with your data imported, has your clothing, inventory, and map. Combined with the report, we can more easily imagine what was happening when the bug occurred. During our search, we often uncover many unrelated bugs, making the search itself effective in bug hunting. With a small team of testers and numerous elements in our game, it's challenging to keep track of everything. Your reports are crucial, and we take the time to address each one, enhancing the game thanks to your contributions. FEEDBACK It's not just about bugs; it's crucial to see your perspective on what's annoying or unpleasant. We are immersed in the game daily, sometimes missing obvious things or getting lost in details. Your feedback helps us see the bigger picture—the game as a complete product, not just individual pieces. We value your feedback and strive to improve the game accordingly. Some of us in the Ylands team keep a close eye on Discord channels to catch all the bugs or other issues. Feedback on the game can sometimes be contradictory, so we consider the majority of feedback and the core direction of the game. COMMUNICATION Solving reported bugs involves communication with various areas of our Ylands team, especially programmers. We may need help understanding log files, exceptions, and errors. Cooperation with designers is essential too, as sometimes issues are more design-related than bugs, requiring the input of designers. Testers also provide feedback when a new feature is implemented, contributing to the polishing process before the feature becomes fully functional. In the case of your sent feedback, we are the ones trying to reproduce reported bugs, and our community manager then maintains communication with you. RANDOM BUGS These are the tricky ones, and we're powerless against them since random bugs may appear once and never again. Fortunately, we have Unity tools to mitigate the damage from these bugs, such as a tool for restoring lost items and exploration points. As mentioned, feedback, whether bug reports or general feedback, is crucial for us to uncover hidden bugs. Your help in catching them is invaluable. Thank you, and have a fantastic day! Stay classy and keep providing feedback!

Ahoy Ylanders! We all love some ships, right? This time Prokop the Asset Designer (and a Deckleader as is written in his sea book) has something to say to you classy bunch, as he might be one of the biggest historical ship enthusiasts among the team. For designers, it is important to draw inspiration from things they are passionate about, so take this as a peek inside the mind of an Ylands designer! Building a ship as your mobile base and travelling across the vast oceans is an inseparable part of the Ylands experience. But that is also not far from reality, because not only you, classy adventurers, use your ships as mobile bases. Did you know that ships were, and in many cases still are, floating manufactures with plenty of "workstations"? That's right, during the Age of Sails many specialists with their proper equipment were a part of the crew. The sailmaker was a skilled tailor able to stitch and patch any damaged sails, the cook used the stove aboard to bake fresh crackers. But perhaps the most skillful artisan of them all must have been the ship carpenter able to not only repair the hull, but also make a whole new bow figure if it was hit with a cannonball for example. In the diaries of the great explorer James Cook, you can learn that when a mast was broken in the storm, the captain ordered the ship to be dragged to the shore on a desert yland. Then the carpenter looked for some good tree and made whole new mast from it. All that was done in only a few days, but imagine doing that to repair your ship in Ylands, that would have been quite the workout! Although many expeditions in our real world are no longer done aboard sailing ships, you can still experience uncovering the unknown under the sails and charting new maps in Ylands. As the game medium simplifies things but also allows many fantasies to come through, you can build your ship however you like without the need of having properly trained carpenter. And with the upcoming Update 2.2, you may even get your ship going faster with the new Elven Sails than you could with an engine! Let us know what your favourite sail ship is and a fact about it in the comments. For Prokop, this would definitely be the brig La Grace, as its captain, Augustine Herman, was the only known Czech privateer in the Caribbean! Stay Classy, Ylanders!

Ahoy Ylanders, What do you love the most? Whether its your mum, spouse, yourself, your favourite pet or tea brand, Ylands game or the day after a paycheck, one thing's for sure: everyone likes sales and discounts! That's no secret, right? That's also why we're writing this diary. This Valentine's Day won't be secret at all! Quite the opposite—Valentine's sales are coming to the Ylands shop and we hope they will be as visible as light itself. Let's see what we have in store for you! Limited Pet Everyone should get on board with this cute Fox On Board pet! You can see it in its eyes that it already loves you. Sadly, Foxy won't be here forever and is available only until 22nd of February. Lovely Sale 'till 22nd of February In case you need to propose to your significant other, this February there is a 50% discount on the Proposal emote! Also, we wanted to make sure that our lovely Fox won't be alone so we are throwing in a 30% discount on the Gryphon and Fairy pets! But THE SALE is the Vases recipe bundle, which is 80% off. Feel free to gift it to all of your friends and go picking flowers together! Discord Foxy Rewards Already got the Fox On Board pet? Great! Send us a screenshot with your new lovely pet on our Discord server to the #screenshots_ylands. On the 13th of February, we will randomly choose 3 winners from everyone who sends a screenshot of Foxy accompanying them. The prize is yet another Fox pet that the winners can gift to their significant other. Lastly, let us express our love to you. Thank you so much for constantly returning the love that we put into the development of Ylands by sticking with the game in the good times and worse times. Stay Classy, Ylanders!

Ahoy Ylanders! In game development, not everything we do is immediately visible or playable in the upcoming updates. We often find ourselves preparing for future features, creating tools for designers, or making adjustments to NPCs, resources, or gameplay mechanics to enhance the player experience. Sometimes we need to get back to the old features or technology and rewrite the code or change the graphic assets so it fits the game better. Gameplay adjustments Gameplay adjustments are often necessary during the development to improve the overall player experience and ensure a fun and engaging gameplay. Let's explore an example of gameplay adjustments made for Ylands, specifically related to the introduction of the Tech Tree and resource placement. When preparing to release the Tech Tree, a significant improvement for Ylands, the design team had to carefully reconsider the placement of resources throughout the game world. The goal was to create an experience that encourages players to explore the Ylands world, discover new recipes within the Tech Tree, and ultimately, have fun. New tools for designers Luckily, not everything has to be handled by the programmers. They often cook up some nifty tools that designers can use to sprinkle in all sorts of stuff into the game without any coding. Adding a quest into the handbook can be a good example. That way, the seasoned programmers can put their focus on the really important stuff while the game keeps getting cooler. Yet, creating tools like this is not instant and starts delivering visible impact exactly one update later. Technical debt It is not uncommon for game developers to introduce a completely new feature, only to realize during team feedback or playtesting that it requires a few additional elements to enhance understanding and enjoyment. At times, these additions can be quickly implemented. However, in other cases, programmers may resort to "hacking" or applying temporary fixes, these deviations are often responsible for bugs in the future. Therefore we need to rework this code in the future updates, as they can hinder the implementation of new features. Additionally, when extending an existing feature, developers may discover that the initial code was flawed or some important aspects got overlooked. This realization requires reworking the code to address the shortcomings and avoid accumulating technical debt. Have fun with any new update We hope that you enjoy every new update even if there is no "flashy new feature" and we "just improve" something for you. All the changes, whether they are small or feels invisible are made so the Ylands could be an even more awesome game than it is now. Thanks for understanding and Stay Classy!

Hello Ylanders! Do you ever wonder what happens to the bugs which we at the QA department find in the game and submit into our system? Today we'll take a look at their journey! If something in the game doesn't work or doesn't match the way it was designed, we'll mark it as a bug. This can be a whole range of things - from a badly rotated block to the game crashing completely. Let's say, for example, we're entering the incorrect block. We assign it the proper priority, "epic" (what feature or group of tasks it belongs to), component (which areas of the game it applies to), and which version of the game it belongs to. Then it is important to determine a "fix version" in other words, when we want to have the issue fixed. For example, if we want the bug to be fixed by the next update we assign a fix version with the next update number. If it's an issue that isn't as pressing, we assign it a Backlog fix version and then such bugs are solved when the person they are assigned to has more time. This brings us to the last step in the issue creation and that is the "assign" part. We use it to determine who is in charge of fixing the issue. In the case of our poorly rotated block, we will assign an issue to someone from our art team who takes care of the visual parts of the game. So the issue landed on a graphic designer in a "To Do" status. Our graphic designer will fix the bug by rotating the block to the correct position and sending it back to QA. They do this by switching the bug to the "Prepared for testing" phase and assigning it to the QA lead. They must also remember to fill in the revision (the version of the game) on which the issue can be retested. QA then waits until the revision is built and at that point it can start testing if the block is rotated correctly and if it's been fixed on PC, Android and also iOS mobile devices. The "Prepared for testing" state is then changed by the tester who is testing the issue to "In test". This is how the others can tell that a tester has started working on the issue and we avoid two people testing the same thing at the same time. Now we are at the stage where either the issue is fixed or we have some reservations about it. If it is fixed on all devices we can close it (switch to "Done" state). If we are still not satisfied with the solution (for example the block is turned in the right direction but too much) we add a comment to the issue, fail it and send it back to the graphic designer who fixed it, they fix it again and send it back to QA and this is how it goes on until we are satisfied with the fix. However, there may be cases, and it is very common, where fixing one issue causes a new issue or several new issues. For example, the moment our block is turned around correctly, a problem with the integrity of Blueprints may occur. By changing the pivot of something we break the Blueprints of the people who used that block in their Blueprints - because it also gets rotated in their Blueprints. So we submit a new issue and link it to the one already fixed. When testing, it's important to remember that every fix can have consequences, and just because we fix something doesn't mean it won't break something else. Game development is a very lively and dynamic process. It's made up of many pieces and there is room for error in each of them, so it's important to not only test individual parts, but also the whole. Therefore, please be forgiving and if you find something that doesn't work, report it to us. Now you know what path your issue will take and that it's a winding road. Have a great day, enjoy playing and Stay Classy!

Ahoy Ylanders! As you might have gathered from the previous programming dev diary, changes always carry the risk of introducing bugs – and this goes double for last minute changes. Programmers are conditioned to avoid risks where possible; after all, it’s our job to make sure that this huge machine of a game works as expected. But in some situations – such as when a winter festival is to be held for the first time and the game lacks throwable snowballs – you just have to pick up the gauntlet and roll with it despite the short timeframe, because you feel that the fun potential is worth the risk. We already had throwing controls complete for grenades, but wanted the snowballs to behave more like an arrow does, just hitting a target and disappearing instead of exploding violently. Sometimes, programming new features is just like LEGO, you take existing pieces and creatively combine them in new ways, and that’s it. There’s also another way programming is like LEGO – sometimes to get what you want, the only way is to tear the current construction down and rebuild from scratch. Fortunately, for snowballs it was the first case, because we have already invested time into making projectiles work well beforehand. So let's have a quick look at how projectiles actually work in Ylands! There are two main approaches to simulating motion – kinematics and dynamics. Kinematics is where we directly describe the motion via an equation based on position, velocity, and acceleration. Dynamics behaves more closely to how the actual physics works, by applying various forces to an object, which can then generate motion based on its physical properties – mass, inertia, shape, etc. Looks like dynamics must be the way to go, being the more accurate option, right? Well, there's a catch. Due to its complexity, dynamic motion is much harder to predict, analyze, and make deterministic – key properties for a multiplayer game, since they allow us to have exactly the same projectile trajectory for all players. In fact, most motion in Ylands is kinematic, except for vehicles and ragdolls, which are too complex for kinematics. Choosing a simpler but a more controllable approach where possible is actually very common in game development! So we opt to simulate projectiles via kinematics, but we need an equation for projectile motion. Very fast projectiles such as bullets can be thought of as having a constant velocity, and thus moving on a line. Having an initial position P₀ and velocity v, their position at time t after firing can be easily calculated as P = P₀ + v ⋅ t. In fact, we can take bullets even further, thinking of their movement as instantaneous – their velocity is so large that they can reach any point we shoot at immediately after they are fired. This simplifies the simulation to checking whether any object lies in the line of fire between the origin point and the target point, which the physics engine can conveniently calculate for us via a raycast query. The simplified equation can only take us so far however, because it excludes the effects of a very common force - gravity. With bullets, we could ignore it because the initial velocity was so large that we hit the target before gravity has a significant impact on the trajectory. But that won't work for slower moving objects such as arrows, grenades, and, you've guessed it, snowballs. What gravity does is it applies uniform downward acceleration (gravitational acceleration) to the object, building up velocity over time. The equation for uniformly accelerated motion is P = P₀ + (a ⋅ t²) / 2 where a is the acceleration, in our case the gravitational acceleration g. If we combine this with the effect of initial velocity as seen on the bullets, we get the final equation P = P₀ + v ⋅ t + (g ⋅ t²) / 2. This is a quadratic equation, meaning that the final trajectory will be a parabolic curve – which is what we expect from snowballs and arrows. Once we have the equation for calculating projectile position at time t, it becomes a simple problem of tracking how much time has elapsed since the shot was fired and moving the projectile to the calculated position based on current time. Except now we are ignoring all the obstacles along the way! First thing that comes to mind would be checking for collisions at the current position – if we overlap with some object, we have just hit it and can deal damage to it. Unfortunately, this won’t work for fast projectiles and thin obstacles – the way the game simulation works, we can only update the projectile position after a fixed amount of time passes from the previous update. If we just check the previous and current positions there might be no collisions, but only because we have already fully passed through the obstacle – a phenomenon known as “tunneling”. But hey, we’ve already solved this for bullets! We can again look at the previous and current position and check if anything lies between these two points via a physics engine raycast. If we hit something, we determine whether the obstacle stops the projectile movement – in which case we stick the projectile into it and apply damage – or if the projectile should pass through the obstacle unhindered. And that’s the gist of it! This small bit of kinematics allows you to throw a snowball (or a grenade if you’re not feeling particularly festive) in the face of your fellow Ylanders. It also allowed us to implement gun and bow aim assist for mobile and gamepad controls in 2.2, so stay tuned for that – and stay classy!

Ahoy Ylanders! Patrik from marketing here! 2023 was a wild one for Ylands. Just consider the craziest thing, instead of the awaited 1.12 version we released the biggest update in Ylands history: the 2.0. Even though this was the bomb, there were so many other important numbers throughout last year. Let's see some marketing and game data! Marketing data You sent 101 691 messages and spoke for 76 243 minutes on the Ylands Discord server. What can I say, you just love to chat and admire each other's work. If you want to find some friends to play with, our Discord server is the best place for you. Now, we know, that you were not bored, and here is proof that the Ylands Marketing team also had a lot of fun this year. 4 Ylands Streams were held, 1 of those was quite a revolution as it took place on Discord, being closer to you all as we were playing games together, competing, chatting, and chilling. We posted over 300 posts on Facebook, Instagram and Twitter X, and within traditional weekly community screenshots, we shared 156 of your in-game screenshots and amazing builds. From the video perspective, we presented the world with 2 trailers and 61 short videos for our TikTok and YouTube. If you are not following us on some of these social media you should definitely give it a shot! We held 18 competitions and contests, and delivered at least triple the amount of prizes and giveaway items! We simply don't know the precise number here as sometimes, we just have to reward you randomly for being so awesome and helpful to each other. Last but not least we released 50 Dev Diaries and 21 maintenances were run. But let's get back to you, Ylanders! Game data 5 617 blueprints, yes that many amazing creations were uploaded to the blueprint shop by you, Ylanders! And what about all the wonders you accomplished directly in the world of Ylands? Oh boy! You picked up and cut down 1 245 456 plants, tamed 11 227 animals out of which there were 1 777 horses, and crafted 26 705 134 items. Surprisingly enough, among these 26 milion, there was only a single cultist skirt crafted. Those are all amazing numbers and we couldn't be happier. Thank you so much for all the time that you spent with us, whether it was chatting with other Ylanders on Discord, creating blueprints and sending us your screenshots, watching our videos and liking our social media posts, and most importantly for the time you've spent in the world of Ylands. We wish you to Stay Classy in 2024!

Ahoy Adventurers! In this week's dev diary, us in the QA department have been asked to talk about game dev experience from our point of view. We've been scratching our heads how to convey the Tester Experience TM and after some thought and pondering, we've decided to focus on the life cycle of an update and put forth the following description of events. As you read this account of ours, try to immerse yourself in the spirit of good-natured humor sprinkled with just a tiny bit of desperation. We do love game dev in general and our game in particular after all, but perhaps being tasked with finding the mistakes and shortcomings in everything we touch reflects in the mentality and jokes we make. But all we do, we do to help make Ylands as amazing as possible. Ground Zero - An earthquake update hits the floor The culmination of several months' worth of pressure effort and preparations. At long last, an update is released, however the work isn't done here by any means. For us at QA headquarters, the ride continues and the show goes on. During the release maintenance window, we scramble to double check that crucial systems and infrastructure work. Some things we can reasonably expect to work once live, but things like logging into the app, the workshop, servers, exploration and similar cornerstones of the game can hide issues we only discover last minute. Usually things are fine, though sometimes the maintenance window needs to be prolonged for us to be able to deliver. And in the absolute worst case scenario, if a blocker is only uncovered now, we have the option to break the glass and hit the Big Red Button to roll back the update, restore the previous versions and dive deep into what went wrong. Needless to say, nobody likes to even consider this option, least of all us at QA HQ. Let's assume things went more or less well, losses are within parameters and move on to the next stage. Our wonderful community manager announces that the maintenance is over and an update is live and we start dealing with the fallout. First responders & Damage control It's close to assured that there will be issues to iron out after an update. Nobody is perfect after all, and while all of us in the dev team give it our best to achieve that state, it's ultimately impossible. So, in the first days or possibly weeks after an update, we spend much of our time investigating any issues that eluded attention until now and roll out hotfixes and patches to control the fallout. The tempo is rapid and while we all long for relief in this time, we know it's important to keep the pressure up. Rapid QA response to fixes and other commits, attention to detail and in some cases, figuring out why a critical issue flew under the radar are the items on the agenda in this period. Forecast: crunches with a chance of meatballs. Eventually, the most burning issues are wrangled and we can finally let out a tired sigh of relief. For a short while, it's done. Humanitarian relief A thick line between the previous update and the next has been drawn and we finally start looking to the future. We regain our strength, we refocus, we learn. The length of this window heavily depends on how many patches were pushed for the last update and there always exists the possibility that relief never comes - the sheer amount of necessary work takes so long that we can find ourselves deep into the next update's life cycle even before the previous one is over. Speaking of the next update... Another crisis on the horizon When an earthquake hits, a tsunami may follow. The development of features and new content doesn't halt just because things needed fixing. Eventually, we need to turn our eyes to what's on the horizon. There is a surge in workload as requests for testing start coming en masse and we give one last tearful wave to the short period of reprieve as it sails away. The quicker we dispatch these tests, the more time for adjustments, polish and feedback there is and, as it logically follows, the better the state these new features will be in. And as we send back bugs and feedback, retest, report newly found bugs, return whatever wasn't sufficiently improved, rinse and repeat. Damage projections As the ongoing cycle matures, there comes a time when everyone needs to take a step back and look at the larger picture. Before the dev team fully commits to a given state of the game, feature states need to be re-evaluated and prioritized. Sometimes you can be enthusiastically crunching away at a feature but find out you didn't quite have the time to get it done, sometimes the core is done but during development you find out there are simply too many issues for you to be able to fix before it's too late and sometimes, a feature was just too large and took so long to finish that we at QA HQ simply don't have the time and people to properly make sure it's in the best possible state. This is the point where hard decisions have to be made. Will a feature be postponed? Will its scope be reduced? And will it still be viable after that? Sometimes it is better to postpone than to release something we're not happy with, after all. A tsunami Data lock confirmed The data just came in from the boys in the lab and it's dire. The vague threat of another disaster has taken a more concrete shape, the dreaded data lock. From here on out, no new features get in and it's all about polish, fixes and making sure everything works together. And even then, every new merge needs to be considered carefully - is it important enough? Is it safe? Can it break something else? Is it a new issue or something we've been able to live with already? These and many more questions are behind every new ticket we throw at the rest of the dev team from now on. Evacuation and infrastructure reinforcement After data lock, a new branch is built - Release Candidate. It is here that any merges deemed important and safe enough go and are tested in the name of stabilizing the build and making sure it comes out in it's best form. For us at QA HQ, that's not all however. It is at this moment that we start retesting any and all new things, be it new features or tweaks of existing ones. No ticket gets left behind as we have to make sure that nothing broke between us first seeing a ticket and now, after hundreds and hundreds of commits that could have potentially influenced whatever we're looking at. We also launch a large scale integrity test of the whole game around this time to ensure that there are no critical weak points in existing systems. It is a long and laborious process, but we couldn't proceed without it. Simulations and drills Sometimes, when there is a reasonable need, it is prudent to prepare the public at large for the coming disaster. This is where an experimental build might be released for you all to romp around in once the RC build is in a reasonable enough state and there is need for community feedback on the changes the dev team has prepared. This spells another workload surge for us as we need to go through your reports and figure out what's already known, what's new, what needs to be fixed ASAP and to compile your feedback to figure out how to best utilize it. Often times balance changes are made based off of what we gather during this period, which then need to be tested once again. The tide draws near As we're closing in, mobile and Windows Store submissions need to be covered as well. These can take anywhere between a few days up to weeks to resolve for each submission. The workflow changes somewhat during this time as we need to allocate more time to testing on these platforms before their respective submissions to ensure the builds are healthy, and once a submission has been dispatched we can then reallocate all of that time back onto the main game to run the same tests on the steam build. The quiet before the storm It's almost here. The suspense is incredible. Tensions are high once again. Everything seems quiet, things look fine. Maybe it's the job, maybe it's just who we are as people, but whenever things go too well, all of us here at QA HQ start sweating bullets. Like any leadup to a big event, this is a very stressful time. After all, we could always find a last-minute blocker, which is a scenario nobody wants to see. In theory, should such a scenario occur, this is where QA can veto a build instead of giving it the coveted green light. This means an update could be postponed by a week or two to fix something absolutely crucial to the release, but schedule is often very tight and the release process is a complex matter, so unless it's something that renders the game or a large part of it unusable, we often need to proceed anyway. As a result, we might start getting first responders ready even before the disaster hits. During the last moments of this journey, an announcement about an upcoming maintenance is released to the public and soon after, the big moment is upon us all. Ground Zero - A tsunami An update hits the shore This seems familiar, doesn't it? Almost like we've been here before, one might say. As we close this entry here at QA HQ, we would like to add that there are many aspects of our work, additional intricacies and processes that might even differ between different parts of the game. Those are, however, stories for another time. Stay QAssy!

Ahoy Ylanders! Welcome to Dev Diary number 300! The Ylands team is a cheerful bunch and we love any opportunity to celebrate and we wanted to invite you to celebrate the release of 300 Dev Diaries with us! First of all, let us thank you because without you, Ylanders, there would be no need for Dev Diaries. Thank you for being here and for being awesome! When Ylands was still a baby, Aleš and the team released sneak peeks every now and then, but eventually, they started releasing Dev Diaries. If you don't want to go looking for the very first one, we've dug through the archives and pulled up the link for you here: https://ylands.com/community/topic/285-dev-diary-1/ We've come a long way since then, which we touched upon a bit in Dev Diary #200. So it is only fitting that we look at what's happened since number 200! Update 1.9: Ocean Odysseys took a deep dive, literally, into the ocean. Sharks made a big comeback after learning their place (which of course is not in the skies above but in the waters below), many new fish made Ylands their home and the underwater world became a much more exciting, but also dangerous place. To sail such dangerous seas, we added an entire arsenal of ship devices that help navigate the unpredictable waters, where ships might get damaged and even sink! Ymproved Ylands, aka Update 1.10, brought oh so much new stuff! The FPS camera was brought back Mythical Animals appeared in the game Blueprints got better Mounted actions became a thing. Probably the most important improvement of this update was the beginning of a larger scale Adventure balancing for the best possible gaming experience. To continue the improvement of already existing features, Update 1.11: Crafty Crafts focused on crafting and Blueprints. The entire crafting menu got a much needed overhaul and Ylands creators could upload their Blueprints to the market so that as many players as possible can enjoy them! Many other pieces of the puzzle started to fall into place with a new gifting system, randomized loot, new monsters and many more tweaks and fixes. And finally, the Classy Adventurers Guild opened its doors to adventurers young and old and welcomed them in Ylands Update 2.0! C.A.G. has brought one of the most important features into the game: Adventurer's Handbook and with it the very first mission: find Horation Reginald Elmwood, the adventurer extraordinaire! Handbook was such a big deal that even on its own, it would have been huge. But we know that you wanted more and we delivered! Ylands introduced sailing with wind, improved terrain generation, new main menu, better tutorial, new random encounters and soooooo much more. Ylands also changed its visual identity, not significantly, but enough to be recognizable, unique and truly ours. Since this Dev Diary is written by the marketing department (remember when we told you that each Diary will be written by a different department to give you more of an inside look? ) we can only say how extremely proud we are of our entire team for making 2.0 happen and to give us something incredible that we are so excited to show the world every day. But we didn't stop there, of course! In Update 2.1: Sunken Sands, inventory sorting was implemented and made all of our lives much easier and organized. If you're not the social type or simply enjoy playing Ylands in Singleplayer mode, pausing the game was likely a very welcomed upgrade to the experience. And you got your second big mission from C.A.G., this time in the Arid region! And as always, there were many more quality of life improvements and additions to the game. Which ones were your favorite? So what's up ahead? We've already told you about the upcoming tremendous techtree that will make its debut in 2.2 and we really think that... wait a minute. Tremendous Techtree. Tremendous Techtree? Tremendous Techtree! Let's call it that! So in Update 2.2: Tremendous Techtree you can look forward to just that - an amazing feature, which will surely be helpful for any and all C.A.G. members! What else? You're gonna have to wait for that a tiny bit longer, but worry not, that info is just around the corner and we aim to reward you for your patience. Once again, we are very grateful for your support and love that you show us everyday. Thank you and as always... This is Ylands! Oh... and Stay Classy of course!

A ho ho hoy Ylanders! A cup of hot chocolate next to you, a fluffy blanket around your shoulders, a soothing crackling fireplace in front of you and then... *SPLAT* a snowball hits you in the face! Well, not you, but your Ylands character! Welcome to YLANDS WINTER FEST! We hope that you are ready to spend this winter in the world of Ylands, exploring the lands and searching for 6 new Christmas themed animals and 10 different kinds of collectible toys, completing 3 new achievements, and throwing snowballs left and right! So what have we prepared for you in this time-limited winter event? New Christmas Animals Six kinds of our animals have put on Christmas bling and can now be seen roaming around their respective regions. These can be tamed using a special Christmas bait which is found as a reward in random encounters. If you want to befriend these special animals and keep them even after the event ends, hurry up and go tame them now! Toy Collectibles Christmas came early and there are many wonderful gifts hidden within random encounters! Can you collect all 10 kinds of toys and earn a special new achievement? You will of course get to keep all the toys you collect even after the Winter Fest event is over. And then you can spread the joy and give them as gifts to your friends in the game! Snowball fights Who threw that snowball? Who was it? *brushes snow from face* We're just trying to peacefully explain all that's new and available during the Winter Fest and you go throwing snowballs at us?! Well, we can't really blame you, because throwing snowballs you discover in random encounters is sooooo much fun! We will even organize a snowball fight with the developers on December 21 at 5pm CET! 3 New Achievements Tame all 6 Christmas animals, collect all 10 kinds of Christmas toys and throw at least 30 snowballs at your friends or NPCs - that's the way to obtain these special achievements, which will be available only during the Winter Fest event. Don't forget to show them off, it's no small feat to gather all three! And if you complete all of them, run to our Discord and let us know! The first three people to do so will win a free pet! Time-limited holiday pet Is Socky the Shark the cutest pet to ever come to Ylands for an exchange program? Definitely. Is the Santa's elf who went to the ocean instead of Socky struggling in the depths of the water? Who knows 😅. In any case, grab Socky from the shop before his exchange program ends! All the new things that Winter Fest is bringing are just tools for you to shape your own holiday adventure and we love to see how you use them, so please join our Discord and let us know! Share screenshots, find friends to throw snowballs at, show off your toy collectibles and much much more! Winter Adventure Awaits, Ylanders! Stay Classy (and warm) this winter season!

Ahoy Ylanders! In this dev diary, we will take a deeper dive into our programming and patch/update release workflows and we'll get a bit more technical, as our programming department shares the ins and outs of the job! Since we just released the Winter Fest patch and Update 2.2 is on its way, it is a good time to peek behind the scenes at what it even takes for a new release of Ylands to get to you, our dear player! Each new release contains a multitude of new features requiring new code and data. We toil on them daily, saving (or committing, as the proper lingo would go) our changes to a 'version control system' (VCS). A VCS helps us keep track of project history and lets us recover an old state on the off chance we ever mess up. Importantly, it also allows us to work on multiple versions of the project (called branches) at the same time, with work on one usually not disturbing the others. Daily changes are committed mostly to the trunk version (branch). On a busy day, there can be over a hundred changes made to the trunk. One part of a programmer's job, on which we spend a great deal of time, is dealing with bugs. A bug is a term used for any issue with the game, whether it comes from bad code or bad data. The development of a long-term project like Ylands is fundamentally about adding or improving new features as well and as fast as possible while minimizing the number of new bugs we accidentally add. The first line of defense against the insectoid menace is something called 'continuous integration' (CI). CI is a term for a system that automatically integrates and tests changes made to a project. It is important to say that 'integrates and tests' actually means specific things for specific projects. For Ylands it goes like this: several times a day, about every hour or so, a new build of the game is made with the new changes made since the last build (from only a couple to low tens of new changes per build). Before each build, we run set validation procedures that help us automatically check any rules that we can enforce without the need for human oversight. If validation passes, we build a new version of the game. A successful build continues to automated testing, where our in-house automated system simulates player input to run the game through a range of predefined gameplay scenarios to detect any regressions (a feature that worked but does not work anymore after a recent change). Recently, we also introduced multiplayer testing against dedicated servers. CI, in our case automated building and testing, usually uncovers the most obvious regressions in existing systems. For anything more complex, we rely on our QA team, who know the game inside out. They test new features, to ensure they are the best they can be and also continuously check that our meddling did not break any of the existing stuff. This process of daily development and CI continues merrily until the release of a new version draws near. We set a date of a 'datalock', usually about a month before release. A datalock comes when all new features should be good and done in the trunk branch and no new changes should really be required, besides the occasional bugfix. In theory at least. On the day of datalock, we copy the trunk version into a new 'release candidate version branch' (RC), so that it is not further disturbed by daily changes. We then proceed to test RC builds rigorously. The RC branch receives only as few changes as possible to avoid introducing any more last-minute issues. In some cases, the RC build is made public as the Experimental Steam beta branch about two weeks before a release. We closely monitor player feedback and react to any critical issues that might be found. What is super exciting, is that starting with the 2.2 Experimental, it should be even more useful for us, as it will let players continue with their existing progress from the live version of the game (but not carry over experimental progress to live). Finally, once the day of release is set in stone, we announce a maintenance window. On the day of the release, we flip the button, push the final build of the game live, and do a last round of checks to make sure that everything works. We celebrate, take a breather, and start the whole cycle anew. And there you have it, Ylanders - the release cycle summarized from the point of view of our programmers. Is there any topic from the development of Ylands that you would like to hear about? Let us know here or come chat with us on our Discord! Stay Classy, Ylanders!