Jump to content

Fire Giant

WFG Retired
  • Posts

    1.319
  • Joined

  • Last visited

Everything posted by Fire Giant

  1. Exactly. The often imagined "Asterix"-legionaries with square shields and standardized armor and weapons are in fact the troops of the late republic and the empire, which came up after the Marian reforms which allowed poor plebejans (who could not pay for their own equipment) to enter military service as well. Before, the army was divided into the Velites, Hastatii, Pricipes and Triarii units (as shown in Rome - TW as well; though they are wrong with some details about the equipment in Rome). With these reforms, not only the whole army life and equipment changed, but also the tactics commanders used. We are trying to represent this dramatic change - which not only involves the army, but rather the whole society and government structures after the rise of Caesar and Augustus - by dividing the romans into two civilisations. Sure, it might look somewhat annoying if Republician Romans fight against Imperial Romans, but you can have such a conflict with all other civilisations as well (Iberians probably have never met Dacians in battle). The Imperial Romans will surely be played quite different from the Republician Romans, and with some other neat features we have decided to put back for Part II, we might be able to represent the Imperial Roman army as accurate as possible and give this civilisation the uniqueness it deserves
  2. Think of Imperial Rome, the Parthians, the Huns, the Dacians, for example
  3. Congratulations on the successful launch to everyone who was involved with creating this new website! It is (IMO) a milestone of advance for WFG PR, since it's a lot better than the old site and personally appeals much more to me (and I doubt that's much different with other people). Great work, everyone!
  4. I don't know exactly, but somewhere in December/January 2001 (?), I think... but Jason should know this much better. As I said, I've only been actively involved with WFG for about two years now, and therefore don't know the very old times - though I already knew WFG when it was still called WFS and 0 A.D. was still an AoK mod
  5. LOL, some people here seem to overestimate the progress we made on the game in the last months - we haven't even had any time to *think* about implementing such things as dripping water, as we do not even have all game-basics in place Probably we can talk about that again in late 2005 or early 2006... though it may probably never come, due to being technically possible but very complicated to implement. Please do not forget that we need basic game elements to be done before we can get started on anything "new" or "nice-to-have".
  6. No, I think space was one of the reasons why we switched to full-3d, as high-quality 2d renders tend to be larger than a 3d model plus its texture. Also, we wanted to have the option to have a "free camera" for cinematics and such neat things, and we concluded that graphics hardware will be much faster in some years, so we can still have good-looking buildings, even if they are 3d. Asides, I think full-3d was easier to code for the programmers
  7. Just a remark: There already is a discussion on that Javascript thing in this thread. Anyway, I do agree with you, Simon We cannot expect everyone to have cookies allowed and might therefore even scare off new members who have already registered themselves but get annoyed by this JS thing every time they visit the forums.
  8. Hmm, somewhere in the late year, I know that - when I joined, it was some time after the first anniversary of WFG, and I joined in very early (January) 2003 (it feels like it has been a much longer time, though - I had to take a look at my Outlook in order to see wheter it wasn't 2002!)... maybe the anniversary is in late October or early November - but we'll need someone who's been at WFG longer than me to tell us
  9. I think I can say this without having any PR- and confidentality-doubts: We don't know yet, as water isn't implemented so far
  10. Same here in Germany, Halloween isn't too popular here, though the companies try to make more money from it every year. I personally won't do any celebrations, the only important thing this weekend for me is that the daylight saving time all over Europe gets changed back to normal time at 3:00 am tomorrow, so time zones will change yet again and I have to find out at what time the programming department meetings will start then
  11. Hmm, I wonder how the menu background link got leaked - if I remember correctly, the image was only posted on the intranet for in-team use... However, I could delete the image any time I want - but in fact I'm too lazy Or is it stored on another website? (could you PM me the link in that case?) Besides, that menu background image is very old already, and the actual background in the latest versions looks quite different
  12. I guess you'll learn more as soon as the game reaches beta or release stage Asides, I think there *may* be preview articles some time dealing with those gameplay stuff - but it way too early for that right now.
  13. It has been over a year since I have read the DD for the last time, but I'm pretty sure that it says yes
  14. I'd say no, too. I've never used it too much, and the community isn't as large that we are going to have a forum shop too soon.
  15. Thanks, Philip. I think I might have located the problem then - the script is trying to assign the size in a string-like format. I'll probably look into this in the afternoon today.
  16. Probably we could have a config entry for that? Like, if developer mode is toggled on, the last five lines of the console would be displayed on top of the screen on a nearly transparent panel. I think that would be helpful, but it's not urgently necessary, since we can always look at the log wheter something broke. Also, how does the GUISize-Type work? I know that setting it to something like "10 10 20% 20%" works, but if I take these variables out of other variables (an array in case of the current GUI code, I think), it doesn't seem to work and complains about the value not being a "GUISize type" (but probably there's only a type somewhere in there, though, will try to check again).
  17. Thanks for the indeed very long (yes, there's actually someone reading the task updates out here ) and well-written reply, Stuart. I admit that you are quite right in some points, but I'd really like to further discuss some others. However, I do not have the time to type up a long reply today (and won't have it tomorrow, probably), but I also do not want to finish this with a hastened reply, so I won't write anything right now. Only one thing - I noticed the problem with selections using more than one row, and also noticed the cause of the error: Somehow, the GUI doesn't accept your current values as valid for GUI size (it didn't work with making them strings as well, though, I think). I'll look into this - but the GUI code has gotten a lot longer and I need to get into it and know what's where again in order to know what to change and what not to change in order not to break even more stuff.
  18. Hmm, even though it may look slightly strange - I'm not the one to get crazily happy about the merger. It means that there will be even more new posts and topics every day, and I will have to read them all if I use the "View New Posts" feature - and since I acutally sometimes hardly manage to read all the new posts in the 0ad forums on weekdays, I'm not too happy with the new situation. But we'll see how things develop Probably the downtime will make me start to do real work for the game again for a change; the most I've done in the last week was attending the meeting and reading over the GUI code one time, noticing that there are some errors I don't know how to fix
  19. Okay, here's my promised reply (I hope I'll manage to write it parallel to the programming meeting and I'll manage to finish it before dinner). When I first saw this concept, I honestly thought "Oh no, what's that - he's ruining the GUI" (please don't take that personally, Stuart - I just want to be honest), but lateron my opinion changed a little. I'll therefore exlain my concerns, ideas and suggestions. 1. The Innovation vs. Intuitiveness-dilemma As you remember, we already had that discussion back when we were first writing the old GUI DD in early 2003 (or was it 2002? I really don't remember). The first GUI was innovative and we had a lot of great ideas in it. But then, the design team decided to go back to a old-fashioned GUI for the sake of playability and intuitiveness. Now, it looks to me like we are rapidly going back this way and even further into the "innovation"-direction than we ever have been. Well, nothing is wrong with that - I've never been the one who was against innovation in the GUI. The problem which is some kind of appearing to me is, though, that we will probably later flip around again and decide to go a more conventional way again (probably based on feedback from beta tests). A counterargument for that is that we can more easily experiment at this early stage, though. This is not a major concern to me, but I wanted to mention it. 2. The top-alignment I don't know why, but this is something I really don't like about the new GUI. Having GUI controls "hang down" from the top like apples on a tree just doesn't look appealing to me. Sure, all the argument for it are clear and theoretically right (better battlefield perspective, windows apps having controls on the top), but somehow, it doesn't look right to me. Probably it's the fact that the GUI build a solid "base" for the screen, or the fact that in non-scifi RTS games I'm imagining to have my "tools" and "documents" (the GUI) right in front of me while looking around (like a table). In the latest version, where one can flip the GUI to the bottom, I have to say that I like the idea of the rounded and innovative GUI much more (haven't looked at the code yet though). The resource tray should go back to the top, though (okay, I've fought for that thing all the time I've been in charge of the GUI and even though I deeply know that there are good arguments against it ). 3. The lack of information That's a major, probably the largest, problem to me. Probably I'm an exception, but I do care about exact stats for the units - I really like to know how much attack and armor my units have just now, if only for comparison with other players units. And I know I'd never open a ingame documentation during a heated multiplayer game or look at tooltips. This lack of exact information is a major problem I have with C&C Generals as well (they don't have ANY unit stats there, only HP bars). Especially for RPG-style scenarios it's likely to be very important to know the exact stats of a unit in order to be able to judge wheter to attack an enemy or better flee the combat. In the same kind of scenarios, the unit names are very important, because hero and object names are frequently changed in these scns, and one often need direct attention. Therefore, I would really suggest not to leave out the unit name (also, our nice random-name feature couldn't be used efficiently when the player hardly sees the names). Maybe I'm a stats freak, but I simply don't like to have to assume wheter my unite are stronger or weaker than another players units - I want to know it by hard facts, even though I'm surely aware of the fact that this idea really isn't historically accurate (in ancient battles, they also could only assume how strong their enemies were). Asides, I think the area representing the selected unit needs to be larger anyway. With its current size, it kind of reminds me of the advisor portrait in "Rome - Total War" - something I only liked the first couple of times it appeared and which I turned of after 30 minutes. And out unit representation is one of the most important parts of the GUI, so it should get the most prominent place and size of all GUI parts. 4. The overuse of circles vs. the overuse of rectangles This is a general problem that occured with all the GUIs we had up to date - they used one shape, and used that extensively. But a good, "living" GUI needs different forms, different shapes, all kind of "loosening up" that it can get. This can be done through asymmetry (sp?), rough borders, ornaments, organic shapes and such - but a circle- or rectangle-only GUI is very functional but doesn't look like it belongs to our detailed, nice little world. Because of this, I'd suggest that we try to mix different shapes. For example, the unit potrait icon IMO doesn't necessarily have to be circular, even in the new orb GUI. We could also use a rectangle here, or a overlay that gives the image smooth borders (I'd have to try it out). What I want to say is, that we should (at least in out time period) not rely on perfect, functional, black-grey circles only. 5. The placement of the menu buttons Minor thing, but it annoys me - the menu buttons are placed directly near the minimap and therefore loose their prominent place and their "importance" gets downgraded to a little more importance than the minimap buttons have. I highly doubt that a new player will find them intuitively, without being told where they are. 6. The semi-transparent background of the group selection thing Semi-transparence generally isn't a bad thing, I used it myself for the main menu tooltip. But I personally think it should only be used for possibly redundant info like tooltips - because it always still has the irritating "background" behind it and the viewer doesn't focus on what's actually on the semi-transparent area. Also, I personally believe that the unit portraits are too small (may be due to my high resolution, though). Besides these concerns - great work on the group selection display, Stuart. I haven't yet looked at the code, but it is looking great and I'm sure it saved me a lot of script coding 7. The developer problem This is really minor, but an issue I won't like to forget: If we have the GUI at the top, the console will be over it once opened. And as the developers of the game, we will likely need to have the console and GUI open both in order to check something some time - and it might be really annoying if we have to switch on and off the console multiple times just to compare some data. Okay, these were a lot of concerns and problems (and I guess there will be even more coming to my mind), but I should not forget to say some other things: 1. In general, I like the idea of an innovative and "new" GUI. 2. I'm not against reducing the screen space occupied by the GUI, too. The general idea of this new GUI certainly is right. 3. Though we should probably still discuss some details, I'm not completely against this GUI - even the opposite, I favor this one above the old one, but I think there's still the need and room for improvements. I think I will try out some things in the next days and put up my version for discussion - as I said, I think it's generally a good idea to start off from this GUI, and so I will do and try to find a good compromise between this and the old GUI. I'm too tired to write anything further now - I'm sure there's more to say about this, but I'll keep that for tomorrow.
  20. Interesting proposal, Stuart. I have only briefly read over this yet and installed the OrbGUI into my binaries, and now - after almost six hours of reading forum topics - I'm too tired to write up my thoughts about it. I guess I'll sleep about it and write a longer reply tomorrow. My first impression, though, is that it is an interesting alternative which needs some tweaking in some aspects to fit my ideas of the GUI - but after all, I'm only one person, and I'll happily give in if the rest of the team votes against me
  21. Hmm, this is a tough question - making the scripting system is a process of complexity (i.e. greater possibilites and options for advanced scripters) vs. ease-of-use (better for newbie scripters and easy start-off). I guess, though, that we will be aiming for a more AoM-like system, since that will integrate better with our scripting environment and the engine.
  22. Sounds a little like "Rise of Rome", no ? Anyway, it's better than the old name... though I think you guys will have plenty of time to play around with names and concepts for your mod as it will still take a lot of time until the real game itself is done
  23. Yepp, they got started on the 3d engine right after AoE was out (though only with a very small team of one or two programmers)... so you may as well add two years
  24. Nice FAQ, Argalius That should definately sort out some confusion about modding in 0 A.D. Still, I'd like to add something: This is how we think it will likely be - we cannot promise anything, and if technical or gameplay specifications require to change anything from this list, it might not be in the final version the same way it's described here...
  25. Since 0 A.D. is a historically based real time strategy game, I guess you won't be seing anything like magicians in it - since there is no proven evidence of any magician, wizard or witch and their abilities. We try to keep quite near to real history, as long as gameplay doesn't require otherwise. For fantasy stuff, you'll likely have to wait for TLA
×
×
  • Create New...