Ylands News

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!



[h3]Limited Pet[/h3]

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.

[h3]Lovely Sale 'till 22nd of February[/h3]

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!

[h3]Discord Foxy Rewards[/h3]

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.



[h2]Gameplay adjustments[/h2]

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.

[h2]New tools for designers[/h2]

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.

[h2]Technical debt[/h2]

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.

[h2]Have fun with any new update[/h2]

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!

[h3]Hello Ylanders!
[/h3]
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 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.

[hr][/hr]

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.

[hr][/hr]

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.

[hr][/hr]

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!

We're thrilled to share some behind-the-scenes insights from our 3D artist department about a new animal coming to the Taiga region in Update 2.3. This is going to be a great one so you will have to wait a bit longer for it.

The Creative Journey: From Squirrels to Cows
Our journey began with an open slot in the Taiga region, prompting our designer to suggest adding a new animal. The first idea was a giant squirrel, but animation challenges led us to brainstorm further. We then played with the idea of something prehistoric and herbivorous, like a dinosaur. Imagine that in Ylands! However, we soon realized that the best idea was right in front of us, especially with the upcoming 2.2 update bringing encounters reminiscent of the bygone cowboy era. Our designer, Pypse (who often interacts with you on our Discord), came up with a brilliant idea: a cow.

Merging Utility with Aesthetics: The Taiga Cow
This cow isn't just an animal; it's a symbol of our commitment to blending utility with aesthetics. It animates well, is great for riding, can be milked, and fits perfectly with the Taiga's cowboy theme. Deciding on the type of cow was challenging, with numerous breeds to choose from. We settled on the unique Highland cattle, known for its shaggy coat.




Artistic Challenge: The Highland Cattle Model
Creating a model of the Highland cattle required special attention to its distinctive, shaggy fur. Thanks to our team of experienced artists, we found a fantastic direction for stylization, making our cow model a work of art. We're excited to show you the initial versions of the fur!



Bringing the Cow to Life: Sounds and Animations
In the Ylands team, we hope you'll also appreciate the sounds and animations of this noble Taiga creature, integral to our thoughtful stylization process. We're in the process of creating those, so stay tuned!

Thank You, Community
Your feedback is crucial as we continue to develop and refine our game. We're grateful for your participation in the Ylands community. Your adventures, challenges, and achievements inspire us every day and we are so excited to hear what you think about this furry cow addition to Ylands.



Happy exploring in Ylands, and we can't wait for you to meet our newest Taiga resident!

Stay Classy!

[h3]Ahoy Ylanders![/h3]

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!