• Announcements

    • PITTPETE

      NEW Career Subscriptions now available   06/08/2019

      The all new highly anticipated / requested "Career Based Subscriptions" are available through www.WWIIONLINE.com/account only, starting at $9.99! There are three new subscriptions being added; 1) All Infantry at $9.99/mo, 2) All Air Forces at $9.99/mo, 3) All Ground Forces (Army Persona) at $12.99/mo. Continue reading to learn more and get back into the fight now! View the full article on battlegroundeurope.com
    • CHIMM

      18th Anniversary Event Awards!   06/23/2019

      This year we are giving out trophies and awards for the top players during the "Kill a RAT" event! We need the following players to contact @CHIMM at chimm@corneredrats.com with your physical address to mail these out.   @mook2  @dasei88  @c00per  @kardehk  @chau90  @kdped02  @Simcha  @pulfer  @bus0    
hans1939

Game Strengths and Weaknesses

32 posts in this topic

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.

Edited by hans1939
3 people like this

Share this post


Link to post
Share on other sites

CRS has a bad habit of ignoring some things that are extremely bad. Take the spiral death cam for instance. I find a great hiding spot and kill an enemy infantry, then a little while later he runs right back and kills me after re spawning close by. I know this to be the case because when I am killed at times, that death cam exposes the location of my hidden killer.

1 person likes this

Share this post


Link to post
Share on other sites

Old CRS recognized that in WWIIOL, and generally any game with a steep learning curve, the high K/Ds of many vets were achieved by slaughtering noobs, and therefore that a key reason for low noob retention was vets. The game isn't completely zero sum, but it's close.

There were Design Forum discussions about a game system in which players would see, and could interact with, only those other players that were similar to them in K/D and noob-status. So, noobs and vets wouldn't see each other. Obviously that'd result in complications. Other discussions were about running two or three simultaneous instances, with players automatically allocated according to some combat effectivness metric unless they choose a "harder" instance.

None of that ever went anywhere. The concern was that too many vets would leave if they couldn't get easy kills and were killed more often themselves.

Edited by jwilly

Share this post


Link to post
Share on other sites
3 minutes ago, jwilly said:

Old CRS recognized that in WWIIOL, and generally any game with a steep learning curve, the high K/Ds of many vets were achieved by slaughtering noobs, and therefore that a key reason for low noob retention was vets. The game isn't completely zero sum, but it's close.

There were Design Forum discussions about a game system in which players would see, and could interact with, only those other players that were similar to them in K/D and noob-status. So, noobs and vets wouldn't see each other. Obviously that'd result in complications. Other discussions were about running two or three simultaneous instances, with players automatically allocated according to some combat effectivness metric unless they choose a "harder" instance.

None of that ever went anywhere. The concern was that too many vets would leave if they couldn't get easy kills and were killed more often themselves.

Star Citizen was literally going to do noob on noob/vet on vet, I'm not tracking on that game but I understand that was a major design goal.

Share this post


Link to post
Share on other sites
51 minutes ago, shiloh17 said:

CRS has a bad habit of ignoring some things that are extremely bad. Take the spiral death cam for instance. I find a great hiding spot and kill an enemy infantry, then a little while later he runs right back and kills me after re spawning close by. I know this to be the case because when I am killed at times, that death cam exposes the location of my hidden killer.

The death cam is a game mechanic to teach you a lesson of actual warfare: single-location defensive fighting tends to make you dead, because attackers learn where you are and figure out how to put fire on your location. In-game as in real war, moving around is dangerous but not as dangerous as not moving around.

Any game like WWIIOL has no gameplay if too many players are stationary in "great hiding spots" and waiting for other players to come by. So, the game is designed to make that tactic problematic.

Edited by jwilly
1 person likes this

Share this post


Link to post
Share on other sites

OP, completely agree on the general point of new player support.  I think this game would have been a big success, possibly Rats 1.0 still there, if that had been a major focus from day one.

 

I liken the default approach for many years to lizards laying their eggs then waddling away.  Only the strong and the lucky survive to hatch and grow into vets, the rest get eaten or die.  We need more mammalian approaches to retention, and talking to a noob like we are asked to do does no good if the noob doesn't answer back on text.

 

That's why Voice Comms is THE hot button dev item to do.  Won't fix it all, but it's a clear target with a finite achievable goal.

 

As to the rest of it, while I get your action thing, I disagree that guarding should be written out.  That's part of WWII, boredomboredom OMG!  Area capture can reduce a lot of this and area spawning should free us from some of it, but ultimately in order to have a fight where players set the terms and it's open, you gotta have guarding some asset and consequences for failing to defend it.

Share this post


Link to post
Share on other sites

Agree with every thing that you posted Hans (minus the FB part). The webpage has improved but yes, you raise a great point that a player why goes there the first time won't have the impression of the scale or the immersion. You raise a good point about the vet vs. noob thing which certainly can be an issue, but could be alleviated with a better tutorial that focuses on gameplay and not FPS mechanics which all players already know, as well as voice comms which would be huge. I think that for a long time CRS 1.0 effectively outsourced a lot of this training and retention to squads and later attempted to do the same with HC. I think a lot of this could also be helped by like you said some key how-to videos as well as a true game manual.

Now regarding the FBs, I agree with Kilemall here:

15 minutes ago, Kilemall said:

As to the rest of it, while I get your action thing, I disagree that guarding should be written out.  That's part of WWII, boredomboredom OMG!  Area capture can reduce a lot of this and area spawning should free us from some of it, but ultimately in order to have a fight where players set the terms and it's open, you gotta have guarding some asset and consequences for failing to defend it.

I think that its important that WWIIOL has a "big tent" approach and cater to as many players as possible. And I think there is certainly a fair amount of players who like to defend/snipe. I know many vets look down on the snipers in the windows, but at the end of the day they are paying customers enjoying the game the way they want to... and thats ok!

FBs are a similar situation. Although we don't see it now mostly due to population issues, when the server population was high FBs were actually a very active and popular place where to fight. Specifically it again catered to a different type of player. If you were the aggressive capper type, or a tanker you would go and attack a town (most players did this). But there were tons of players who were more defensively minded who liked doing more recon roles, and defensive stuff for which FBs were perfect. FBs were also the go-to place to spawn AA guns for the players who loved shooting at planes. It created this sort of virtuous circle where the pilots knew there were ground targets to kill at the FB, and AA gunners knew the planes would be coming for them. Some of the most intense AA fights outside of an AB under full on Allied AirQuake(TM) were consistently at FBs. Similarly, a fun mission was FB assaults as well. So personally I wouldn't write off the FBs so soon, there are some issues where you can flip one in low-pop, but given the amount of sachels it takes to take one down, even a token defense is sufficient usually.

Share this post


Link to post
Share on other sites
1 hour ago, jwilly said:

Old CRS recognized that in WWIIOL, and generally any game with a steep learning curve, the high K/Ds of many vets were achieved by slaughtering noobs, and therefore that a key reason for low noob retention was vets. The game isn't completely zero sum, but it's close.

There were Design Forum discussions about a game system in which players would see, and could interact with, only those other players that were similar to them in K/D and noob-status. So, noobs and vets wouldn't see each other. Obviously that'd result in complications. Other discussions were about running two or three simultaneous instances, with players automatically allocated according to some combat effectivness metric unless they choose a "harder" instance.

None of that ever went anywhere. The concern was that too many vets would leave if they couldn't get easy kills and were killed more often themselves.

The idea to hide with a vail and split the PB in two literally is an atrocious hybrid imo. The fking n00bs would learn best if they followed some vets, instead of running around like a bunch of headless chickens! But see, the problem is they don't SEE the vets, anyhow. And they don't listen to them vets either...

Share this post


Link to post
Share on other sites

Defending boredom could not be eliminated without also eliminating attacking surprise.

In a game with announced tactical plans, defenders could be allowed to be set up and ready. Attackers could be held away until that readiness. But, defenders could be limited to say 1/2 or 1/3 the pop of the attackers...i.e. the classic even-odds or slight-attacker-advantage force ratios.

That would be a very different game. 

Share this post


Link to post
Share on other sites
10 hours ago, jwilly said:

Any game like WWIIOL has no gameplay if too many players are stationary in "great hiding spots" and waiting for other players to come by. So, the game is designed to make that tactic problematic.

Lol i feel like you just perfectly described agave here.

I would say priorities to address the primary point of the thread ...

1A)  Integrated voice comms

1B) Improve UI 

Edited by choad

Share this post


Link to post
Share on other sites

Think dump the whole FB concept too.

No more FBs, make PPO FB, no closer than 4k to enemy town; 3k if contested.

The truck that sets FBPPO sets off EWS at 5k from town.

 

Right now, I'm sitting at FB watching it to our AO - not attacking, not defending, sitting.

Now, to be fair, I wouldn't be attacking as horrendous capture timers end that, but I could be at a DO town.

1 person likes this

Share this post


Link to post
Share on other sites

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).

Edited by hans1939

Share this post


Link to post
Share on other sites
44 minutes ago, delems said:

Think dump the whole FB concept too.

No more FBs, make PPO FB, no closer than 4k to enemy town; 3k if contested.

The truck that sets FBPPO sets off EWS at 5k from town.

How would that change the dynamic? It's still an FB you have to defend. The only change is that the enemy needs to first find the FB, which with air recon won't be too hard.

Share this post


Link to post
Share on other sites
15 minutes ago, hans1939 said:

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 Oostmaale, then, once the Axis declare an AO on Antwerp, the Allied FB to Oostmaale 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).

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.

Share this post


Link to post
Share on other sites
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).

Edited by hans1939

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
43 minutes ago, hans1939 said:

Discord (...) is a program that most gamers have anyways

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.

Quote

I don't see how voice comms are a priority for this game

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.

1 person likes this

Share this post


Link to post
Share on other sites
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.

Edited by hans1939

Share this post


Link to post
Share on other sites
49 minutes ago, hans1939 said:

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).

<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.

 

2 hours ago, hans1939 said:

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?

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.

 

 

Share this post


Link to post
Share on other sites

*** How would that change the dynamic? It's still an FB you have to defend. 

It would completely change the dynamic.

A) would never have to get a FB to attack a town - you can attack w/o putting up your PPOFB, just have to drive further. (or para spawn?)

B ) your FB would never get busted ruining all the action.  Just means you have to driver further as truck or tank - but existing MS from an AB would still be up.

C) Add a whole new dimension in cross country fights, opening the entire space between towns.

D) Bring in the element of hunt the FB.

E) You could have the two opposing towns attack each other at the same time!  Can't do that today as one town always has a FB and blocks the other town.......

Edited by delems

Share this post


Link to post
Share on other sites
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.

Edited by hans1939

Share this post


Link to post
Share on other sites

***  that has objects like FBs hardcoded in

No they aren't.

There are many towns w/o FBs.  So can easily be done obviously. (and we've added many new towns with and w/o FBs.... so not a big deal)

Just remove the FBs.

The PPOFB, well, that different, might be harder to code.

Share this post


Link to post
Share on other sites
4 minutes ago, delems said:

***  that has objects like FBs hardcoded in

No they aren't.

There are many towns w/o FBs.  So can easily be done obviously. (and we've added many new towns with and w/o FBs.... so not a big deal)

Just remove the FBs.

The PPOFB, well, that different, might be harder to code.

Yes they are absolutely hardcoded into the terrain engine with backends to whatever state mechanic.

 

The fact that there ARE links with and without FBs is a clue there is optional programming involved, particularly with the 'is link friendly to allow missions from either source town or FB?' logic in.  Has to be tied into the spawnable logic too.  Likely not casual, even ripping out.

 

I'll be happy to be corrected by the experts, but Rats 1.0 often stated these things are embedded in the terrain as objects and it all has to work together to function as is.  Breaking down the logical components tells me there is more then just 'delete object from map' involved.

Share this post


Link to post
Share on other sites
16 minutes ago, hans1939 said:

@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.

I would agree that literal voice comms in game is a Big Project, and I expect the Rats know this too.  That's desirable but not necessary for stopping first stage sub bleeding right now. 

Your particular architecture is advantageous in that it could be fed to text if the player is deaf (this is a thing) and through a translator since we are a worldwide game.  It would also be a BIG THING to implement.

I wouldn't be surprised though to find the Rat conception is more natural voice with relative position defining what can and cannot be heard.

A default check/install and macro that sets up the CRS voicecomm sites if already installed on a TS/Discord/whatever platform is all I'm talking about.  And for the payoff, real high on the list IMO.

Share this post


Link to post
Share on other sites
2 hours ago, delems said:

*** How would that change the dynamic? It's still an FB you have to defend. 

It would completely change the dynamic.

A) would never have to get a FB to attack a town - you can attack w/o putting up your PPOFB, just have to drive further. (or para spawn?)

B ) your FB would never get busted ruining all the action.  Just means you have to driver further as truck or tank - but existing MS from an AB would still be up.

C) Add a whole new dimension in cross country fights, opening the entire space between towns.

D) Bring in the element of hunt the FB.

E) You could have the two opposing towns attack each other at the same time!  Can't do that today as one town always has a FB and blocks the other town.......

So if I am getting you correctly both sides have PPO FBs, but neither side can leapfrog one another... you have to steadily push it back towards the enemy's town and advance your own. That may you can have the French attacking Gedinne with their PPO FB while the Axis attack Haybes with their own PPO FB, with supply warping past each other.

Thats not a bad idea, my one major concern here would be how much would this slow down the map? Campaigns already can take months. What are the unintended consequences of such a FB system?

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.