Jump to content


WFG Retired
  • Posts

  • Joined

  • Last visited

Everything posted by Acumen

  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. The same applies to any rumoured or speculative release dates.
  7. 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.
  8. 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.
  9. All the included art was taken off the website, so yes, you won't be missing anything.
  10. Micromart. It's the 14th-20th July version, so nip out to your newsagents while you still can.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. The plan for provinces/territories is quite detailed and subject to change, so I'm not going to go into a lot of detail here. But it's not going to be like Total War (no turn-based mode) ... Here, a single game map is split into different areas (provinces) that the player must seize (and hold onto) in order to exploit that region. As it turns out, Empire Earth 2's territory system is remarkably similar to what we came up with many, many months ago (although more complex in a lot of ways). Consequently, recorded games (replays) should hopefully be adequate to handle your second request, since you're recording the growth of your territory during the course of a single mission. We chose "ore" because there are a number of different minerals and metals (steel, gold, iron, silver, bronze, etc) that would have gone into manufacturing equipment or producing coin. That'd be more accurate, but since the player would then be managing a whole lot of extra resources that are gathered in exactly the same way (mining), it seemed like extra effort for no gain. So gameplay won out over authenticity in this case and "ore" provides a way to refer generically to precious minerals. We do not currently plan for the engine to be open source. But, we are focusing on making it data-driven so that modders can alter the entity/UI/logic scripts and so affect gameplay.
  17. Could you give a tip about the kind of articles you'd like to see? Community feedback would help give us some direction into what subjects you'd like us to write about.
  18. 0 A.D.'s Programming Department is getting to a point where we need more manpower in the areas of GUI and entity scripting, and is looking for fresh blood. There's a whole lot to do in making this game as playable as the design team want it, and that means time, energy, and talent. We're literally coding everything that we take for granted in the gameplay of an RTS from first principles. The more help we get, the sooner the game can be released. Candidates should: a] be excited about creating gameplay logic and user interfaces from scratch, b] know JavaScript, XML, and good programming practice, c] work well with others and a good communicator, d] like to work hard, for free, like the rest of us crazies, e] be familiar with historical RTSes, and f] have a lot of time on your hands. If you're interested, please fill out the Scripter position in our website's Application Form. For more information about how we're using JavaScript in 0 A.D., this recent thread may prove of interest.
  19. Yes, that's the JavaScript syntax as used in websites (not Java), which we've embedded into our engine via the SpiderMonkey SDK. JS is structurally quite similar to C++ (and in some ways easier to use ... No distinct variable types or conversions for one ), so anyone comfortable with that should feel right at home. Please fill out the application and then we'll have more background and know how things look. Those that look promising will be interviewed (typically via MSN) to bash out the details and answer queries on both sides, and then if it looks like the best thing for both parties, the candidate would come onto staff. I'll just mention that skill and time is only half the battle, though. We're better off being understaffed than taking on someone that isn't reliable and self-motivated, doesn't communicate how he's doing, or causes a disturbance that disrupts the work and well-being of other staff members. Hence the paranoid selection process.
  20. As we recently scripted the resource system, I can say that we aim to make it adaptable (after all, TLA will have mithral, trade goods, and all manner of things, and we need to keep their needs in mind). As it stands, the resource pool is simply a JS object array attached to each player object, so each resource type is defined on startup from JavaScript, and therefore a mod could use more or less resources than what we're using for 0 A.D., have different names, whatever, without having to modify the engine source. Of course, you'd also have to update the appropriate XML-based entities so they're capable of containing (eg trees) or gathering (eg citizens) any new resource you add, and perhaps modify the logic for gathering a resource if you needed that action to function any differently from the existing resource types. And also update the GUI so that it displays a new resource counter control with an appropriate icon and tooltip, is refreshed with the current value of the resource type, etc. And add a cost property to each entity that needs the player to spend this resource to get that unit. Currently Population (how many population slots your units are occupying) and Housing (how many population slots you've unlocked by building houses) are in the list with the other resources (Food, Wood, Stone, Ore), with some custom scripted logic since they aren't gatherable in the same way as other resources. So equally, if you wanted to, say, have two population counters, one for economic and one for military units, you could also script that yourself by modifying the bit where the population counter is updated when an entity is loaded onto the production queue. And go through each affected entity defining its alternate population properties and which buildings generate which type of housing. So it requires some knowledge of programming logic and plenty of hard work, and isn't as easy as just clicking a button to inject a new resource into the game, but we're aiming to keep the meat and potatoes of gameplay mechanics adaptable by modders in this kind of fashion. You'll (hopefully) be able to do anything our scripters can. Our hope is that modders will be able to take what's available and make an RTS mod that looks and plays drastically differently from 0 A.D. Given time, craftiness, imagination, and dramatic amounts of effort, of course. Though hopefully it'll also make it possible to drastically adapt our own gameplay through testing during development, and make 0 A.D. fun enough that you won't have any inclination to make your own to replace it. I probably gave away far too much information, but it feels good to be able to answer a question with some degree of knowledge for once ... Shameless Recruitment Drive ... Incoming! Incidentally, if anyone else is: a] as excited about creating gameplay and user interfaces from scratch as I am, b] knows JavaScript and good programming practice, c] works well with others and is a good communicator, d] likes to work hard, for free, like the rest of us crazies, e] is familiar with historical RTSes, and f] has a lot more time on their hands than I do , ... we're getting to a point where we need more manpower in this area. There's a whole lot to do in making this game as playable as the design team want it, and that means time, energy, and talent. We're literally coding everything that we take for granted in the gameplay of an RTS from first principles. The more help we get, the sooner the game can be released. If anyone's interested, please fill out the Scripter position in our website's Application Form.
  21. It's funny how often the same questions are asked. Fortunately, this is why we have a FAQ ...
  22. So ... No requests? No preferences? No suggestions? Nada? Hmm, due to lack of interest, I guess we shouldn't release any more articles, then ...
  23. As you probably already know, we periodically post articles about our experiences at Wildfire Games in the Developer Articles section of our website. So are there any topics that you would particularly like to see in future articles? This would help us to ensure that these articles are relevant and interesting to you. Please post your suggestions below.
  • Create New...