feneur

I'm also mostly a fan of the way AoE does things =) But with this I'm definitely starting to lean more towards doing things like this: units are created as individual units (and in terms of promotion etc always are), when doing economic tasks they stay as individual units, even if you've given them a group order (perhaps even give them some "spread out" unitAI to avoid all gathering from the same tree etc, and more importantly to avoid having to individually order them to gather from individual trees, to avoid issues with units gathering in places where you really don't want them they should probably just spread out within LOS of the spot you initially ordered them to gather from). When you want to move larger groups they get put into a column "formation", which is as thin as required depending on the obstacles and "snakes" around obstacles on the way. If they are attacked during the way they break out as individual units and respond (only if they are within LOS of the attack, if some units in the column aren't they just keep on walking, if they later come within LOS of the enemy - depending on stance and whether or not you're using attack move - they also respond to the attack). True formations should only be used on the battle field (i.e. big open spaces), and be a "battalion". Their movement would be restricted (slow, takes time to turn around), but they would be greatly bonused in other ways. I'm thinking they should still keep individual experience (they might have been part of another formation earlier etc), but should probably lose hitpoints evenly. Or perhaps the formation could be split in a couple of areas for damage purposes? That way the direction you attack the formation would matter, but it wouldn't matter exactly which unit was hit. In fact you'd only be able to attack the formation as a whole/per section rather than individually. If you want to get units back to economic purposes you'd turn off formations and perhaps also if you want to pursue fleeing enemy units (as most if not all formations should be slower than individual units moving around). It would be really nice if it is possible to have the units automatically go back and forth between "proper" formation and a column for movement. That way it would be more likely for players to actually use them, while allow the game to benefit from the good things of using a column for movement. Not sure whether that's reasonably easy to do though

Something like that is the plan yeah We don't necessarily make any difference between male and female animals, but the idea is that you will be able to corral domestic animals (chicken, goats, etc) and get a slow trickle of food. That would symbolize milk, but also eggs and killing off a few every year etc.

Ah, true. Was thinking about the Romans, but thought "Oh, but they have more or less two buildings already" =) But now that you said the above I'm reminded that (apart from generally most likely being used together) none are meant to be built "at home", so they'd not have something unique in their base. A Siege Workshop would be great

I also think something like what we have now is good. We need to remember not to make the game too difficult to understand for new players. If you think about it there are quite some different buildings, all civs has at least one special building, and the only civ that just has one so far is the Celts, and for them you get two different fortresses depending on which sub-faction you choose (I know it's not a new building in terms of function, but at least it adds some variation). I don't think we should add any more buildings at the moment at least. If we find in Beta that new players easily grasps the current buildings and that new buildings would enhance the gameplay, that's another thing.

Finally got around to adding the useful of the ones you mention, I've left out the G key as that seems less than useful in most cases. I think it's generally best to keep this document as short and basic as possible, at least until we have a proper manual system with several pages, and perhaps search etc, for now too much information and people will be unable to find the important stuff in all the text. For more info there's always the Wiki manual.

Yeah, I was reminded yesterday about that =) It's up to them what they do with the engine, but they have to obey the rules

The technology system isn't yet implemented, so at the moment it's not possible. I'm afraid you'll have to wait a while yet.

No, there's no communication between us and them. And no, they don't contribute to the engine in any way.

Oh Amish posted about it a while ago I think.

It's actually an old feature =) It's been planned for as long as I know to have the cavalry able to capture female citizens. (Having them carrying them to the home base would take too much work to implement I would guess, so the plan is to have them convert enemy female citizens which are within an area around your cavalry units, and don't have any enemy non-female units nearby.)

Yes, we are aware of it.

I played a bit on Oasis V against Jubot today, and every say ten seconds or so there was a slow-down. It seemed like it was caused by the AI being confused by there being two CCs (or at least because it tried to put units from both places in formations or something, or perhaps just that the central, most direct route between the two initial player one CCs is fairly narrow, with a lot of trees). That's probably a bit hard to work around (alternatively depend on other non-AI improvements). Another thing I noticed should hopefully be easier to do something about: the AI tried to build CCs right on the edge of my territories, where it was easy for me to destroy them (at least once I noticed what it was doing =) ). Perhaps you could put in a limit for how close to the enemy CCs/fortresses the new CCs should be built. At least the first ones shouldn't generally be too close as they are too vulnerable.

Well, I both agree and disagree =) The web site sure could be better, we've been aiming for a new site for quite some time, but web designers seems to be busy people so we haven't gotten very far so far. That has kept us away from doing much about the FAQ etc as it has seemed a bit pointless to do a lot of work on the old site. On the other hand, we've wanted to keep the news in general from going into too much detail about the development so people who just want the big news has a chance to do that. If you want to follow the development closer you can do that by following the forums, IndieDB ModDB profile, Facebook page. That's not to say we couldn't do more, but just that we shouldn't do too much as some people don't want to know everything before they play the game (and don't want to play the game until it's finished) and at least don't want to know much more than the releases. The exact balance is of course hard to find, so thanks for your suggestions. We'll think about them and see if we can do some of it. In general though: if you want to follow the development more closely the other places are more useful than the news on the main site (and will continue to be).

It is indeed intentional. One small extra thing that can give you benefits if you tend to it (i.e. make sure they leave their first resource at a dropoff site before starting to gather the next), but which doesn't punish you terribly if you aren't careful.

Looking forward to hearing your new recordings And I'm sure almost any microphone is better than a webcam microphone, so hopefully it should be more than good enough

I think I meant possibly trade, and the bounding box patch wasn't in then I believe, and perhaps the rally point marker line patch was on my mind as well So something like that. Great to see that update Philip, and a great write-up of the issues involved in reviewing patches. Perhaps something like that would be good to have written on the committing patches page in Trac? (After the process related stuff of course so people can find the most urgent things without having to read through a lot of text, but it would be nice to have something like this available there so people committing patches get a greater understanding of what's going on with their patches. And why it might take a while.)

TLA has indeed been indefinitely postponed. The people involved in the project simply were to busy with real life to keep working on it.

It's actually a feature, not a bug Or rather, not the long time, but rather the fact that the game converts all textures to .dds. This allows for artists/modders to use PNG files for maximum ease of use, but at the same time the game can use DDS which is more efficient. For release versions all textures are preconverted, but for SVN versions all new textures will have to be converted. It only does this the first time each texture is used though, so as you say the next time it should be the same as using a release version of the same map.

During the last month we've had the joy of welcoming four new team members here at Wildfire Games. First we had the chance to reward three of our most diligent Open Source contributors: Jonathan, Jeroen, and Yves, who all have worked hard programming for 0 A.D. and we thought it was time to recognize that. Jeroen (vts on the forums) has worked on fixing things, perhaps most notably making selecting units a lot easier (a more technical explanation: he's worked on making the bounding boxes correspond better to the actual models). He's also worked on adding rally point marker lines. In other words: the rally point you place to tell newly created (and ungarrisoned) units to go to a certain spot on the map can be a bit hard to find at times, but with this feature you get a line on the ground showing you the way to it. And also roughly the way the units will walk to get to it. It's probably easier to see how useful it can be from a screenshot though, so below you have one: Rally point marker line, the line going from the building to the rally point. Yves (Yves on the forums) has mostly been working on upgrading to premake4 and other compile related fixes (a less technical explanation: he's made it easier for people to build the game - the process of turning the code into an actual game that can then be played). Jonathan (quantumstate on the forums) has been (and still is) the leading force behind qbot, one of the AIs for 0 A.D. A video showing a match against one of the latest versions of qbot. Second, we've gotten a new artist on board: Enrique (Enrique on the forums), who has already created some marvelous Roman buildings which will help enhance the game world. New Roman temple (to the right, to the left is the Hellenic temple for reference).

There is music setting in, but it will be redone eventually, so perhaps it will be more to your liking =) As for "screaming" letter I'm not so sure about that myself We've been talking about making it more exciting, adding some kind of cool overlay with spoils of war or something behind the dialog (but overlayed over the game world), but have put that idea away for now as we haven't had the skills on team. And even when we do other things have priority, like new main menu backgrounds or unit portraits etc. It may still happen before the game is finished though The problem with the second part of the message is how to say it short, because it's probably mostly so you can see the end result of the game, where the enemy put his buildings etc (if you lost at least, otherwise there won't be very much to look at), but also as you said you might want to continue playing even without the enemy.

Units do heal when garrisoned though, but yeah "active healing" (i.e. a unit which can heal other units) is not implemented yet.

The debug build produces an .exe with a different name than the one in SVN, so that doesn't cause any problem. And the conflict isn't really much to worry about unless you absolutely cannot stand the notion of there being conflicts =) It's just the SVN saying that you have another version of those files, so nothing to worry about in that sense.

That's one thing There are a few more things which might make it as well

To some extent your asking for two completely opposite things, on the one hand you're saying territories need more strategical value, and on the other you're asking us to remove one of the things which gives them strategical value The ability to limit your opponents access to resources is one of the nicer things about territories as they are right now. And don't forget that you can still gather resources which aren't in your territory, it just takes longer as you cannot generally build a resource dropoff point nearby. It would perhaps be one thing to make Outposts buildable in neutral territory, but the problem I see with that is: what happens when an enemy builds a Civic Centre nearby and his territory expands to cover the area where you've built your Outpost. If Outposts doesn't affect/are affected by territory at all, then you essentially have buildings in enemy territory. Just giving them a bit of territory would also present problems. Not only would they be outside of the general paradigm with buildings cut off from CCs loosing loyalty etc, they would also just be tiny pieces of territory inside enemy territory in the above scenario, to me that doesn't sound like fun. Especially not for the person building the CC, having to fight off an Outpost just to be able to use the newly acquired piece of territory properly. Edit: Also remember that we intend to have an unlimited game mode without territory limits etc for people who don't like these restrictions.

I'm sure there is some way, after all that sounds more or less like watching two AIs play out a game If you want more direct tips for how to do I guess you'll have to wait for someone with more direct knowledge of the scripting, but for now/if you want to take what little advice I can give, I suggest you take a look at how the AIs in the game does things. The two most up-to-date are Jubot and Qbot. Jubot is in the game, and qbot can be found via the links here: http://www.wildfiregames.com/forum/index.php?showtopic=15159