wraitii

Hello Lion, this is a known issue. The way we want to fix it is by implement scrolling, but we haven't so far. Thanks for reporting anyhow!

My opinion on the trade vs resources debate: I agree that resources should be faster when they are still present. However, I also believe they should be faster given equal technological investment, ie upgraded trading might be faster than basic resource collecting, but not upgraded resource collecting. I also believe that trading should be able to replace resource gathering somewhat efficiently when resources are depleted so that the game doesn't slow to a complete crawl. Finally, with that particular implementation, I think it might be worth it to have a civilization where trading might get more interesting than gathering overall for some resources not necessarily all of them though), for example the Persians, which are supposed to be a trading-strong civ (in SVN they get 25% more from their traders, here their markets are 25% more efficient). So say maybe for Persians, they don't have access to the best (say) metal gathering techs, but trading can compensate. Also worth noting is that trading rate currently depends on your trade preferences, which may or may not be a good idea, because if you focus entirely on one resource, you will get a much better rate. Perhaps players should no longer be able to determine what resources they want to gain from trading? I do agree that it would be interesting if players could raid markets, but it would require quite a lot of changes. In the meantime, perhaps markets should ungarrison units even when only slightly damaged or captured.

Uploaded an updated patch to a trac ticket.

Most of the team (at least those who played a bit) agree that the current "champs only" win strategy is boring as hell. We're looking at ways to change it.

Attached is a mod that implements (to an extent) my "context-sensitive GUI" idea. You'll find a few differences with SVN: -Garrisoned units appear in a new panel on the top left part of the GUI (similar to the production queue), leaving more room. -Commands are now in the left panel. -The "raise alarm" icons are now commands -The Middle area has been changed to feature the two most common armor types -There is a new context-sensitive row in the middle -The "identity" zone was made slightly bigger so you can see more of your unit badge. Overall I think the system works rather well. Obviously there are no tooltips yet, which would give more info, and I'd like to make it so that clicking on the unit icon opens a complete description (there's a ticket for that on Trac). But it will give you a feel of how it could work. GUIMod.zip

I agree with wow on that, it's pretty easy. Plus the GUI is super obvious about this.

I see where you're coming from with this Yves, but your approach has a number of technical issues and isn't necessarily more obvious. I think it mostly comes down to an interface problem - that can be fixed - and the fact that it's not the same as in AoK, but the system isn't difficult to understand and I think with a simple tutorial it'd work just fine. The tying of CCs with markets is mostly an artifice because allowing a player to have a ton of markets may be a little gamebreaky but I'd need to check that.

The tech web concept is definitely interesting, but I fear it may be slightly too complicated for our interface unless we get a lot more screen space. Something to think about. There are a few problems with making phase upgrade city-centre-centered, namely I can think of: -The local vs global upgrade problem: it would be a little weird if buildings upgrade locally but, say, blacksmith upgrades are global. -The use of territories: would they have any? -Scale: it might be a little odd if you can build a huge stone Tower and 100 meters next to it only a wooden tower because it's somewhat arbitrarily attached to another city.

Had a better idea, so I changed the mod. Previous idea wasn't very elegant after all. New version, partly inspired by ffm's comments: -Markets generate income. -Markets garrisoned with workers generate more income (ungarrisoned markets only have 20% efficiency). -Markets generate income based on "connections" with other markets. -Traders increase this "connection". -You can only build one market per CC. Basically the way it works is that traders link markets together, and the more markets a market is linked with, the higher its efficiency. This means you don't need 100 traders, you need between ⅔ and about 10 for the most distant markets to keep a full connection at all time. This is also modulated by distance: the efficiency bonus from a connection depends on distance (specifically, I'm using the log of the distance/100). This means that it's better to trade with far away markets, but moving them 10 meters from one another won't change much. Another modulation is that for each market, the total efficiency is sqrt-ed. Ie the more markets you are connected to, the higher your efficiency, but there are diminishing returns. It's quickly better to make another market and connect that one than focus solely on one market. The effect overall is that: -You need more markets. -You need a "web" of connections and not a straight line. -You need fewer traders but more workers so the overall pop is the same. The good thing is also that the income rate is very easy to manage and control. There's also plenty of opportunity for technologies: traders could increase the connection more/go faster, so that you need even fewer, markets could leverage efficiency better… Please try it, I think you'll agree with me that it's a much much better idea. Note that I probably broke naval trade but that's not a big issue. TradeModv2.zip

I agree that it's not tooo different from what you did in Sibyllae Vox, I think there are two big differences between the approach I'd take and yours: -I'd make cav weaker than infantry. The idea is that Cav is for charging. -It makes champion swordsman and champion spearmen mostly the same units, allowing them to always be the bulk of a strong army. I do believe champions should be the "way to win" in general, and not just a particularly strong unit. However you don't really get another option right now because buildings are pretty much too difficult for citizen soldiers to capture or tear down. I think part of the reason why is that garrisoning is a little too efficient, and too used as a mechanism in 0 A.D. in general. In a mod I'm working on I'm currently making champions have about 3 times the attack and 2 times the resistance (same HP, higher armor), but I think their HP should be bump-able by tech (I'm also slowly starting to think of techs). So basically yes they are no match for citizen soldiers. They are very costly units though, so they're not really as cost-effective as it seems. I think the progression should go: -first 15-20 minutes battles with citizen soldiers, where hard counters are more possible so you can't just insta-win. But winning then needs to be possible, and in 0 A.D. right now it's kinda hard. -Champions would come into play slowly, it should take some time to get a sizable army (and a few champs won't be a match for ranged units). -in parallel you could research technology to make your citizen soldiers better counter units. I don't think all civs should have the possibility of improving all citizen soldiers, though. Fully upgraded, you might end up with units that are more cost-effective than champions, but the pop cap makes champions attractive. It's also a bit of a choice between champions and upgraded CS, so we should probably try to differentiate on that

This is probably the time it takes to compute a turn, which "hangs" for a bit every 500 ms in multiplayer. I'd suggest not using AIs in multiplayer to alleviate the issue.

I don't remember this tech web discussion, probably missed it while I was gone. Do you have a link? It sounds interesting. I'm not going to argue against the fact that our techs are uninspired, though. That's just a fact.

The roles you outlined for units are accurate, but imo they are too different. The core issue in 0 A.D. is that most civilizations have vastly different unit rosters (see attached image). You also need to consider the champion/citizen soldier dichotomy. All civs have spearmen. Not all civs have champion spearmen. Here are the viable rolues imo, assuming we'll get charging someday, and not relying on formations particularly. CS = citizen soldier. CS Spearman/Pikeman: cannon fodder, somewhat useful against cavalry charges and cavalry units. Pikeman a bit more general purpose (because Mace has no spearmen). CS Swordsmen: more agile, slightly stronger, not really good against charging cavalry but will tear down non-charging cav. So pretty much the same unit but slightly better at raiding. CS Ranged: Most civs have javs (except mauryans), but not all have archers. I'd say they should have mostly the same role, with javelineers being more powerful but much riskier since they'd have a much lower range. As ranged units, they would be absolutely destroyed by any melee unit, but should deal reasonable damage to unprotected units, including champions. Basically the idea is that having ranged units tips the balance in your favor. The CS cavalry javelinist should be OK-ish at raiding and that's it. More of a scout. The CS melee cav (either sword or spear) should be useful to have a cheap mobile force that can target ranged units, but should never get into real combat. Maybe some light raiding. I don't think they should really be able to charge, or not super efficiently. Champion melee: both spearmen and swordsmen champion units would serve the same role: be a general-purpose good army unit. I think the dichotomy from the CS can be somewhat kept, but under no circumstances should champion swordsmen really be too vulnerable to cavalry charges, or civs that have champion swordsmen (gauls, brits) will get absolutely torn down when facing the civs with cavalry champs. The next two roles would be more niche-roles, but you'd still want them. Champion Melee Cav: They would be countered by melee infantry, which is a problem. I think they should have the role of highly expansive, "joker" units that have an absolutely devastating charge but not much more use beyond that. A very strategic unit that would have one shot at tipping the scale of a battle in your favor if used at the right time, but get completely mauled down otherwise. Champion archers should probably be glass cannons, compensating for a weaker base infantry. And have a sniper role. These however would be quite strategy-dependant: Champion cavalry archers imo should mostly be great raiding units (and I mean great) but circumstancial, they'd require your opponent's base to be somewhat open. Not sure if we have champion cavalry javelinists except for the Iberian "siege cav", which is again circumstancial. Slingers are an odd case. I agree with Karamel that making them longest-ranged makes sense. I think we should use them so that they become somewhat useful to bring down infantry units from a distance despite their protection (since the crush damage should go through armor - which it doesn't right now), and help against buildings and other things since the civs that have slingers are usually weaker in the siege department. But I'd make them less mobile. And a very poor accuracy. So really more of a siege helper with a slight support ability on the side. I would add that citizen soldiers would by default be quite rubbish, but upgrading them to elite status should make them somewhat cost-efficient options against their counters. The rock-paper-scissors would go, for both CS and champions. Melee Inf > Melee Cav > Ranged Inf > Melee Inf (as support). However cavalry charging into engaged melee infantry should be quite efficient to make it a viable tactic - we don't need formations for that. Melee champions should be much stronger, which makes them the core of late-game armies. However I think they should be slower to build than they are now, to make them rarer. In combat, having unsupported champions should also be somewhat easily counterable: having ranged units, some CS melee inf to hold them and a simple cavalry charge should make short work of them. This dynamic doesn't really exist right now as champions are just waaay too tanky and mobile. But this is very reliant on population caps. On top of that we'd have a few units with a different role intersecting in there. Then on top of that we could add some civilization specializations. Some shielded units should have higher base pierce armor making archers or other ranged units less useful against them. Some civs would have army comp that make them more archer+melee or cav+melee. Some civilizations might have citizen soldiers that become viable units on their own with upgrades, I dunno. I think we need to completely change where units get trained and how they get upgraded and stuff, too.

There's a ticket for that. http://trac.wildfiregames.com/ticket/3668

I don't really think anyone is going to disagree with you here, you're covering every existing base. But a "phase growth" technology is imo a super weak way of representing settlement growth. Like literally the worst way you could do this. Even a super simple where you'd need a number of buildings or a certain villager pop to unlock buildings would work much better. The issue of whether techs are interesting is separate, and I do disagree with how you handle tech pairs. I'd like to reintroduce them, but I'm not sure how, haven't given it much thought.

I support the idea.

Made a small mod with the changes to the trading mostly following my own idea. There were a few issues with my original idea (mostly some players could be left out in cases multiple players traded). In the mod — simply enable in the in-game manager — trader will move around "trade goods", a new local resource. This resource is stored in each markets, and markets convert this resource into the actual in-game resources at a fixed rate. This rate is exceedingly slow in the beginning, you must garrison workers (females or citizen soldiers) inside to improve it. However, even full, it remains fairly slow, I think you'd need a few markets to get acceptable income. Obviously those values should be tweaked and techs would play a part, I haven't changed those. Have implemented a distance limit between markets of 160. Not sure what to do of docks. You will notice that trader goods are a very low value: this is because the consumption rate of markets is quite low. The formula I'm using is of the type "Log x + x" so markets that are too close to each other won't give any resources, but distance isn't a huuuge advantage either. Trading with allies is better. You probably won't need more than 5 traders at any rate. Merchant Ships carry twice as much as traders for the same distance, so you can make fewer of them, and docks don't improve when garrisoned but have a higher base ratio. Garrisoning traders in a merchant ship no longer does anything. I haven't completely revamped the GUI but you can see the trade stock in your markets/docks and the tooltip tells you the rate. It follows your global settings otherwise. TradeMod.zip

I agree that capturing siege rams is usually the best option. I think the main problem is that it is not immediately obvious who owns a ram, so sometimes your rams get captured and they stop attacking adn you don't understand why.

I'd like to point out I suggested that in my opening post. I completely agree that it would be an interesting experiment.

Well that's certainly an upgrade. It's in the cache which you cna find here: http://trac.wildfiregames.com/wiki/GameDataPaths

I'm not entirely certain but I believe you might need prefer_glsl to be true.

Hey Mikita, I review your patch on Trac.

If you post your texture (and the cached version in-game) I might be able to tell you what goes wrong.

Are you sure your alpha textures use the full grayscale range? If those renders are in-game, this might also have something to do with the fact that alpha values below 0.5 ( out of 1 ) are scrapped iirc when rendering the basic non alpha-blended pass. Compare your alpha and the alpha of in-game textures, the difference should be obvious

Fog with the isometric view would basically be impossible in the current implementation, sadly.