Ykkrosh

They have "Season Pass" bundles which give you all the content over a six month period for $100 (USD), so it won't be $200 unless you like the game enough to spend a year playing it, in which case surely $0.50 per day isn't such a bad deal, compared to spending $50 for a standard game that's probably ten hours long and that you probably won't play all the way through anyway (I guess they realised the terrible situation that people are still playing AoK after a decade without giving any more money to Microsoft, and are making sure to fix that this time...) That costs hundreds of thousands (or maybe millions) of dollars worth of man-hours, so I think AoEO is a relative bargain at any price

The font we currently use supports all kinds of weird accents on Latin characters, so that should be okay. (A font that doesn't support them wouldn't be usable for the user's-native-language text either.)

The old design also locked us into English text, whereas the new one can be translated to other languages (once we implement translation support), and a fixed aspect ratio (it looked ugly on widescreen monitors). I think it was a nice idea, but not very practical

We collect a load of data from users (currently about 20K distinct users, 50K hardware reports, 80K performance profiling reports, 2K text messages; about 1.6GB of text in total (uncompressed)). Currently it's all stored in a MySQL database, with most of the data stored as JSON in a text column (so the data collection code doesn't have to know schemas of every message type the game might send). The hardware data looks like this; profiling data is like the F11 profiler mode. Queries are very slow, since they have to copy all the JSON text from the MySQL daemon to the application and decode it all and do most of the processing manually in Python. There's a process that transforms the OpenGL data into a series of separate tables that are designed for fast queries for the web interface, but it'd be nice to support more ad-hoc queries without requiring that much effort. I've started playing a bit with MongoDB to see if it could work for this (actually mostly just because it's fun), and it seems alright. It's basically a system for storing lots of schemaless JSON documents, and then doing queries or map-reduce processing over them. It takes about five minutes to import the data from MySQL but then it can be accessed efficiently with no more JSON decoding. That means it's possible to write some Python code like connection.userreport.hwdetect.find( { "data_version": {"$gte": 2}, "$where": "!(this.data['x86_caps[1]'] & (1<<26))" }, {"data.cpu_identifier": 1, "data.gfx_card": 1} ) to find hwdetect reports (of version 2 or greater) without the CPU capability flag indicating SSE2 support (tested by a JavaScript function that runs on the server), returning the CPU identifier and graphics card, and it runs in about a second (with no indexes, and sufficient RAM to keep things cached). (Formatting the result gives this, showing at least a few people with acceptable graphics cards but no SSE2.) Some other code like map_caps = Code(""" function() { var c0 = this.data["x86_caps[0]"]; var c1 = this.data["x86_caps[1]"]; var c2 = this.data["x86_caps[2]"]; var c3 = this.data["x86_caps[3]"]; emit({caps: [c0,c1,c2,c3], user: this.user_id_hash}, 1); } """) reduce_sum = Code(""" function(key, values) { var count = 0; values.forEach(function(val) { count += val; }); return count; } """) map_merge = Code(""" function() { emit("total", 1); emit(this._id.caps, 1); } """) mconn.userreport.command("mapreduce", "hwdetect", query = {"data_version": {"$gte": 2}}, map = map_caps, reduce = reduce_sum, out="temp_cpu_caps" ) caps = mconn.userreport.temp_cpu_caps.inline_map_reduce(map_merge, reduce_sum) does a couple of map-reduce jobs to count the number of distinct users with each set of CPU capabilities (plus the total number of distinct users), giving this data in about five seconds. I can't run this on my web server, since the database is too large for a 32-bit address space (MongoDB mmaps the entire thing) and it likes lots of physical RAM (for caching) and it still has too high CPU cost for real-time usage, but it seems convenient and fast enough for offline analysis. It'd probably be useful to publish some analyses of this data and update them over time (maybe run it over each 3-month period), like the Steam or Unity ones. I don't know if I'll have time to do this soon, but just in case: what kind of reports (tables or graphs based on the hardware/profiling data) would be interesting or useful? (If they're mostly variations on a few themes then it should be easy and quick to do lots of them, so hopefully this shouldn't take much effort.)

The "technical details" button in the menu screen says what information it sends, and source/ps/GameSetup/HWDetect.cpp implements the collection of hardware/system/driver details, and the server code (Django/Python) is where Jan says, so you can check it very carefully if you want

For mouse lag, try setting the environment variable SDL_VIDEO_X11_DGAMOUSE=0 when running the game. (Next alpha release should do that automatically.)

Looks like just a spammer - deleted now

Hmm, the hidden terrain thing sounds a bit annoying. Maybe it'd be fine just to have the line follow the terrain even in SoD? The terrain height in SoD is already not well hidden from players (they can e.g. use the camera zoom to detect hills and valleys, or click in SoD and look at the little animated movement-order confirmation symbol that we haven't added yet, or just modify the shaders if they want to cheat trivially), so exposing the same information through rally point marker lines (which is a pretty slow and unreliable method) wouldn't hurt much more. If it turns out to be a problem in practice and players exploit it, we can fix it then - it doesn't seem certain to me that it will be, so it's probably best to avoid the effort and complexity now and do the simpler terrain-height-exposing thing. (I think it's more important to hide the existence of enemy buildings (especially walls) than the terrain, so it's probably still worthwhile having it stop using the full pathfinder data and doing the straight-line thing once it reaches SoD, even if it's still going to expose terrain data.) Assuming the rally point paths get recalculated whenever the player selects a building in order to see its rally point path, I think it's fine to never update it automatically - players aren't going to look at it for more than a few seconds so it won't get very out of date, and if it does then they can just reselect the building manually. (There isn't any way of detecting when a path becomes invalid (other than recalculating from scratch and seeing if it's the same) - it wouldn't be sufficient to check for buildings that are on the path, since destroying a building that's not on the path might open up a new shorter route and change the path.)

It sounds kind of like they took a decent (albeit old-fashioned) RTS design, and then stripped out most of the features so they could gradually feed them back to players as a reward for playing; the result is that you spend a long time playing an incomplete RTS game (which is less fun and less well balanced because of what's missing) and all you end up with is a complete RTS game that you could have bought from a shop ten years ago and played without all this levelling-up hassle. Presumably it would be better if players started with access to a complete RTS game, which was properly fun by itself (so it wouldn't be perceived as grinding), and then the persistent online features were built on top of that instead of subtracting from it (though I don't know exactly what that would entail). (Or at least 'better' from the perspective of experienced RTS gamers - presumably Microsoft's money-counters and (they hope) hordes of semi-casual gamers will have a different perspective.)

Looks like you need to run "make clean" to get rid of those "cc1plus: error: obj/scriptinterface_Release/precompiled.h: No such file or directory" errors (which are caused by outdated build files).

That sounds like you need the surroundedness check and the get-captured-by-units feature, whereas I was suggesting having merely the get-captured-by-units feature (regardless of surroundedness), so my suggestion is simpler (I'm imagining the get-captured-by-units feature would have the building remain owned by its original player (not revert to Gaia), but any enemy unit can go up to it and do a little capturing dance for a few seconds without being interrupted and the building will then switch ownership, but it will remain at zero loyalty so a different enemy (or the original owner) could come and do another capturing dance and take it back almost immediately, until the new owner gets around to building a civ center nearby to cement their ownership of the building (which will slowly recharge the building's loyalty, making it much harder to recapture). That avoids the problem of ping-ponging between one owner and Gaia - you won't immediately lose control of the building when you lose its loyalty, but it'll become extremely vulnerable if enemy troops reach it and you don't have enough troops nearby to defend it.)

I was mostly wondering what's the benefit of distinguishing surrounded vs not surrounded, rather than having the loyalty drain/capture apply to all buildings that are cut off from their civ center regardless of surroundedness. (Simulating supply lines sounds kind of like pointless pseudorealism to me, and not worth the effort of detecting surroundedness if that's the only reason for it ) (When a building is surrounded, it might be surrounded by multiple enemies, so we probably couldn't have it be immediately captured by the enemy whose territory surrounds it (since which one would we pick?). So I'm assuming capturing would probably involve the building putting up a (metaphorical or literal) flag of surrender and then switching over to whoever first sends a unit along to take it. In that case, exactly the same could apply to buildings that are surrounded by neutral territory instead - they lose all loyalty then are captured by whoever reaches them first.)

Feel free to tweak the values, I just picked one at random If there's no effect when a territory is disconnected from civ centers but not surrounded by enemies, you could probably build a chain of houses/etc and stick some dropsites on the end a long way from your civ center, with no harm or danger and no cost beyond the cost of houses, which seems to partly defeat the role of territories in keeping your cities clumped together, which doesn't sound great. (When there's some kind of decay, that long chain would be very vulnerable to the enemy destroying a single building and cutting the chain in half and indirectly destroying the rest of the buildings through decay, which gives players a more interesting choice between risky fast expansion vs solid well-connected territories.) If we did depend on whether buildings are surrounded, what does "surrounded" mean? In particular, what if the building is by the edge of the map (or maybe a big cliff or ocean etc), so the enemy territory can extend partially around the building but can never reach around the final side, so the building can never be completely surrounded? It seems bad if you could exploit that to make buildings unexpectedly resilient when enemy territories are nearby. More generally, what combination of adjacent friendly/ally/neutral/enemy/second-enemy/third-enemy/etc tiles should trigger the "surrounded" behaviour? Also, what's the expected gameplay benefit of your proposed changes? (Not saying I disagree, just it would be good to have justification for adding complexity )

We use UTF-8 for file input/output as much as possible. Strings in memory are effectively UCS-2 or UTF-32 (depending on platform).

Autobuild should be there now.

Yes, all user-visible text is done with Unicode strings.

Added some decay - if a territory does not contain an entity with <TerritoryInfluence><Root>true</Root></TerritoryInfluence> (currently set on civ centers) belonging to the territory's associated player, then its border will flash and buildings within it will lose 20HP per second (see template_structure.xml) until they either die or come back into a civ-center-connected territory.

Don't know - we haven't started implementing any translation support yet, and will need to figure out what's the best way of doing it, and don't have any real plans so far. (I expect we should reuse some existing system and avoid doing anything novel ourselves, so suggestions of software or community setups that have worked or not worked for similar types of project would be particularly useful )

Fixed.

Thanks, looks like a significant difference. I changed it to avoid using shaders on GF FX by default now.

JavaScript has optional semicolons too, so it doesn't seem much better; in any case I don't think optional syntax is really a problem since you can just enforce some coding conventions to keep things consistent and readable. JavaScript uses pretty much the same concept - everything's an object with string-named properties, including arrays (which also have a magic 'length' property) and classes (which are function objects with a prototype property with function properties). I don't think those sound like convincing technical arguments for JS over Lua - it seems more like it was down to personal preferences of a couple of people, and I guess I wouldn't have agreed with the decision if I was around back then (and wasn't as inexperienced as I would have been then). But I'm quite glad they made that decision despite the reasoning, since JS has grown in performance and popularity since then and is a nice enough language for our needs Yeah, I think we started with version 1.5 as in this graph, and now use the rightmost version, so there's definitely been an improvement, and they're not stopping yet

Should be fixed.

The game is fairly tightly bound to details of the SpiderMonkey API, as well as using JS language features that only SpiderMonkey supports, so there's no realistic way to get rid of SpiderMonkey. Depending on what you want to achieve, it might be possible to just add V8 alongside SpiderMonkey, in which case it's basically the same as embedding V8 into any other C++ application.

Ah, interesting. Could you maybe check the framerate (press shift+F and look in top-left corner) with and without that option, to see how much effect it has? (You can change it by pressing F12 to open the console and entering renderer.renderpath="fixed" or renderer.renderpath="shader" to test both ways.) Can anyone test this with a GeForce FX on Windows? I'd guess it's a hardware limitation (apparently 32-bit FP is very slow on GF FX, and the ARB shaders don't allow 16-bit FP so they'll be slow) so it should be the same there. Probably we should just default to the non-shader mode for all GF FX hardware.

That too, though be careful in long games - it effectively stores a saved game every 2 seconds (or every 0.1 seconds if you're holding down space and running 20x faster), so it's a bit slow and can eat up huge amounts of memory