quantumstate

If you just delete all of the factions the game will probably stop working properly. Would it not be more sensible to gradually start by adding your own stuff first and then removed existing things once you have the replacements working. Once you have got the hang f adding new stuff it will become more obvious what needs modifying or deleting. Take a look at the current champion units which cannot build and compare them with the normal units which can.

Does the projectile prop point need to be different from the archer prop point?

That is pretty neat.

This will be good, a step through debugger would help in quite a few situations. We could add some neat features to make it easy to look at the components for an entity.

Zaggy seems to go in for great attention to detail in his animations, it would be a nice touch.

Similarly with the art, if you use existing art this is under a similar license to the code. It would be possible to replace all of the art and then disallow people from copying your artwork. For 2 and 3 you will find the data files in binaries/data/mods/simulation/templates. There are also a few other things scattered around the game. You asked a very general question though, without more specifics it is hard to give exact advice, creating a whole new game is a big thing.

I moved the thread since it isn't really art. Having this manual is nice, one concern is that we will have too many manuals. So far we have one on the trac wiki, one on play0ad.com and now your (plus I am pretty sure other people have started similar things in the past). This seems like a massive duplication of effort and makes maintenance a pain since everything we add now needs documenting 3 times or something will get out of date. I would like to see online and offline versions from the same base, latex should be able to do that but it might take some effort working things out.

The AI sees the whole map. Currently it can't stand up to a moderate player, the economy is quite reasonable in early and mid game but combat is poor and later in the game it struggles when resources start running out.

The AI/Engine low-level API page which you linked to is up to date, it is just lacking information.

The overhead to wake up a thread shouldn't be very large. 100 microseconds on old hardware perhaps (vague conservative estimate). Recent CPUs should do it in about 5-10 microseconds. Waking every 1 second seems reasonable, why would you want it switching more often?

The bug should be fixed by revision 13044.

I can't see much hope for the game now. Unless things have changed significantly since I last played the multiplayer setup was poor and there are no tools for users to create content. Without these things it is hard to have much of a community.

Could I now be added. jonathanmarkwaller at gmail dot com. Yodaspirine sets a high standard as always.

I also agree about the lack of openness possibly putting off programmers. Also it is pretty hard to tell if you will use pyrogenesis (are you planning to?). Also in the summary you mention "C++\C# coder" when pyrogenesis uses a mix of C++ and javascript. I would personally be looking for quite a lot more technical information before contacting you.

The mirror tower, while entertaining seems pretty unrealistic. Also the curvature on the mirror looks much too large, incoming light from the sun is parallel so the focal point is at the place where the normals of the surfaces meet.

This looks like a very interesting map. One comment is that building room is quite restricted, though perhaps this will encourage more aggressive expansion.

"What age are you in?" is an audio taunt from AoE, the equivalent in 0 A.D. is "What phase are you in?".

Plus a whole pathfinding component to route units around the map, so they don't walk round in circles, cluster in a group, miss out areas...

The way that we do multiplayer in 0 AD is to send all of the players commands over the network and have the simulation run identically on each users computer. This is why the GUI buttons use the following function (this example is the promote units debug command). Engine.PostNetworkCommand({"type": "promote", "entities": g_Selection.toList()}); These messages are received by Commands.js on each player's computer. Commands.js is part of the simulation code so it can then call the necessary simulation functions. The simulation is made up of lots of components. There is some fairly good documentation about components here . You will want to add some components, perhaps Capture and Loyalty, as you design the code this should become clearer.

The model looks great. Something doesn't look right to me with the ambient occlusion though. Inside of the building looks too light.

We should probably start sorting maps into categories. There should be a core set of fairly standard resource density maps and then if people want to create unusual maps like this they can be put separately into something like a 'challenge maps' category. The game balance will be strongly affected and the AI will probably have significant problems, so it would be better for new players not to get a bad experience.

Thanks for letting us know the problem. I have changed the topic title to reflect this.

That is odd, I was using this feature for my balance tester recently without any problems (except for those warning messages).

I saw this problem just before we released Alpha 12 but didn't consider it significant enough to risk changing things for. The game will still work fine, you can just ignore the error messages. Also you can use F9 and then type Engine.SetSimRate(5) to set the game speed to be 5 times faster. Edit: The last error is interesting, I am guessing this only happens on your map? Could you upload the map somewhere since this is a new AI bug.

There are legal issues, it is copyright infringement. It is hard to predict whether anyone would try and stop the project though. If you still wish to go ahead it would be better to not to upload the files to these forums.