historic_bruno

Yeah rally points are less than ideal currently, I would expect this feature at some point: http://trac.wildfiregames.com/ticket/745 I believe we temporarily increased unit speeds since the game felt too "slow", because we don't have game speed controls yet, but expect more changes for realism once we have running and stamina implemented. We're planning to change the siege behavior, as quantumstate said, only certain classes of units will be able to attack buildings and the rest will capture them. Capturing may have benefits over siege in certain cases. As eye candy this will have lower priority than some other missing parts of the game, but I wouldn't be surprised if we added a bit more bloodiness to the game (particles maybe or terrain decals). We will introduce a limit of only one living hero per player. We actually don't have herding behavior yet What you're seeing is just hunting. Herding will be capturing enemy or gaia animals (or breeding new animals) and moving them into corrals where they will generate food automatically. See the design document for a bit more detail. We're missing animations for certain animals, namely because there is no official animator on the team. That's triple click.

Use triple click

So I installed Lion and Xcode 4, and now I understand what people were complaining about The UI has totally changed and our projects aren't compatible with the new concept of "Schemes". All of the separate projects are treated as schemes which is bad: it makes the process of changing build configuration almost impossible (there should only be one scheme for debug builds, one for release builds, one for testing, etc). So I guess we need to unify all the Xcode projects into one as we do for Visual Studio, that's not bad in itself but I don't know how hard it will be for premake4. On the positive side of things, MacPorts did work for all the dependencies with no issues, and the build completed successfully.

I got this problem with public SVN on OS X after upgrading to SVN 1.7. Which is annoying because it was a fresh install of Lion and MacPorts installed 1.7 by default, so I had to manually get an older revision of the port and downgrade to avoid downloading GBs again

The minimap needs some major work, I can't even see territory borders Someone was working on it but they seem to have disappeared.

Very nice For the AI options, there's a ticket which includes that. I was thinking of defining the list of possible options in the AI JSON data, which becomes a series of dropdowns in the AI config box. Hmm, I'm not sure if setup options even get passed to the AIs, but if not we can add that

Territory data is now added to the AI state (r10408). One consequence I notice with Jubot on certain maps like Gambia River (player 2), it tries to build too many mills. I think the problem is it focuses on a resource outside of its territory area, and keeps trying to build mills without realizing it can never get close enough. Territory should be taken into consideration when computing distance to resources, maybe forget a resource if it's too far away from your territory (or better yet, expand territory with CCs to capture it ) Unless we choose to allow building mills in neutral territory, but I must say it gives some extra incentive to have territory!

Territory data is now added to the AI state (r10408). There's a slight change that will affect Split Bot and others, the passability map returned from the engine is now called "passabilityMap" instead of "map". This is to distinguish it from the new "territoryMap". Other than that, see Jubot and Testbot code for examples of how to handle territory build restrictions

One thing to watch out for is constructing multiple buildings each turn, because the obstruction map only gets updated on the next turn (not immediately when you post the "construct" command). Pathfinding obstruction is irrelevant for placing a foundation, only building passability (terrain characteristics) and foundation obstructions should be used.

It would indeed be a welcome feature (F11 is already used for the console).

I was thinking about this earlier and would like to do the same thing for OS X. As long as we test the prebuilt libraries on different versions of OS X (specifically 10.5-10.7) and confirm they work, it seems very worthwhile to avoid needing the likes of MacPorts. We could possibly even go so far as handling 32- and 64-bit builds, but if not stick with 64-bit. As far as Windows is concerned, I don't see any problems with our setup, it's very nice to have all the libraries (except wxWidgets) worked out in advance by a developer, because they only rarely change in practice. I would like the OS X build process to become more like the Windows build process, not vice versa.

Yves, would you be interested in working on this when you get time?

Do you have VS 2008 SP1 installed?

Yeah, unfortunately the process on OS X is a pain right now Basically the advice in this thread is the best. Or you can wait for cc_julian to finish his precompiled bundle with Atlas.

It requires a custom build from SVN, since the required changes were made after Alpha 7 was released.

There's nothing official yet, but read the discussion here

Another heads-up: the new premake4 build system is now the default and the old has been removed. So you'll want to use update-workspaces.sh now

It would be helpful if someone familiar with the game and how the vision has changed over time would put a notice on the outdated pages of the DD, and possibly add them to a list of pages requiring work. Fully bringing the DD up to date will be time-consuming but this is a good first step.

Nice work, I love winter maps. Now all we need is snow falling and blowing in the wind to complete the effect

I like how Starcraft II deals with endgame scenarios. If your base is destroyed and you don't rebuild it, you get revealed to your enemies. We could do the same with CCs - lose your CC and after a short time you get revealed to your enemies. Although that may make more sense in a modern setting like SCII and less sense in the context of 0 A.D., it's one way of handling conquest.

Try gathering from an enemy (non-gaia) farm some time

Currently every building has the ConquestCritical class and almost every unit as well. It's been proposed that some buildings such as houses and fields should not count against victory by conquest. Back when houses could train females, it made sense to keep them conquest critical, since a player could conceivably continue a game with only a house. That is no longer the case. I don't think conquest should be so tedious that every single enemy building and unit needs to be destroyed to defeat them. Any thoughts?

Interesting, I guess we need to check that a farm (any resource?) is either player owned or gaia before gathering from it

Can you confirm the CC build plan is actually executed? That's when it looks for a valid position, but I think it will always come up with something.

The patch includes some API changes, so I wanted to make sure all active AI devs are aware of that before they are implemented (they aren't certain, we may be making even bigger, more fundamental changes - stay tuned ) Territories have multiple aspects. There's the building restrictions which are fairly simple, see the second patch in that ticket for an example (I combined foundation obstructions and territory restrictions into a boolean concept). I haven't look into Split Bot's implementation, so I can't say what changes you need to make, but if it's based on Testbot/Jubot there should be a similar process. Territory expansion is another problem, like building new civ centres when needed and in strategic locations. I haven't even thought about that, the AIs are overall lacking in strategy.