Jump to content

feneur

Administrators
  • Posts

    9.642
  • Joined

  • Last visited

  • Days Won

    102

Everything posted by feneur

  1. Sounds good. And don't worry, keep the grammar section as long as you need
  2. Would it be possible to have two versions of this? I.e. one for programmers who needs the "deep-down" version, with the RELAX NG Grammar and so on, and a simpler one for scripters/modders/artists who might want to/need to edit these files? That could be too much work/make things unnecessarily complicated, but at least a notice at the top which makes it clear what goes in the actual XML file and what's for the game to understand so to speak. I'm guessing (/hoping) there will be examples in each section as well which would help a lot (and lessen the need to split things/oversimplify). I'm not sure if it's just me, but it can be hard to remember exactly what's the difference between integer/decimal etc, do you think it would be possible to add some quick reference, either to each listing of Value type (which sounds a bit too much) or a cheat sheet at the top of the page? I'm not sure how much use it will be, but it would make it easier to edit/mod the entities. And since editing the entities is something that's probably going to be needed to be done a lot when we start playtesting + it can be a boring/menial task it would be nice if it would be as easy as possible to allow for as many as possible to do it.
  3. (And just to make sure I'm not misunderstood I meant "is" in the future tense not the present, though I hope it gets present not too far into the future )
  4. Ok, as long as it is updated it's fine with me
  5. Michael, are you sure about that for the Hellenes? Because in that case the DD could use an update
  6. You are allowed to write a proposal Seriously though, if you want us to give you some kind of official status you'll have to show us that you are ready to put in the time and effort to get this finished + show us an interesting enough idea We can't, nor want to, stop you or anyone else from using the art or any other resources we provide as long as you or anyone else do what the license allows you to do, but it takes a bit more than a good idea to be a part of the Wildfire Games team. Please tell us more about your proposal though.
  7. Hmm, seems like I'll have to explain the design a bit. Only the Citizen Soldiers have economic abilities as well, each civilization also has what we've chosen to call "Super Units" who are meant to represent the professional soldiers. They're better than the Citizen Soldiers at fighting, but cannot be built until later in the game and don't have any economic abilities, and of course cost more. Also the Citizen Soldiers upgrade (Basic-->Advanced-->Elite), which means that the more they fight the better they get at fighting - but also less and less good at economic tasks. Speaking a bit more about Rushing: At the start each player will have a few units + a small amount of resources, if one really wants to one can of course take those first units + the few one can build using the resources one gets at the start of the game to go attack the enemy at the start. But unless on a very small map I'd guess the enemy would have time to gather enough resources in the amount of time it takes to travel to the enemy to have a larger army than the attacker. And even if not, the enemy is still likely to have the same amount of units as they have the same starting amount of resources/units and he/she doesn't have to choose between military civilian units so it should be a fair fight. That said, it can still be a valid strategy to try and rush, for example your enemy might spread out his units too far so you might take them out one by one or something. But that could happen regardless of whether you get units which can fight at the start of the game or later. Finally I'd like to say that before we make a final release we want to take a lot of time to playtest the game to make sure it's as balanced as we can make it. In other words, if we find that it's too easy to rush we might lower the amount of resources a player get at the start of the game or if we find that a unit is too overpowered we'll lower its attack or whichever is making it overpowered and what else might be necessary. EDIT: Seems like Michael had something wiser to say while I wrote the long post above I still think some of it might be valid, but yeah, the game is still a work in progress, and if we find that things don't work then we'll have to change them.
  8. Philip is one of the team members, and sure creating a browser game could potentially be interesting, but at least within the closest future I think the main 0 A.D. game will be our main priority. And even in the case there will be an official browser game I don't think it's a bad idea for someone else to do it as well, to use the graphics he'll have to provide a link back to us so we'd still be getting the news out about 0 A.D.
  9. Eh? Where have we said we consider creating a browser based game? It's not something we've considered to my knowledge, and I should at least know about it if it's been discussed the last couple of years since I'm the project leader (We have discussed using Webkit, which is used in browsers, as the basis for the GUI, but that's something totally different.)
  10. Hello Pavan, thanks for your interest in 0 A.D. To address the first issue of military units being available from the start I quote from the Design Document: So yeah, military units will be available from the start, but while you are free to think what you want about that it would be more interesting if you would provide a reason for why you think that's a bad decision than just to say that it's a flaw. I'll provide some reasons why I think it's a good idea, and then you are free to provide some reasons why it's not, I doubt we're going to change one of the most fundamental ideas of our design, but you are free to try and convince us why we should To me it seems like it's less likely to encourage too much rushing, the enemy will after all have units who are capable of fighting back, so you'll probably want to wait until you either have more units/better units. If you are good enough you'll probably still be able to rush, it's just that you have to be more careful about how you do it. Another reason why I think the concept of having Citizen Soldiers rather than just either villagers or soldiers (though there are more advanced military units who will be available later in the game which haven't got any economical capabilities) is a good idea is that it allows for the units to be useful even when they're not used to fight. Can you please explain why you think not having a specific Stable/Siege Workshop is a design flaw?
  11. The art is licensed as CC-BY-SA (See http://creativecommons.org/licenses/by-sa/2.0/ for more info), which in short means that as long as you tell people where you've got the images from and allow other people to use your edited images under the same conditions.
  12. Hmm, not sure whether we will have totally inaccessible forests, but as you can read more about on this page in the Design Document: http://trac.wildfiregames.com/wiki/List:_E...e:_Flora:_Trees the idea is indeed that some units will be able to pass through the forest while others won't. A brush to paint forests rather than just individual trees is planned, but other things will have a higher priority for quite some time as far as I can tell (though some individual programmer might find it interesting to implement, and since letting people do what interests them is one of the few currencies we have to reward team members in we're hardly going to stop someone from implementing it) as it's possible to place individual trees.
  13. In short, yeah, but as long as the alternatives are in the same order, which they should be as there's no apparent reason to change it, your vote is one of those four that Jan listed first So while the forum software didn't remember it Jan made sure it wasn't lost.
  14. First, JavaScript and Java have nothing to do with each other apart from the "java" part of their names, confusing yeah, but sometimes that's how things are. Second, most of the actual gameplay code is/will be written in JavaScript, so it will need to be fast enough in the first place, and one more or less script shouldn't affect the speed noticeably.
  15. I'm guessing what you mean by upkeep is having to pay continually in resources (rather than once when you create the unit), and in that case the answer is no. While that might disappoint some it's really a question of what kind of game this is. In this issue 0 A.D. will be a fairly old-school RTS, and to me it's a good thing as it makes sure any new resources can be used to expand rather than keep you from losing your units due to not getting more resources. I'm guessing it shouldn't be too hard to create a mod that has that effect though if you really want it.
  16. We've had discussions about this, but in general we came to the conclusion that having campaigns where the exact outcome of one scenario would affect another would add too much complexity. It would for example be very hard to balance a scenario if you don't know how many units a player will have from the beginning. It's not very likely to be a feature in the official campaigns (that does to some extent depend on the scenario desginers, if we have some campaigns implemented and there are people who want to spend the time getting things to work, and it's easy to implement the needed code, then it could happen), and thus support for it in the engine isn't a priority. The game is Open Source however, so there's nothing stopping someone else from writing the code that makes it possible and submit it to us. Then we might include that feature in the engine even if we don't use it ourselves. So, in short, not likely, but this game isn't done until it's done so if things change it could happen.
  17. You can learn And I'd say creating an entire faction would require more than one person in any case, so you might be the leader If you start with gathering information and designing how the faction would look/be played, and then try and get other people to join you might get it done even if you don't know how to mod (I doubt you'd get too many skilled people to help you if you just make an announcement "Hey, please make this mod for me", but if you do the hard work, i.e. the research, I'm sure there are people who'd help you with modeling etc.)
  18. Is there anything stopping you from creating an Egyptian faction?
  19. For an overview of what's been implemented in the new simulation system (and thus what features are currently present in the game) please see the following wiki page: http://trac.wildfiregames.com/wiki/GameplayFeatureStatus In general I'd say that as long as it's not a crash/something that makes launching a game or similar impossible it's just not yet implement though and not worth reporting yet. We generally are nice and friendly and answers questions though, so don't hesitate to ask if something is weird.
  20. Now it should be possible to know how to start Atlas on Linux, please tell me if it could be written in another way to be easier understood etc.
  21. If that's where the game is installed yeah, it will probably not be in the exact same location on every computer/system, but yeah, I'll add something like that
  22. Please see http://trac.wildfiregames.com/wiki/Atlas_User%2527s_Guide for the Scenario Editor User's Guide.
  23. Welcome to the team Goblor! Looking forward to working with you
  24. Welcome to the team Tyler! Looking forward to hearing what you'll create
  25. We haven't been getting many more new developers if you think about people actually joining the team, I think the number of new people joining is roughly the same. I think Open Sourcing was a good way to get more people involved though, participating in a big project like this takes a lot of time and can be a big commitment, but if you can do relatively small things like submitting a bug report, packaging the game for some Linux distribution or translating a web page, that makes it easier for people to contribute. And that makes more people involved in the development process, even if they aren't "officially part of the team" or actually writing code or so. So, in other words, even though I'd been happier if we'd have gotten more actual developers thanks to opening up the source code I'm really happy for the new ways of contributing it's opened up for people.
×
×
  • Create New...