Jump to content

Acumen

WFG Retired
  • Posts

    4.095
  • Joined

  • Last visited

Everything posted by Acumen

  1. Hmm, while we're on the subject, allow me to dispel the myth that QA (in the mainstream gaming industry) is simply an opportunity to play a game before anybody else does, and is something highly desirable. "You get to play games all day and they even pay you for it? You're in nirvana, man!" Or to resurrect my driving metaphor from an earlier article: "This lucky guy gets to drive a prototype Ferrari hot off the assembly line before the company has begun final manufacture? We curses him, my precious. We hates him forever." Er, yeah, but this isn't a fully functioning Ferrari identical to what the "end user" would see. If it was, there'd be no point in testing it. Our erstwhile tester is the human equivalent of a crash test dummy (and in the industry gets roughly the same rate of pay and unpaid overtime). When he starts driving this bootilicious "wonder", he'll find the seat adjustment controls are totally out of whack. The fuel meter shows his speed. Punching the cigarette lighter opens the bonnet. The image on the rear view mirror is reversed. The wheels don't spin unless he's on a road with a name starting with W. It's not uncommon for the engine to fail when he flashes his headlights. And if he ever reaches 120mph in 4th gear, the brakes stop working. Oh, and he has to make sure that the airbag works under all conditions. The hard way. And he'll have to somehow get this smoldering wreck to a halt so he can write out reports and hopefully not endanger his life/PC the next time those problems are found and fixed (assuming he's provided enough information that the problem can be replicated and repaired, and that the programmers have time to do so). Although fixing that first layer of bugs tends to unleash ten more, and he'll have to find those too, often in the same places he looked yesterday. It's the tester's job to go through all this hell so *you* don't have to. Day after day. Month after month. For the pay of a clerk at Virgin Megastore. Sure, playing games is fun. Playing the same game ten hours a day for six months, pushing your avatar against every collision boundary and trying to do every crazy thing a user could do under every possible configuration, and having no choice but to come into work tomorrow and do it all again under increasing deadlines, that's a *job*. But you know what's the worst thing? After playing Generic Shooter VIII under those conditions for half a year, you'll probably shudder every time you pass its gamebox on store shelves. You'll certainly have no desire to ever play it (or possibly anything similar) again. And though you really loved that series, you're probably not that keen to play the sequel anymore either. When you spend your days finely dissecting human entrails, somehow your fellow man don't look quite so attractive anymore. Sometimes it's better to only see the surface veneer. Thanks for listening. Just wanted to put things in perspective.
  2. Not exactly; buildings still have their own properties that need to be accounted for (researching, training, garrisoning, increasing housing, sometimes attacking, etc). However, they don't move around (costly pathfinding) or have the wide variance of animations and related actions that units do. Good point, though, Bakayaro, as buildings do still take their share of the available processing time.
  3. Nebula: It means that each player can't have more units on the map than that specified by the cap. So if the cap is 200, each player can't have more than 200 units at a time (so if there are 8 players, that'd ensure there are no more than 1,600 units in the game at a time, so players can't build unlimited units and slow the game to a crawl as it does continuous calculations for them). (That's assuming that each unit is worth one population point, of course; some games have infantry worth 1 point and cavalry 2 points, depending on the complexity -- horse and rider takes more polys than just the humanoid unit -- and strength of the unit).
  4. Though keep in the mind that the FAQ merely reflects information at the time of writing it, and is highly subject to change. Conservative conceptual phase estimates are likely to adjust depending on more accurate insights discovered through actual implementation. In other words, until it has an accompanying completed game, the FAQ is a guide for what is likely to happen, not a gospel of what shall be forevermore.
  5. TLA is currently in preproduction; in other words, they are busy designing and discussing the game in its entirety, documenting the game mechanics, producing concepts, and so forth. 0 A.D. started a bit earlier, so they've already completed their design phase (more or less ) and are now implementing their design, steadily working their way up to alpha milestone. It's far too early to say yet, but when 0 A.D. is (eventually) released, that'll hopefully coincide with TLA completing its preproduction and ready to reuse the engine (the more mature and stable the engine is when they begin, the less fixes will have to occur in parallel). So probably what'll happen is that some experienced staff from 0 A.D. will move over to TLA, some will work on the 0 A.D. expansion pack, and no doubt many others will collapse from exhaustion, retreat from human contact, and go into hiding on a remote island out in the South Pacific to subsist on clams and coconuts.
  6. We're planning to include "non-essential" assets (ie anything not used by the official campaigns and random maps; those just intended for custom scenarios, stuff that we made but was later superceded, that kind of thing) in an optional download pack, so scenario designers can use that stuff without making average gamers download extra content they aren't going to use. The stuff used in the official maps will also be easily available for placement in your own scenarios or for modification. I hope that answers your question. This article may give you some more details if you haven't already read it. A hearty amen to Adam's points.
  7. From the forums at Renderosity, a 3D art forum. It's a long story, but has to do with 0 A.D. and a solo game project I was working on both being sprite-based at the time, and Jason and I brainstorming about how to overcome some shared issues with the prerendering technique. [plug]Details in the article that Boris just posted. [/plug]
  8. Let me just clarify the situation (I think there may be some confusion between releasing the game(s) and releasing the engine source) ... 0 A.D. and TLA will be released as freeware, so you can download the games for no cost. The distribution will include a compiled executable of the engine used to run the game's assets, but the engine itself isn't open source (ie we won't be releasing the engine source code), much like most commercial projects (except that you download 0 A.D, for free, and it's made by amateurs rather than people who do this for a living). But the games are designed with the intent of moddability (a lot of gameplay logic is scripted rather than being hardcoded into the engine and unchangeable), with open formats to make it a little more flexible than many commercial games to alter the game data to make and install mods, if you so desire.
  9. a] As Malte said, we're not a profit-making organisation. We plan to use the engine exclusively for in-house Wildfire Games development projects, which will be released as freeware. b] Selling an engine that's still under development would be like selling a bag of spare parts and calling it a car.
  10. Also makes it easier to keep track on their progress (it shows their health, level, etc). Should be easy enough to do, if you want it. Depends on how much of a role you intend for heroes to play (eg integral to the plots of campaigns, required to complete objectives, etc, as in AoM and Warcraft 3). In WC3, they similarly stack Hero portraits against the side of the screen, where you can click to select/centre them. In AoM, they had one button that cycled between however many Heroes you had on the map. Current game rules state that in MP, we'd only have 1 Hero at a time, so it's less of an issue, but the player could be given anybody in a campaign. Right now anchoring isn't implemented, though as mentioned we'd need some kind of anchoring capability at some point to handle things like health bars (unless they're hardcoded into the entity system, like selection circles are). If they don't need to retain a position relative to the target, then I could start experimenting with them now. However, without that relative positioning, you lose a lot of the benefits of this scheme. Travel distance is increased if you're, say, clicking a unit in the corner of the screen. Usually the icons only appear when you hover the mouse over the unit, but here they'd be visible all the time unless disabled (though translucency helps), that kind of thing. Still, would give an opportunity to at least set some ground work in playing around with it. Sorry, I didn't explain that very well. What I meant was that if we did it like: click builder unit; click ground; building options appear around ground; pick a footprint ... then we'd get the issues I mentioned. Placing buildings of varying sizes is an example of when we can't get around having to use a verb-noun approach. As for the approach you suggested, yes, that'd work well in theory. The things to consider have already been mentioned ... a] Whether it'd be awkward to activate that interface around small, mobile units; b] Whether it'd take longer to navigate through multiple rings of options to get your choice, versus the traditional "click in the corner" method. As pointed out, context-based games with lots of options tend to need a pause option (as in Neverwinter Nights and TS2) as the complexity gets out of hand. Though with only a few choices, it's very efficient. Anyway, thanks for your comments, guys. If I get some time I'll try to play around with it in our GUI and see what I can work out.
  11. I didn't want to clutter up Jason's excellent report, so I've split this to a new topic. My intention here is to describe the theory of noun-verb interfaces, and see why we should and shouldn't consider using them in 0 A.D. Secondly, I haven't regrettably played BfME yet (though I have studied all the Inside the Battle movies, and any screenshots/previews/reviews I can get my hands on, rather like a deluded fan boy ), so if I've made errors of interpretation, please let me know. 1. "The Legacy" As time has gone on, RTSes have become progressively more complex. There was a time when a simple Windows-like point-'n-click interface was adequate. Clicked a unit? He's selected. Clicked empty ground? He'll move there. Clicked an enemy? He'll attack him. No extra buttons, no clutter, no awkwardness. Just one click. Intuitive to anyone. The Marketeers rejoiced. As time has gone on, units have needed to do more, and players have come to expect it. They've gotta be able to garrison, repair, heal, patrol, escort, cast fireballs, deploy into more powerful forms, and so on. This has made point 'n click insufficient, since more than one command could be linked to a context. When the player commands a unit to perform an action on a ship, does he want him to board it? Repair it? Scuttle it? When the player right-clicks an enemy building, does he want to attack it or capture it? Typically to fulfil these extra commands, these are added as extra buttons in the bottom bar of the interface. The player drags the mouse over to the button (eg Garrison), clicks it, and drags it back to wherever he wanted to perform the action, and apply that command to the target. I call this a "verb-noun" interface. This is slow, inefficient, and counter-intuitive, since typically the player was probably hovering his mouse around the target in the first place. The extra commands are also taking up space on the screen, even when not in use, when the player's focus really should be on the game world itself. This process can be sped up by using hotkeys, of course (press key to change command, click target), but that creates a barrier to new players that have to memorise hundreds of key-presses in order to have a chance. (Aside: BfME seems to use precisely this method to control the special abilities of its units, which looking at their movies seems to be just as awkward as ever -- though they did move those buttons closer to the centre of the screen where the player is likely to need them, cutting the travel time in half. Also, by drastically playing down the economic aspects of an RTS, the player has more time to micro these individuals heroes and their abilities. Given the choice, I would have these units use their combat abilities automatically, perhaps linked to power bars if too powerful, a la AoM, so the player can focus more of his attention on the macro coordination of troops, instead of fiddling with the interface in the heat of battle.) Anyway, the alternative is a context-sensitive interface. 2. "What the Sam Hill is a context-sensitive interface?" It's basically the opposite of the above, a "noun-verb" interface. The player clicks the target, and when more than one option is available, these pop up in the area around it. He then only has to move the mouse a very short distance, pick from the available choices, and the command is fulfiled. To show just how sad I am here's an example from The Sims 2: The player clicks a Sim's fridge. Depending on the Cooking skill of the active Sim, there are options like "Cook Cheese Toastie", "Cook Pork Chops", "Cook Lobster Thermidor". There are also generic commands like "Restock Fridge" and "Juggle Bottles". The implementation can differ drastically from game-to-game, but the general idea is rather like the context menu you get when you right-click in Windows. The computer works out the situation, and depending on the context you have options for Properties, Cut, Paste, Select All, etc. If a command isn't suitable to this context, it doesn't appear. This has various advantages: * The player only sees what we needs to see: Commands only appear when he needs them, and when they'll work on this target. No clutter. * Easy-to-use: It's still a mouse-driven, intuitive interface. * Rapid reaction: Travel time is far less. 3. "This doesn't look like Nirvana to me." Of course, this method has disadvantages too: * It works best on immobile objects: The ring of context-sensitive commands needs to stay in orbit around the target. If the target moves around, the commands would move with him, making it difficult to click on them. Thus, this is an interface only really viable for large, non-moving objects like buildings. * It works best when there's only a few commands available: The more commands pop up, the more room they take up on the screen (generally an orb of buttons shouldn't take up more room than the target itself), the more overwhelming the choices, and the longer it takes for the player to find his desired option. It works well in BfME, but they also removed a heck of a lot of options that the player normally has. There are only a handful of unit types. There are few techs to research. Building doesn't require units or placement of a footprint. AFAIK a number of commands like rally points and garrisoning and town bells, have been removed. Another option, when there are too many of them to take in, is to package groups of commands under certain categories (rather like the tab system already in place). So to use The Sims 2 fridge example above, there might be options "Make Dinner ..." and "Make Dessert ...". Pick the dessert option, and the ring is repopulated with sweet and tasty choices like "Gelatin" and "Baked Alaska". But again, tabbing commands makes it require one more click in order to get to them, slowing down interaction rate. * Sometimes, you *need* to pick the verb first: A good example is standard construction of buildings. In BfME, they simplified this by putting plots on the ground that were a fixed distance from each other, and these were the only places where the player could build. The player clicks the plot, chooses a building, a peon appears out of nowhere nearby, and it starts constructing. We, however, don't have that liberty. Players could build anywhere that there's a flat surface. They can be of varying size. And the command to build is given to a unit (which as explained above, could move around). Take the Mobile Construction Vehicle from the C&C games. This slow-moving unit had to be moved to a particular spot, come to a halt, then you click on it to see if you have a deploy option (which would cause the MCV to turn into a Construction Yard building). If you didn't, then something must be in the way of where its footprint would be, and you'd have to move it around blindly until you found a decent spot. That's pretty much how free placement of buildings would have to work in a context-sensitive interface. 4. "In conclusion." Context-sensitive interfaces are still something I'm hoping to look into. There's definitely potential there for increased ease of use, assuming they can function optimally with the wide variety of commands that are required. (Perhaps a hybrid interface, with "passive" commands (those that don't require a target, like Town Bell) on the bar, and "active" commands (those that do require a target like Garrison or Repair) handled by a context menu. Currently the game GUI isn't capable of supporting such features; it's a 2D interface applied over a 3D world, with no means of attaching a control that retains a position relative to that world, so this concept isn't something that requires any consideration at the moment. However, in time we will need to start implementing controls with an awareness of their environment (such as hitpoint bars attached underneath units), and I hope that functionality will provide opportunity to experiment with this intriguing approach to user input.
  12. 5 days a week, every hour at work. But then I guess that's why caffeine and deadlines were created.
  13. Since airplanes weren't in common use in the classical era, implementing that isn't the highest of priorities. In all honestly, we'll probably be more than exhausted enough trying to implement what's required for 0 A.D. However, gameplay script should hopefully be adaptable enough to incorporate such logic in one's mod.
  14. The general idea was that completing the challenge would flag availability of that cheat in your user profile. The code wouldn't work until flagged. Of course, someone could just upload his profile, or figure out how to modify the profile to change which campaigns and challenges he's completed, so even if it's not cheat-code-based, I don't think we could ever get around the unlock being plastered over the Internet in some form (especially with the game being so mod-friendly). But for those that want to have the satisfaction of completing a single-player challenge and being rewarded for it (rather than the hollow victory of downloading someone else's hack), the option's there.
  15. Thanks for replying to this, Michael. Correct, we plan to revise the Cultures section in more detail when all civ buildings and units have been implemented and tweaked. We have a pretty thorough plan, but it's liable to get a serious hammering as we put it into action, and then the website info would just be constantly out of date as the game evolved. Also we don't want to create disappointment if we preview something and then have to change it later (eg get everybody worked up with special Hellenic Onagers that hurl Greek Fire, only to remove that later because it hadn't been invented yet in this period). We'd like to first ensure that things are working reliably so that we can more accurately reflect what will be in the game. Finally, it lets us do a better job on the Cultures section because we'll have more final material to include. For example, we could include a polished in-game snapshot of each unit/building, alongside the piece of concept art that inspired it.
  16. Actually, if I recall correctly, Big Huge Games themselves had a similar problem when developing RoN (I remember reading about it somewhere, possibly their gamasutra postmortem) ... Since historical RTSes all base themselves on the source material, they had a hard time trying to make their units and buildings look distinct from other games in the genre. This particularly proved a problem for promotional material. They opted in the end to focus on the futuristic units in their screenshots where they had a little more artistic license. Not particularly helpful to you, of course, but just a fact bite to let you know you're not alone.
  17. rquader: Thanks for your comments on Tonto_Sanjab's translations. Could you please let us know what Persian words you feel should be used in these cases, and then we can go about correcting them?
  18. No, it means that we plan for the game to have one or more expansion packs. The first edition will ship with six civilisations that peaked within the period of 500 B.C. to 1 B.C. (those civs are covered in the Cultures section elsewhere on the site, but they're the same ones you already know of). In the expansion(s), we plan to start to add A.D. civs to the mix (those that peaked in 1 A.D to 500 A.D.), as well as adding trickier backburner features that we didn't want to risk adding until we'd established a firm foundation and were comfortable with the engine's capabilities and our tools. Far back in the forgotten eras of 0 A.D.'s development, when it's design was still based on an AoK mod (where as you know the civs shared an extremely common base), we'd planned to release a game with almost double that number of civilisations. Splitting our efforts allows us to focus on a smaller number of civs at a time, and make them more detailed. Six is more than enough to do at once. Of course, that's a long-term plan, and we'll have to see if we first kill ourselves trying to complete the first objective.
  19. Thanks, Argalius. There's always one bug that slips through the net. Should be fixed now.
  20. Hmm, which is more likely to have an accurate awareness of the internal development state? ZeZar, or the official FAQ? *ponders* Though we've made tons of progress in the past year, I can categorically declare that the game is not at a state where it could be released as an open beta in a month's time. Beta, by the way, in case there's confusion, means that the product is totally feature and content complete, and just in need of thorough user testing prior to release (which itself is likely to take a year, including the internal staff beta). I think, however, that the quoted thread referred to earlier milestones in the development schedule, not the beta milestone, which might explain the inconsistency. But yes, the *speculative* release date mentioned in the FAQ has also been pushed forward in recent months, having had the opportunity to assess our rate of progress during the last year of implementation. Sorry, chaps. The FAQ's preliminary date is more feasible, but we'll have to see when we get there.
  21. Actually the building is a couple of variants of Iberian house if I recall correctly. And yeah, that's much higher-poly than we're doing now, since at the time the buildings were going to be 2D for increased detail. The female statue is Athena, which I think Jason did for some graphics art contest.
  22. I used some preproduction renders from Jason for promotional material when doing some programmer recruitment on gamedev.net. So I'm probably (also) to blame. It was stuff that looked good at the time (this was before we were up to even releasing in-game screenshots), but as Malte says it's all obsolete now, so hardly worth worrying about.
×
×
  • Create New...