Darkcity

Current boat fighting i think can be improved a lot. Right now it works same as siege tower in water. 2 features which I think are feasible can be added. Option 1: Visible garrsion: It should be visible how many units are there on boat: Some one has already developed this mod of visible garrsion. Attackable units: Units should be attackable. This is work same as walls. The unit can attack other in unit in their range that means boats with archers will have higher range compared to skirmish. The defualt boat firing range will reamin as it is. Unit position: Since max 10 units can add arrow to the boat. 5 units will be 1 side of the boat while 5 will be other side of the boat rest in center. Only side units can attack or can be attacked. Unit Shuffling: In case units on side (attaking unit dies) then unit in center unit (no attacking unit) will occupy his space. This way all units in the boat are useful unlike present where 30 units in the boat are same as 10 on water. Option2: Treat the boat area as a normal surface where garrsioned units are standing and they will attack anything in range and can be attacked. To attack the boat player has to mention sepcifically just like walls. Advanced options Reduce pop taken to 1. First 2 unit will add to boat speed. Speed logic will be current speed*x/3, where x<=2 , and is the number of units garriosned in the boat. Rest units will add to attack. So, we will have less player roaming aroung with empty boat with fast speed. This will make archers as an interetsing units on water as range will important role. The unit damage and boat speed can be balanced accordigly. @borg- you must have had this idea before :p? @Lion.Kanzen interesting enough?

This can be initiated as seprate thread as well. But to add. Splash damange was broken imo in a23, all you needed was just catas and few units to slaughter everything. But yeag some amount of splash damange can be added for exmple elephant attack damage that @borg- was suggesting. It has to be minor so it doesn't become nuisance like a23. For example hit damage to a units should be like bolt shooter but and rest units take 1 damage in lets say 1 meter redius. Point is it shouldn't be op. Back to making siege tower intersting. I have another idea to it. Following can be done. Make siege tower units attackable. In this case units will be garriosned on 2 layers of siege tower 10 on bottom and 10 on top. ground units can attack the units. Point is siege tower units armor will be increased just like wall garriosned units. So, they will behave like moving wall (only for analogy). This logic can be applied to boats also, which I'm in high favor. Allow capturing from siege tower. This will be like giving option to siege tower to both either attack or capture a building. The capture strength will be equal to number of units garriosned in the tower. Point is, Siege units will take less damage compared to ground units as they are garrsioned in siege tower. Movement speed variation as units increased or decreaed in siege tower. I think these conversation can be initiated on separate threads as well. Including improvements for boats.

My thinking was also same @Grapjas. We maybe leave other values like damange & armors but modify movement and attack speed. Also, give bonus for extra garrion so people prefer garrsioning them instead of treating them like normal units which cost more pop but comes with high damage.

Ok, so following changes can be done. Siege will cost 1 pop, and by default values of movement and attack rate and damage will be 1/current pop cost. For example ram will cost 1 pop with 50 cursh, 4.5 second of interval with movement speed of 2.4. As you garrsion more units till 3 (which is the pop cap) stats will increase. Garrsion limit will still be the same as before. Idea is to promote garrisoning using hence people start using them as tactically. We might not stop at just current stats but also allow stats boost by like 20% if fully garrsioned. something like that.

Hello 0.A.D community, I think currently siege engines in general are not interesting to play as they are handled as simple as any unit. I was thinking of introducing following changes to make them more interesting to play. Top level idea: A siege engine shouldn't take popluation to produce but it will not move or attack untill units are garriosned. The attack and movement will depend on unit garriosned. Siege engine popupulation utlization: A siege engine shouldn't take any population or train, that means from current population of 3 to 0. Movement, attack & armor: Movement & attack will varies with respect to the number of units garriosned in the siege engine. While other statics will remian the same. The current and expected values can be seen in following table. Current Expected Inputs Siege type Attack Speed Attack Speed (current*x/pop utlized) Currently pop utilized Unit Garrisioned Crush Pierce Interval Crush Pierce Interval Battering Ram 150 1.5 7.2 50 0 4.5 2.4 3 1 Siege Tower 2.5 12 1 6.3 NA NA NA 2.1 3 1 Bolt shooter 160 4 8.1 0 80 8 4.05 2 1 Catapult 210 7 7.2 0 105 14 3.6 2 1 *Siege tower has impact only on speed and not other stats, as attacks depends on indivudual unit and not on siege iteself. Lets take an exmple of battering ram. With 0 unit garriosned ram will not move or attack. With 1 unit garriosed, its attack damage, speed and interval will be 1/3rd of what is currently there. With 2 unit garriosed, its attack damage, speed and interval will be 2/3rd of what is currently there. With 3 unit garriosned, it will behave as it behave currently. More than 3 will not have attack on stats but you can garriosn in it as per current state. Gameplay cases You can train as many siege as you want but in order to use them, you will need units inside. Depends on your requirement you can garrsion 1/2/3 or more. You are not pop constrained here but at same time you are, but tactically. You can park the siege out of fight and after fight when you wants to kill buildings garrsion units and start. This will also insure to use garriosing units in siege. There are many use cases I can go about. But i hope you got the idea. @borg-, @Stan`, @ValihrAnt, @Lion.Kanzen, what do you guys think? Open for suggestion if you find it interesting.!!

You can do few things till Devs are busy with other tasks. Don't allow late specs. If you don't want your game to ddosed then allow the people whom you can trust to spec and kick rest of them. If still getting ddosed then keep a suspect list and don't allow them next time forward. Or Don't allow spec at all if you want. Still getting ddosed then you know whom to blame :p.

This a core problem that 0ad should address, which is being ignored for long time. Here what we can do. Ask for a email id as optional parameter while user logs into the 0ad (We will show him the text tag that it will be used to reset his password). When he click on forgot password on login panel, we will ask for registered mail and send a mail to reset password. Once reset he can login with new password. @Stan`Please check this.

Hmm, I see. So the only possibility is to totally block the attacks from either side of the wall untill wall is destroyed, but attack from garrisoned units can be allowed and they can also be attacked. It can be tested in a mode if this is a good game play or not. (Prone to many bugs)

Its understandable. But I think there are few possible solution which can be configured and probably will help with this issue. Reducing the range of the unit based on the height of the wall. Example: Archers with range 60 meters. Wall height : 15 meters. Follwoing use cases are possible Archer is standing near the wall, in that case his range on horizontal will be 45. That means he can attach a unit stabding <=45 meter other side of the wall. Archer standing x (<=45) meters away from the wall. In that case he can attack any units standing 45-x meters away from the wall. Archer standing x (>45) meters away from the wall can't attack unit inside the wall. These are the core features that can be implemented. Enhancement feature: The archers visibiity range will also be modified accordingly. Example, Current scenario: any archer standing x (<=60) meters can see inside the wall. Expected Scenario: Any archer standing x (<=45) can only see inside the wall. Note: all ranges here are vision ranges, the deducation of 15 is applied to see accross the wall. Exiciting feature: The projectile to go above the wall. This is somehwat exist already. For example units attacking enemy units garsioned on wall. Similar fashion the projetiles for all ranged units will go above the wall. @Stan` @LordStark, and @Grapjas Let me know what do you think about feasibility of the solution with current supported mechanism we have in place.

There are 2 similar use cases where it can be implemented in main game as well. UC01: Bribing units Current scenario: We can bribe opponent's 1 unit but only to share vision. Expected: Select whether you want to share vision/become your unit. The resource cost for becoming unit will double of share vision. for example lets say, sharing vision cost is 100 metal, then becoming your unit will be 200, and if you bribe with 1000 metal and select become your unit, then 5 ranodm units of opponenet will become your unit. Where should it work? for initial testing purpose it can be done in diplomcay game mode. It will be very intresting to play. UC02: conquering units Game settings: Regicide & word population enabled. Exmple settings, 3 player game, word pop 450, regicide. If a player1 kills player 2 hero. All his buildings and units will be of player1, and his pop cap will rise to 300. It will intensify game play. There are other settings i have in mind but i think for starter this should be enough. Let me know your thoughts @Stan`

Context This is a fair ask. There are multiple benefits to it and a lots of players feel like this should be there. Recently i promoted coral only game play in tgs and most people are started to like it, although the one of issue with that is one mentioned above. The problem it will solve are follwoing. New players are not used to fast paced game play and they are slow in how to handle pop boom, it will help them imporve fast, hence user retention. This is an good to have feature. This will insure people will use this auto train feature more and more. It will promote coral usages It will impact user experience as whole. Like player are seeing that their batch in training progress. There are 2 solutions to above problem. First is mentioned by the @MirceaKitsune. I have some more inputs on top on how to pause the production Example Scenario: Auto queue for 5 women from civic center , currently only 150 food availble. 1. Simply don't start training the que untill you have the required resources. Here training of 5 will be 0% and wil progress only after 250 food is available. 2. or, Start the que prodution and halt at the percentage of the resource availale. Here training will be continune, as long as available resource > %training time completed * resource required. AOE like mechanism. second solution is: (Taking same example as earlier) Drop the que size to available resource. So, here the queue size will drop to 3 and that will continue, the least number it can drop to is 1. If resource available is not enough to train 1 unit then the queue will pause at 1. Why second? this is useful for continuous training of units given available resource. The player doesn't have to wait to reduce size or get resources to produce his next batch. My pick will be go for first. Extra suggestion: For new installation/new players, keep auto train by default.

This can be done by capturing in game clock time and show that time stamp along with the pause so you can capture the differece and guess how much time game is paused. But the question is, is it really needed? if so what are the use cases for it? In my opinion its not needed. Here is why. 1. most player stick around during pause untill they think they want to leave now, so they are not tracking the time limit. 2. They ususally put commnet in chat and it has time stamp in HH:MM format, through which they can guess easily. Let us know why do you think we should have pause time feature?