Acumen

The trouble with that is that we'd have to maintain and represent multiple resources for an object, and also presents problems with the interface. (Normally you can just right-click a tree and the unit will harvest the wood; now you need a means to choose one resource over another.) What might work, though, is to do it in two stages ... Have a fruit tree and a wood tree. When the fruit tree is exhausted of Food, the entity is "killed" and the equivalent wood tree referenced by the fruit tree entity is spawned in its place. Obviously that creates a little more work on both sides of the artistic and programming fence. But there's nothing stopping you from having stand-alone fruit trees right now ... They'd just need fruit-bearing actors, fruit-picking animation (since they'd have to stand and reach to pick fruit -- which would also have an effect on the reasonable height of such a tree), and a special type of tree with Food content.

This was slightly before I joined the project, but as I understand it, other than the impressive voiceover which was provided by a third party, it was all done by WFG members (using Poser figures (I believe the Roman centurion was a heavily facial-morphed version of Daz's Michael 2) superimposed onto Bryce scenes, if I recall correctly), with Wyrmwood doing the sound, Jason doing most of the art. Pretty darn good for a first attempt, I have to say. It took a lot of man hours to put together.

Exactly. Stone is used wherever stone is needed (stone buildings, particularly walls, slinger and onager ammunition, etc). Some civs used more wood than stone in their construction (eg those rickety Celtic huts), so the importance of the resource can differ a bit from civ to civ. Ore is used as the basis for metals and currency, so it'd cover metal weapons and armour, expensive technologies, wages, costly commissions, and so forth. Ore is typically a lot more rare and stone a lot more plentiful (depending on the map's environment).

All this is highly subject to change, especially during usability testing, and is not indicative of the final product, but at present: Yep. Food, Wood, Stone, Ore. (And Population/Housing.) (There were originally Metal and Gold, but since the mining technique and general function would have been almost identical, we opted to merge them into representative Ore which covers a range of minerals in their unrefined form, including bronze, silver, iron, steel, etc.) Food can be gathered from various sources (grain, meat, berries, etc). Wood from trees, Stone from rocks, Ore from mineral deposits (pretty standard). All natural resources are finite. A little of both. At present, units gather resources at a site directly into the resource pool without physically taking them back home (and frankly, I don't think you really miss your gatherers shuffling back and forth and getting in each other's way). But there are also plans to require drop-off buildings in order to gather certain resources in certain areas. The key design principle is to reward the player for good tactical thinking and encourage strategic thought over mindless build-ordering. We want to avoid tedious, repetitive activity and instead focus on giving the player interesting decisions to make. To this end, managing your economy, technology and advancement is essential to your war effort. Personally I get the biggest kick out of the base-building side of an RTS game.

Quick answer ... The bulk of the player's military forces (infantry and cavalry "citizen soldiers") gain promotions by killing enemies. Then you have a couple of legendary units ("super units", for lack of a better term) which are only available in the late game (such as Carthaginian elephant cavalry or the Persian Amrtaka). These don't gain veterancy and are expensive, but are very powerful. Both categories can benefit from improvement by researching technological advancements. As always, the design is subject to change at any time depending on what proves to be fun and feasible.

The same applies to any rumoured or speculative release dates.

Incidentally, if anyone out there has is familiar with the Max SDK and wants to help out, please fill out an application form on the website. We currently lack programming experience with this toolkit and MaxScript, and in order to finish 0 A.D. we need to upgrade our exporters with a number of additional features, including: support for non-biped animatable objects (siege, ships) vertex skinning and attachment (using skin and simple bones - vs. physique and biped) export simple 3dmax bones and bone animations (for quadrupeds, fish, birds, deer, sheep, elephants - anything nonbiped) skin information (for vertex assignments to simple 3dmax boned animations) vertex based animation (like how 3ds saves its animations - for things such as trees falling) support for newer versions and other modelling tools such as Blender (our current exporters only work in 3ds Max R6) This task has been idling for many months due to lack of informed manpower, so if you can help out, we'd appreciate it and be able to get this game out that much sooner.

Of course, if the wolves want to make the project go faster by helping out, feel free to fill out the application form on the website.

All the included art was taken off the website, so yes, you won't be missing anything.

Micromart. It's the 14th-20th July version, so nip out to your newsagents while you still can.

Yes, the UI as it stands is completely scriptable, so you'll be able to change the user interface (including the main menu) and include those changed scripts, additional texture sprite artwork, ogg audio files, etc) in the mod pack. Exactly how mods are enabled/disabled is something that we'll need to work out at a later date, but probably "global" mods (like the menu mod above) would be toggleable either in a mod tree toggler tool or at least in a .cfg file (it'd have to be done out of game, since the game's already loaded by the time you reach an in-game UI, and then it's too late to load the mod ). The plan is that scenarios in turn could include any amount of "local" mod content, that's only active during scenarios in that mod pack so that it doesn't override the rest of the game.

Going off what we have at the moment, I can't guarantee that modpacks will be *easy* to make (that'd require much tool development, and therefore it's dependent on the degree of tool programmer resource at our disposal -- and they'll be plenty overworked by putting the dev tools and Scenario Editor together ) ... But in terms of doing it by hand at current, the engine is very flexible. You can build up secondary trees of assets which override the official game (so mods can be enabled/disabled without overwriting the release version), we're using open file formats as much as possible so that there's less need for converter tools, and we design our systems in an extensible, generic fashion. We're also aiming to script as much gameplay-specific logic and UI as we can, so that it can be adapted during development and beyond.

Hmm, that's a pretty broad question, since it's a pretty broad task. Let's try an example ... Take a tree. It's a source of wood, which units can harvest from it. When its supply (quantity of wood resource) is exhausted, it's removed from the map. It can change texture depending on the season (red leaves in autumn/fall, green in spring/summer, dead and snow-laden in winter, etc). Some units can navigate through trees and hide in them to perform ambushes. Some of those are intrinsic traits (like the quantity and type of supply). That's defined as an XML property for this particular tree's entity. Some are tied up in events that fire when units perform certain actions (a unit gathers from the tree or a unit attacks another unit ... JavaScript logic defines what happens under that condition; manipulating the supply value, for example). Some are unique behaviours tied to a certain entity type (the hide-in-trees exception). Some are triggered by certain conditions (eg the change of seasons makes certain entities switch to a predefined actor variant with a season-specific texture). All of these are high-level design requirements that need to be written in code form to make the game play as intended. That's the job we're offering. Writing the logic that makes an RTS play like an RTS. Think of all the steps and stipulations that go into constructing a building or training a unit in, say, Age of Mythology. All that has to be written from first principles when creating a new game. We've been making do by having programmers and designers chip in with the scripting, but we really need to devote manpower to it in order to make substantial progress, write the code in a clean and efficient manner, and finetune the design implementation. Tell you what ... Fill out the application form and we can bang out the details during your interview.

Hmm, the Programming Department is pretty full at the moment. I'd say that if there's anywhere we still have a gaping need, it's having scripters to write the barebones of what makes up 0 A.D. gameplay ... building GUI screens and scripting player interaction results, event logic for entity actions, setting up entity attributes, and so forth (since the programmers are more than occupied with writing the actual generic engine). In short, we need more people to help with making an actual game out of it. I know you said you don't like doing interfaces (and we already have a new guy working on the GUI side), but maybe there's something in there that appeals. JavaScript's syntax is practically identical to C's, and although it's object-oriented it's pretty easy to get your head around (you're just grouping properties under a parent object). I instigated a recruitment drive some time ago (eg the Recruiting Scripters new post in the Archive, which describes the role and requirements in more detail) but didn't get much response, unfortunately. Still, if you could fill out the application form in as much detail as you can, then even if there's nothing suitable at the moment, we can still keep your profile on file for the future.

As Bobby said, splash screens are too low-priority for us to have a definite answer right now (it's also dependent upon available free libraries for decoding movie files). More than likely we'll just incorporate our self-glorification into the main menu and credits. Likely what'll happen (if it happens) is that movies will be called from a JS function when the GUI initialises. Since those scripts are modifiable, one could theoretically point to a different splash, add more function calls, or omit it entirely. But none of that's implemented yet. On a personal note, if we do have splash screens, I'd probably add a toggle flag to the config menu to disable them. And because they're annoying and people might skip 'em, they probably aren't worth doing in the first place.