wraitii

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.

I believe we already have libraries to do memory pooling (and indeed, do in a bunch of places). We probably need to work on it, but the underlying stuff is there I think.

WhiteTreePaladin: could you post the commands.txt to that game? That could be more of an AI issue.

Those sound like very interesting MP maps.

Thanks for the comments Alex Yeah basically my idea would be a full revamp, so basically destroying your enemy would be a combination of raiding their supplies (if they're unprotected and you can find them), harassing, and actual sieging when you've built a big enough army.

Auras are kind of the "I like this game, but I'd like it better if it lagged just a bit more" components of this game. But it's pretty nice work overall

Imo it's a bug to do anything else. Components should not rely on other components being there unless it makes complete sense (e.g. Armour requiring Health).

I just saw this animation on Reddit: https://gfycat.com/SpiritedWarmFattaileddunnart , from this conversation here. I figured it was the coolest thing i've ever seen and that we could use the idea to revamp the splash screens in our trailers, which are currently this: There's a variety of ways this could go, but I thought it'd be a good idea to at least share the animation if someone is feeling inspired.

This is an idea I've had from reading /r/SubredditSimulator, a subreddit where bots post content using Markov chains. I've been giving it some thinking and I thought I'd share it. I don't have yet anything to show for it as I'm unable to code at the moment, but might try it later. The idea is quite simple: let's use some sort of markov Chains to make our random maps nicer. The biggest problems in our random maps, in terms of niceness, is not so much the larger elements (such as continent shape, ...) but the finer details. It just looks too random quite often, compared to scenarios. My idea is simply to use markov chains to replicate those scenario achievements in random maps. I won't go into details on markov chains (google it), but basically the idea would be to analyze scenarios of a similar biome (or may only one map, if it's good enough. Fiddling with the data would be needed.), and then use this as a database in a "beautification" pass for random maps. So RM would still create the maps as we do know, put terrains as we do know, then add basic "necessary" entities, such as trees, player entities, and could also add some larger beautification elements. Then we'd go into a beautification pass. I see a few ways this could work: For each "important" entity, check what "decoration" entities are usually placed around (from the markov chains) and place those.For each terrain type, check which decoration entities can be found aroundPossibly this would require us to "pre-sort" important entities by checking how many important entities they have around (as you might place different stuff around a lone tree than in a forest), but this would have to be checked. It might be extended to actual terrains too, to make it easier to have nice transitions, but I'm not entirely sure it'd work so well. Just an idea, anyways.