Free Play Account
  • Content count

  • Joined

  • Last visited

Posts posted by hans1939

  1. On 4/16/2019 at 5:55 PM, parasit said:

    Not sure if a mobile AF is a glorified FMS. But, you're right is sounds like it. But it takes planes to fly 10 minutes to a battle, do we really want them closer and all the camping that goes with it?

    I know I heard about the rats having no programmer, but I can't remember the source or do I like to search for it. Sorry.

    Wait, so the Rats don't have a web developer (PHP, JavaScript, MySQL, HTML, CSS) or an applications programmer (C++ most likely, possibly C as well)?  'Cause I'm pretty sure a bunch of the changes made recently would require applications programming...

  2. 57 minutes ago, Kilemall said:

    <Shakes head>  ya assumptions.  This is a proprietary game with an engine that has objects like FBs hardcoded in.  While I'm certain there are common process calls in there along with some table or database that keeps track of FB state, I would not assume anything with how the objects in the engine interact and the difficulty of making logic changes.


    Two parter to this.

    Different programmers for different kinds of programming, so talking like they have a pool of programmers that are being assigned to this or that priority is not their reality.  There are priorities within their silos of specialty, and some are dependent on others so a total prioritization is needed for those, but generally speaking voice guys can proceed and not interrupt equipment modeling or financial backend work.

    Where it would be a bottleneck is client guys for at least the install/default UI access, and a whole lot more work for integrated voice comms in terms of in the game audio itself.  That would be desirable but a real big project and ya a big win if we get it but not something ahead of 64-bit.  When I'm talking voice comms I'm talking a default install of Discord or whatever that sets everything up for them and gets them talking in the first hour.

    There is utterly no question that our retention would skyrocket as they have somebody to talk to rather then getting lost in the text channels or not even trying.

    Now then, no question that the UI needs fixing. 

    One of the great regrets I have is that the DFW area had Redmond Simonsen and I didn't believe it, he was the literal God of Wargame UI and I didn't believe he actually lived here so I didn't get him introduced to the game.  Not more then 7 miles away and he would have done volunteer work for something this ambitious.

    Anyway, the two are not mutually incompatible to work on, and is vital for new player retention.  Even a jump up to 5% noobs subscribe rate would be huge.



    @XOOM Can you let us know if FB generation is either (1) hard-coded (i.e., unique) for each FB or (2) done through a series of programming loops?

    Kilemill, just so everyone is on the same page, creating the algorithms necessary to handle voice comms (i.e., to compress unique sounds, transfer those sounds to everyone's computer, and then play those unique sounds) would be (relatively speaking) quite complex when compared to existing in-game sounds (i.e., [likely] telling the user's client what locally stored sound to play and at what parameters [e.g., sound level, sound direction/location).  The data requirements for in-game sound might not even be feasible with existing architecture.  This is why I mention that you would need to shuffle programmers:  it isn't just the sound; it's the processing power and bandwidth requirements that could require significant architectural reworks.

    Ultimately, if CRS did decide to use unique in-game sound, they might need to use an algorithm that looked something like this:

    // interpret the words a person was saying and convert to English text in a sentence structure,
    // send this text (and other applicable data, such as sound level and direction, word inflection, etc) to all applicable clients, and
    // play the player-generated sentence in a voice which is stored locally on every clients computer.  Note:  for additional realism, there could be a dozen or more client-side (locally stored) voices and each person could be randomly assigned one.

  3. 38 minutes ago, jwilly said:

    Old CRS's surveys of departed customers / ex noobs (and I presume those of new CRS as well) indicate that a large percentage did not have Discord or another relevant voice comms program.

    Old CRS's surveys of noobs and ex noobs (and I presume those of new CRS as well) indicate that being on voice comms immediately on beginning to experience the game...not at some later time...substantially increases noob game engagement and retention rate.

    It also increases game satisfaction of those vets who try to help noobs, by making that process substantially more effective.

    I have no doubt that, under the current system, having voice comms would be of substantial benefit to noobs.  However, any survey is likely conflating the issue:  the issue isn't voice comms, it's new player support and the user interface.

    From a programming perspective, it is much easier to both (1) update the User Interface and (2) provide real-time feedback (little messages on the screen) for users, when compared to creating a voice comms system that would reflect both (1) whispering/talking/yelling (i.e., without a radio) and radio comms (e.g., tanks, trucks, planes).  Especially considering the server has to handle the transfer of unique audio messages from possibly up to 100 players in a battle that can be heard by either side within proximity.

    One stopgap measure might be to use the existing audio system to have preset voice commands (similar to CS:GO).  There could be common verbal commands that a player can shout out, such as, "Yes sir!", "Sniper, get down!", "I need ammo!", "Enemy in the spawn!", "Mark the damn enemy tanks!", et cetera.  They could press 1 button to access the groups of commands (e.g., ~), select a specific group of commands using 0 to 9, then shout a specific verbal command using 0 to 9.  This would allow 100 verbal commands shouts by players.  This would likely place much less load on the existing servers, depending on how audio is currently programmed.

  4. Also (sorry for the double post), but I don't see how voice comms are a priority for this game.  CRS has very limited resources.  From an organizational perspective (with limited resources), why would you allocate time to creating in-game voice comms when Discord, who specializes in voice comms and is a program that most gamers have anyways, can simply be linked to directly by CRS?

    If CRS had a dozen or more full-time programmers I would say, sure, let's get voice comms.  Put a few coders on it for a few months.  But in-game voice comms aren't that large of a benefit OVER Discord.  So how could it even be prioritized based on the current situation?

  5. 27 minutes ago, Kilemall said:

    Big big assumption on your part.  Depending on how it was done, it may be hand coding for every individual FB pair and a ton of QA involved.


    It's also not just how much programmer effort involved, but the payoff in gameplay and ultimately subscriptions.  VoiceComms may or may not be easier then FB redo, but it pays off bigger IMO.

    Although it is an assumption on my part, it is not a "big big" assumption.  Just as it is standard to build a house with 2x4 or 2x6 studs for the majority of the walls, it is standard to create loops when those loops will save a massive amount of coding.  That said, it is possible that a novice programmer individually coded every FB (just very unlikely).  Although, CRS could correct me if I'm wrong.

    In an ideal situation, the FB code might look something like this:

    Initial function that loads when the game is first started:
    // iterate through the database; if IS_FB_ACTIVE (a boolean variable) is set to true, then call the LOAD_FB_FUNCTION for each active FB.

    Supplemental function that is called whenever an FB is destroyed:
    // call the REMOVE_FB_FUNCTION on the destroyed FB, which would change the IS_FB_ACTIVE variable as well
    // call the LOAD_FB_FUNCTION on the newly active FB, which would change the IS_FB_ACTIVE variable as well

    There are, of course, many ways to program something.  But, if the FBs are programmed as above, then my suggestions could be very rapidly implemented.  A programmer who knows the existing game code could likely complete the change in hours, most of which would be testing how the system handles removing an FB when an AO is set (and returning an FB when the AO is removed).

  6. Thank you for your comments everyone.

    Just to clarify, I am not against the concept of FBs, and perhaps my original point about FBs was incorrect.  How about this: 

    FBs should be indestructible and always active.  When an AO is set against a town, FBs can be removed for the defending links.  (e.g., if Axis have 1 link to Antwerp through Schilde, then, once the Axis declare an AO on Antwerp, the Allied FB to Schilde from Antwerp will be removed until the AO ends).

    Please keep in mind that, as a hobbyist programmer, I am trying to make suggestions that work within the existing framework of the game.  Although voice comms in game would be nice, this requires substantially more coding than modifying existing code to (1) make FBs always active, (2) make FBs indestructible (perhaps by switching a single variable to give the FBs an insane amounts of hitpoints), and (3) remove defensive FBs when an AO is set.  From a programming perspective, the coding time required for these FB changes can likely be measured in hours or days, not months (e.g., voice comms).

  7. I wanted to give my overall impression of this game in one sentence:  By far the best combined arms game with by far the worst new player support (but only on a technically, since Elite Dangerous has no new player support at all).

    The Strengths

    • In higher population situations (30+ per side in one town), the game is not only at its best, it is the best.  When you have multiple highly-populated AOs ongoing (i.e., with all the forward bases up), the action feeds itself, and 6+ hours can fly by like it's nothing; this is especially true if you are a more experienced player analyzing the map and recommending brigade movements to High Command and/or setting up new attacks.
    • (Comparatively) Realistic damage model makes for challenging game-play.
    • Hundreds of towns and limited (but replenishing) supply attracts all types of players (operational, tactical, strategic).

    The Weaknesses (with Suggestions)

    • New player support is absolutely atrocious.  This is very easy to see, considering max rank vets make up a majority of players on pretty much every army mission.  I'm sorry, but as a hobbyist programmer for more than a decade (Java, PHP, Javascript, MySQL, CSS, HTML), there are just so many things that can and should be done (see Retention of New Players comment here: http://forums.wwiionline.com/forums/topic/422057-suggestions-eh/#comment-6388363.  The playerbase cannot be expected to address these deficiencies by training new players themselves.
    • The main page needs to be a sell page for the game.  If you can't hook the reader in 10 seconds and keep them reading in a coherent manner, the main page of website isn't doing its primary job.  A concept for a proper main page could be as follows:
      • [PICTURE OF AN IN-GAME BATTLE]  Introduce the game concept in a few sentences (e.g., "A first-person shooter set in World War 2 that is massively-multiplayer and 24/7/365.  With NUMBER_OF towns, each with their own unique terrain and layout, you fight to secure Europe for either the Axis or Allies.  You control NUMBER_OF types of infantry, NUMBER_OF types of tanks, NUMBER_OF types of planes, and NUMBER_OF types of ships to secure victory.  The winner is the side who QUICK_VICTORY_CONDITION_OVERVIEW.  Possibly mention limited supply (that refreshes) and surrounding towns, which allows for lots of strategy!
      • [PICTURE OF ZOOMED IN MAP TO SHOW 12 OR SO TOWNS] Introduce the concept of the map, showing the number of towns, how connections work, and so on.  Just a few sentences.
      • [PICTURE OF A SINGLE TOWN WITH ENEMY FORWARD BASES] Introduce how a town works and how it is captured.  Again, just a few sentences.
      • [5 MINUTE VIDEO OF GAMEPLAY] Explain what is going to occur in the video.  Ideally this would show a battle where there is at least 40 a side, and emphasize that the sounds, shots, and smoke are all player generated.
      • [PICTURES OF MANY OF THE UNITS] Show and describe some of the more common units.
      • Show additional resources (e.g., wiki [which needs a SERIOUS reworking]).
      • Explain that the game is free to try and introduce the tiers of payment here.
    • Game mechanic failures
      • The game should not require people to sit and guard (especially FBs), with the sole exceptions of army base bunkers and airforce bunkers.  By expanding the zone-of-control considerably, but giving a bonus to anyone in the CP, you can have people engage in much more dynamic battles, because anyone sitting in a CP (generally) isn't fighting.
      • The game must not have situations that discourage attacks (which generate that awesome and fun action).  In other words, FBs should be indestructible and always active.  When an AO is set against a town, FBs can be removed for the defending links.  (e.g., if Axis have 1 link to Antwerp through Oostmaale, then once the Axis declare an AO on Antwerp, the Allied FB to Oostmaale from Antwerp will be removed until the AO ends).


    Additionally, this isn't a weakness, but this is a word of caution:  if you focus on returning vets (and therefore, increasing the % of vets in game), those vets will likely reduce the retention of new players.  Why?  Because us vets who can knock out ETs in 1 or 2 shots from 1+ kilometer away (or sap/shoot ETs with near 100% accuracy), which will discourage new players from playing.  Noobs need to be able to have a chance to fight other noobs so that they can learn and enjoy the feeling of actually getting a kill.

    3 people like this

  8. As someone who thinks the sides are pretty balanced in terms of equipment, I think the following would be very interesting:

    After each campaign, there should be a mini-campaign that lasts for 1 week.

    The mini-campaigns would be different in purpose that the existing campaigns. 

    The purpose of the mini-campaigns would be to see how long the other side could hold out for (to a maximum of 1 week).  In other words, each campaign would have a defensive side and an offensive side.

    In my opinion, the following two situations might make excellent mini-campaigns:

    Operation Dynamo (On or after May 26, 1940)
    Focuses on the Allied evacuation at Dunkirk.

    Battle of the Bulge (On or after December 26, 1944)
    Focuses on the Allied closing of the Bulge after the failed Axis offensive.


    2 people like this

  9. 15 hours ago, goreblimey said:

    what about the dlc etc 

    but yes long overdue cleanup

    Here's a more detailed look at how this could be organized, using the Axis equipment as an example:

    INFANTRY (Tier 0)

    Karabiner 98k (Enlisted)
    Karabiner 98k (Officer [High Command])
    Modello 1891 (Enlisted)

    Sub-Machine Gun:
    MP40 (Enlisted)
    MP40 (Downloadable Content)
    MP34 (Enlisted)
    MP34 (Reserves)
    Modello 38 (Enlisted)
    Modello 38 (Reserves)

    Panzerbüchse 39 (Enlisted)

    Light Machine Gun:
    MG 34 (Enlisted)

    [Sniper] Karabiner 98k with 5x Scope (Enlisted)
    [Mortar] Granatwerfer 36 (Enlisted)
    [Engineer] Karabiner 98k (Enlisted)
    [Sapper] Pistole Parabellum 1908 (Enlisted)
    [Ammo Bearer] Karabiner 98k (Downloadable Content)

  10. Should break down available units into logical sub-categories, so-as not to overwhelm newbs with the 20ish unit types.

    For example:

    INFANTRY (Category)

    Rifle (Subcategory)

    Semi-Auto Rifleman

    Anti-Tank (Subcategory)

    Anti-Tank Rifle
    Anti-Tank Soldier

    Sub-machine Gun (Subcategory)

    SMG Type 1 (e.g., MP34)
    SMG Type 2 (e.g., MP40)

    Light Machine Gun (Subcategory)


    Support (Subcategory)


    Repeat with tanks (e.g., heavy, medium, light, anti-infantry, tank destroyer).

    3 people like this

  11. Retention of New Players

    List the Help channel as F1 and have it preselected so noobs can always talk to someone.

    Have a button that lets the user spawn into the most populated battle in the game-world as a rifleman.  Alternatively, if this is complex (from a programming perspective), then allow HC to set the FMS or CP the player would spawn into when this button is clicked.

    For each type of unit (e.g., infantry, plane, ATG, tank), the user's screen should be populated with useful and sequential information.  For example, upon joining the game world in a tank, the user could see the following data in bright red letters that change when each command is completed:

    Press [KEYBIND] to start your engine.
    Press [KEYBIND] to close the driver's viewport (to protect the driver).
    Press [KEYBIND] to switch to commander.
    Press [KEYBIND] to open hatch for better view (exposes commander).
    Press [KEYBIND] to use binoculars zoom level one, again for binoculars level two zoom, and a third time to return to regular view.
    Press [KEYBIND] to switch to gunner.
    Press [KEYBIND] to deploy gunner's optics.
    Press [KEYBIND] for changing optic setting, switching ammo, firing, etc.
    Press [KEYBIND] to switch to driver.
    Press [KEYBIND] to switch engine gears to get moving.
    Download this guide for where to hit tanks.  Some tanks cannot destroy other tanks!  See the guide for full details.

    FB/AO/CP Changes

    FBs that allow for more "up-time" (fighting) could be:

    only placed when an AO is set,
    moved to within 2.0-3.0 KM of every town, and
    added to all towns for all links (e.g, Haybes).

    AOs that encourage more dynamic fighting/strategy could:

    remove themselves automatically after having not held a CP in the AOed town for a certain period of time (e.g., 30 minutes), and
    prevent the re-AOing of a town for at least 1 hour (to simulate a failed attack and/or opportunity for counter-attack).

    CPs could be turned into more diverse Zones of Control by:

    expanding capping zone substantially (e.g., 15x the area of the CP building itself), and
    giving people who are physically inside the CP building a capping bonus (e.g., of 400% over just being elsewhere in the ZOC).

    Other Minor Suggestion

    Add a "save password" checkbox on the launcher; standard protocol these days is to have a unique (e.g., randomly generated) password for everything.

    1 person likes this