Jump to content

Acumen

WFG Retired
  • Posts

    4.095
  • Joined

  • Last visited

Everything posted by Acumen

  1. Malte: The GUISize object is covered in this document: http://forums.wildfiregames.com/0ad/?showtopic=1330 Does that help? Or do you mean that you're trying to make sense of the crazy two-size array thing I'm doing to keep track of coordinates for GUI objects either on the top or bottom of the screen? If so, basically I call a function each time an object is declared, which adds the object's name, and two sizes to three separate arrays (don't think multi-dimensional arrays are possible, and was too much of a wimp to try structures). This gradually builds up an index of the size values for each object in the session GUI. Then when you flip the GUI, it works out which set it should be using, and overwrites the objects' size with the appropriate one from the array. EDIT: Philip: Ah, that's handy. I didn't realise you could reference the subcomponents of the size string. Definitely much greater potential for less redundant script using that method (reuse variables when multiple objects share the same x position, and so forth).
  2. Yes, please. It'd make it a lot easier to track them down and wipe them out (although hopefully we've eliminated the invalid objects in the current batch).
  3. Thanks, Malte. Perhaps we should bash out the details on MSN some time when you're more available? Would probably be faster and less horrific than throwing theses at each other. Thanks for looking into the groups. That makes a lot of sense, as I lost the extra portraits when I switched to using the two size sets and tried to bring my code in line with Gustav's compliances. There must be a size in there that's of an invalid format, which then crashes the rest of the function call. I'll try to have another look at it.
  4. Well, that's the beauty of having the GUI on the top of the screen. Seriously, it's just a matter of personal opinion, but I'm really trying to find ways to keep the game's controls in one place as much as possible, to give things a much cleaner look. Having bits of it all over the screen makes it look like Jason's desktop. See how much better the screen looks when you toggle off the FPS counter and exit button, for example? Well, true, the decision was largely aesthetic ... But are they really that important? They tend to get tucked away in the corner of the screen on most RTSes I've seen, because what the player is doing most of the time is interacting with the world and controlling his empire. Selecting stuff and giving orders. Though it's important, he spends a lot less time percentage-wise making alliances, reading up on his objectives, chatting, firing signal flares, etc. They still get used fairly often, though. Anybody that hasn't mastered the hotkeys yet still needs to find idle villagers or centre on last notification quite a bit. Having said that, though, this interface itself went through many revisions while being coded. An earlier version started with the convention of keeping the menu buttons in the top right AoK-like and hinging the Mini-Map to it (but the Mini-Map orb wound up taking up a much bigger section of the screen, plus it didn't seem like we'd need that many buttons; see attached). A counter-thought, though ... If we could stand extending the Mini-Map further down the page (by bumping the menu buttons to beneath it), we'd also have to increase the size of the Status Orb to retain symmetry. Which means more room for stat icons (see below). Again, it depends on where that new player is coming from. I mean, are we assuming that our target audience has played nothing but Age of Empires for the last few years? Someone coming from Empires/Empire Earth, for example, would feel right at home. Take a look at this: See how those buttons are mixed in together next to the Mini-Map? http://www.strategyplanet.com/empires/game/interface/ I guess what we need to establish is whom we are trying to appeal to (what's their background? what's familiar?), and what's universally necessary, because other than some major recognisable building blocks of functionality, each major RTS title tends to follow its own path. Each person will prefer the exact interface style of whichever game they've played the most (or are playing at the time, for that matter). Please keep in mind that the interface is only 50% implemented at the moment; the Status Orb in particular still needs a lot of work. As has been mentioned, there's a lot of wasted space in that orb, and we could easily shift down the icons, add some progress bars, and dedicate the top half of it to unit text of civ&class&personal names (font sizes and maximum lengths of text permitting). We could maybe also shrink down the unit portrait if we need more space? I dunno if we'd be able to fit all the other stats too (which made me wonder whether the player references them so often that he really needs to see them all the time), and I quite liked the symmetry of Status and Map taking up roughly the same amount of space on either side of the screen. Unit commands are also open to speculation. I was thinking that a dynamic set of buttons would appear around the unit, depending on his number of abilities. Some could be tab buttons (eg for building structures) and be clicked to drop up/down a list of structure icons which could be clicked to place the footprint, but none of that's attempted yet. Anyway, this section even moreso than most is definitely ripe for experimentation. The guys gave some other ideas above, and Jason said he'd throw us a few concepts. Well, I prefer to think of it as having a theme or style. Also since this is mainly using placeholders, that meant a lot of basic geometric shapes. Some actual textures, little widgets, etc would break it up considerably. But yes, other than thematic conventions there's no reason we couldn't eg make the smaller portraits square (and it has the added bonus of them being either (depending on implementation) easier to click because they take up a full square, or realistically clicked because you can't click on edges that are smoothed off). This is what happens when you send a programmer to do an artist's job. It looks okay on 1024x768, but yeah, we can easily increase the size. Again, smoothing off the edges to make them circular also makes them take up less area, so squaring them could have the desired effect. *shrug* Difference of opinion, I guess. I thought it helped to group those portraits together while still not blocking the player's view with an opaque panel, plus making it easy to dynamically adjust it depending on the number of portrait rows. In fact, if I had my way (which I don't) I'd use even more transparency to create better awareness of what's going on behind the GUI. Hmm, maybe I just need to get used to playing at a higher rez. But we also need to make the game pleasant to use at the default 1024 rez. *shrug* Please do; it's kinda broken right now. There should be up to 3 or 4 rows of portraits, but the function's stopping after the first one. Very true, although we could perhaps wangle it for the console to switch position depending on whether you're using the top or bottom GUI. Having said that, though, I think the consensus has been clear that the key WTF?! response comes from putting it on top, so the default at the very least should be for the GUI to be on the bottom for reasons of familarity (if the top GUI even survives). Trouble is that means losing the "Resource Pool and menu buttons on top of screen, but GUI is altogether" compromise. Anyway, thanks for your initial thoughts, Malte. As long as we don't kill each other in the process, attacking it from these two different directions will hopefully wittle it down to a GUI that's familiar, easy-to-use and effective to most. We needn't be in much of a hurry to finalise the GUI or design the "perfect" one either, of course ... We'll have plenty of time for it to evolve through sheer use and experimentation.
  5. Thanks for your thoughts, Malte. Really. Critical opinion is the best there is, because rest assured, if the GUI isn't appreciated by players, they won't be taking our feelings into account. They'll be filling up the pages of forums with their misspelt rants. But I'm also confident that we'll settle upon the perfect GUI through sheer use. Ultimately it's going to have to get used regularly by everyone on the team for a couple of years, plus the open beta testers, so if things don't work we should be able to fix them and find an alternative pretty promptly. When we do something that sucks, it won't be long before we know about it. Yep, always going to be the problem. It's very risky to experiment with an established interface. Even if something's better, if it increases the learning curve to the point that players don't feel comfortable, they'll give up and play something else, and we'll lose them in those crucial first five minutes of play. The trick is to therefore innovate only where innovation is required, retain the convention wherever possible, and to take very gentle steps away from the standard so it isn't too scary. The tricky part of course is establishing exactly what the 'convention' for our target audience might be. Age of Empires. Age of Mythology. Empires. Rise of Nations. All historical RTSes, and all liable to have been played by those who want to play another historical RTS. And each one with a radically different convention about where elements should appear on the screen (the Resource Pool, for instance, is differently placed in each one). So who do we want the game to appeal to? Well, everyone. And there lies the challenge. Par for the course, in my opinion. Look at the Inside the Battle movie for BfME on their interface. They went through about ten radically different designs before settling on one (and they just showed the ones that actually had completed art and were good enough to show the public; who knows how many used placeholders, were iterative adjustments, or didn't get past paper). The GUI's going to change more often than our underwear until we get the perfect match (especially if we risk trying anything that isn't an exact carbon copy of another game's interface). I figured for that reason that now seemed like a good time to try the really zany ones, especially while gameplay mechanics are being implemented, before we get too far along in development. Yeah, this is clearly the wackiest thing in the concept, which is why I went through and made a second version so we could try both. In fact, if I'd had the energy to make the bottom one the default (easy to do, just go to the session_gui empty control and change "FlipGUI()" to "FlipGUI("bottom")"), your first impression would have been a lot better, I suspect. Ironically, the top GUI was initially built on the premise of retaining those parts in the top bar like you're used to in the AoK way. Resource Pool's up the top, the menu buttons were in the top right, then started building the rest dynamically on that premise. What I also like about having it on the bottom, though, is that the (loose) conventions are automatically reestablished, or at least reasonably familiar. Unit info's in the left corner. Map's on the right. Portraits are in the middle. And it's easy on the eyes and hides stuff until you need to see it, which was the primary goal.
  6. Gee: Yeah, my new code is highly outside of your compliances (as the general lack of interactivity possible right now proves ). Will work with Malte on trying to fix all the controls that don't use proper x1/x2/y1/y2 sizes. I never really got the hang of relative sizing either until it was too late (despite you telling me how it worked a couple of times), so the GUI coordinates would also be much more efficient when I finally get around to making them relative to their empty control groups (which could then be moved around to move their children). No problem with calling it an error, as it definitely is an error. If you could output to the console which control is blocking the screen, though, as you suggested, that'd be a tremendous help, and really aid us in finding and smacking them if they ever slip through the net.
  7. Okay, thanks, Malte. And sure, there are still a lot of things that need to be finalised, particularly the Status Orb layout (and twice as many things I haven't had a chance to code yet). I hope you don't mind, but I've released a build and updated the Art Pack with the new GUI; it was beginning to become a nightmare trying to hold onto the new scripts and art while also generating and testing builds. With two of us working on it, that situation was only going to worsen. In addition, it was getting harder to keep in sync with new additions to entities and the GUI code. Also, it's more up to date than the one linked here, and I wanted to try and cut down on redundant versions. The drawback is it's also a little more broken than the one above. There are a few glitches that have crept in (such as there are supposed to be three or four rows to the Group Pane, but inexplicably it doesn't exceed the first row at the moment), but I haven't had time to fix them yet. On the upside, you can now use hotkeys to toggle parts of the interface and flip them to the top or bottom of the screen (see system.cfg for a list of the new hotkeys). On the downside, the code's double its previous length. I'm sure it's also horribly inefficient and repetitive code, but it's a start. I figure that even if we roll back to the old "panel" GUI, it'd still be a good idea to build on the code in this new one, since it's at least split into separate sections, there are more utility functions, etc. I've backed up all the original art and scripts to here: PanelGUI. I recommend bookmarking that, as we'll definitely need it in the future (ie there are some icons that aren't used yet but will need to be later, like the stat icons for things like Pierce Attack). EDIT: Uhoh, looks like I'm also getting a lot of "ERROR: Left click blocked" messages now that I've updated to a new ps.exe with the GUI fixes. I presume that means my code is loaded with 0 0 100% 100% sizes that are blocking access to the screen. Hopefully you can please help me to stamp on those and do it the right way?
  8. Yep, intuitiveness was my major concern ... Even if another GUI might work or look better, if it stops the player from enjoying his first five minutes, the game is toast. I hoped, though, that if enough of you liked it at first glance (especially if you had a chance to stick it in the game and play around with it), that might simulate that scenario. Sounds like the most controversial is, not surprisingly, the position on the screen. I'll see if I can do a version at the bottom of the screen too, and see how that comes out. Since I'm going on a whim with this top one, that could make this interface a lot "safer". Doing two interfaces: It's possible, but it means double the work and double the headache, both in testing them both to make them work, and keeping them in sync (change something in one, you have to change something in the other). For example, say I made two, one anchored to the top, one to the bottom. All the images have to be duplicated and flipped (increases size of assets), all control coordinates have to be duplicated and recalculated. Also it doubles the amount of localisation to do (and text fragments aren't always going to be in the same places or even calculated the same way). I gotta do it anyway to get a bottom sample , so I'll give it a shot, but life would be a lot easier if we could establish one interface that pleases everyone. Good point about the "zero" symbolism, Bobby. Makes it seem less like I stole it from BfME's Palintari. (sp?) Mark: A dynamic 3D plane minimap that conforms to the camera angle? Very interesting. I'll have to chat to you about that when I get back (gotta head out for the weekend now).
  9. Thanks, Boris. I'll look into that. I actually experimented with circular health bars in an earlier revision (attached), but in the end decided to go with something simpler because non-rectangular progress bars seemed quite tricky to do. Well, I must say I'm very impressed with the feedback so far. I was expecting to be strung from the yard arm.
  10. Yeah, currently I just used placeholder images to convey the overall intent (black bordered backgrounds), etc. Hopefully the GUI artists could then redo them and give the interface some personality (which hopefully might make it look less space-agey). Well, I was mainly referring to AoE/AoK. I can't immediately think of any other game than AoM that puts its resources in the lower left; it's an interface in a league of its own.
  11. Well, we could use a tooltip for that, and hover the cursor over any portrait to get the unit's name, class, owner, etc, as mentioned (Cry of Indignation #5), but yeah, I could see where we could fit that.
  12. Like Aviv, I recently had a dream. Over the last week or two I've been refining that flash frame that came in the night after doing a lot interface research, and putting it into scripted form to prototype how it pans out. It's very unusual, so I'm almost certain it will be disregarded for reasons of unfamiliarity alone. But I had to give it a shot, and to my twisted mind, it doesn't seem that inaccessible (maybe just because I've been looking at it for too long). So, I've had a crack at mocking it up in the GUI (with the aid of Jason for some placeholder art, and Gustav with various pestering questions) so that you can take it for a test drive. I've mainly just put some basic controls on the screen with minimal functionality; a lot of what I still plan to do depends upon accessing some entity stats, some more GUI controls, some extra events, and a couple of fixes. Where there's something in the GUI that I've noticed needs improvement, I've marked that to describe it in more detail in this topic's footnote. I hope it gives you a rough idea, though. I also dumped a lot of the GUI script and started over, just to keep the pages clean. It's probably highly incompliant and buggy, but at least it's consistent. If you want to check it out, make sure you have the Latest Build, Art Pack and System Pack. EDIT EDIT EDIT Only download this file and unzip the contents over the top to overwrite GUI art and scripts if you want to revert to a version that's a couple of weeks old (but less buggy). The one in the build is more recent. EDIT EDIT EDIT Hopefully it's not missing any files. It's been a long couple of weeks. If it doesn't work, try removing your official/gui/ folder and replace it with this one (it might not like additional files declaring the same objects). OBJECTIVES I had a few objectives while putting this into place ... a] Centralise: Keep the GUI in one area of the screen. b] Maximise: The player's view of the game world. The interface should support his interaction with that world, not become the focus. This includes using a lot of dynamic elements. If the player doesn't need to see part of the interface, remove it so that he can look at the world instead. c] Smooth: I was reminded of something Malte told me earlier, which I'll paraphrase ... Rectangular controls are very space-efficient, but curves are much easier on the eyes, kind of an ergonomics thing. So, I went out to maximise the use of circles and arcs. Major inspiration here came from Battle for Middle Earth and Warrior Kings: Battles. d] Symmetry: Try to keep a decent balance between either side of the screen. PREVIEW For those without the patience or desire to set up a testbed, though, here's some screenshots. This is how the interface might look if the player doesn't have a unit selected. Note that only the mandatory stuff is shown on the screen: Resource Pool and Mini-Map, and they're tucked away in the corner of the screen. All the rest is dedicated to the game world. This is the worse-case scenario. The player has selected a whole bunch of units and he's saved a full complement of groups to the 1-9 hotkeys. INITIAL REACTION Cry of Indignation #1: "Have you taken leave of your senses? Why are you putting the interface at the top of the screen?" The interface could work just as well at the bottom, but while I was at it, I thought I'd try something ... Due to the perspective of the camera, things at the bottom of the screen are larger and more accessible than those in the distance. By putting the interface on the bottom, we're effectively stopping the player from interacting with items that are right in front of his face, and forcing him to click on stuff that's further away. This situation is only worsened with the perspective camera that Jason has in mind (have a look at ScEd for an example of the "chess board" angle that he ultimately has in mind). Anyway, try it out, see what you think. Either could be done. As an added bonus, it keeps the Resource Pool where Agers expect it to be. Cry of Indignation #2: "Ha, you fool! You finally caved in and moved the Mini Map to the right. We were right all along, haha." This is true, and the method in this madness was the result of looking at a Behind the Battle movie of BfME about its interface (I've lost the link, but Jason could provide it if you're interested). Their GUI is even more spartan than this one (there's no Group Pane, no Team Tray, etc). What they did, though was put the core of their GUI -- the Mini-Map -- right down in the bottom left corner, and built other interface components on that as needed. Just about everything springs out of the bottom left corner, but virtually everywhere else is clear. Even so, I couldn't help feeling that was the part of the screen I wanted to look at the most; I don't know about anyone else, but typically my focus is on the centre of the screen (particularly the mouse cursor) and to left of centre. But I'm quasi-ambidextrous, so I could just be badly wired. Anyway, see what you think. Cry of Indignation #3 (from Aviv): "What happened to my resource icons, you fiend?" Jason made up another batch, largely by accident: I asked him to make a circular set for a unit's Supply to match the gold-and-white statistic icons we already have; then it turns out they look better uncircular. Since we had the assets, I thought I'd throw them in here too to see how they look in-game. I shall leave it up to others to decide which combination is preferable. GUI COMPONENTS Let's focus on the second screenshot and go through all the components of the GUI: RESOURCE POOL The set of five counters and icons at the top centre of the screen, showing the player's Food, Wood, Stone, Ore, and Population. Nothing you haven't seen before. MINIMAP ORB * Mini-Map: In the top right is the miniaturised view of the game world. Same old, same old. The size of the minimap box pretty much defines how much of the screen the interface is occupying. People like a big clear, mini-map that lets them distinguish details like different unit colours, so I used square and top-down for clarity. That's about the only square thing on the screen, though. * Mini-Map Buttons: These 8 buttons wrap the Mini-Map, turning it into a circular orb. I call this construct the Mini-Map Orb. 4 buttons are for sub-windows (prob. Diplomacy, Objectives, Chat/Tech-Tree, Menu). 4 are for navigation/map controls (prob. Signal Flare, Idle Villager, Last Notification, Civ Centre Cycle). I don't have the talent to create icons, and they don't do anything anyway right now. One handy thing about this arc construct is that we can prioritise our buttons. Buttons that get used regularly (like Idle Villager) can be on the larger central buttons. Buttons that aren't used as often (like Signal Flare) can be on a smaller edge button. STATUS ORB On the left-hand side of the screen we have an orb that appears when the player selects at least one unit. This is basically the statistic window, and it shows details about the selected unit (or the leader of the group). It consists of: * a 64x64 portrait (which can be clicked to centre on the unit); * Red Heart: hitpoint counter (I'll probably also put a hitpoint bar there too; I couldn't get progress bars to work at the moment); doesn't appear for invulnerable objects; * Yellow Chevron: counts the number of upgrade points until the unit's next rank (number of chevrons, 1, 2, 3, indicate the current rank; only appears for Citizen Soldiers; * Meat: shows the resource type and quantity of supply (eg wood in a tree, food on an animal); only appears if the unit is carrying some kind of resource; * Gate: Number of units garrisoned out of maximum; only appears if unit (eg building, ship) can be garrisoned. Cry of Indignation #4: "What about attack, speed, accuracy, etc?" This unsettled me too at first. Then I realised ... how often does the player really have to check a unit's attack rate? Very rarely. Maybe once in a blue moon he'll compare two units to see which has the best attack. The only stats that player needs to monitor are those that change regularly. For the rest, we have the online manual. A page of detailed stats, descriptions and histories are just a hotkey away (a la AoM's manual). Because it's pulling data directly from the game at run-time, we can also display any dynamic stats (eg the +2, -1 modifiers gained from techs) in the manual. Icons indicating that the unit is being locally affected in some way and his stats are changing (eg in range of an Aura) might also need to be appear here, that's another option, or it might just create unnecessary clutter. Still, there's plenty of room in the corners of the orb for extra icons if needed. COMMAND BUTTONS Around the Status Orb appear all portraits for all the commands available to the unit. This is dynamic, so if a unit has 3 commands (Garrison, Scout, etc), then just 3 icons will appear. Equally, if a command later becomes available (Ungarrison) then it'll pop onto the arc. These start in the right-hand corner of the Status Orb and arc out on either side. This keeps the icons closer to the centre of the screen for easier mouse access. This section is still under a lot of consideration, mostly because it'll need to read entity abilities to generate the commands(1). What I'm thinking of doing though is integrating tabs into here alongside normal buttons. eg in Warcraft you click Build Basic and it fills out the Command Card with buttons for all basic buildings to construct. In this case, you click, say, the Build Military button in this set of command buttons, and a second arc of buttons appears around the primary set, showing all the military buildings that can be constructed under that "tab". Because you're building on another circle, this means a wider radius and so up to 12 buttons could fit in that arc. I didn't add the secondary buttons since it's totally non-interactive right now(1), but hopefully you get the idea. Another possibility is a radial menu that appears over a building when you hover the cursor over it and you can select techs, etc, that way. This is slightly less intuitive, though (not to mention impossible to implement right now).(2) The buttons may need to be larger than 32x32 too (for one thing, circular buttons appear smaller, since the corners are cut off). It depends on just how many buttons we have to display at once for each unit. GROUP PANE Below the Resource Pool is a list of any group the player currently has selected. Depending on the context, this could be the portraits (and hitpoint bars) of a bunch of units the player has selected, the research/training queue for a building, the units garrisoned in a ship, and so forth. The semi-translucent box is dynamic, and increases in size as the number of units in the group increases and more rows are added. I stopped at 3 rows, 13 on each row = 39 in a group, but we could easily add another row without exceeding the height of the interface, maybe even add another column on either side up to a max of 15x4 = 60, twice what we could do with the existing interface plan. Currently the group is centered for symmetry's sake, but we can make the group add up in any order we want. Obviously one would be able to click the different portraits to do appropriate things (select a unit from the group, cancel a tech in a research queue), but I couldn't seem to get that to work at the moment.(4) TEAM TRAY Finally, the numbered batch of portraits on the far right is the Team Tray. This shows the portrait of the unit most common to a saved group, and provides a mouse-controlled way to select (left-click) and save (right-click) Ctrl groups. This is the least necessary part of this interface, and could easily be scrapped if more screen visibility is preferred. It's not considered a mandatory part of an RTS interface (only a couple of games eg AoM have used it -- though it just displayed broad classes like cavalry or ranged), but it does have the advantage of helping you to remember what you've saved to each group. Keep in mind also that any part of this interface could have a hotkey to toggle that component. The player could even play full-screen if he wanted to (though that'd be pretty crazy with no map and no resource view). ODDS AND SODS There are a few little details of an interface that aren't covered in this example, and I'm not entirely sure where to put them. * Event Text: eg "Acumen has allied with you", "You have been defeated". These typically get put in the top left corner of the screen, which is currently occupied. I guess they could either go in the bottom left, or on the left below the interface, depending on which works better. * Chat Cursor: Where to put the cursor and input string when the player is sending chat messages? Again, probably bottom left or underneath the interface panel. * Triggered Counters: eg a counter until the territorial borders between Provinces goes down, the number of Houses the player has to build to complete an objective, etc. These usually get put on the far right. * Scores: List of the scores of each player, in player colour. Again, usually on the left. Usually only used by ladder players or the extremely competitive (score-based games are fairly rare). * Time Elapsed/FPS: On the left again, normally. Cry of Indignation #5: "Well, that's just great, genius? But what about all the descriptive text? How does the player know a Hoplite from a Triari? How does he know to whom a unit belongs?" For this sort of stuff, I'm planning to hide it away in a tooltip (with any less important text going into the manual). Unfortunately tooltips don't seem to be working at the moment(3), but fixed-position (like the main menu one) and following (appears near to the cursor) types are covered in the GUI TDD. I'd suggest going with the cursor-anchored one in this case. Finally, there are other things we're used to seeing in text-heavy RTS games, like a progress bar at the top of the screen indicating the progress to the player's next Age (or what Age he's currently in). I'm banking on that being less necessary in this game, though, due to the lack of an Age focus (the city upgrade system is very much like that in Warcraft, for example, and they don't seem to need one). If there's other critical RTS stuff that I've missed, please shout it out and I'll try to figure out how to make it fit. Well, that was extremely long, and if you've managed to read through all this without skimming, I'm very impressed, thanks. ( *awaits the inevitable cascade of scorn and derision* (1) I unfortunately can't get most buttons to do anything because currently the game map doesn't seem know when the mouse is over a GUI object, and so clicking on a control that's over, say, grass, makes the cursor select the grass and therefore deselect the unit. Since having no unit selected hides the dynamic GUI, that means I can't do very much interaction at the moment. (2) Basically we'd need to look into creating controls that are aware of an object in the gameworld, can be anchored to and follow them, and so on. Like hitpoint bars, and so forth. Currently the 2D and 3D view are very separate entities. (3) Quite a few of the controls detailed in the GUI TDD unfortunately don't seem to be available yet (or maybe I just can't figure out how to use them properly). This includes input box, tooltip, checkbox, radiobutton, and progressbar. A bit of a shame, as I was really amped after reading the docs, and spent hours revising the script trying to make them work. (4) Also I think we're going to have to create some additional entity flags that the GUI can recognise. For example, I have to update the info for the selected unit every tick, which is coming to be a lot of code to do every time with all these dynamic groups. If we were able to check for an event that a different entity(s) has been selected, then we could cut down on some overhead.
  13. Well said, Malte. I hope you don't mind, Argalius, but I've added Malte's disclaimer to your FAQ to make that abundantly clear.
  14. This isn't exactly a bug, but more of an amusing workaround. In Baldur's Gate, they had a fallback mechanism should it be scripted for a character to speak dialogue, but for some reason he's not on the map (you've killed him, he didn't spawn correctly, etc). A mysterious character called Biff the Understudy would materialise and read his lines for him. The show must go on.
  15. Just for the record, we're planning to make 0 A.D. available under Win2k+ and Linux systems, and currently the engine works perfectly on both platforms.
  16. Klaas: Good idea about the wooden temples. It'd be ideal if we didn't have to do some forest grove, as it needs to be able to produce units, do research like a normal building. Would be a bit strange.
  17. To answer your question about the trees, Bobby, they do look a little pixelated, although so does the rest of the image, to an extent, so I figured that was probably the result of JPEG artefacts. A little antialiasing in a future milestone should hopefully improve on that, but the tree meshes are definitely much improved over their predecessors. And indeed, suggestions for a historically appropriate version of the Celtic temple would be much appreciated.
  18. Nope, no bump mapping; just incredibly gifted artists. Graphically things will improve during development. We're focusing on implementing the basics for now and will make cosmetic improvements to the renderer further down the line.
  19. Information on release dates are purely the domain of the "Holy of Holies", so I'll leave that one for Jason. But, I'll take this opportunity to shed some light on the matter of release dates as it pertains to the nature of an online project. a] We're new to this. For most of us, this is our first project of this scale. That means a lot of unknowns, a lot of experimentation, a lot of growth and learning, a lot of mistakes and learning from mistakes. In many respects, we simply have no idea how long something will take to do until we've done it. b] This is a hobby, not a full-time job. We only clock as many man-hours as people are willing and able to give at any time. Members come and go. Stuff happens (I, for example, have been bedridden for the last couple of weeks following an operation, which affects the time I can commit). And since we're not doing this for a living, we can expect things to take three times longer than they would in the 10-20 hour days of "real world" game development (then double that for insurance). Where, I might add, it still takes several years to ship a game with full-time trained professionals. c] We want to take the time to do this right. No money, development contracts, salaries, monthly costs, or external influences like publisher mandates are in place to force us to ship a buggy product by Christmas, come what may. We're in the best possible position to have it done when it's ready. In short, it's tough to schedule and define timed milestones when man hours aren't fixed and performance can't be quantified. Any fixed date could therefore be described as little more than a vague goal to encourage motivation. However, if you want a guesstimate ... We've made unprecedented progress in the last few months, and I have no doubt that it's going to just keep getting better in the months to come. Even so, given the ambitiousness and complexity of the project, that the technology is being entirely built from the ground up (including creating a viable infrastructure for TLA and RTS modding), and the circumstances under which we work, I wouldn't expect to see a beta this year. But I do anticipate that we'll see significant progress along the path to that destination. I say that now because I wouldn't want to see us accused of "pulling a Valve" come Christmas. Nor of hyping the game to unattainable heights a la Tiberian Sun. But, if you feel that we're taking too long and/or you can't wait, let me offer a suggestion ... Help. WFG exists because people all over the world are willing to come together, give up their free time, and work long hours in order to accomplish a highly ambitious dream, and learn and grow in their trades as it takes shape. It is the skill and sweat of such people that will bring us to the seemingly revered beta and beyond. If you could make a difference, if you have the skill, maturity, time, and perseverance to assist 0 A.D. in rising above the desert of bones that is independent game development, then please contact the appropriate Department Lead for an application form.
  20. Wonderful! I'm off to go rename all the Persian units and buildings.
  21. Excellent, thanks! Here's the full list (it adds up, huh? ) Arabian = Tazi (originally from Tayy (an Arab tribe), later used for all the Arabs, also means "arabian hounddog") Aramaean = Arami Archer = Kamandar Armoured = Zerehi Armoured Horse = Aspzerehi, Zerehasp Fully Armoured Horse = Asp-i Porzereh Assyria = Ashura Assyrian = Ashuri Armoury = Zerehgah Blacksmith = Ahangari Babylon = Babiru Babylonian = Babirui Bactria = Balxa Bactrian = Balxi Bireme = Dorade Camelry = Shotorsavan Cappadocian = Kappadoki Cataphract, Heavy Cavalry = See Armoured Horse, Fully Armoured Horse Cavalry = Aspsavaran Chariot = Charxjangi Cilician = Silisi Corral = Jânvargâh Cypriad = Kebresi Dock = Langargâh Farm = Keshtzar Farmer = Keshavarz Fishing Boat = Kashti Mahigiri Fully Armoured = Porzereh Fully Covered = Porpushesh Gate = Darvâze Granary = Jowgah Harbour = (See Dock) Heavy = Sangin Horse = Asp, Spah Horsekiller = Aspkosh Indian = Hendi Infantry = Piyade Ionian = Yunani (old name for Greeks) Javelinist/Javelineer = Zhupinandaz, Zhupindar Knight = Gord Lancer = (See Spearman) Light = Sabok Light Cavalry = Asp-i Sabok Magus = (See Priest) Man = Mard Mede = Mad Media = Mada Median = Mad (language = Madi) Merchantman = Bazargan Mesapotamian = Miyanrudani Mill = Asiya Orchard = Golestan Outpost = Padgan Palace = Kax Peasant = Dehgan Persian = Pars (language = Parsi) Phoenician = Fenisi Phrygian = Frigi Port = (see Dock) Priest = Mogh Ram = Darvazkub Rider, Horseman = Aspsavar Ship = Kashti Skirmisher = Zhupinandaz Slinger = Tirandaz Soldier = Sarbaz Spearman = Neyzedar Stable = Âxor Swordsman = Shamshirdar Temple = Âtashkade "the Great" = -e Bozorg (eg Darius-e Bozorg) Thrower = Andaz Tower = Borj Trade = Bazargani Trade Ship = Kashti Bazargani Transport Ship = Kashti Kasbar Trireme = Serade Three = Se Two = Do Village = Rusta Villager = Rustayi Wall = Divar War Elephant = Pil Jangi Woman = Zan, Banu Zoroastrian = Zartoshti
  22. Wonderful, thanks! I just have a few more, and then we're all done: Corral = (A corral is an animal pen, a fenced enclosure where animals are kept; kind of like an open-air stable) Gate Dock, Port, Harbour Priest, Magus Temple About the accented a's: yes, please. I've been compiling your translations into a full list, so I'll post the full list once we're finished.
  23. Tonto_Sanjab, Thanks very much for your translations. They were a tremendous boon. Could I please request a few more to finish it off, and then I'll run the list by you, if that's okay: Camelry Cavalry Fishing Boat Javelinist/Javelineer Lancer Merchantman (Trade/Transport Ship) Swordsman Trader Babylonian Cilician Cypriad Median Persian Phoenician Zoroastrian Armoury Corral Orchard Outpost Palace Tower Wall the Great (as in "Darius the Great")
  24. Tally-ho! Ta for the publicity, chaps. That'll give one to Jerry, me old rucker. *takes his medication* Excellent, gamedev.net were even kind enough to make it a Featured Article. Also, Jason informs me that they've made a comments thread for it. I was naturally compelled to post a reply almost as long as the original article.
×
×
  • Create New...