feneur

Great work indeed. A really nice building, and an amazing image

I'll let our composer have the final say, but if the three songs you posted are representative of the kind of work you do I can say with almost 100% certainty that they do not fit the current style and that we don't want to use them. To get an idea of our existing music please listen through the songs here: http://play0ad.bandcamp.com/

I'd say let's remove the default ability for wall towers to auto-shoot (but still keep it for CCs, Outposts and Fortresses, and always allow garrisoned units to add shooting power to a tower) and then add a tech to enable auto-shooting for wall towers.

Is this after the changes quantumstate made yesterday? (Decreased build time for houses and mills)

I personally don't feel 0 A.D. is too slow, at least not in multiplayer against an opponent who knows how to raid But still, adding options to set the speed of the game in different ways is probably a good idea. I think we should begin with implementing an overall game speed setting though as that should just be to create the GUI for the already existing JS(?) command. Can you please explain how the tech pairs double the time needed to research?

Please provide sources. Even if the old information might be wrong let's make sure any changes are based on fact-checked information

I think so, what you set is the "normal pop cap" after all. Otherwise you'd have to lower the amount of units all other players can use (if you put the civ with the largest total pop cap as the limit set, i.e. 100 if you set the pop cap to 100). Which would be a lot more confusing imho, especially since that could mean that a "normal civ" would have a different pop cap depending on whether they played only against other "normal civs", against one or more civ which has a 10% bonus, against a civ that has a 20% bonus etc (or it would be set relevant to the largest possible bonus, which would mean that something "outside the current settings" would affect the current settings, which seems unnecessary to me).

A couple of comments: First, I'm not sure this is really a Design Committee issue now that I think about it as it doesn't have anything to do with the game's design or actual gameplay but rather with how it is implemented. Still, as it's such a major change if we were to go through with it I think it can warrant an overall decision here. Second, it would be relevant to create a post in the public forums as well as the Design Committee isn't necessarily the best equipped to make decisions on programming issues as only one member is a programmer. Good, I see now that you have Third, understandably as you are a proponent of this idea you list more pros than cons, but there certainly are a few more things to take into consideration: If we'd change to another system for the GUI all the existing implementations would have to be redone, which could take more time than it would take to finalize it using the existing system (especially since XML isn't that different to HTML (CSS might be a good comment pro though, but you've mentioned it thrice so... ). Adding an HTML engine would either add another dependency for users who build the game themselves or add another library that we would have to keep updated if we decide to include it with the game. Adding an HTML engine to the game (as opposed to just including it as a dependency, which I have no idea whether or not we can do, at least on Windows which doesn't do those things as easily) would mean that the size of the game on disk would increase. Probably not too much, but still, it's better to mention all the things now so we are sure we make the best decision. Some comments on the pros: Highly movable Could you please explain what you mean by this? (You should at the very least be able to edit your original post) I'm assuming you might mean the possibility to move things around on the screen? Using CSS media queries, designers get more flexibility for different layouts depending on screen size In the case of completely different layouts this is an argument pro an HTML based system, but afaik you can still do a fair amount of things with the current system since you can use relative units (might even be the only way, I haven't been looking too closely at the GUI code/XML). Using CSS, designers don't need to get programmer help in order to change the UI You don't need that now either, you need it to add completely new functionality yes, but you'd still need that with a new system as that would still be done via JavaScript. Using jQuery, designers can create "drag and drop" components for the UI Could you please explain this a bit more? I mean if it's just about copying and pasting pieces of code you most certainly could do that now as well. Though I guess you might need to edit it slightly to e.g. make sure you don't put two buttons in the same place, but I can't see how that would be different in an HTML based system. Allows for implementation of a more content rich UI with possible server-side documentation and help It's one thing to make it possible to connect to/update the documentation, but we should most definitely not make server-side documentation the only way to do things as not everyone will want to be connected to the internet to play the game. We have to make a game for single-player users as well. This is not really an argument against the use of an HTML based system though as this could be done even with an XML-based system (though it could definitely be made easier with an HTML based system). Opens a whole new level of awesome things to come (POTENTIAL) The existing system could hypothetically do things we can't do with HTML, so this argument goes both ways. After all, if we want to add some new feature to the engine (rather than the GUI) we'd need to add it ourselves regardless of whether or not we'd be using an XML or HTML based system. All in all, I think this is an issue where we really can't make a theoretical decision. In other words, as zoot said in the public discussion thread, someone needs to make it before we can make a decision.

As someone said before: have we ever went for the most obvious one? =) (On a more serious note, maybe once or twice, but it's certainly nice to have something more unique. Both since it gives us a chance to teach people about something that's lesser known, and because a more unique name makes it easier to e.g. search for the alpha release in Google etc =) )

I would assume you can set them manually in the map file as well But it's certainly a lot easier to set them in Atlas where you get some feedback immediately

Speaking of which, the committee forums can probably be made public now. I'll do that right away so people can follow the link and I/we can add some descriptive topics tomorrow.

I think we should decide one thing before making this decision (as the gameplay impact varies quite a lot depending on how we do other things): Should non-siege units be able to attack foundations? I could see arguments for doing things both ways, after all, if they can't the unit roles would be more clearly defined and the role of siege would be bigger. It would of course make it harder to raid though, and also a bit harder to claim as realistic. It would mean that the attacker would be forced to focus more on taking out the builders (especially early in the game), but again, that could be a good or a bad thing. Removing the ability for non-siege to attack foundations would lessen/remove some of the concerns which have been raised against tying completion % and health together, after all a tower doesn't generally provide much of a challenge to siege engines.

There are a few, see: http://trac.wildfiregames.com/wiki/Manual_Settings Though most of the features which actually demands anything much of your graphics card (apart from the water) are disabled by default and need to be enabled to be used.

Then they lose the benefit. Note: I only think it can be a good way to implement "hero effects" if we can implement formations which doesn't break in battle (unless of course some specific conditions are met, like there being too few units to be able to keep the formation together etc).

Groups can already be selected via buttons in the GUI as well as hotkeys (see http://trac.wildfiregames.com/wiki/HotKeys for more info on the hotkeys). It's been planned for most heroes to have an "aura effect" where units in their vicinity would have more armor or fight better against certain units etc. Maybe it will be easier to implement such effects for formations rather than for an arbitrary area around the hero.

Where the unit can be trained should be possible to find out by parsing the building templates, right?

It's editable by everyone who's registered (we can always remove bad edits).

Cool. In case you haven't found it already (assuming you have, but still, better to be too obvious than to make it hard for people unnecessarily) a lot of useful information can be found on the wiki: http://trac.wildfiregames.com/ and more specifically: http://trac.wildfiregames.com/wiki/GettingStarted and http://trac.wildfiregames.com/wiki/GettingStartedProgrammers

It's a bit of both, we try to set some rough deadlines etc, but in the end/specifics it comes down to when people have time to work on the game. We do work with the intention of releasing a new Alpha every 2-3 months or so, but the exact release date often varies a lot depending on: how long it takes to implement a specific big feature we really want to include (and which we think is reasonable to assume can be finished during the release cycle), if there are any release blocker bugs remaining (bugs which render the game unplayable for a large number of people), and more specifically on when the people creating the actual release files have time to do so NeHe's blog? Would be nice with a URL

Just a thought, and something that's probably not related at all, but it should be quick to try: Could you try turning on and off shadows to see if that changes anything?

It can be useful for "sandbox" games where the player just wants to experiment with basebuilding etc, but presumably it ought to be possible to have two players set, and then set the other player to unassigned. Hmm, just tried that and remembered that the other players starting units/buildings still get placed. Would it be possible to add a "Sandbox" game mode where enemy players are calculated, but their units/buildings aren't actually placed or something?

It's as good as planned I believe, at least it's something that's been discussed. Can't remember if there is a ticket or not though, hmm, after a quick search http://trac.wildfiregames.com/ticket/785 is the closest I can find. Should probably be implemented in conjunction with adjustable game speed anyway.

Could you please post the full name of the files which doesn't work? Would be a lot easier to try and track down the issue then

Ok, cool. Then as a trial task I'd like you to update the http://trac.wildfiregames.com/wiki/Manual_SettingUpAGame page. It's up to you if you want to just update it for the new release, or organize it differently etc. The layout of the GUI has changed quite a bit, but apart from that I don't recall any too big things, so it should be a good task to start with. It's also relatively self-contained, and there will always be need for a page describing these options, so regardless if the rest of the player manual will be reorganized etc or not this is likely to stay more or less as it is, i.e. no wasted time on your part I hope you are able to create the kind of simple graphics required, it should be easy enough in e.g. Gimp or Photoshop

Thank you for your application. Would you say you would be more comfortable with user documentation or developer documentation? Not saying you have to have a preference, if you join the team it will be apparent over time where your strength lies after all, just asking to get an idea of what you want to work on and what I should give you as a trial task (Also, since we hope to encourage people to mod the game the border between user and developer is a bit fuzzy ) In either case I recommend that you register at Trac ( http://trac.wildfiregames.com/ ) and start to take a look at the existing documentation to get a good idea of where we are right now in terms of documentation. There is also documentation to some extent on the web site and in-game (rudimentary at the moment as we haven't included a more advanced documentation system), but since it's easier to keep updated and collaborate on the main source for our documentation is the wiki. (Generally speaking information is added there first/more indepth, and then more basic versions are added to the game/web site.)