Ykkrosh

Well, sure - somebody wants to play a game, and we want them to play our game, and we have to compete for their attention against every other game. When a major game has just been released that wins the attention of lots of RTS gamers, we have to compete harder to get some of the attention back. We can't control anyone else's game, so all we can do is make ours as good as we are capable of. Seems sensible to me

Do you not believe there are many people who like RTS games regardless of the setting, and who would spend their time with SC2 instead of 0 A.D.? (Or, indeed, people who like games regardless of the genre and setting, and who would do the same?)

Indeed, the game engine doesn't try to take advantage of multi-core CPUs. Largely that's because multi-core CPUs didn't exist when we started, and it's very hard to retrofit at a later date. Also we want the game to work on single-core CPUs, so we have to design it to work within that limitation, which means it should still be fast enough on a single core of a multi-core CPU and there isn't a great advantage in using more. And multithreading is just a hard problem anyway, particularly since games are inherently quite serial - you have tens of milliseconds to process one frame, and then you have to finish with it and start over again on the next frame, and it's hard to split that one frame's processing into enough chunks that can be distributed across multiple cores to get a real benefit. (We do use multiple threads for reasons other than performance, e.g. to run some background timer stuff and to separate the editor GUI from the game renderer, but only one thread is doing any heavy computation.)

I was quite happy when I got 2.3MB/s on a torrent (around four years ago) . Don't think I've ever exceeded that, but I haven't really been trying If we can set up servers to provide direct downloads, we can mostly get the same servers to run as torrent seeds, so there shouldn't be any problems with a lack of seeding. (That's more an issue with, uh, less legitimate content, which relies on the goodwill of random individuals to keep seeding.)

I would strongly expect it to be both. Direct downloads are necessary because some people can't/won't use torrents, but torrents are useful because they save us from having to pay for bandwidth and we have no money

I'd much rather have the 10,000. RTW taught me to savour the glorious sight of a huge peasant army sweeping down to engulf the enemy, who then burst out in a riot of colours and rout my peasants into a beautifully dispersing cloud, like a raindrop striking steel. (Nobody said I was meant to win the battle.)

The revision log feed is generated automatically from those SVN commit messages, but it doesn't include the whole of each message - the messages sometimes have technical details that won't make sense to anyone other than WFG programmers (e.g. "Adding the m_base check"), or links to private forums, or verbose descriptions that are informative to the developers but that nobody else will care about, and so on. So, to make it more appropriate for the kinds of people who will typically be looking at the revision log on our web site, only lines explicitly prefixed with '#' in the commit message are displayed in the public log, and we try to put simple short vaguely-understandable messages in there so that people can get some idea of what we're working on.

Yes - as long as the meshes and animations were made with the same basic skeletal structure, you can mix them together in any combination and it should work sensibly.

To be slightly more precise, most of the models in AoM don't use Granny at all - the BRG files store the position of each vertex at frame 1, the position of each vertex at frame 2, and so on for all the animation frames. Any bone structure used by the animator in 3ds Max is entirely discarded, and everything is flattened into simply a list of moving vertices.AoM only uses Granny for its high-detail cinematic models, probably since they have a lot more vertices and it'd be really inefficient to store the position for every one at every frame. AoE3 uses Granny for everything, probably for the same reason. Granny files do store the skeletal structure of the model and animation, but everything is highly compressed (e.g. it ignores any bone keyframes that the original animator put it, and works out a new minimal set of keyframes that will give approximately the same movement curve). It might theoretically be possible to reproduce an editable skeleton in 3ds Max from the data in a Granny file, but it'd be really quite difficult and it wouldn't match exactly what the original animator exported. Currently our game engine is designed to load COLLADA models and animations, which you can theoretically re-import into any modelling program that supports that format (which is most modelling programs nowadays), though in practice there are often compatibility issues if you mix programs (e.g. exporting from 3ds Max then importing into Blender), but it should still work better than trying to import some new undocumented proprietary format. The game automatically converts those files into a more efficient internal format when they're first loaded, but modders should be able to ignore that and just use the COLLADA files.

Yep - it was some small updates to the code that generates the public revision log on the site, to make it work on the new servers. Also it was an opportunity to test that that code picked up the revision messages and regenerated the log properly

96.4p per litre around here (UK), apparently. So that's about $5.45 USD/gallon, or $6.63 CAD/gallon, or $1.75 CAD/litre, or $2.17 AUD/litre, at current exchange rates. I'm happy that I don't have a car

That's the old (current) method - the new (future, once we've sorted out all the remaining issues, I hope) method is that we export standard COLLADA files instead. There are widely-used COLLADA exporters for 3ds Max, XSI, Blender, Google SketchUp, and most other modelling programs. Then the game will just load those files (and automatically convert them into the more efficient internal PMD format, but you should never need to know about that). I've tested this with animated skeletal models from 3ds Max and XSI, and with static meshes from Blender, and it seems to work in all of them, so you should be fairly free to choose whichever program you prefer

Yep, that's helpful - that message means there was more than one object in the scene, and the converter couldn't work out which one was meant to be the exported mesh/skeleton, so it gave up and cried. In deer_mesh.dae, the <visual_scene ...> directly contains both <node id="deer-node" name="deer" type="NODE"> and <node id="deer01-node" name="deer01" type="NODE">, so the Collada loader doesn't know how to decide between the two. (deer_mesh_skeleton.dae seems to have basically the same issue). You can hopefully fix it by deleting all but one of those objects (or by only selecting one when exporting, and being careful that all the necessary linked objects still do get exported); or in 3ds Max you can right-click on the desired object and go to the 'user defined properties' window (if I remember correctly) and write "export" in there, if that's more convenient.

Urgh, seems like there's at least two more problems... When I try to load your mesh, mainlog.html says "WARNING: FCollada warning 54: Missing or invalid URI target" (and then everything dies painfully). That can be fixed by modifying the .dae file: where it says <visual_scene id="deer_idle_01.max" ...>, and where it says <instance_visual_scene url="#deer_idle_01.max"/>, delete the '.' character in both. (I don't understand why that fixes anything - there must be an odd bug in the FCollada library that makes it dislike '.' in IDs, so I suppose I'll have to look at that at some point in the future (and see if updating to the latest version of FCollada helps).) Then there's a second log message: "ERROR: Assertion not satisfied (line 384): failed requirement "mesh is made of triangles"". Fortunately that message is almost understandable, and it just means you have to enable the "Triangulate" export option. (I think you also want to enable "Normals" on export. The other options can hopefully be left at their defaults.) Then I have no idea what'll break after you've worked around those issues

One problem (maybe the only one, but I'm not able to test this easily) is that skeletons.xml contains a syntax error. Try opening the .xml file in e.g. Firefox, and it will say: XML Parsing Error: mismatched tag. Expected: </bone>. Location: file:///[...]/skeletons.xml Line Number 450, Column 4: </skeleton> ----------^ Looks like the error is <bone name="Deer01_Neck1"> missing its matching </bone> - it should work better when you add that. (There ought to be a better error report in these cases, since it looks like it's not being very informative yet - recorded as #201.)

It will be. The editor is written with wxWidgets - it currently works on Windows and Linux, and should be made to work on OS X too. We didn't want to use Qt since the non-expensive version is GPL, which would require the whole of the editor and game code to be GPL-compatible too, and we didn't want that restriction. Also, Qt4 wasn't released when we started development, so it would have been Qt3; and I think wx works alright anyway

It's only available for "Windows & Linux (soon)", whereas we want Linux (now) and OS X too. It also looks like it can't be used as part of any open source software, since it has restrictions on redistribution that don't allow derived work. Even without monetary issues, commercial libraries are quite problematic for projects like ours. Open source libraries like ODE are much better from a licensing perspective, but I believe the main problem with implementing physics is the complexity and time that would be needed to integrate it with the game's art and engine. It's particularly a pain for modders - if you look at a building from AoE3, the artists have to create several models and animations to handle destruction for every individual building, and it becomes prohibitively difficult for anyone else to add their own new building model into the game.

There are 'actor' files (in a simple XML format, with an editing tool available) which define the appearance of an object: each actor specifies a mesh, a texture (there is only one used on the actor's whole mesh), whether that texture is interpreted as alpha-transparency or player-colour, and also there's animations and some other bits. So, normally, transparency and player-colour can each be used on any mesh (and affect the whole mesh), but you can't combine both on the same mesh at the same tim. Actors can also have props attached (like a spear attached to a rider's hand, or a rider attached to a horse's saddle), and those props are also actors with their own independent settings - so you can have e.g. an actor for a building, with one mesh and texture and player-colour; and then have a second actor with a different mesh and texture and with transparency instead, and attach the two together, so the final building object combines the two. So it should be possible to get the desired effect in most cases, and it doesn't add much complexity to common simple cases.

It will be available on Linux (and, if there aren't unexpected problems, OS X) - some of the programmers here are Linux users, and are making sure the game and all the editing tools work properly. I would hope all the versions can be released at the same time, though we don't currently have any plans about that. I expect it'll be harder to release things on Linux than on Windows, since there's a lot more variation in libraries and services and drivers, but we'll try to make it work

AoM's DDT format isn't really that much like DDS - it often uses the same compression method (DXTC), but it's also used to store uncompressed paletted textures (with 12-bit, 15-bit, 16-bit palettes, and 8-bit greyscale, if I remember correctly) and is generally rather weird . (AoE3 dropped all the paletted modes, so its DDTs were much closer to DDSs, except for the file format being completely unrelated to DDS.) AoM stores the alpha in a separate channel in the same way as 0 A.D. (and AoE3 etc) - it's just AoMEd that converts that into a black-and-white-alpha-below-image format, so that people with Paint can still edit the image

C++ for the engine code, and JavaScript for scripts.

I have a 1280x800 display now and our main menu GUI doesn't work very well in widescreen . The rest of the game is fine, though - I think it works until you get around 10:1 aspect ratio and then the camera starts acting weirdly... I don't think there's an OpenGL vs DirectX difference - they can both handle any resolution, and it's just up to the game to decide which options to let the user choose. There are some difficulties with supporting non-4:3 resolutions, like making the in-game GUI fit properly, and making sure players with wide screens don't get an unfair advantage in multiplayer games by being able to see more, and making sure cinematic sequences don't miss bits off the edges on narrower screens, etc, which I presume is why some games don't bother letting users choose that.

RAM usually helps significantly too, particularly since Windows uses up much of it and doesn't leave a lot. But it's too early to give any actual numbers for 0 A.D. now - we'll be adding more content, but also optimising the code, and probably adding low-quality options (reduced texture resolution, etc), so we can't predict exactly how it will end up working. And it's better to wait as long as possible before upgrading anything in your computer, because then the hardware will be much faster and cheaper

This link works.

Oops, looks like it broke when we moved to a new server a few days ago. Thanks for the note The video wasn't actually rendered in real-time, though I think the game almost can run at that speed and quality on reasonably modern computers (and the graphics can scale back a bit for older hardware). Because of the cost of just saving the video to disk (about 1.5GB for 45 seconds, if I remember correctly), real-time recording doesn't work well, so it was done slowly with the game saving each frame before rendering the next; and since the recorded video is large, it really needs to be done on the same computer that does all the editing and eventual compression; and since I ended up doing the editing, I did the recording too. And since I only have a GeForce 4, which doesn't support the pixels shaders we're currently using for the reflective water (I think that needs GF6 or something?), I used NVIDIA's software emulated rendering mode, which is incredibly slow, so it took about five seconds per frame...But if I run the game without the fancy water (and without high-res shadows and things, and without trying to record video at the same time), it still works fast enough for me, so I don't feel any need to upgrade my hardware yet