wraitii

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.

In fact, most old school RTS and their successors can be said "time-management" games. Multiplayer in AOE was about who was the fastest (all other things being equal). Same deal in Starcraft, same deal in most RTS in fact (there's this quote by a dev of Command and Conquer: "A player controls hundreds of units, dozens of buildings and many different events that are all happening simultaneously. There is only one player, and he can only pay attention to one thing at a time. Expert players can quickly flip between many different tasks, while casual gamers have more problems with this.” The only way to make an RTS that's not a clickfest is to remove this need for time management, which is probably why a lot of the more strategy-focused games are turn by turn to some extent. My only idea on how to do it in a game like 0 A.D. right now is to upscale the map by a factor of 50.

I've given this some more thoughts, and I'm convinced that a good way forward would be to scale everything up, including time. It'd play out more like SimCity, with some basic actions taken and then a lot of fast-forwarding. With support for some sort of supply lines and seasons. With seasons things can get really interesting strategically, and it helps make the game not too boring at any time. A gameplay that's more automatic, like some sort of huge-scale Caesar game, but where you can give a lot of input on a lot of things if you want. Basically make it a game about supply lines with real season support and things will get interesting. But really I'm also quite convinced that it's nowhere near being possible with the speed of current computers. It would require too much dialing down.

Looking pretty good, I must say. With a bit of work we might be able to put together a simple intro video using this.

I think your stone tower example would work better with individual upgrading and an option to ugprade all. But I agree that it might be useful.

I think you could improve the look of your oceans a bit. On your first map I'd increase the murkiness a bit and use a slightly more natural color for the deep water. On your second map I would also tweak the color and reduce the waviness.

Note that our AI is almost purely javascript and fairly documented so it's quite readable code, for an AI.