sanderd17

Entities can be made undestroyable without a problem. Next to that, there's still the herding food source, and traders provide an infinite source of everything.

Welcome, programmers can indeed start without application. It's advised to start with one of the starter tasks. They're not necessarily very simple, but they usually stick to a single part of the code, so you don't have to know the entire code to work on it. And you're of course welcome on irc to ask questions, discuss a certain way to solve something, ask for a review, ...

Keeping the farm fields for town phase, and requiring natural resources or herding for village phase might indeed make the food more interesting. I also though about the possibility to completely abandon constructable fields, but making sure the map has enough fields, and players need to concur those fields. Then maps can provide easy food, by placing a field next to it, or they can make it hard to get food.

That's a planned feature, so we'll probably have it some day, but it's not implemented yet (remember that we're still in alpha phase). Loading saved games is possible, but it can't assign networked players yet.

Indeed, unit and building templates are here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/ Note that we use inheritance. So the specific Athen archer inherits from regular archers, which inherits from ranged infantry, which inherits from ... That means that shared stats aren't in the specific templates, but in one of the parents (you can see the parent in the first line of the XML). EDIT there are also some patches underway to improve the inheritance. Like allowing to add or multiply a previous number instead of just overwriting it. Technologies (that modify the initial stats) are here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/data/technologies Though before beginning to actually modify hundreds of templates, it would probably be better to come to the chat (https://kiwiirc.com/client/irc.quakenet.org/0ad-dev), and specifically talk to scythetwirler (who does our balancing currently, but is busy with exams now).

Hi, thanks for your comments. But remember, since we're still in alpha state, and not all planned features are implemented, it's hard to balance. Like about a month ago, a building capture system was implemented, which should give the harasser a big advantage, as he doesn't only take down a building of the opponent, but he also owns it and can use it to fire arrows or produce units near the enemy. So even with slower and more expensive buildings, this could lead to more back and forth (since the new owner can also lose his building again). However, that also means that, at this stage, any combat with buildings is severely unbalanced. Wrt the cavalry, we also plan to have a "charge" attack, that should primarily (or only) be used by cavalry, and where cavalry could exploit its speed advantage. But nobody started working on this yet. However, the strength of cavalry and archers has gone up and down over the last alphas. A16 fixed a chase issue, which meant that cavalry could finally attack moving units (before, they would stop to attack, and by the time they could attack, the target would have moved out of range). But the fix meant that cavalry suddenly was a lot stronger, and that unit speed actually mattered. A few versions before that, the minimum damage done was always 1. Which meant that fast-fire units (like archers) could deal a lot of damage against buildings (even if the buildings had 99% pierce armour). Allowing decimal damage helped a lot with the issue of using archers to attack buildings. Resources and the cost of technologies has also changed a lot in the previous versions. In previous versions, about all games were early rushes, and they were often done in 15 minutes. So the cost of the technologies has been upped to allow longer games, and units can't do a lot against a garrisoned CC now to limit early rushes to do merely economic damage (like destroying other buildings or killing loose units). So, as you see, balancing often goes in a wave of OP and UP tactics, normally towards an equilibrium, until a new feature disrupts that equilibrium again. We do, however, try to keep the game playable and fun (the changing tactics on their own are actually also fun, like you get a new game every update). So comments on balancing are welcome, but it would be even better if you'd make comments (or send us patches) for the current SVN state. See http://trac.wildfiregames.com/wiki/TortoiseSVN_Guide on how to install the developer version of 0 A.D. (don't expect it to always work though).

Note that this way, you also enable the AI (or any player choosing that faction in the game setup) to build Roman structures, and in fact become a complete Roman civ. In SVN (and thus the next release), this behaviour has been disabled, if a player gets access from a building of a different civ, it will only be able to produce its own units from that building (if it has comparable units to produce).

A zip should be allowed for sure. It might be that a rar isn't allowed. So was it a zip or a rar? Maybe you also need 5 posts to attach files (just as with using the PM functionality). Not sure.

Zip up the log, and attach it here (via the advanced reply form). Also, what version are you using?

This can't really happen to one person. The game is synchronised, which means that all players calculate the entire game state, and every few turns, the state of the different players is compared to each other. So if this bug happens always to your friend, it should also happen always to you. Else you'd get a notice that the game is out of sync. So I'd like some more details on when it happens. Always on the same map? Always to the second player? If you don't see a pattern, I'd really like a commands.txt log of such a game. See the wiki on where to find the logs: http://trac.wildfiregames.com/wiki/GameDataPaths you'd have to sort the files by creation time to find the right commands.txt file (every game creates one).

It's better to not focus on the pathfinder details for now, it will be re written in a short time, and what now is impassable might get passable or vice versa. But the best way to block pathfinding would probably be to make a big, but invisible structure.

The nickname was changeable in A14 or A15. And it was abused very often (like spamming with nickname changes, impersonating other people, ...) So that feature was removed on the request of the players. Also, requiring the email address would make the registration process a lot harder (enter an extra field, wait for confirmation mail, click confirmation link, log in to the game again). While I thought you just wanted the registration process to be easier.

Sometimes spammers are banned, and you can only create one account per hour (to prevent them from returning). By allowing anonymous chatters, that would either mean that they can only join the lobby once per hour, or spammers could use it and keep joining. I really don't understant what's hard about registering. Could you explain it to me, because I don't know why you're writing these long posts if you can register with two keystrokes (one for the nickname, and one for the password).

And what would be the advantage of automated nicknames? More spam? More sockpuppets?

How would you be able to chat if you can't have a nickname? The login is already quite anonymous. We don't ask your email, or any other verification. You must just choose a nickname and a password (so others can't use your nickname).

If there's any unlockable content, it should be for the singleplayer IMO (via a campaign). To give some sort of mission for players who prefer to play alone. Multiplayer should have all content unlocked from the start, as the mission is to get the highest ranking (without that ranking influencing other stuff).

UnitMotion has a turn speed setting, but it's equal for most units. Only ships have a longer turn speed. But setting the turn speed might not give you the wanted result. When you order them to move backwards, they will turn while moving in that direction, not turn first and then move.

From the moment you enter the "actor" part of the game, it isn't synced again. Like the calculation of the spear position only happens when it's actually visible on your screen and has to be rendered. Having a prop position that should always be calculated will slow down the game. No matter how good you make the actual code to do it. Maybe direction checks would be possible for entire formations (as there aren't that many formations in-game at once), but not on a per-unit base.

The spears are just an animation. That means they're local and cannot be synched for multiplayer. So you can't use it as a centre of some range query.

We limit ourself to the timeframe of 500 B.C. to 1 B.C. for part I. And only include civilisations that were at their best during that time (and came into contact with a Mediterranean civ). As such, for Egyptians, we'll only include the Ptolemaic Egyptians (which are already in game), and we won't include Vikings (which are mainly medieval).

Directional checks would be a lot heavier. Checking a distance is easy (just do a dx²+dy²<dist² test), while checking angles requires trigonometric functions and thus are more demanding (those require a lot of higher powers to approximate the value).

Auras don't stack by design (would have been easier if they stacked, maybe more intuitive too in some cases). And you're right about the formation aura, it counts whenever units are in any formation. Maybe it's time to implement decent formation effects.

I prefer slow development speed. If we suddenly get masses of contributors, it becomes very difficult for us to review those patches. With a steady growth, we can guide new contributors, and make them team members when they stick around and give good contributions. As it is now, there are enough changes between versions to give a "new" feel every time people have to update.

As said here

You should probably use the formation type aura for the testudo change, like Iphicrates: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/units/athen_hero_iphicrates.xml Also, don't add zero-changes. It only clutters the template and causes extra values to save for no gain. For the syntagma change, how did you measure it? A range of 8 is really small (it's only 2 tiles). The range of a pike itself is also 8m. Only affecting speed when units are already standing still doesn't help a lot. Besides, you may encounter the range mismatch. The attack range for units is calculated from the unit center to the target boundary. So with big targets (like buildings), it doesn't try to reach the center, but it reaches the side of the building. While for most other ranges, speed is preferred and only both center positions are compared with each other. So if a pikeman attacks a different unit, it can be around 9m away from the unit.