wraitii

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.

I think cavalry archers should be more expensive, they are too efficient in the early game as they are very hard to counter except with more cavalry archers. Perhaps a tech to reduce their range until the town phase? Another thing is walls and palisades, which are imo waaay too expensive, given their limitations: cannot stop LOS, cannot stop arrows, need to be built in territory. Since we also cannot build towers close to each other, it is very difficult to efficiently protect a dropsite or close an area off in the early game. And building a small palisade wall costs a TON of wood. Actual walls are probably too expensive too, but I never tried them. Another possibility would be to allow placing wall foundations out of territory, but only allow building if they are in territory, and make walls expand territory. So you could actually build a wall beyond your territory, but it would rightfully be somewhat expensive (though walls are imo still too expensive).

Hello gameboy, thanks for this report, I understand what the problem was. Sadly it seems like it will be difficult to fix, I will try, but it might be for A20.

I think for our game's detail FXAA is slightly too on the blurry side. We have many very small details everywhere that get blurred. SMAA looks like it would fit us better indeed.

That's always been one of Age of Empires' strongest point and it's good to see they've kept it.

No that's something else stan. Nikagra you may want to get in touch with Yves who is currently rewriting the renderer to use OpenGL 4+, if you run into such issues. As far as understanding our current code goes, I think Yves, Philip (on IRC) and myself would be the most knowledeable. Thanks for your interest!

We do actually somewhat need gldrawinstanced to improve on what we have now. Also we have very little texture atlasing, in particular for stuffs such as bushes. In general I think the engine should be able to do better on instancing by being clever about things, not by raw openGL techniques. LOD would be useful in some edge cases, such as when the camera is rotated to look super low. In particular, the cinematic camera could really use it. I think it would be a more useful feature to have higher-res meshes that rarely get used, more than lower-res meshes though. I think a bigger improvement would be to cull objects that are too small at a distance, but that would take some fine tuning.

Bumping, might be interesting to reconsider this, i'm sure we could special case the entity the unit is inside in some situations.

This is a great find, thanks Lion.Kanzen. I do believe this is something we might have not followed enough on some buildings.

Graphical options are currently a complete mess. My personal opinion is that if users want to get advanced, they should go to the config file. Otherwise, a "very fast-fast-nice-beautiful" setting (possibly with more than 4 levels, and possibly a few different bars for a few different things) should be enough. On the technical side, options are even uglier. It's absolutely the ugliest code in the game. Finally I do agree that most of our menus fall in the "open-source" conception of a menu: you can find everything, and you better know what it refers to.

I've found this very interesting series of article on Reddit: it dissects how GTA 5 renders a scene. I wanted to highlight some differences with 0 A.D. http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/ http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study-part-2/ http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study-part-3/ Now obviously GTA 5 uses deferred rendering, which isn't entirely possible for us so far because we support older OpenGL. It doesn't change much, except it makes it much easier to support many lights, something which could be interesting. In part 1, one thing to notice is the use of LOD, and more importantly the huge amount of instancing: the number of draw calls to render the scene is about 1900. We in 0 A.D. are quite regularly above those numbers on much "simpler" scenes. In part 2, it explains how they actually swapped a hill with models on it for a single model to reduce draw calls. On the other hand, it seems like GTA has found no better way than us to render the ocean, or indeed even reflections on the swimming pool.

We hope to have the release done in November, though no exact date is planned. Most of the remaining bugs are assumed fixed, we are now testing to verify those assumptions.