The West Dev Blog

Calling all userscript developers: synchronous ajax (on the main thread) is bad, news at 11. We will soon trial blocking the use of jQuery’s async: false on the public beta and eventually live worlds. If you use this legacy feature, please rewrite your userscripts so all ajax calls are asynchronous.

Converting synchronous code

No ajax calls need to be synchronous. The easiest way to convert synchronous code to asynchronous code is to use ES2015’s promises and ES2017’s async functions, now supported by Chrome, Opera, Firefox 52, Safari 10.1 and soon Edge (currently insiders only). These two functions perform the same task:

var currentlyUpdatingLogs = false;
async function updateLogs() {
    if (currentlyUpdatingLogs)
        throw "Don't read the logs twice at the same time!";
    
    currentlyUpdatingLogs = true;
    var newLogs = [];
    for (var pageNum = 1; existUnreadLogs(newLogs); pageNum++) {
        Array.prototype.push.apply(newLogs, await getPageOfLogsAsync(pageNum));
    }
    var logs = getSeenLogs();
    Array.prototype.unshift.apply(logs, newLogs);
    storeSeenLogs(logs);
    currentlyUpdatingLogs = false;
}

function updateLogs() {
    var newLogs = [];
    for (var pageNum = 1; existUnreadLogs(newLogs); pageNum++) {
        Array.prototype.push.apply(newLogs, getPageOfLogsSync(pageNum));
    }
    var logs = getSeenLogs();
    Array.prototype.unshift.apply(logs, newLogs);
    storeSeenLogs(logs);
}

Can you spot the difference? Aside from a guard to avoid the function being called again mid-execution while idly waiting for a http request, there are only two:

• The function declaration has the keyword ‘async’ inserted before it.
• The call to get a page of logs has the keyword ‘await’ inserted before it.

There is generally very little refactoring required. You can see a demo of this function here. It’s also possible to emulate async functions by using generators, which are supported in more browsers. There is an example of this in the TW Best Friends userscript here.

Thanks in advance for doing your part to keep The West fast and responsive for our players 🙂

Facebook users, rejoice, for this is not a drill: in Version 2.47 we will introduce a number of usability improvements for tablet and smartphone users. Using the latest advances in web technology, we hope to make the game work smoothly with both mouse and touch input. The game will continue to work best on large screens (such as those of the Surface Pro and larger iPad Pro model) but even phone users will reap some benefits from our latest push.

The West ? Scrollbars

• Mobile browsers will now load the game at our minimum supported resolution of 1024px instead of the default 980px, avoiding a horizontal scrollbar at 100% zoom.
• Ever noticed a vertical scrollbar after opening your inventory? Poof – it’s gone too!

Window Management

• The quest tracker/notepad will now be minimised by default if your browser is 1024 scaled pixels wide or less. Additionally, the default position will be saved locally instead of syncing to the server, so the window won’t start off in the Never Never if you login using a computer with a narrower screen.
• Windows will be repositioned more rationally when the screen changes size, for example when an onscreen keyboard appears.
• In supporting browsers (see below), windows can be repositioned by dragging their title bar with one finger.

Safari is the New IE

Unfortunately, some of the best changes I’ve saved for last are reserved for users of Microsoft Edge, Chrome 55 for Desktop/Android, Opera 42 for Desktop/Android and eventually Firefox for Desktop/Android. The notable omission is Apple Safari and all derived iOS browsers. In 2007, with the release of the original iPhone, Apple heavily invested in the mobile web. Since then, a number of forces have caused Safari to drop from leader to laggard:

1. Apple has a vested interest in promoting its own App Store over the web, where it takes a 30% cut of all app revenue.
2. Safari no longer shares its core engine with Chrome and can’t ride on its coattails with joint development.
3. All iOS users are monopolised into using Safari’s core engine, Webkit, harming competition and innovation.

Pointer Events, the World Wide Web Consortium specification that drives our touch and stylus support, are not supported by Safari for now. We hope we can fill this gap in the future but please understand that, like with Internet Explorer, this is not always possible in a timely fashion.

Other Touch Support

• In the pre-battle screen, your fort starting position and target can be adjusted by dragging them with one finger.
• On devices with a screen width of at least 1366 scaled pixels, the map can be dragged with one finger.

That’s All, For Now…

We hope you enjoy testing these changes on the public beta! If the update is well received we would like to go further and implement additional tweaks for mobile browsers. The suggestions on our radar at the moment include allowing full screen mode as well as improvements to pinning the game to the home screen. Please let us know if you have any others!

Adventures have been on the public beta for almost two weeks now and we are very happy with how things are going. The servers are stable (and bored, which is good thing to be when you’re a server) and we notice – and get – hardly any bug reports. Players do keep reporting connection issues but those are harder to resolve unfortunately. But most importantly, the feedback that you, our players, give us is extremely positive and we’re very glad that you enjoy the adventures. To give you some numbers: more than 5 000 adventures were played in the first week of release. With each match taking about 15 minutes that’s a playtime of 1 250 hours – or 1 250 fort battles. In total, more than 40 000 (non-unique) players played the adventures, an average of eight players / adventure. Again, that would mean you could fill up more than 150 (big) fort battles – which is almost a year worth of big fort battles on most worlds.

Looking at those numbers, we concluded that the adventures beta-launch was very successful and that the work we put into the adventures, even though we’re knowingly opening another job-site, was The Right Thing to do.

Moar numbers!

You want more numbers? Sure! For example, 1.3 million abilities have been executed – Move and Attack obviously leading the ranking, followed by current meta ability selection of Quickshot, Snakeshot and Heal. Coming back to the Move ability, players walked more than 2 million fields. If we define one field to equal one meter, you guys walked about 2 131 km. That’s about the distance from our HQ in Hamburg to the most southern part of Italy and it would take you about 446 hours (according to Google Maps). Apart from that, 93 million damage has been dealt in total. As healing is not that effective, more than 28 000 players were knocked out – and, unfortunately, more than 1 200 players were shot in the back by their friends.

that’s the typical adventure activity – can you see when it’s night? 🙂

So, what’s next?

We’re now finalising The Last Things that need to be done before we can launch worldwide. We’re still working on improvements from user feedback, adding more gameplay information (like a scoreboard at the end of a game) and making the adventures in general easier to pick up and play. We’re adding more stuff to earn from playing adventures (the most obvious are achievements) and, post-launch, we’ll add a new map every now and then. We also know about the issues of afk-players and lobby-leavers and have several ideas and things in the making to reduce the pain those players cause, e.g. a ready-dialog before the lobby opens (the elite testers do know that one already) but haven’t decided on a solution yet. So there’s still a lot going on and a lot of things which will change – and hopefully create an even better experience. It’s honestly a very exciting time to play, keep playing or come back to The West.

A Happy Goodbye

With all that good news, there’s one sad piece of news as well – this is my last devblog post because I am leaving the team to start working on a new project. I have been working for The West almost three years now and I am glad that I was able to do so. The West changed a lot in those three years, for better or worse and I got to know quite a lot of players and people. It’s always nice to talk to actual people (and then being surprised that they are able to talk and criticise in a constructive way instead of flaming only ;)). However, I’m very happy that you, the players, have lifted the burden from our shoulders concerning the adventures as it was my last big project with a lot of uncertainty and high risks. I’m sad that I won’t be able to escort the adventures into the real life actively, but I’ll follow its progress for sure and hope that the rest of the world thinks the same as the players who have been able to test them already on beta.

So long, thanks for your time. My horse and I keep riding into the setting sun.

 

Most things start with a simple idea. Although I was not working for InnoGames at the time The West was created, I’m pretty sure there was an idea which resulted in the game you play today. The multiplayer instances, in short MPIs, started off with an idea as well but as the development progressed, that idea evolved into more than everybody would’ve thought of. When we first started working on the MPIs, it was designed as an improved fort battle, with similar graphics and gameplay but different maps and objectives. After a couple of technological decisions, the developers started working on an initial visual prototype, a proof-of-concept:

First MPI prototype

There was a small graphical update with an actual cowboy and some trees and stones:

Slightly improved graphics

After a couple of playtests, however, we thought that we could do better visually. Meetings were conducted and several options discussed. We looked at different games and their perspectives and, in the end, decided to try out an isometric one. We got back to work and started on another visual prototype. The initial result was the following:

First isometric prototype

From there on, we went with both versions, top down and isometric. The player was able to switch between them while playing the game as the top down view presented a better overview but the isometric view looked nicer. Although it was better, the visual quality of the images was lacking as they were mainly dummy images. After a couple of iterations, sweat and tears, we put together a simple new map with the latest version of our graphic assets:

High quality graphics in the isometric view

And it looks great. With the art style and high-quality images finished, there was one more big task to take on: the UI. Again, ideas had been gathered, nerf-guns had been used but we, as we always do, settled on a first version:

There’s also a new, second setting: desert. No grass here!

However, although we have played the MPIs quite a lot, we haven’t with such an UI. More playtests and your feedback will decide on the UI’s future. There was also another victim that couldn’t keep up with the pace of changes: the top-down view. As the isometric view received more and more visual information, the top-down did not. At one point, the isometric display had the better general overview and therefore we decided to cut the top-down, freeing up resources to focus on the remaining view.

Anyway, did you see the icons in the bottom bar? Those are your abilities! Not just the graphics, but also the gameplay evolved. Instead of a basic Attack and Move, one will have the possibility to choose between different abilities, such as Eagle Eye, which increases the chance of your next shot to hit critically, or a Quickshot, which shoots your target twice!

We are very happy with how the feature evolved, and we hope that you, as soon as you’ll have a chance to play the MPIs, will also like it. There surely are still a lot of question marks around your head but we’ll try to answer those in the upcoming weeks with further information and dev blog posts!

This blogpost was written – but not published – a month ago. I finally had some time to prepare the images which hopefully makes this post a little bit easier to understand.

The first prototype of MPIs had already featured a bear and a working pathfinding implementation. Unfortunately, it only worked because it was incomplete and the bear itself was smaller. Nowadays though, the bear (and the MPIs, more on that later) has received a facelift and increased in size – from a 2×2 object on the map to a big 2×3 object. Unfortunately, this change led to a problem that was known in advance but postponed for a prototype at a later date (read: now) to deal with. So, what’s the issue? Objects can turn; they also have a “front” (their face, basically). Now try to turn a square around its center – it remains in the same position, albeit the front is facing another direction. Now do it again and turn a big 2×3 object around – the position of the object changes:

The old bear didn’t turn. It would always look in one direction and would walk either forwards, sidewards or backwards but it would never turn around – and it didn’t need to, as the bear in the first prototype had a 360 degrees field of view, not 90 degrees. What I was working on over the last couple of days was to make the bear turn around; to create a more pleasant, more natural looking path.

This turned out to be not as straight forward as people might think. The old pathfinding algorithm was working but the grid system had several shortcomings. Pathfinding basically boils down to how you visit your current neighbours and rank them relative to your actual goal. Before you can rank each neighbour, you also have to make sure that it’s actually free. That was slow in the old system because it basically moved the complete entity (which is several cells big) and tried to place it on the new coordinate – if it succeeded, the cell than would be ranked, if not, the cell was not picked as a candidate. Let me tell you, that is a lot of overhead: the more cells an object covers, the longer this check would take. I was banging my head against the table looking for another option, and it came in form of a method called clearance-calculation.

According to the article, a cell’s clearance value defines which object of what size fits in that specific spot. If a cell has a clearance value of 8, every object with the size of 8×8 or less can be moved without issues to the cell in question. Instead of checking each of the object’s cells, one only needs the size of the object and the positon it wants to move to, check the clearance value of the cell and decide accordingly.

There’s a catch though: it only works for square objects, but our bear grew to 2×3 which ain’t one. Using a clearance value of 3 doesn’t work all the time, since there can be areas where a 3×3 object wouldn’t fit, but a 2×3 one would, so the information available with the given clearance value is not complete.

Based on the clearance value, I was thinking about ways to pre-calculate if an object fits a particular position and ended up at calculating a clearance value for each unique layout per map. The 2×3 layout is moved to any non-blocked cell to see if it fits. If yes, save a clearance value of 1 for this cell or 0 when it doesn’t, then continue with the next one. That’s still not enough information though as the 2×3 is, when turned around, a 3×2, so I had to do the above again for a 3×2 layout and merge those values together: if both 2×3 and 3×2 fit in one cell, it has a clearance value of 3, if only 2×3 fits, it’s 1 and if only the other one fits it has a level of 2 – so the bear could fit into that specific spot if it would turn around before.

The next issue on the list I had to fix was object blocking. Objects block each other, meaning they need to be taken into account when calculating a cell’s clearance values. As the current calcuation only works for static stuff like buildings (since they’re placed in advance and cannot move), the clearance map needed to be updated every time an object got placed on the map (e.g. player) and moved around to be useful for pathfinding. Luckily updating the clearance value is straight forward and only cells to top left need to be recalculated:

(12 = clearance value of 3 (1 + 2))One thing I wasn’t paying attention to up until now was the object’s positioning on the grid. Every object has a center of rotation which is also used as the coordinates to place the object on the grid – the other cells which an object covers are relative to the rotation center. The rotation center is, who would’ve guessed, in the center of an object – on the other hand, the clearance value does not specify that the rotation center, but the top-left cell that an object occupies. Easy solution: either move the calculation to the rotation center or let the layout reference the top-left corner in each direction. I chose the latter one, problem solved.

With all these pre-calculated and dynamically updated clearance values I finally was able to go back to the actual problem: letting the bear turn around. As I stated earlier, it boils down to the neighbour-selection and ranking for each possible neighbour. Instead of only considering the neighbours of the direction the bear is facing, I also visited the neighbours of the other directions, adding them to the list of possible candidates. Unfortunately, that wasn’t enough as the rotation was calculated as an additional step which reduced the likelyhood of being chosen. The bear kept going sideways. I was able to remove the additional step due to the fact that I now visit the other direction’s neighbour instead of the direction itself. Theoretically this should increase the amount of checks but it practically decreases them as a valid path is found faster with less traversing. I also heavily increased the likelyhood of choosing one of those direction neighbours as the next waypoint if the direction the bear has to walk (e.g. left) and the directional neighbour would face to same direction (e.g. both would go left), so the bear turns around and goes left instead of sidewards.

Colorcode – green: walking north, yellow: walking east, blue: walking south, red: walking west. Also for the following images. The yellow area at the start is just the starting point though.
Almost the way I’d like it to be, but do you catch one last issue? The bear has a tendency to go upwards and I was scratching my head why it would like to do that. It came down to a default value: if the bear moves diagonally, the directional value was set to 1 (= facing upwards) as a diagonal direction is not supported. This means every time it moves diagonally, it sometimes would highly prefer to face to the north and go down from there.

How to resolve that issue? If I wasn’t able to calculate a natural looking direction for the next waypoint, I just used the direction the bear should face relative to the actual target. If a bear’s target was south from its current standpoint, the default direction would be 3 (= south) – this little tweak reduced the occurance of weird behaviour to a minimum!

Are we done yet? No, the algorithm still needs some tweaking as there are still some weird issues where the bear moves in the proper direction but then decided to do a quickturn before going back on the orignal, good-looking path.

Also, in the current version, there is an issue with AI finding a proper goal to walk towards – where the pathfinding actually can find a way – to. However in the last month we have been focusing on the frontend instead which you can see every now and then when our Community Manager Joony leaks a screenshot on facebook, the MPIs are covered in the latest Innogames TV.

It has been a little bit quiet around here but that silence should be broken today! As we have been secretly working on the Multiplayers Instance whenever we had spare time, the hard labour finally paid off and first results are on their way. I won’t show you anything fancy today, I’m sorry, but maybe it’s interesting nonetheless. Today I’ll talk about the stuff you normally don’t see but is crucial to everyone – the server architecture.

Independence Day

What we wanted to achieve is independence. Independence from location, independence from servers, independence from worlds. Well, the game has to run *somewhere* on *some server*, but we wanted to lift the restriction that games from world 1 can only run on the servers of world 1. It’s a common problem that one server has spare resources while others are busy, slowing everything down on their world. Adding the in-development feature MPIs to those might slow things down even more during peak hours, having a negative impact on the normal gameflow. As a result, we had been thinking about splitting the MPI systems into three parts: a world server, manager server and battle server – each with different tasks.

World server

This one basically is the player’s gate to the MPI system in general. It serves you everything you need: the client to connect to other parts of the system, a list of available games, allows you to create games and forwards you to the battle server where the actual game will take place.

Battle server

The battle server is the heart of the MPI in terms of game logic. It handles all the instance specifc data, lets you attack other players or move to another cell on the grid. Everything that is related to the game itself is communicated between the battle server and you, the player directly. As previously said, you will be forwarded to a dedicated server as soon as you create and start a game.

Manager server

All the data needs to be kept somewhere, and that is the manager server’s responsibility. It knows who is playing from where, in what game and on which battle server, who is currently queued and searching for a game and who just lost an instance.

What I briefly described in words can also be nicely illustrated with the help of a picture:

A Workflow Example

A client (player) connects to its world server, tells the world server that it want to create a new instance which the world server then tells the manager server, which then will create a gamelobby for the instance. From that point on, other clients can see the newly created game and join in. If the number of players are sufficient, the host (the client who created the game) can start the game. Again, the world server forwards the information to the manager server. Now the manager has to decide on a free battle server to host the game on. After it found one with a low load, it tells the chosen battle server to create the game and forward all information needed to connect to the battle server back to the world server who then pushes the answer back to its clients. On recieving the information, the clients finally connect to the battle server and the game can start. As soon as it finishes, the battle server will inform the manager that it’s over along with the actual game result and if any rewards are set for the given result, the manager will push the data back to the world server who will grant the players their deserved rewards. Rinse and repeat.

The Idea Behind

The interesting part of this architecture is: while it’s technically possible to run everything on one actual hardware-server (and that’s how we start rolling out the MPIs), it’s designed to be split among different ones. While each world will have its own world server, there is no need to have a manager server and battle server for each world. The world servers can connect to any configured manager which can forward games to any battle server the manager server knows about. In the end, it’s specifically designed to let each world server from the same market connect to one, and only one for the complete market, manager server. And if it’s only one manager server, there is one big queue, one big list of available games. Every player would be thrown into the same pot and players from different worlds could play together … or against – world vs. world, anyone?

I’m sorry – you’re thinking too small.

Over the last few weeks, more and more information has been released regarding a feature called multiplayer instances. Since those are quite long and boring words, we internally go with MPIs. Yeah, that’s not really creative, but for now, function over form has to suffice.

Today I’ll add to the information already available. As mentioned, the MPIs are derived from the current fort battle system and are, in the first iteration, PvE content. Unlike fort battles, you can undertake a MPI whenever you want (as long as your character is not busy doing something else) with either your friends or random players. Right now, we’re working on the first playable prototype which will have one main character besides the players: The Bear(tm). Short and sweet, you and a handful of other players are sleeping in a forest when suddenly a bear shows up! As you have been a bad boy scout (otherwise you’d have realized that there’s a cave just next to your resting place) you have to protect yourself and fight the bear. Luckily, the bear is not the smartest bear you could’ve faced and only attacks the closest player – but it makes up for its lack of cleverness with some very strong attacks and boy, it’s fast, too!

The Art of Drawing

Although I completely made this story up, the scenario in fact is not and covers a couple of features (AI, anyone?), none of which I will talk about today though. A feature which is not mentioned in the story but I do want to talk about is the bear’s and the players’ eyes. Sure you have beautiful ones, but the most important job of your eyes is to actually see what is going on. Fort battles do already have lines of sight, but these are actually pre-compiled for every map as the sight-blocking objects are known in advance and other players don’t block each other’s sight.

This is different for the upcoming MPIs. Every actual object will block your view. There’s a tree? You won’t know what’s behind it. There’s a big fat bear standing on his hind legs in front of you? You should get comfortable with his furry belly (or just get crushed) because you’ll see nothing else. Besides some static objects (e.g. walls, trees), there’s a lot of movement going on which means that what you see changes almost every turn – everything has to be calculated in real time.

So what we need is an algorithm that calculates what the players see and don’t see, and that’s what I’ve been working on for the last couple of days. It first started with an art class as we had drawn nice lines and circles to get used to the actual problem. Here’s what it looks like when non-artistic software developers go on a drawing-spree:

Nice, isn’t it? I’m thinking of starting a more artsy career – or at least I am now aware that I’ll always have an alternative available. What’s actually more interesting is the meaning of all those lines and boxes. Since I’m a good guy and not your art teacher, I’ll tell you directly. You might not be able to see it, but there are several ideas hidden within the picture. At first we dug up our geometric skills and drew some straight lines at a couple of angles to each other (you’ll have different view radii, so far: 90, 180 and 360 degrees). Our first approach was to project the lines from a specific point (the player’s eyes) in the direction they are facing. This is also known as ray tracing. If a line (or ray) hits a blocking object, the stuff behind that object is hidden. That is one approach, but from the beginning we have also been working on another one which you can see in the upper right corner.

Instead of sending out rays, another way is to iterate over the player’s field of view and, if you hit a blocking object, calculate the shadow of this object. Finally, add the resulting squares to a list that contains all of the hidden squares. When displaying the grid, just check if a square is in the hidden list or not and show its content accordingly. The algorithm to calculate an object’s shadow is the interesting part. It was quite easy to start with, and still somewhat is, but there have been quite a number of edge cases and there are still some bugs left.

After the implementation, we started on a ray tracing algorithm. Since a ray doesn’t fit one-to-one on a square grid, we have to convert that information using the Bresenham Algorithm to match the straight ray to the underlying squares. The code is easier, shorter and more efficient but yields different results. How can we check if the results are appropriate though? Quite early on I was not keen on writing tests for such a visual feature, so I decided on writing a simple, quick and dirty standalone visualizer to test it. Now to the fun part: it’s available online! Before you head over there, please keep in mind that it’s not at all optimized but is just a proof of concept (as the code you can look at is seriously bad). It’s also very slow when not opened with a decent computer and a decent browser (Firefox does not count as decent here, unfortunately; Chrome should run well enough).

Space Invaders Incoming!

A quick explanation of what is shown and what you can do:

When hovering over the grid, there’s a red square beneath your mouse cursor. This is you, the player, whose position is used to calculate what you can see from that point and what you cannot see. Hidden stuff is either dark green or grey (have a look at the legend to the right), light green squares are objects which will block the red square’s view, thus having a shadow. The rest, the white squares, are things the player can see. You can add / remove blocking objects by clicking on a grid square.

To the right of the grid, there are a couple of settings you can change: a different direction (it defaults to a 360 degrees view) and a different view angle, which itself results in a different raw field of view. You can also customize how far the player can see. Next on the list, Show Shadows, only works when the other one, Use Ray tracing, is not active and shows the actual calculated shadows. If you tick “Use Raytracing”, the ray tracing algorithm described above is used. If it’s off, the algorithm we started out with comes into play.

So, here you go: http://map.the-west.de/view.html

I found myself building quite a number of labyrinth maps, wandering through them.
What did you build?

As you all might know there are some problems in the actual state of the fort battles. We think the addition of the resistance and damage formula were a good step into the right direction, but there are still lots of balance issues left and we are aware of it. But as usual the main problem is “where should we start to find a better balance” there are tons of advices from players through all the market forums and of course a lot on the public beta.

Maybe some of you know already that i made a first step to find a better balance on public beta weeks ago my approach was to switch the stamina skill with fine motor skills. I thought and still think it is a step in the right direction, because actually attackers have much more advantages with red skills then defenders have. The outcome is just simple if defender and attackers are equal at health points its 95% clear that the attacker will win, so one thing is clear we need to change something!

After lot of research, mining data and internal discussion we agreed on a more general approach. As first step, which is not really related to the actual balance situation, we want to bring more players to the fort battles with less restriction and easy attending. I will show up how we want to approach that

–       You will no longer need to belong to a town to attend on fort battles

–       We want to add an attending button in the fort battle overview

–       A player does not be present at a fort to register, just during the battle

–       Fort battles of my alliance will be more highlighted in fort overview

–       Screen to choose your side will be reworked and simplified

–       The tactic screen will be simplified and will give you an overview what is required todo

–       You will get a kind of buff icon if you are attending to a battle which also shows the timer when the battle starts and reminds you to travel

–       There will be chat announcements if battles starts within an hour and not full yet

–       You will have the option to get a reminder mail for fort battles

 

With these changes we hope to get more players back to the fort battles.

As our second step we definitely want to do something about the balance lot of player are very unhappy with the actual situation. Health points and red skills are more or less the only viable option and for the evaluating health points are the most important value.

So we finally want to try to change things, but it is very complicated to start and we are aware that we will need to test a lot and a long time and we will need to change many things for example all the fort battle items and sets.

Nevertheless I finally created a prototype of 2 absolute new formulas, which I want to test with you on public beta. The goal or better my intend why I created two new formulas instead of change the old one is I think that the old formula have to much problems in itself and it is not transparent enough for player. Another problem, which many players also mention, is that the old formula has such a very high luck factor in it.

Finally I will present my first version of the formulas to you right now, please keep in mind it is just an idea for now and most of the factors are more or less a blind guess. This is the reason why I want to test it a lot and then adjust it with the feedback the community gives, because I think I am not able to create the perfect formula it should be developed hand in hand with the community / public beta players.

First we have a new hit chance formula, which looks like that:

50 + Leadership^0.3 + Aim^0.4 + Hide^0.5 + ownSectorBonus * 0,5 (max 5%) + offenseBonus * 0,5  (max 5%) – distance^0.6 – targetSectorBonus * 0,5 (max 10%)  // (max 90% hit chance)

 

With this formula is a max value of 90% possible, this means even with more skill points on aim or leadership I cannot get over 90%, but I should think about if I go a little over the top because the distance will be a minus value for myself and the enemy sector bonus will also be a minus value of max -10% (this equals for now a fully build town on biggest fort), with this knowledge it might make sense to skill a little bit over the top to compensate those factors. Just as remark a non – fort battle skilled player will have at least 50% hit – distance – targetSectorBonus.

Second we have a new dodge formula, which looks like that:

5 + Leadership^0.3 + Dodge^0.4 + Endurance^0.5 + defenseBonus * 0,5 (max 5%) // (max 40% dodge)

 

We will also do some smaller adjustments to the resistance and damage formula:

Damage: Weapondmg + Pitfall^0.7

Resistance: resistance(items) + Trade^0.7

 

If Player A hits Player B the Player B has the possibility to dodge with this formula with a max value of 40% I cannot get more that these 40% and I have at least 5%.

So the sequence changes a bit:

–       Player A attacks Player B

–       Player A needs to calc hit chance

–       If he hits Player B calc dodge chance

–       If Player B fails to dodge the damage and resistance will be calculated still in the same way

 

What is the goal of that changes and the 2 formulas?

Quite a lot people will now say that it becomes even more worse, because you will have 2 chances to miss/dodge and this is more or less right. Since we have a calculation for hit and one for dodge there will be another new luck factor, but both new formulas are more stable in their luck behavior and we have some kind of minimal values, which every player reaches. In the actual system it is possible to counter a set of skill directly but it is now that viable, so many player invest most of the points in health points.

So back to the goal of the 2 new formula first we want to reduce the luck factor this is why we added a minimal value and added some caps like (max 10% sector bonus) this also sets the focus back to the skill points. Another goal we want to achieve: make other skills more viable beside health points. We want to see other directions of skill sets such as tanks with much life and a high dodge value or some kind of a sniper with an incredible high amount of hit but low life and dodge, who is protected by the team tanks and stuff like that J

And last but now least we want a system which is more transparent to the player this means that in the evaluating overview the leader will see any hit/dodge/damage/resistance and life values and can do a better decision making. You will also be able to see those stats in the battle in future.

If you’re a beta player, you’re already enjoying the recently added Quest-Tracker in it’s purest and most prototypal form we could offer you. Although working hard on getting it done for the just released 2.03, we had to postpone it to 2.04. Despite the fact that it basically works sufficiently, we felt it still needed a little bit more love regarding its feature-set and looks. Therefore we sat down, read your first impressions and collected your features-requests. As always, we couldn’t add everything but I hope we found a good middle ground.

How do I activate the Quest-Tracker?

It’s activated by default and every quest you accept will be automatically added to the Quest-Tracker.

If you want to add already accepted quests, just go to your beloved quest book and tick the new shiny check box.

How do I deactivate the Quest-Tracker?

If you manage to keep track of all the requirements by yourself and remember everything, you can deactivate the Quest-Tracker completely via

Settings -> Interface -> Quest-Tracker

You could also remove all the wachted quests but this would only last until you accept a new one of course.

How do I remove a quest from the Quest-Tracker?

You can either deselect the check box in the quest book or hover over the quest’s title in the Quest-Tracker. You should see a little ‘x’ appearing which will happily remove the quest from the tracker.

How many quests can I track / will it overlay with the TaskQueue?

As many as you can accept which is currently 15 quests. However, depending on your screen size, you will get a scroll bar sooner or later. This is the only proper solution we came up with to avoid issues with other elements of the user interface.

The dynamic size calculation of the Quest-Tracker might need some adjustments, so let us know how you feel about it. As a last resort, you can always drag the window to another place (although the position is not saved).

Can I collapse the quests?

Yes, you can also do that in the current version but now it also saves the status of the single quests but it takes about five seconds till the status is transferred to the back-end.

So don’t instantly refresh your browser after (un)collapsing to prove me wrong, please :-).

Does it update itself?

Yes, it does update itself most of the time. However, since we have a lot of quest requirements, the Quest-Tracker doesn’t react to every requirement out there. If you encounter a requirement which doesn’t trigger an update, tell us. We’ll have a look and might implement it afterwards.

Some requirements are not implementable though. Also, the update might take up to five seconds. If it hasn’t updated itself, you can always reload the Quest-Tracker manually to get the latest status.

Anything else worth mentioning?

Well, the little quest book next to the label “Quest-Tracker” will open the quest book. A click on the quest’s title will open the quest (unfortunately, this doesn’t work for quests whose quest-giver are located on the map (like Waupee)).

Oh, and you can minimize the Quest-Tracker (I just added this feature while I was writing this blog post … I’m too lazy to take new pictures though, bear with me!).

That’s it for today. I don’t know when we gonna update the beta servers to 2.04 yet.

Recently there is a small addition on our TheWestAPI which can be used by scripters.
The belonging The West API page on this blog will be updated soon.

Our TheWestApi.register method now returns a GameScript object.

It contains most of the functionality as the TheWestApi.
Due to backward-compatibility the usual methods are still there, but are marked as deprecated and will be removed in the future versions.

When at least one script is registered to our Api a new interface element shows up.

It opens a new window where all registered scripts are located.
The content of the tab is left to the scripter itself.

It is quite simple to use. Just take a look at this javascript code-snippet:

var MyScript = TheWestApi.register(‘myscript’, ‘My Script’, ‘2.03’, ‘2.03’, ‘Myname’, ‘http://www.example.com/’);

MyScript.setGui(“<b>THIS</b> is my personal tab for my script.”);

 

Let us know when you want to have additional features implemented to the GameScript.