Darkcity

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.

Neither denaying this nor I mentioned that it is not case. We can't ask user/player to no do certain events when it is possible in game, right? These cases needs to be handled accordingly. No proposal has been put in front. Thats why I always put my point of view in buckets. Gameplay disucssion was purely from the point of view of player. I plays game quite frequently with both pros as well as new players, so my comments were based on that. Logical persecptive was to answer @Gurken Khancomment that if romans has access to eles in past then they should have used it. It was my logical answer to that Product perspective was my understanding of how UI will be complicated. Attaching a screenshot of the same. If you have 2 different types of units under a player and you select them then what will you see. You can so the buildings they can build, the panel is full. Don't we need this special handling if any units can be trained by any civilization? Cosider a case where 3 or more civilization units are there. 4. I replied to @Gurken Khan how can be handle this case. 5. This was my proposal and final comment @alre. I wasn't completly opposite to idea. I totally onboard to have somethig in between, but based on observations I don't see option 2 as good idea. And, not sure where did I make false claim though. Let me now if I have missed something. I can understand if we not used to look at any disccusion in parts but thats alright. Thanks @Sevda for the code piece you shared.

@Gurken Khan Lets take an example of Sele capturing Brits Baracks. WIth 2nd case, Sele can train Slingers. Now the problem is Sele civic doesn't have slingers, so how do we support it? 2 ways. Make a model of slings under Sele. If we do this we have to support all types of units present in the game under each civilization - Not ideal & very big task, and prone to many bugs. Use sling model of brits. In that case sling can still make brits buildings. Not ideal, UI will break. This is just 1 use case i explained. There are so many use cases and edge cases where we have to figure out how to handle. Besides logically we have modify slings stats here but again effort required is high. We can have something in between. For example. If mace capturing Mauryas cc. Since maryans has skirmish cav, Mece can also train skirmish cav, and since mece doesn't have normal skirmish they get Merce Skirmish. So, if the types of unit is supported by catuptured civic then capturer should be able to train that unit, but the unit will be of capturer and not captured civic, which is the present logic and I think it is fine.

There are two options. Allow capturer to train captured civic units or not allow that. We can look at from multiple perspective. Gameplay persepective Not allow case: In this case gameplay will be as usual nothing impacted. People will know what to expect and what are the benefits of caturig the building. Allow: New gameplay kicks in, people can train any units of any civilization as long as they capture the buildings. Maybe interetsing gameplay, but few limitions are there. User will see so many units types, He will have so many questions. He opts for a civic that has some units. Now he sees so many units from so many buidlings, which one to train? Therotically speaking a game with ffa of 8 players, a player can have 8 different variation of each units like skirmish cav, will he even going to use that? People play a civic becasue they know the civic, sure some variation in units are preferred but with too many options player might get confuse. There can be other cases as well. We should test out this in mode if possible. Logical persecptive: A civilization that especialize in certain units types should have suprior units compared to a capturur that doesn't especialize in it. If Romans captures Sele elephant stables and train eles then they should be inferior in stats. If we are willing to do that then I think it should be fine logically. Certain units types are specific to a civilization that defines their indentity, should fire cav be trained other than by Iberians? It can be questioned. Product perspective A single player can have so many types of units trainable under him, depends on types of buildings captured. It will add to some level of more complexity. UI handling will be difficult. Suppose you are brits, you have ptole backs and roman barcks and mauryans barcks captured, and so on. In certain cases, no of differnet units will exceed the supported number on screen. For example on slecting barack we can show 10 differnet types of units. But now we have 20 types of units, the UI will break. The units trained under capturur shouldn;t be able to build captured civilization building. This needs to be disbaled else it will be hugh mess. For example if a roman civic captured mauryans & brits baracks and trained archer and sling. These units should not build those civic specific building. UI will break. To handle this we will need hard checks, another level of complexity. =================================================================================================== My point is allowing going with option 2 is more complex and less logical than we think. We can make some expercation for certain units and among certain civiclizations, but fully allowing I'm not in favour of. We can either go with option 1 or have some exceptions (something in middle) but not option 2.

I think the whole point of not allowing training for certain units from captured buildings is to maintain uniqueness of the civlization. For example followings doesn't make sense Romans makings eles from elephant stables mauryas making siege towers from capture siege workshop Sele making sowrd cav from gauls stables. And many more... I believe any capture building should only train units that are related to capturer. Which is the current implementation, except few bugs.

@Dizaka, @Stan` What's the expected behaviour here? Civilization A can train unit X from capture building Y of civilization B, only if unit X is supported by builidng Y of civilization B? Becasue I have seen this broken many times. To give you an example. If you are iberians and captures Embassy of Carthas, You can train merce sword cav. Which is weird because Iberians doesn't have merce sowrd cav. I will take snap next time and share the same.

I was referring to this @Stan` How come a player has such stats?

At present lobby doesn't support one on one chat, it only allows lobby messages which are visible to all players. So, if two player needs to have certain discussion or conversation they either have to host a game where no spec is allowed or create a room where they discuss while asking random joiner to leave. I think this need improvements. This can be done as follows. Solution: If a player wants to send personal message to anyone they can use @playername to send the message. In this case the message will only go player and not to entire lobby. You can always tag player with using names without @ so using @ is fine for personal message. Example, @Darkcity 1v1? (FAQ by vinme). limitation: Certain people might get toxic and can use it in bad way. Hence we can do following improvements. Put profinity check as usual chat. Allow personal messages to friends only. How to decides who is friends? This can be done using current buddy tagging. Right now you can tag anyone as buddy so it can't be considered as friend since you can mark anyone buddy. So, only ff both players tags each other buddy then they should be market as friends. You can only tag friends with @ to chat. Profanity checks will always be there. @rossenburg, @Grapjas will you be able to include this in your modes?

@rossenburg I like your solution, as it is simple and might be effective. I have some questions, comments ,and improvements about your feature. Questions......... How would you finally verify a player as smurf? based on number of reporting for the player? How would you handle collective abuse of the feature? Where certain group of players mark certain player as smurf (for fun or some other reason) even though he is not? Will smurf will have his say in deciding his account as smurf? What is the exact role of lobby modeartor in your solution? He is just a tagger or he will also have his say tagging the player as smurf? Comments.......... Try to add more functionalities than just smurf reporting. More use case a feature covers most likely to be added. Example use cases are Report for leaving a game Report for DDOS Report for in game abuse etc... Penalties suggestions are Muting in lobby Banning for certain days. This will be more effective, as player would want to play 0ad and he will login with account to play. After a while he wil be tired of making acounts and will return to original. If player finds out the original player, tag original account as smurf. This will scare most of smurfs as they don't want to loose their orginal account. (Although player concent should be taken before banning as warning) Improvements......... Creating a level of messaging and penalties for smurfs based on number of reportings. lets say x number of players has reported player as smurf then. 3<=x<=5 , kick/disconnect from lobby with notification "Your account has been reported as smurf account, please login with your original account". 5<x<=8. Ban for 1 day 8<x<=10, ban for 3 days 10<x<=15, ban for a week. x>=15 permanent ban. The decision to ban should be with moderator while kick and disconnet should be automatically. Change the color of your ! as these reporting are done. for example from a color grade yellow to red. -------------------------------------------------------------------------------------------------------------------------- 0AD_BOSS case is kind of questionable. @Stan` is this becasue he is using certain mod? Else how come someone has such stats? Example -ve matches?

It won't be good player experience for new players. It might stop some smurfs but it will impact all newbies. So, not sure if this will be a good solution. Also, most smurf don't care about ratings except few, so this will only go in their favour, where no ratings is shown untill he can ruin 10 games for other players. It can go as overall suggestion to 0ad on how to calculate initial rating based on first 10 (or x) rated games and there after normal rating system that is currently present, but for smurf i'm not sure about it.

I see these 2 as good solution to this whole smurf and new account problem. Second point I want to add is what stats to show for a player in 0ad lobby through which people can check whether or not he is smurf. At present we show following values Ranks Ratings No of rated 1v1s Win and lost games Win % I think here win and lost games are redundent if we are showing Win%. Instead of this we can show, Number of Team Games played or Total games played by the players. These stats will ensure that perticlular player has played many games and not a new account. So, we will see followinf stats. Total games played Total rated games played Rank Ratings (highest and current) Win % in rated games It will resolve following issues. Unrated old players will not be marked as smurfs New accounts can easily be identifiied. No one can be too good when he just played 2 total games and unrated, people will know. Good to know who has more exprience in TGs, even newbies with low ratings at present with good amount of TGs played can say that he has experience to play matches with high rated players. They are often removed from the matches which I feel bad about. @Stan` This should be small change, should be added in ticket in my opinion. CC: @borg-, @rossenburg, @Sevda, @Alar1k