Ykkrosh

Don't blame IE - the image is in a center in a table in a div in a link, which is totally not anywhere near being valid or sensible HTML

I tend to dislike bloom, since it usually seems to be unpleasantly overused, but other people can ignore me . There was some discussion a while ago about implementing a simple bloom filter, and it seems like it shouldn't be hard to make something that gives kind of the right effect, though it's not something we've tried working on yet. As far as I'm aware, HDR is much more complex and would need changes through most of the rendering code, so we're not likely to bother doing that.

The first I heard was when being pointed at a screenshot (with a 2D building sprite on 3D terrain) by TVS, and the second I heard was this thread via HTTP_REFERER.

Population?

Too late for that - we've already got him . (Might just take a short while to set up the forum permissions.)

It does mean that, and it is a little annoying - it's just a compromise to improve efficiency and simplicity (both for the engine and for the artists). Polygons are quite cheap, so you could probably use a few more of them to make the detailed shapes.

I think what Belisarvis said is correct. We're mainly working on x86 and Windows/Linux, and have got some way towards x86 OS X; I don't think there are any unusual problems with porting to other architectures (though there are the usual issues with assembly code and endianness and library dependencies and whatever), but we haven't had the hardware and the time (and probably won't unless somebody joins us in order to help with those things). Open source would definitely help people get the game running on obscure systems, but it has various drawbacks too - I don't think we have a clear decision on that subject at the moment. But I believe it's not a decision that needs to be made in the current stage of development - even if the project was open source, I think cathedral-style development is the only way that would work, and so it doesn't matter if any release decisions are delayed until nearer the time. But this is all just my opinion, and others may differ For me, Gentoo. I've almost memorised the installation handbook now

It does support transparency. The main limitation is that you can't combine transparency with player-colour (i.e. where it makes some parts of the texture match the colour of the player who owns it) on a single mesh. But you can use multiple meshes for a single unit, e.g. one mesh for the horse and one mesh for the rider (and one for the rider's shield, one for his weapon, one for his head, one for his helmet, ...), so normally that's not a problem. (Actually, our current horses use that colouring system to change the horse textures into randomised colours (not actually player-colours - just various browns and greys - but they're implemented the same way), so we still can't use transparency on them. But, anyway, it should be possible to achieve the effect you want by some method )

It was wrong when Argalius posted, but it seems to have fixed itself now. No idea what the problem was - hopefully it wasn't anything important

It's an interesting idea, though I'm unsure how feasible it would be. At the moment, graphics isn't the only important performance issue - CPU speed is relevant for running all the simulation (largely since the flexibility of scripting and data-drivenness has a necessary cost). So the game won't work well on really old computers, and if you have a fast enough CPU then you'd probably have the hardware to do at least some form of 3d graphics acceleration. In that case, it's probably much easier to just disable some features in the game's normal 3d renderer - we don't have low-poly versions of the models (and I believe they would need too much effort for too little benefit), but it's easy to do low-resolution textures and disable shadows (and if you want to be really extreme, disable lighting and animations and terrain blending and transparency, though then it'd be much worse looking than the original Age of Empires.) The engine isn't really designed to support multiple different graphics systems (which is more than just the renderer, though it's not designed to support multiple renderers either). It's roughly modular, but there are quite a few components that care about graphics - GUI, minimap, console, profiler, etc - and they would all have to be changed to support a new system. I'm not sure at the moment whether it's something we'd want to do or not...

I believe we're going to have some kind of system in the future to keep units more orderly in battles, especially for the ones like Romans - I don't know any details (though other people do), but I think it's a valid complaint at the moment

We'll see what we can do Actually, I suppose you could count the current video as an editor video since it was recorded from inside the editor, just without any of the editor UI...

Yep - I believe that just happens when they change target and switch into walk/idle mode before starting to attack again. We'll probably add something to make that transition smoother at some point in the future.

The current version of the ColladaMax exporter says it's only 7/8/9. Maybe older versions of the exporter support Max 6, though? ColladaMaya says it's for Maya 6.5/7.0/8.0. XSI has a plugin for 5.1 and built-in support in 6.

We're working on supporting the COLLADA file format now, which can be exported by most programs (to varying degrees of quality) including Blender and 3ds Max 7/8/9, so that shouldn't be a problem

Plus a little bit of brightening in Photoshop . (The video itself is unaltered, so it's a bit darker, but I think it's just an issue of modifying the lighting and gamma and stuff - we shouldn't need anything like full HDR.)

The animation speed and randomness is something we definitely intend to work on - we made some changes just before the video to improve a few issues, but still ought to fix transitions between animations and to avoid people being perfectly synchronised or repetitive. It does actually choose randomly between animations already; but some units don't have many choices, and 'true' randomness often doesn't look nicely random, so that situation can be improved in a few ways. I think the animation speeds just need some tweaking, after we've made some minor changes to make it more easily tweakable. So hopefully those issues will be fixed reasonably soon

My vague guess is that it'll be higher than what's in the old FAQ, but not by a great amount - maybe double the suggested RAM and CPU would be more reasonable. We still don't require any features that aren't available on the GeForce 3, and performance seems perfectly acceptable with my GF4 (after disabling fancy water and full shadows). So it's certainly a lot heavier than AoK, but any computer from past few years should still do alright . (But I am just guessing, and we won't have an actually good idea until things are finished and optimised and tested, and then we can add low-quality options if that helps at the bottom end.)

Scenarios are just a special case of mods (which can replace anything in the game) - once you've created a scenario, you could decide to create a new unit type and new textures and new models and whatever, and then use that new unit in your map, and then package all the files up and distribute them in the same way as you would distribute a plain scenario. (Technically you can't modify a single unit, you can only modify unit templates - but the editor can hide the distinction by just creating a new template for every customised unit.) (That's not all implemented yet - we're missing the editor support for it, since it hasn't been a critical part of the development so far, but it's supported by the engine and by the design.) The aim is (obviously) to make it intuitive and easy to use, though I don't know how to measure how well it's succeeding at that so I just hope it's alright . In some ways it's necessarily more complex than AoK, because the game is 3D and so there's just more stuff to think about than in a 2D game. But AoM's editor's UI always annoyed me with lots of windows floating about and getting in the way and intercepting the arrow keys - I think our interface layout is more similar to AoK's, and I use it without getting annoyed. But I've never actually done any proper map designing in either AoK [actually SWGB] or AoM/AoE3 so I'm not sure what the significant differences are, so maybe someone else has a clearer idea. Don't know yet, but it seems like a sensible idea to consider. That fits in with the 'scenarios are actually mods' concept. That FAQ is probably years old, so it's quite possible that we'll end up doing something different . I expect the main problem is hosting, but I don't see that as a major problem (since it'd probably need less bandwidth than our web site), so we'll see how it goes. All the screenshots are originally PNGs, but they're far too large to use on the web so we have to put up with JPEGs

I think most of my recent memories of world geography come from Defcon. That's probably quite worrying, but at least I can locate Seoul on a map now.

Hmm, "Introductions" seems to be hard to find if you just follow the 0 A.D. forum links... But even vaguely game-related topics should be fine in 0 A.D. General Etc anyway It will be scriptable, though I don't know how like AoK - we're using JavaScript instead of whatever AoK has (it kind of looks like Lisp plus the C preprocessor?), so I guess it'll be more procedural than declarative... But I know very little about the AI (and I think we have lots of work left to make high-level AI work nicely, so the design is not finalised yet), so I can't say anything very useful

As a minor technicality, I believe that is untrue - you just have to design the whole game (not only the implementation) around the concept that anybody can modify the client code, so any modification is (by definition) not cheating and (if the design was good enough) not a problem. You can't hide units in fog-of-war since anybody could make them visible, so you don't have any fog-of-war (or any other form of hiding information). You can't stop people writing AI code to automatically micromanage all their resource collection and combat, so you remove all that automatable micromanagement. You can't stop bad players replacing themselves entirely with less-bad AI, so you remove any ranking system and you make sure the game is still fun when you lose. But that's irrelevant in this case - you might end up with a game design that could still be called an RTS, but it wouldn't be the traditional AoE-style RTS that this project has always been trying to create, and the AoE-style RTS with AoE-style synchronised-simulation multiplayer will always be vulnerable to people cheating by modifying the client code to reveal information, and so we need to make it hard enough that not many people do that.

Sorry, I was just joking (probably badly) - ignore everything I said . No Python; and there should be no problems with installation in any case, since we're designing it to work as simply as possible.

Unknown at the moment. I think our code should be able to work on anything from i386, since all the SSE-using parts are optional, though I wouldn't want to try playing it on a real 386 Like http://wildfiregames.com/~philip/svnlog.xml ? I only just added that so I'm not sure if it works reliably, but if it seems alright then I could move it and link to it from the main 0 A.D. page.

I bet Vista doesn't have the window decorations disappear at random intervals, and doesn't have windows occasionally be entirely black until you minimise and restore them. But Beryl is much more fun to use . (I had 0 A.D. running on the rotating cube desktop a while ago, which was nice, though it took a couple of days to compile enough of Gentoo...) I think currently the only plan is for x86 (so not PPC or x86-64), though it shouldn't be impossible to port the code onto others. We don't have any plans at the moment about processor-specific compiler flags (optimising for i386 vs pentium4 vs pentium-m or whatever) or even about what compiler to use (gcc vs icc) - the difference in performance will probably be quite small, so it's not terribly important, but I guess we'll just experiment and see what works best. There's one on the forums here which has the news from the front page. But it'd be useful to know if there's other kinds of information you'd want to see.