wraitii

Agreed. Looks just a little thin to me, but otherwise it seems like it will look pretty good. Recommend you use "set smooth" in Blender to get a better approximation of the end result, though I think you need to remove it to export the collada files.

Aegis is in a state where if you let it play, it's reasonably skilled. On "Medium", I believe, it doesn't cheat. hard/very hard make it collect more ressource, easy make it collect less, and there are a few other changes too (I'm pretty sure it starts attacking later and builds fewer military buildings so it recruits units slower. Not sure about different army sizes though). Work on AI is very much still planned, however, but progress is stalled right now (I'm mostly doing it and I'm focusing on something else). Aegis can be overwhelming for a beginner player. I suggest playing very easy until you feel more at ease with the game. It's not really too hard to defeat once you get to know it.

I think we already model-swap airplanes between air and ground mode. I would suggest adding an "multiterrain" component of some sort that would specify how to handle air-land, land-water or air-water transitions (same model? What template animated transition?)

This is sort I a side request but I'd like it if the animation guide was going into slightly more details. I have tried and failed to load an animated mesh into 0 ad and it's really hard to figure out why. Anyway, good job! I'd like to see the Nile crocodile myself, looks like it could fit some maps

From my experience, in our genre, more is usually better. There are two reasons not to have more civilizations: -if two civs are really similar (gameplay-wise mostly), they could be scrapped. -if it introduces unbalancing. Right now I do not think we have the first issue. Beyond art beeing fairly different, the "sister" civs play slightly differently ( most notably the Greeks) which is welcome as it offers more playstyles. As for the second one, it's mostly ok. Given historical accuracy constraints, I think 12 is a really good number already, and it keeps things interesting.

Do note though that if you can without much loss of detail reduce the number of triangles, you should try, it will be faster (ever so slightly) to render

I think that's a fair aim. If there is any indication that esr24 will not be too different from v22, I say go for it. Multithreading and stricter compiling are two very good points imo.

I'd agree with historic Bruno. If it seems like we can't really get more out of v17, then we should not upgrade at all. But if we can get more from v22, then it's interesting, even of right now potentially buggy. At the very least, your work wouldn't be most and could serve a a framework for a future upgrade once it's stable

I think it's a planned feature that never got implemented, but still should be someday.

I think the issue is that it's in the C++. But CcmpVision handles technologies already. Using the exact same stuff, here's a patch that appears to be working for that (just create a tech and try it). However I'm not sure if that resists serialization (which could bug in Vision too). Also in that component there's walkspeed, runspeed, and "speed", which seems to alternate between both and I'm not really sure what it means. UnitMotionTech.patch

Interesting bottleneck you found here. And great work so far, it's been a very interesting read!

I think if someone is willing to take the time, having the pathfinder as a separate library could be interesting in regards to "this could help the rest of the free gaming community, and probably more". Discussions about pathfinder are however usually fairly sterile, because there is a huge difference between theory and reality in that aspect. Crowd stuffs could be interesting, particularly as your description makes them "simple enough". It seems to me that pathfinding in RTS could use 4 steps: -Accessibility checks: as far as we know (we being the unit that moves), is the target accessible or is it not? If inconclusive, assume it is. Philip had implemented that with squares that were connected to each other. (I personally implemented that in JS for the AI using a flood-fill that's never updated after game start.) -Long-range pathfinder. Returns a few waypoints for avoiding big obstacles. This can also be set up to avoid forests, coasts, stuffs like that. That's the thing I JS-coded in the AI and that is inefficient there (also because it's fairly unoptimized. It's fast enough only because I downscale the map by a factor of 3). I believe that's were A* + JPS shines. -short-range pathfinder: get the path to X, where X isn't far away. And on top of that, we could add some crowd stuff in case there are many units around to make movements more fluid. This might make units slightly lose track or where they want to go, but with proper tweaking (and some units perhaps stopping), I'm sure it would get efficient enough. But it means work. Lots of annoying work, as pathfinding never really works properly. As for formations, I think the theory was that they would resort to snaking in a column (fairly un-cohesive) if moving over long distance, mostly eliminating the issue of rigid formations getting stuck but leading to some pain with short-range pathfinding (this is where crowd movements might be able to shine). Then as they get in formation, they should basically be treated as one big unit. Individual movement in those cases could probably be made simple enough to handle rotation and a few other cases (turning around, turning 90° right…) That's how I see it. With crowd movements, perhaps (only speculating here), if we add buildings to them, we could have a fairly imprecise short-range pathfinder just to avoid getting stuck in a few edge cases (such as having to make a u-turn to get around an obstacle). Tuan Kuranes: am I right in believing that crowd techniques basically loop over units and adjust their orientation each frame (or about each frame perhaps)? (and secondly: are you French?)

I think this is a known issue with the wall placement things, which is (as you noticed) not too easy to fix. It is something that's on the To-do list of things to fix, though. I'm not sure I understand your idea of gradient walls. Do you mean an automatic tool to create walls at a given height around a hill?

We could allow to upgrade palisades by simply having a button that removes the palisade and places stone walls in the exact same position. Would avoid having to destroy+replace.

Is there somewhere a description for that (and if not, could you describe what you mean)? Seems like it shouldn't be too long to do.

We need to consider performance though. If we go the whole way, a batch of archers firing might just slow the game down too much (unless using some stuffs like what Philip designed on his new long-range pathfinder this can be checked easily). Dynamically creating a 2D map for each unit is, imo, too slow, particularly as it would require a range query or more for each unit/formation.

So far, we have exponential armor and blacksmith (WIP), right? I think the multiplayer lobby also got a huge step forward, what's the progress report on that? I also think trample damage is worked upon. If all those got finished, we'd probably have a decent A14 already.

Exactly. Basically it handles a lot of maps in one go, and JS is not exactly perfect to do that. I'm considering switching some stuffs to c++ as part of improving the AI. I want however to be sure that the added cost of memory transfers are not bigger than the increase in computation speed.

That function should be disregarded when profiling. It does big 2D image manipulations that really shouldn't be done in JS in one turn. I'll try to find a way to even that one out whenever I can.

Tuan kuranes: that's pretty spot on. I'll just add that right now getinrange sorts the unit for no really good reason(in some cases), and a speed up can be obtained from removing that (though that could be linked with returning duplicates, which for rendering might or might not be annoying). One thing though: your idea about frustum culling could lead to trees or tall objects popping up in front of the camera, which is bad.

Should have made myself clearer: I meant a quadtree with a final "top/bottom" branching, for stuffs that are only near the ground. This could be useful for refraction/reflection culling for the water, for example, and in a few odd cases. Not too interesting, I have to admit. Frustum culling is currently done by checking the bounding box of every renderable model against the frustum, afaik.

I wouldn't rule it out. If it's not too expensive (I'm speaking CPU-wise here), we could use it to have better frustrum cullings (such as removing bushes that can't be seen but not big trees or something). It would probably need to be slightly clever, though. And it'd indeed be nice to have. But if it leads to a somewhat significant slowdown, then scrap it.

We do use a basic subdivision system (not a quadtree because we don't navigate nodes, we directly access the right square using a vector, I believe) for notably the range manager and the obstruction/path finding managers. It's somewhat efficient, though there are inefficiencies that Could be fixed. The problem is that each manager keeps his own and the simulation as a whole doesn't, when it really should. I'd advise looking at the obstruction implementation: it keeps static objects (no need to update them) and moving objects (need to be updated at a cost). The game can use events for updates. Overall, a new quadtree/octree ( I'm thinking it wouldnt cost muuuuch to make it an octree, not sure it has a point though) would need to be owned by the simulation (perhaps a manager) and shared for all stuffs that could use it, in particular the renderer for frustum calls.

I think you get artifacts because you consider points and not surfaces, which is what you actually ought to consider. Diagonal points can make a lot of difference in the water flow, and this is probably where your results are wrong. Your current implementation simulates constant raining, which should give a good enough result but would be better if you kept the water map over every frame, I think (twist it though, because given your algorithm it would be much too strong. You'd need to lower the strength). In that case, you need to lose some water (multiply WaterFlow by an arbitrary constant). For the rest, seems good.

The basque words sounds like a Basquization of the roman word, though, so I'd advise using something else.