wraitii

The V3 API (uncommitted) does go up in phases though. So progress is not as stalled as it seems. This is indeed one of the areas where the AI will be improved.

I'm getting this error against 10.7 using the bundle maker: Undefined symbols for architecture x86_64: "_iconv", referenced from: wxMBConv_iconv::wxMBConv_iconv(char const*) in libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::ToWChar(wchar_t*, unsigned long, char const*, unsigned long) const in libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) const in libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::GetMBNulLen() const in libwx_baseu-2.9.a(baselib_strconv.o) (maybe you meant: __ZN14wxMBConv_iconvD0Ev, __ZN14wxMBConv_iconvD1Ev , __ZN14wxMBConv_iconvD2Ev , __ZTV14wxMBConv_iconv , __ZN14wxMBConv_iconvC1EPKc , __ZN14wxMBConv_iconvC2EPKc , __ZTS14wxMBConv_iconv , __ZTI14wxMBConv_iconv , __ZNK14wxMBConv_iconv5CloneEv , __ZNK14wxMBConv_iconv11GetMBNulLenEv , __ZN14wxMBConv_iconv14ms_wcNeedsSwapE , __ZN14wxMBConv_iconv16ms_wcCharsetNameE , __ZNK14wxMBConv_iconv9FromWCharEPcmPKwm , __ZNK14wxMBConv_iconv7ToWCharEPwmPKcm , __Z18new_wxMBConv_iconvPKc ) "_iconv_close", referenced from: wxMBConv_iconv::~wxMBConv_iconv() in libwx_baseu-2.9.a(baselib_strconv.o) "_iconv_open", referenced from: wxMBConv_iconv::wxMBConv_iconv(char const*) in libwx_baseu-2.9.a(baselib_strconv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [../../../binaries/system/libAtlasUI.dylib] Error 1 make: *** [AtlasUI] Error 2 make: *** Waiting for unfinished jobs.... (I'm compiling with Clang but I'm also getting it with Gcc). The other path works just fine.

It looks pretty good. Quite a sturdy warship so the swords and things like that don't seem like that big of a problem. It feels kind of un-intimidating though, which may or may not be an issue.

I believe this was discussed and agreed upon at some point, but it has not been implemented (at all) now.

Ah. Then I believe the word bad accurately describes this situation. Though then again 4 Aegis at 200 units is not exactly fast right now...

Certainly. 40ms alone seems a lot though, I assume debugging slows things down slightly.

Hm, I have hardly any accurate data to give you on that topic right now, it'd require testing and stuffs like that... I do believe, from my testings when trying to lower the AI memory heap, that there is a problem of memory cluttering because of the simulation state update. Memory is allocated to it, and never really deleted until GC. And this is quite expansive, memory-wise (probably too much, there are certainly issues there, but lacking proper debugging tools, it was hard to tell). I'm not too sure why Aegis is much worse than qBot, but there are probably even more stuffs being created regularly, so it's not that surprising. Reducing the amount of times GC has to be executed is therefore linked to the amount of "memory creation" every frame which is kind of out of control right now (lack of debugging tool, and I must say also lack of care, at least on my part), and the fact that since it's bloating so fast, and the heap is quite low, it needs to be run often to avoid going OOM. I'm not sure if it's faster to run the GC regularly with a small heap, or once in a while with a big heap (thus a slower GC, perhaps?)

Intrusive might not be the right word. What I mean is that adding a phase indicator to every icon kind of clutters the GUI, making it not necessarily harder to read but at the very least feel less clean. If it can be avoided, I'd like it as much. My opinion is that a single mark per phase, in the top left of the icon of the first building in that phase, is both informative enough and not too clutter-y. This however requires sorting the icons per phase, I dunno if they already are.

I find it fairly intrusive too. Perhaps a simpler solution would be to sort the icons by phase, and then only show a number for the first building in each phase/mark the separation with a line or something. I believe this info should be available without going in a tutorial since with many civs, this gets tedious.

Unless there is a specific civ for which this would mean an overflow, I support the idea.

FYI: using the new xcode 4 projects, SVN compiled nicely without any issue on my repo. The only problem (already there before) is that you have to manually change all the "build schemes" to release if you don't want to play in debug mode.

Just to give another idea: how about a "global experience" sort of mechanism. The more you fight, the stronger all your citizen soldiers are and the slower they gather. This would automatically make the game slow down as time goes by.

I don't mind the slower growth (as long as it doesn't get boring. The beginning is a bit lacking in that aspect. Perhaps scouting could be made more important or something) . It's the fact that it suddenly goes in overdrive (and pureon is right) that's problematic. Perhaps the solution is actually slowing down the late game. Making buildings costlier, units less efficient/costlier/longer to train. Perhaps most tech could lengthen the training time, making for an interesting possibility for tech pairs or something. Perhaps smaller skirmish should be favored in the mid game (15-25 minutes on) before actually breaking out the big siege units and the big walls.

I feel like I agree 200%. The game starts slowly and finishes really fast ( Ai growth for example is basically exponential. At 10 minutes, hardly a village. At 20 minutes, a moderate town. At 30 minutes, the map is covered in TCs. This is a serious issue.) might be the playstyle, as you can still raid quickly, but I always get that feeling, which I did not get in aoe or aom In particular, house building was (still is to an extent) notoriously slow. I also agree about tech pairs, I feel like the choices aren't right. I love the idea of pairs, but I agree that cost vs power usually makes more sense than Melee vs ranged. Though a bit of both would be perfect (to allow more customization in-game. Finally, I wouldn't mind slightly slower battles, really.

Perhaps here could be a combination of both (though then again, perhaps this is not really simpler). Still, I think there should be a maximum armor or something so that catapult hits still feel powerful even against a 90% defense.

Agreed on them being overpowered. I also agree that perhaps wooden palisades would make more sense, in which case they could be closed. (also, it's still noteworthy that aegis currently disbands the walls, keeping only towers)

I tend to support the percent idea since it's fairly simple, very efficient gameplay-wise, and gives usually pretty sane outputs. Perhaps the curve could be non-linear but rather dependent on attack strength, ie you'd get 50% defense against an attack of 10, 60% against an attack of five, but only 10% against an attack of 50, thus maintaining the advantage to a catapult or something. I dunno. Might be interesting. (obviously we'd only show one value, say against an attack of 10) Edit: might just have rephrased what Fexor wrote.

I believe it is the latest version, yes. The ticket is #1650.

Further information for AI-side optimizations: My API v3 (still not in the game, afaik) will use a shared component and a player-specific component. The architecture would thus be this: C++ Side: AI Manager -> AiWorker (for threading). The AI Worker deals with getting the simulation state (from Ai Manager), running the shared component and sending it to each AI Player script, and runs the AIPlayer (C++ side) which calls the javascript AI. Javascript side: shared component / Ai script. Basically this architecture means that the shared component could probably, for the most part, be ported to C++. I do not believe it should necessarily be too easily moddable since it's only there to do basic, but necessary stuffs: entity filtering (possibly entity collections too, but that might be kept JS side using a clever hierarchical (ie à la octree)). It does map filtering and things like that, which could be ported to C++ efficiently (I believe). AI scripts should however probably remain mostly JS only, for easier moddability. There are areas of improvements there too: detecting what is ran too often and running it less often, optimizing probably in a lot of places, porting some logic to the shared component if it happens to be worthwhile. Furthermore, the JS itself could be faster. About the GC: AIs tend to waste a lot of memories in allocations and deallocation. With a small runtime size (the default 16Mb or the current 24Mb), this means running the GC fairly often. It should be tested wether it's more efficient to run the GC once in a while with a larger runtime (I think we could afford 32Mb), or fairly often with a smaller runtime.

I'm ready to bet there'll be an AoE mod anyway.

Now that's mighty cool

You should just need to compile it, Geek.

Looks pretty fine to me.

Same bug as one that was reported before... I've fixed it in the APi V3 but didn't in the V2, I'll see if I can this week.

I believe those were oriental norias (specifically, big norias here) in Anno 1404. They irrigated surrounding areas to allow farming. Might want that for when we revamp the farming system.