Darkcity

I think i'm able to clarify. Let me reiterate. 1. Observers can't text privately to any player, they option to chat with everyone, or to single onserver or all observers. So, if they want to anything to say anything everyone will see it. [Screenshot from game a moment ago] 2. If they want to give away any strategic info, they would rather talk about pop, resources, upgrades, no of womens, any other information about player, then why it is cheating he says "Player1 has flared or Player1 has flared at 8'O clock". @hyperion, @alre, please help me understand the issue. Becasue oberser able to flare doesn't add any new cheat to the game.

@hyperion I'm not able to understand your conern. I need to know whats your concern on first use case "Observers able to see player's flares". Let me give you an example and what will happen so its clear to you. We have 8 player game. Player1 initiate the flare. Current scenario: Hi team mates Plyare2,3,4 will able to see the flare. Expected Scenario: Observer will also see the flare. Now, If observer wants to do cheating he can do 2 things Text on chat which is visible to everyone Communicated by another medium like discord. First case, an obsever can put anything about player1 on chat, he might as well share player other stats like units food wood and women. What will obsever achieve by putting a text to everyone that "Player1 has flared or Player1 has flared at 8'O clock"? Allowing him to see the flare doesn't add any cheat. Second case, again not the problem of flare. @hyperion If you are thinking of any other scenario, please explain, becasue I'm able to unserstand the probelm here. @Stan` Can you please mention the concern related to "Observers can see player's flare" becasue of that we are saying

Hmm, this is for second feature, "Flares for onservers, where observers can flare and that will be visible to other observers", which I think we should add in mod example: Boon GUI. For first feature "Allow observers to see player flare", I don't think we have any (actual) issue. Should be added in main game as well..

What if we do it in rows instead of columns? Should fit right?

You are right @go2die. Observers can only talked to observers in the game, or send message to everyone. If a observer wants to say something (give info to a player) then he can say irrespective of flare, and besides that chat is visible to all, so host can ban the observer. My point is player flare visibile to observers is not adding anything extra that can give away something or can be called as new cheat. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- For the feature "observer flare", it can be added but should be tested out in mod first to test out whether it get traction from observers, becasue as i mentioned earlier. And commentators usually go for Boon GUI, so it should be added there.

@Stan` If players wants to cheat they can cheat on alternative mediums like discord. I understand the use case where observers might communcate falre of one team to another but that doesn't really add any additional/unique info, which they can't share on discord. Allowing observers to see player's falre for observer experience, for discussion and commerntries would be great. Not many players observer game throughoutly, so not sure main game should have it. It's definitely a good idea to be added in Boon GUI. @seeh if you are still making changes in it :P.

Hi @vladolf1984. Welcome to 0ad fourms and 0ad. We already have some of these features available in the game. Sandbox AI: You can change the AI difficulty level to Sandbox. Online: You can join the lobby (in menu go to multiplayer than lobby) and play with other online players. Campaign: This is work in progress, but you should try scenario maps. Example Death canon map. Construction: For this allow cheat in the game and use cheat code "gift from the gods". This will give 100k resources (food, wood, metal, stones). All buildings will be unlocked and they will build instantly. Enjoiy!...

Hmm. As long as its calculations are in right direction (+ve and -ve) then it should be fine. There are 2 cases for smurfs. They play with Pros/ Pro TGs They play with beginner The second is major issue compared to first, becasue they ruin the experience for new/recent players. In this case if they are coming up with baised high +ve then thats fine. Atleast, player should know that this person high level smurf compared to other low level smurf who plays pro TGs only. Besides, even if we are about to come up with new logic, it will also have some flaws, so, let's use what is existing. Here decision lies with host so. Besides final decision will be on moderator, so, should be fine. ==================================================================================== On separate note, another param can be used is, win rate. Most of these smurfs has 100% win rate with few about <15 games played. But again we will need account creation date for that to validate. Account creation date will be key to finding smurf or any other detection mechanism.

I like your account name @0ad is the best rts game

I see. Thanks @rossenburg. Local storgae is not a good idea, it will only allow sumrf to find a way around. @Stan` Can we atleast save account creation dates for the player? I can think of following use cases for storing these field. Identifying players experience in games - This is for players. Data analytics for 0ad: It can be used both for historical data analysis as well as some for good GTM for alphas. Player retention - example old players returning in new alpha Player acquisition - New users signing up Fake account identified - More clean data Account creation behaviour over time Release in season when accounts are created the most. i can add more use case but get the point. For # of game played, it is not as imporant as compared to account creation date, but if it can be added with @rossenburg if any player is AI Bot don't count else count. It can be considered if possible. Meanwhile I think we can mod the smurf reporting piece. @rossenburg I would love to check your mod once completed. If need any input from somewhere then PM me. @Sevda let us know if you want to add anything.

I was thinking of a comprehesive solution for taking care of smurfs. Along with reporting and tagging. Player can have idea about the smurf through following logic. Identifying smurfs: This will require 3 main inputs: Creation Date, Total Games played, and local rating. The reporting will fall in multiple smurf likelyhoods, we can say these are smurf levels, where 1 being highest and 5 being lowest likelyhood. Creation Date <= 7 days. Total game played <=10, and Local rating > +50. or Total game played >10, and Local rating > +40. 7 days < Creation Date <= 1 month. Total game played >10, and Local rating > +40. 1 month < Creation Date <= 3 months. Total games played <=20, and Local rating > +40. 1 month < Creation Date <= 3 months. Total games played > 20, and Local rating > +35. Creation Date > 3 months. Total games played > 30, and Local rating > +35. These are just rules through which a player can identify and report. We can implement it along with @rossenburg smurf tagging solution and let hosted player know their smurf level. Or, we can just inform player to check these details if they don't know the player. Note: This is specific to player, as they rely on local rating and additional info which we will provide like creation date and total games played. These numbers can be adjusted as we may see fit. @rossenburg Let us know if you figure out how we can access total games played and creation date. Thanks in advance. CC: @Sevda

I think espionage feature - unit bribing to share the vision, is the least used feature in gameplays. Some people don't know about and people who knew never used it. There are many reason to it inclduing higher cost of doing so (500 food and 500 metal) and less benefit to do so. I have two suggestions here. Cost reduction: We should reduce the cost especially metal cost. It should be something like 200 food and 100 metal. Type of unit to be bribed: Only working units should be bribed, it will exclude female workers. Unit swithching side: If u bribe a unit there is X% chance (let's say 50%) that unit will become your unit. The converted unit be like your newly produced unit. Gameplay scenarios: When player attack after p3, they will use this to use this to get visibility for their surprsie attack or raid attack. They will resreach it because now it affordable. Sometime its not easy to raid people, to make it a little interetsing it will have some impact although not too much on raiding. If u have over flaoting res but can't through defense, you can use extra resources to bribe and converered units will casue some distraction to break through defenses. Impact: We would like to see both Espionage and counterintelligence being used in gameplays, atleast by decent players.

Since we are talking about walls. ============= Idea for phase 1 wall======================================= In previous alphas in Skirmish map Alpine Mountains, we had wall which had forward leaning wood pike covered with some bushes (instead of current phase 1 wood wall which has vertically align pikes). We can bring that wooden wall back with forward leaning pikes, and if a unit run into they take will take damage. Damage logic can be as follows. 1. Unit will take X dps (for exmple 1 damage per second) as long as they are running into walls/touching it. or 2. Unit will take X dps for Y seconds (for example 0.2 dps for 5 sec) and this damage can stack. This will insure that walls are useful ====================== Idea for phase 2/city walls=============================== 1. Add default arrow to turrent by upgrading it. Right now player just destroy one part of the wall and raid easily. 2. Garriosned turrent should fire arrow, I think they are disabled currently. 3. A little extreme idea but catas and bolts garrion on the wall. ( I think this is also discussed somewhere on the fourm)

@rossenburg this return total number of rated games played. Not overall lobby games played (1v1s, tgs etc). Thats why I was asking whether ot not we store this info. Also how to fetch creation date?

same reason units used to get stuck in a24 and people used to get furious about it (inclduing slow turn around). If I understand correctly, large gap also create path finding issues especially in formations.

@Stan` Why did we disable flare for observers? Is there a reason for that? I think allowing observers to see player's flare shouldn't be an issue. It's good for replays and observering the game in general.

@Stan` How can i get account creation date and total games played (including non rated)? Do we have such info in out database or we don't save it at all?

Yeah make sense. Tooltip should be minimalistic yet informatve with more intuitive icons and less text. While information screen can have detailed info.

@Lopess Maybe create a bucket list of feature and priortize for your purpose. And share for a27 suggestions :p

Scenario: I have seen in some gameplays where player1 keep his units in formation marchers towards player2 army and attack. When few units of players1 dies in fight, other units rushes to form the formation. As units keep on dying continuously, they get stuck in making formaiton while player2 kills all units. Outcome: Most units of player2 dies without doing anything becasue they are stuck in making formation. Impact: It annoys players sometimes becasue it wasn't their fault. Besides, most player don't use formation in fighting, they sometime use it only for moving units or to keep them together if they are scattered. I don't have gameplay recording to show it, but will try to get it next time. We can do follwoing if not done already. Maybe we shouldn't regroup units in fromation unitll user wants to move aways units from the fight. Sometime if user tries to fall back, units get stuck. Maybe we should move only selected units in formation rest can later catch up by running? If it is already done then it might be a path finding issue?

Can you please refer me to that thread?. In my opinion, most of the players during game don't talk about captures and loot stuff, they talk about attack and defense stats. Besides player can always see detailed view of unit in information window (on right click on unit image). If we want to add anything we should add them in information screen that is dedicated to show unit related information. For other screen, we should keep only useful info and less text heavy.

Actually you are right. It is the case, that text is jumping to next line with no indentation. [Attaching the screenshots]. I see following problem with in-game stats UI (image 2). [I'm taking my own product and player perspective] It looks too cluttered Too taxt heavy. Not sure if player checks all info. Few suggestions Fix indentation in text Replace text with icon. Example, just like we are showing food and wood icon instead of writing food and wood. Similarly we should use poison icon instead of writing poison. Show Bow icon instead of wiring Bow, replace seconds with timer icon etc. Remove less important information. Not sure how many people care about capture details and loot from the unit. If I put a rank on how important is the information in the stat screen then the sequence is as follows. (image 2). Cost Health Attack 3.1 Primary weapon i.e., Bow/sword etc 3.2 Special damage is any Resistance Walk speed Attack capture Loot We can remove attack capture and Loot from stats pop-up and put it on detailed view of unit (image 1). One more alternative solution... We can also ask for community to help in improved designs.

Just wild guess that It has to do something with healing. I think fire and posion disapper if healing starts by temple/cc/healers. To validate that does fire also stops when garrsioning in any other building for example fort?

@Gurken Khan, @alre, for option 2, let's take an example of, If roman train ptol sling then sling has to belong to romans to make sure we don't get extra buildings, right?. But romans doesn't have slings be defualt, that mean they need to either support slings in units types so they doen't make ptol buildings or any unit trained under roman will not make their own civic specific building and only roman buildings. I don't know if it handled at present, but it needs to be handled. Hope i'm able to clarify my point.

We also need to disable buiilding captured civic specific builidings, no?. So even if a Iberian trains ptol slings, that sling shoundn't build ptol buildings like ptol wonder, colony, light house.