Hello everyone,

Chieftain wrote an interesting post about gun characteristics. You might wanna check it out!

- ISU-130 (ISU with 130mm gun) won’t be implemented for now
- T-35 with additional spaced armor and 122/130/152/180mm guns is complete garbage according to SerB
- T-100 might appear in the game (but not with KV-2 turret)
- Soviet Panzer IV with 57mm ZIS gun has zero chance of appearing in game, no info on other two Soviet rearm projects (Panther with 85mm gun, Tiger with 100mm D-10T, yes – that plan existed)
- project variant of ISU-122 with 150mm frontal armor won’t appear as an optional hull
- shell velocity does not combine with the tank forward speed in the game (SS: as in, if the tank moves forward at 1 m/s and the shell flies at 300 m/s, this shell won’t fly at 301 m/s)
- the fact that T69 reloads its autoloader for 26s, T54E1 for 33s and T57 for 25s is due to the fact the T57 autoloading mechanism was more advanced

- S-Tank will not be implemented into WoT, because the developers would have to implement a mechanism especially for it. But if it was ever implemented, it would be a TD.
- WG is not using “agile development process” method (SS: sorry, no idea what that is, another option is “waterfall”), because for WG scale this method is not viable, they use classic methods
- WoWp loading window will possibly be added to WoT too
- Clanwars won’t be changed to 7/42 battle mode. It’s possible Clanwars will have an amount of players increased – for commanders, there will be a special command interface (a map) – “when it’s done it’s done”
- Japanese tanks that were produced but never fought might appear in historical battles, but not straight away
- Japanese tanks won’t have a special spall liner as their “national” equipment (SS: in real life, the Japanese tanks were padded inside with azbestos mesh to protect the crew from shrapnels and splinters)
- it’s completely possible some of the regular Japanese tanks will have improved Hara-type suspension
- so far there is not enough info on Japanese top TD’s

60 thoughts on “10.11.2013

    • Possibly next year, I believe modelling work hasn’t begun yet. I recall some time ago in the Q&A SS wrote that WG has found tier 3 and 4 heavy tanks for the line, but they are missing tier 5 and 6 vehicles for the branch.

      • Good guess is 2015. Japanese TD and heavies are not in 2014 plan according to past FTR posts.

        • actually, we dont know.
          everything can change.
          i heard that serb said many times ”no leo 1, it will never come”
          now it is in game lol
          it is sayed that next year dont bring many tanks.
          who knows.
          anything will changed.
          btw, im not expecting atleast TDs for 2014. heavies have possibility.
          i heard though that chinese tds and arty will NOT come in 2014

  1. Waterfall project mng is very old style, we use it in the Bank it’s for very big IT organizations and used since the 80ths. this does not fit gaming developers.

    • you do know there are other software development paradigms, besides agile and waterfall approach – imho, wot developers could most likely be using evolutionary or iterative approcah

      • Agile does not like deadlines (i.e. patch launches), as a lot of stuff can come up during the sprints that hasn’t been planned, and can’t redo that much in a game that is already released. Waterfall is more conservative and IMO safer.

        IMO agile development is great during the first stages of game development, before there are set beta and alpha deadlines. After that it is a real struggle to be really agile.

        • Actually agile methods like SCRUM or XP handle change and deadlines way better than waterfall, especially when the latter is done strictly. That’s because a typical agile project is hitting a deadline every couple of weeks. (Usually, if the project needs it a sprint can last anything from a few hours to months or even more.) Strict waterfall on the other hand is fixed on features once the specification phase is passed, and has no process of handling trouble that arises during development. Iterative waterfall is better on that respect, but it is halfway to agile anyway and going the full distance gives you a playable game much sooner and keeps it playable all the way to release.

          After release, (be it alpha, beta or gold) when the bugs are out there eating your income and reputation, it’s even more struggle to be waterfall. You need the fixes ASAP and you need them without causing new big bugs. Agile can do that in a coordinated, predictable manner, ad hoc can do that if all the developers get intimate with each other (in a professional sense ;) ) and waterfall is still trying to rewrite the requirements document. At my workplace we use Kanban for projects in the maintenance phase (released, that is) and SCRUM for the unreleased ones starting from gathering the first requirements.

          • Yep, kanban might be better. I think SerB said they don’t do agile, but not that they do waterfall.

            I might be biased because the only agile thing I do is scrum. For WoT I’d imagine that you need something more defined than user stories and be more strict in planning, also strict and iron fisted bosses can be a bad thing for agile, and I wouldn’t be suprised if WG.net had such ones.

            • @OOPMan, that’s why one (should) want to split one’s project into modules that individually can be managed by a reasonably sized team.

              @GTD, yes, user stories might be too unspecific for game development, but there’s no law against more exact specifications. In fact if I were to start a SCRUM game project, I’d do two or three sprints on just the initial design before letting any code to be written. The programmers and game designers need to reach an agreement on what the game needs to be like and what is technically possible. At least an agreement to a degree.

              Strict and iron fisted bosses can be bad for agile, right, but they can be bad for waterfall or anything actually if they don’t really understand the process or the product. But to have a strict and iron fisted SCRUM Master …

        • That is only Agile when done badly.

          Agile can work with deadlines, and there is no reason why unplanned things should happen during a sprint. These days ‘alpha’ and ‘beta’ are simply marketing terms.

      • WG uses ‘depends on how much vodka was drunk last night’ approach. Other game companies don’t use this, but WG knows best.

      • “Evolutionary” and “iterative” are words that are often used to describe agile methods. On the other hand waterfall model could be described as a single all-encompassing agile sprint.

        For me as a professional software developer WG saying their project is too big for agile methods is like saying their project lacks proper compartmentalization. By that I mean it’s not properly divided into smaller modules that handle a single job. For WoT, these could be e.g. movement physics simulation, hit and penetration simulation, user interface, input and control, resource loading, graphics and rendering and so on. You want to keep a single module small enough for an agile team to work with and interdependencies between the modules as few as possible. Those interdependencies that there must be must be constrained into agreed upon interfaces so when they must be changed, every other point where change is necessary is easy to track out.

        The interdependency thing is necessary with waterfall model too, otherwise the project becomes a pile of spaghetti where you cannot make even a small change without causing bugs in several other places. Even seemingly completely unrelated ones. That said, management must also understand what agile methods are and especially what they are not. Otherwise you end up with the same mess actually as the developers try to hit a constantly shifting target without having the time they need to do it properly or even finish features that suddenly became unwanted.

        Oh, yes, I’ve been there and done that. There really isn’t any product that agile methods wouldn’t work for, provided everyone and management included understands how to do them and is willing to follow the rules. Same applies to waterfall and other “traditional” methods too, issue just is that the business management courses still tend to teach those rather than methods that handle change in requirements during development better. This means management often doesn’t understand agile and isn’t willing to learn.

        • I wonder why nobody wants to do something better than WG except Gaijin. It’s very tiring to read such bullshit written by person claiming to be one of the great developers of online calculators.

  2. Couldn’t the same mechanism for the S-Tank also be used for the tier X japanese medium tank and the E10? (Not sure if it was the tier X but I remember reading here that one of the japanese meds could play ticks with its suspension to improve his depression)

  3. about the T-100 with KV-2 turrey, isn’t that the T-100Z?

    and the Objekt 103, will be implemented?

  4. - WG is not using “agile development process” method (SS: sorry, no idea what that is, another option is “waterfall”), because for WG scale this method is not viable, they use classic methods

    This looks like a question to WG about their software development and engineering procedures and process. Agile and Waterfall are too different approaches to organize your efforts. Agile, at least in my mind, is oriented around short sprints of only a few weeks where you strive for small incremental goals and because they are not too far ahead of where you currently are, the team is more likely to deliver successfully. Waterfall is a method where you achieve one thing and move on the next – like water dropping in steps down a series of water falls (or fish ladders). There are a whole slew of approaches to software development and engineering out there right now but these two are certainly popular.

    What WG replied with is: their team is now very large and possibly spread out – but they are all working on what rolls up to a central project so they are not using newer management structures. In my opinion, this makes sense, as I think it is still relatively un-common for very large teams to function with the newer structures. Therefore, they are trying to put their innovation into the game itself instead of their human resource structures. To give anyone who does not work in information technology an idea of I mean here – it is very common in an Agile methodology for the ENTIRE team show up for a stand up meeting (meaning everyone literally is standing) for 15 minutes at the beginning of the day and they discuss and raise issues for the coming day’s work. The usefulness of that type of effort drops as the physical team size increases.

    If you work in information technology, this was an interesting question and response. People can wax poetic on this subject (I cannot – lol) and get very passionate so while I hope to have given I high level glimpse of a complicated subject, I also hope that I haven’t distorted things so much that I start a flame war here! This is interesting to programmers and not so much everyone else

    cheers – Tugboat1964 (north america)
    forgive any weird grammar due to lack of my morning coffee infusion!

    • It’s also rather difficult to do meaningfull Q&A checks if things float around on a dayly basis. It’s far more practical to do large changes where you know what changes other departments are doing at the same time. And then have time to check that nothing went wrong.

      • In reality waterfall often collapses into things floating around on a daily basis. Agile works by acknowledging that things tend to float around, and restricting the floating to specific points where a sprint closes and the next one opens. These points need to be close enough that the requirement setting party can live with waiting at most twice as much for the change. Twice at most, because if it just missed the current sprint, it can be finished earliest at the closing of the next sprint. If there’s no such procedural restrictions in place, managers like to change priorities when they feel like it which leads to the issues.

        Q&A checks are also a lot more effective, and the found issues cost less to fix when they are done against a smaller set of changes rather than larger ones. Frequent releases help there as well as keep the QA people busy, whereas rarer, bigger releases means the QA people are idle for a lot of time. That means they are costing the company money for no gain, or they become snatched to do other work which then tends to keep them unavailable for QA stuff when the big release finally comes.

        BTW. Nothing says that every agile spring needs to end in a public release. Quite the contrary, usually (in a business app setting) most sprints result in a QA only release, the best of those propagate to a Staging release (for end-user testing), and only the best of those propagate to production. Check the version number on the login screen of the WoT client: The current version number in full is v.0.8.9 #546. We certainly haven’t seen 545 releases between 0.8.8 and current version. ;-)

  5. Agile development has some negative associations that come along with it. A lot of us in the programming field take agile development to mean the project goals are constantly being changed and tampered with due to management types not understanding the actual concept behind the term.

    • I gather it’s something of an universal consensus regardless of the field that the management tends to constantly meddle with things it shouldn’t to the detriment of just about everyone and everything involved.
      From what I’ve briefly witnessed of it this view is shared by the lower management charged with actually adminstering shit in practice…

  6. “(SS: in real life, the Japanese tanks were padded inside with azbestos mesh to protect the crew from shrapnels and splinters)”

    …that sound smore like a “tropicalisation” heat-protection measure though; at least the Brits made versions of their tanks with asbestos panels under the top surfaces for hot-climate duty.
    And having been to Osaka in summer I have no problems seeing why they might have considered such necessary. >.<;

    • Hmm indeed, asbestos was known far more for its insulative properties rather than its sturdiness…

      Still, woven into a mesh, I’d imagine it would at least slow spalling down, particularly flakes that spread their force over an area of the mesh.

      • Asbestos saw experimental testing as a possible body armour in WW1 so it does have protective qualities when compressed and presumably set within a resin.
        I presume the asbestos liner though to be exactly as Kellomies said as tropicalisation rather than protection.

  7. - shell velocity does not combine with the tank forward speed in the game (SS: as in, if the tank moves forward at 1 m/s and the shell flies at 300 m/s, this shell won’t fly at 301 m/s)
    This was crucial info….after this i will stop shooting on the move all the time hoping for a higher chance of pen….

    - Japanese tanks won’t have a special spall liner as their “national” equipment (SS: in real life, the Japanese tanks were padded inside with azbestos mesh to protect the crew from shrapnels and splinters)
    If this is true however even though azbestos mesh doesn’t sound like something that would “protect” crew rather the opposite then just add like 5-10% less chance of crew dying from HE for Japs….

  8. Chieftain is a retard, and needs to be fired.

    Him an d SerB have destroyed WOT.. But thankfully NEITHER are involved with World of WArplanes.

    Nobody wants their tainted faggotry in that game. Thank god.. SerB is too stupid to fly planes I hear.

    • Lovin’ the way you methodically build up your case and enumerate the causes of your grief, bro.

      In other words do everyone a favor and uninstall yourself. :)

    • The Chieftain is a pretty cool guy, probably the coolest guy WoT has.

      But hey, I understand; he has an awesome steady job, is extremely knowledgeable about tanks, writes neat articles, makes neat videos. I can see why you would be so jealous of him as to come into the comments section and act like a butthurt little kid.

  9. - WG is not using “agile development process” method (SS: sorry, no idea what that is, another option is “waterfall”), because for WG scale this method is not viable, they use classic methods

    Really? Agile has blown up in the past few years in game dev circles.

  10. Asbestos spall liner: Confines fire damage to the tank interior, protecting the escorting infantry from burns.

  11. Agile project managing is very widely used in computer game development. It’s essentially a method to stay flexible when the design changes or user feedback has to be taken into account for the design.

    Waterfall Requirements, Design, Development, Testing, Deployment to consumer

    Agile: Design, Test, Integration, Test, Development, Test, repeat.

    In short the developers using the Agile method are able to respond to changes faster but use more time iterating on the design.

  12. Regarding news of Sweden’s S-tank omission from the World of Tanks future EU tree? I that give a thumbs down. The S-tank was one of the only vehicles from the EU tree, that I was highly interested in playing. That the many German, Soviet, America fans get their toys to play with, meanwhile the Swedish S-tank fans get totally shafted is troubling.

    It’s all about Wargaming bottom line now isn’t it? If historical reality was a priority to Wargaming, the S-tank would a part of the EU/Sweden tank tree from the start.

    Considering Wargaming already has spoken about design and testing new ‘larger maps’…. What’s the deal with a claim a new mechanism would have to be built? So what? Isn’t that what computer software designers & gaming directors do for a living: Designing, Testing, Creating/Building, Enabling? New maps mean starting over already. Newly redesigned tank models mean every tank will be redone.

    So what’s the hold back on the Swedish S-tank?
    Does Serb’s Soviet era fondness & a love of money biased his supposed love for a historical reality of tanking, and what can be considered of an apex of Sweden tank design?

    Wonder if that other Russian gaming company can do what Wargaming isn’t interested in doing?


    - S-Tank will not be implemented into WoT, because the developers would have to implement a mechanism especially for it. But if it was ever implemented, it would be a TD.

  13. “WG is not using “agile development process” method (SS: sorry, no idea what that is, another option is “waterfall”), because for WG scale this method is not viable, they use classic methods”

    That is comedy gold. Agile works no matter what size your project is. They probably don’t use it because they don’t understand it, when in fact its the perfect system for a games developer with multiple teams. I know, because I’ve used it when working on AAA MMOs.

  14. Pingback: 10.11.2013 | WoTRomania