wraitii

While you're probably right, your system sounds to me like it would be too complicated for the very simple resource representation we have in 0 A.D.

Agreed, my idea introduces concurrence fairly nicely imo. It actually does all bar one of ffm's points: > "The more Traders you got, the higher the profit" Not technically but if you have more traders, the flow will be more continuous and it's less risky since losing one trader will cost you less. > "The further the distance between 2 markets, the higher the profit" Kept as is, since I'd give traders a multiplier based on distance. > "The higher the trade frequency to a specific region, the less gain per trip" Yes because traders steal from each other, and also because of distance. This is why I don't like the idea of a global "trade" power: if the resources are per-market, you need to trade between several markets, which reduces the "straight line" effect, increases raiding risk... > "The frequency of other traders from other regions affects the profit negative, but less with increasing distance to the competitor" Not sure I understand that one actually, but it seems too complicated. I think on the building bonuses we should go on a "trade power" bonus more than a bonus to traders as it'd feel more natural. But we can still have a somewhat high level of detail here. --- On the idea of trade power: If we go with a global "trade items" resource, we could either go global or local. Either way, I think it'd make more sense if traders carried this "trade items" as a resource, which when looted would add to your own "trade items" which you could then trade for resources. Traders would take away from your "trade items" resource and on arrival at a market exchange those for resources. But we could do it with resources directly. Edit: there is one side effect to my system: the only easy way to make it work would be that only the owner of the destination market gets the resources (though we could artificially give some back to the owner of the trade). So if another player trades with you, it's exactly the same as if you traded with them. Traders become sorta player neutral. This could be adjusted, obviously, but I sorta like it.

Okay then: 3. They are in. Some have been revised but they work. 4. Check out this wiki page: http://trac.wildfiregames.com/wiki/Manual_Settings

1. I believe currently all buildings except walls can be captured. 2. 4 Players and 300 pop will still lag a bit in the end-game, but it will be much better than before. 3. Not sure what you mean? Their aura? 4. You can still enable by hand.

Yeah but I don't see how your system is clearer than simply garrisoning units in the markets. Making champions means your eco will be lower (assuming pop cap is reached) as you'd have to kill citizen soldiers. Same mechanism, really. Also I think making citizen soldiers relevant in the late game is also up to making them efficient counter units (I'll definitely plop another thread on that later). I'm OK with a global "trade power" though, that doesn't sound too bad.

While "yes", this is why I want a minimal distance between markets (I'm thinking around 200 meters give or take 50), and also use garrisoning: multiplying markets without pop inside would be mostly useless. I get where you're coming from and you don't need to change my proposition above otherwise. You could make all markets create resources from a global "pool" between markets, or add some sort of "trade power" resource. But overall I don't think it's necessary and I don't think it's much simpler or logical. You trade between markets, it makes sense to me that this "trade power" is per market. You're just trading a tiny bit of micro (in my above description) for a huge PITA of macro. The system I described above is very limited in micro: you just garrison some workers in there, and you leave them there for the rest of the game unless your market gets destroyed. Couldn't be simpler. It's mostly intuitive, since you can just go to the market and check the creation rates out (something which is harder with a global trade power) See above with distance limits. And pop.

That's definitely what I'm envisioning: it fits the theme of city expansion, since smaller cities are more agrarian/primary sector and big cities are mort about craftsmanship and "industry" in the original sense.

No, it's Yves that is working on upgrading the renderer to use OpenGL 4. However, we plan to still maintain an OpenGL 2 rendering system in parallel.

My own background is mostly -AoE and AoK and AoM and AoE 3 -Rise of Nations -Celtic Kings -Warrior Kings -Anno 1404 -Rome Total War The two most interesting ones were Celtic Kings and Warrior Kings, which were huge commercial failures. But by far the most innovative RTS I've seen. Celtic Kings had complex food supply and very big maps, and a very RPG-like unit training and everything. Overall it was a very "out there" RTS that did a lot of stuffs differently and would probably have been super cool with formations, but it didn't have formations; and combat sucked. Warrior Kings also featured complex maintenance, RPG elements, and formations. It probably rocked, but I only ever played the demo. I believe it's the RTS closest to AOE that did formations the best, and it was a dramatic departure from AoE already. Anno obviously featured a pretty great economic aspect. I'd call it too complex, and not city-buildy enough, but there are ideas there. No real need to describe the others.

While I agree this would be an interesting feature to have to an extent, it has the problem of being tremendously slow. This is partly because our LOS code isn't the most elegant, but also because LOS in an RTS is something that is very complicated. I would like walls, mostly, to stop LOS (and arrows), but even that is very complicated. There is a reason if Age of Empires never did it. See above for "Advanced". Your "Simple" advantage might be possible, but it will be slow and difficult. I don't believe Field of View can work in the context of 0 A.D. Units can turn instantly, and there really isn't a point to it. We're not Company of Heroes. Basically all of this would lead to a ton of lag, sadly. Perhaps in the future when computers have gotten faster.

That should already be the case. See my latest post

EDIT: trac ticket.

You're missing the Athenian Marines.

Yes this is what I like about upgrading buildings: you don't have to. You can take risks. Say the first level CC is very weak: you may not upgrade it if you're just interested in making women and not techs or whatever, but if you get attacked early on you won't be able to defend. Or you can make it into a quasi-fortress if you pour enough resources in. I don't really think it'd be that much micro-management, and we don't have to make all buildings upgradable. I'm inspired for this by Tower Defense games, which I think have quite a few interesting characteristics, and also city-builders: I think 0 A.D. should be a little more about city-building. I do agree with you guys that if we keep phases, we need to separate them more and make them more interesting. There are a variety of ways of doing this, but they all end up running in a problem imo: we don't have that big of a unit roster. Most civs have between 5 and 7 different units. And start with 3 from the CC straight up. An issue with making village phase all about economy is that it's really really boring. Hunting doesn't work. Scouting is pretty darn easy with the huge LOS that units have and the territory mechanics. There's just not that much to do. The economic side of 0 A.D. just isn't that interesting, and to this day I regret that the original design wasn't waaay fancier economically. I remain unconvinced by phases. I believe they make sense in the context of games such as Rise of Nations. They had their place in Age of Empires since units really progressed (BTW this is also why AOE 3 phases felt weird to me: you didn't feel like you were advancing in ages). In 0 A.D.? I just don't think so. I kinda like the idea of allowing more specialization in gathering. It makes sense and it would give something to do beyond the early phases for economy. But we need to rethink a lot of the game for that.

Here's to another one of my random "we should remove features" ramblings. I will in this post argue for removing phases from the game entirely. Let's begin with "why phases are broken". Why phases are broken. It's really quite simple. We have 3 phases. They simply are not different enough. The second phase brings the market, the blacksmith, new CCs, and some towers which you can't really use for offensive purposes. The third basically brings fortresses. And it feels like we could just make fortresses way more expensive and have the same effect. There's not a lot of strategical finesse either: rushing isn't reliant on phases, and any other strategy is going to involve champions which means fortresses. Town phase is sort of an awkward in-between, necessary but never "enough". You really don't want to stay in town phase. Why is this worse than in other RTS? Well for one thing phases don't really make sense as they did in say AoE or RoN, where they represented huge technological advances, so you could completely upgrade units and stuff. In 0 A.D., the idea is that you're simply… having a bigger town, I guess? We don't really "unlock" that much nor upgrade our units a ton, so it all feels very forced and not really that useful. As I said, you just want fortresses, there's really no reason to stay in town phase. It's no castle age or anything. Another oddity is that they really aren't that costly compared to units and buildings. Particularly since the in-game economy tends to be super easy to boom, you quickly end up with fortress age being limited by the speed at which you build the required buildings (which can be somewhat big as you hardly need them in town phase), not by ressources. So what do we replace them with? That's of course the more difficult question. We don't want to go back to earlier alphas where the winning strategy was just to make a fortress straight-away. I see one course of action: upgrading buildings manually. You'd start with a small town council, upgradable in a town center then a town hall or something. Each time, you unlock better techs and abilities (say, batch-creating villagers, more citizen soldiers…). But those upgrades are quite costly. Same with the blacksmith. Barracks. Temple? Whatever we can think of, really. The idea is also that the top buildings, techs, and upgrades should be more costly and tied together. Can't build fortresses until eg you have upgraded your town hall enough (sorta simulating phases but differently) or you have enough barracks, or you have unlocked some tech, or you can straight away but they're sorta weak and useless until you pour more ressources in, and champions have a super long build time until you research tech. But why? This would have several adantages: it makes it way easier to diversify strategies. Want to focus on champions straight away? Well it's going to cost you a ton of ressources but if you do it properly and the opponent doesn't scout you it's game over for him. Want to trade right away? Doable. Basically it allows going way crazier. Individual upgrades of buildings also give more info on what your strategy is (particularly if we go with specialization, such as for example allowing a barracks to specialize in ranged or cav units), so that properly countering your opponent's strategy becomes more reliant on scouting. Overall I think this would be a positive change for the game, making gameplay both more unpredictable and more strategic, while also removing a completely artificial system in favor of something that makes a little more sense. The biggest drawback would be of course multiplying our art substantially.

I built it using the build-osx-libs script configured with min OSX version 10.10. I don't know if we specify and SDK when we run that script only and not the whole thing, that could be it I guess? I agree with you that we should probably try to link with our ICU though, it does not seem to need a debug version as my hack above worked just fine. Should we also upgrade libpng to 1.6.19? I tried compiling and it worked just fine.

I think threading needs to be considered mostly for two things: -short-range paths -AI The good thing is that these two problems tend to be for different game modes. The AI is mostly separate and could probably be threaded somewhat easily, but it is generally not the biggest issue in SP anymore. SP doesn't lag too badly unless you experience graphics lag, which is a separate problem. Pathfinding can still be slow, and has been somewhat designed with threading in mind. The benefit would mostly be felt in MP, where 500ms turns mean a lot of pathfinding request can accumulate, particularly short-range pathfinding requests, and lag will become important. The game will appear to freeze every 500ms which is annoying. Threading pathfinding would alleviate this effect somewhat. Another solution would be to reduce turn length in MP which would slightly decrease the pathfinding problems. Of course, we still have a lot of optimizations that can be done on the pathfinding itself, so threading should probably not be a priority.

This seems like a good solution, this code is quite old.

Critiquing greentext mode because quotes take too much space. > There were two way for this: using battalions to reduce the number of controlled entities, or automate the use. Bataillons aren't coming anytime soon. > [Your stamina system] This just can't work. If running/walking reduces stamina, it means you won't be able to win any war away from home. If just running those, why use running at all apart from the charging mechanic since distances just aren't that big? The fact can't be avoided: given our maps, it will always be better to either walk or run. > [On charging] This mostly relies on combat in formation (which realistically just isn't happening). I do agree that this could be used somewhat, for example when attacking (see my post on trac), but it's complicated and stamina isn't imo needed. > [Running] See the rest of what I mean but basically it's gamey all the way. No opinion on stances.

IMO there is no pertinent way to show information for a group of units. We should carry on doing what we do now: just show the selected units. That is true, but since the purpose of this GUI is to show information immediately without having to use a tooltip, I don't think it's really an issue.

Yes, this is basically my idea. I don't think we really need to remove it entirely to "show more of the map" though, our GUI isn't that big and screens are today, even on laptops. I do agree that it's quite a bit of work, but we could determine 2/3 basic states for the beginning and try it out. We don't have to have contextual info for everything, but a few simple distinctions would help. Consider champions that can't gather: there is literally no reason for their armor and attack stat to be hidden behind a tooltip. The way I see it there are three things to consider to determine what info to show: -What unit is selected. Some won't be able to attack, some have packing/unpacking, some trade... -What action is being taken (ie where the cursor is). If its nothing in particular, what should we show as a default state? This probably depends most on the unit type (on a trader, show trade amount,..) -What is happening around the unit selected. If the units are being attacked or if there are enemy around, it is probably worth showing attack/armor information by default. The question becomes trickier when you combine it with the cursor position: should we show gathering stats if a unit is being attacked but you hover over a resource? I'd say yes for consistency, and since you have the health bar already. For the cases where you need a lot of info/comprehensive view of the unit, imo a button that pops up an overlay that shows everything cleanly (possibly taking a lot of place on-screen) can't be beat: it's faster than a tooltip, it's clearer since you have more room, it's consistent across all units...

I think a big part of the problem is that we have too much information to show it all at any time. But I disagree that the proper choice is to hide it away and just show an arbitrary subset of "basic" information. We should have a simple, small button (a question mark?) on the unit that immediately opens an overlay (somewhere on the screen) which shows most/all stats in a clear, simple presentation. This is doable. You could use in-game to get all information you want, and you could also pause the game to get more information by scrolling (works as an encyclopedia like in AoM). However the information that we need to show to the user at any given time are highly dependent on context. I think this is what we need to work on to make a GUI that makes sense in context: if we are selecting a citizen soldier, and we are moving our cursor over a resource, the GUI should display pertinent, easy to read data on resource gathering: the rate for this resource, how useful it is compared to other units of the same civ, other unit's auras that could affect this. We could show something like this: We may not even need the capture and health bar in the unit GUI (though it needs to be on-screen) unless the unit is being attacked/there is an enemy nearby. It's useless info.In a context where a unit is being attacked, we need a simple way to show Health, capture if needed, then attack and armor stat. The important thing is that the rules are consistent and easy to understand. In my opinion, if you have to get a tooltip, we have already hidden information too far away. Tooltips should be helpers for things that are never actually needed/you can figure out yourself easily (for example the tooltip on foundations that tells you how much it would help to add a new builder. You can usually deduce this yourself by the number of workers: it's mostly useless info but you may want to access it sometimes) We can put non-contextual info such as whether a unit is carrying a resource somewhere with a rather small icon; it's not generally the information you're most looking for. This may however require us to reduce the space dedicated to unit name.

Just tried recompiling spidermonkey from scratch (it had been a while, I sitll had 1.8.5 source and it literally took 5GB of my HDD), and I ran into an error: the ICU compilation failed. Now since on OSX we compile ICU anyways (and it works), my solution was to pass --with-system-icu and export the patch to pkg_config. Which seemed to work. Did I do something wrong or has it broken recently? Also I tried compiling with trace logging, and it turns out <endian.h> on OSX doesn't define the proper stuff so you need something like this included.

I've tried some things with palisades and walls, without regards for other stuff. Some metagame comments first: -It may very well be too easy to defend in the early game but that is not because palisades are too cheap or anything. It's imo because CCs have too big a range and too many arrows when garrisoned, and garrisoning is too quick since units move too fast to do real damage when raiding, as villagers are too strong. Women really ought to be a glass cannon for resources. -Palisades should be quick to set up, relatively dirt cheap, and relatively easy to destroy with a good enough force. Their aim is to stop raids in some parts of the map in the early game, not turtle. -Walls should imo be slow to build and very resilient except against siege units. Cost seems mostly good right now: they're expensive, but not insanely so. They should be useful to completely wall yourself in, or to completely block a pass or something, particularly when they are well defended (towers garrisoned and units on wall). But since walls don't block arrows, nor defense tower arrows, this makes them slightly OP right now. That being said, I've changed palisades to be slightly cheaper and faster to build, while making them less resilient, particularly to hack attacks. This means you can set them up quickly but 10 spearmen or 5 swordsmen will do a quick job of opening a wall. However it should stop archers pretty well (except for the range thing, again) Stone walls I've made slower to build, but slightly cheaper. I've made them basically impervious to pierce attacks, and quite strong against hack attacks. This means a defended wall should mostly hold its own against melee units, even buffed champion swordsmen (it would probably take 30 at least to go through). However crush weapons such as rams make a quick job of those walls, even the Carthaginian ones. I'll probably commit that change after A19.

Starting a discussion on how we could improve 0 A.D.'s interface for visualizing unit stats at a glance. AOE2 had a simple system that did this very well, 0 A.D. doesn't. I'm waiting on your thoughts on this subject. I have on idea in particular, though, that I really think we should implement: remove HP count, and replace it by an "HP-armour equivalent" that would simply display how much HP this unit has against a particular attack type. This is because our armor stats make HP mostly irrelevant to actual strength, the real question is "how much of a beating can they take". For example a structure of 2000HP is very resistant against pierce (let's say 80%). Currently you can see that. But it's not obvious that this makes it as strong than a 4000HP structure with a 40% resistance. If we had a representation that was "HP against hack: 3000HP, HP against pierce: 10 000HP, HP against crush: 2000HP", it would make comparing units much, much easier.