Darkcity

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.

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.