hans1939

Free Play Account
  • Content count

    38
  • Joined

  • Last visited

Community Reputation

9 Green Tag

About hans1939

  • Rank
    Member
  • Birthday
  1. 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. @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. 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. 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.
  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. Thoughts?
  9. Here's a more detailed look at how this could be organized, using the Axis equipment as an example: INFANTRY (Tier 0) Rifleman: 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) Anti-Tank: Panzerbüchse 39 (Enlisted) Light Machine Gun: MG 34 (Enlisted) Support: [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) Rifleman 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) LMG Support (Subcategory) Mortar Engineer Sapper Sniper Repeat with tanks (e.g., heavy, medium, light, anti-infantry, tank destroyer).
  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, indestructible, 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.