General concept of maps/triggers/AI/random maps/entities/civilizations

[FeXoR]

I feel a bit sad that this awesome game has a huge rub in its concept of maps, triggers, AI, random maps, entities and civilizations. As far as I can see the single player campaign as well.

There is this concept "simulation" but it's not used for everything and triggers (the only really needed thing) is suspended until part 2.

So there are many different APIs to be programmed, maintained and understood by outsiders for every single mentioned parts of 0AD. That's bad IMO.

I know since development is already quite far it's most unlikely (and perhaps not even worth) to change but I cry for it.

Why only an abstract map, an abstract "entity" and triggers are needed?

With an abstract map (like used in rmgen area and AFAIK in the engine as well but a different one) and triggers available to manipulate everything (e.g. hight map, entities, scy texture, water level, entity states, GUI, sounds, save/load map, ...) you could create random maps (while the screen may only shows a progress bar because you can manipulate the GUI as well), give orders to entities to behave like an AI, generate new entities by changing e.g. the model, the type (like soldier or building or tree however done in detail but just some data fields in general) and so generate civilizations by granting entities specific buildings/units to build/produce and so on.

But as is most things are unreachable from one specific part of the game code (or at least not planned to be accessible though ofc. it's mainly rmgen split because somehow it seamed to be to complicated to add it to the map part but I mainly would like it in the simulation part which might include the map part, I don't know).

Though there is the simulation part it's somehow not very well documented and some parts of the APIs are written for only one purpose (e.g. AI) rather then being more general in concept and allowing all parts of the game to excess it (for example an automatically updated multi core thread save representation of the map e.g. for the AIs but not exclusively).

I really think that in the end the advantage of such a general purpose API fully controllable by scripts would be huge! Especially for things no one imagines right now but later becomes a big popular thing. And still there could be special libs for a clearly defined purpose that makes things easier in this area or do thinks the way it's planned in the team members minds but still leaves the "semi easy" possibility to do it differently as one likes it.

Edited May 22, 2012 by FeXoR

[feneur]

I'll leave it to the programmers to offer more technical input, but as a general comment: Apart from all the technical reasons there's the issue of how much time it would take to redo everything to fit in your paradigm. Perhaps it's not too difficult, but in either case it at least initially would be a lot of work just to get the same result as now. That might make sense for part 2, but to spend a lot of time rewriting something that works at the moment, while we're getting closer and closer to being able to finish part 1, that just doesn't make sense.

It all depends on the technical questions/reasons though, especially since an API can be an added layer on top of what's already existing, so don't take this as anything else than "be prepared that this proposal might be more relevant for part 2"

[FeXoR]

I'll leave it to the programmers to offer more technical input, but as a general comment: Apart from all the technical reasons there's the issue of how much time it would take to redo everything to fit in your paradigm. Perhaps it's not too difficult, but in either case it at least initially would be a lot of work just to get the same result as now. That might make sense for part 2, but to spend a lot of time rewriting something that works at the moment, while we're getting closer and closer to being able to finish part 1, that just doesn't make sense.

It all depends on the technical questions/reasons though, especially since an API can be an added layer on top of what's already existing, so don't take this as anything else than "be prepared that this proposal might be more relevant for part 2"

Heaving everything in one pool for part 2 would be very nice for me already. But it's a thing that would help developing the game, too, and as far as I can see another workaround will be needed for the campaign. So it might in the end be not much more work. Not to mention that it's getting more and more unlikely when more stuff has to be fused...

[Centurion]

What IS the difference between part 1 and part 2? I'm actually planning to try this game once it finishes, and I'd appreciate knowing if Part 1 is intended to basically be a demo and part 2 the finished product, or if they are both completely playable, with part 2 bringing vast improvements and being better all around. Actually, in either case, ill try part 1. But it's comfort of mind!

[feneur]

You can see it a bit like how e.g. Age of Empires 1 and 2 and their expansions worked. Part 1 will be a completely playable game, but to be able to release at least some time within the conceivable future we've cut some features from it (things like seasons, units on walls, triggers/cinematics). Things which aren't necessary for a working skirmish gameplay, but at least some of them things we'd really want to have eventually. Also, part 1 will feature the civs which were prominent/interesting from the 500 B.C.-1 B.C. era, while part 2 will add the civs from 1 A.D.-500 A.D. (And that "add the civs" is important: part two will include all the civs etc from part 1, so once part 2 is released there's no reason to keep part 1. I should probably add the caveat that new features added in part 2 or other balancing etc might change things slightly of course, but it should all be for the better.)

To say it another way, part 1 will be a playable on its own, but part 2 will be a lot more