Skyfaller wrote: Developing an AI ... well, first I'd like to get the mechs walking in the original levels. In order to make modding the levels easier, I plan to export level descriptions as XML files that reference geometry in the PRJ (.WTB files). Once the mechs are walking and shooting, network and/or AI will have to be developed. While it seems easy to program a simple AI (come to a certain fighting distance with the opponent, then shoot until the mech runs hot or there is no more ammo), creating an AI that is interesting to fight is much more of a challenge.
I'm thinking (quite loudly) about how to describe the MW2 levels in XML files. Here's a list of possible approaches, with pros and cons:Sir MMPD Radick wrote: Your assessment I believe to be correct.
You must get the basic movement code functional before you go any farther.. developing an ai without that is possible, but it would seem to me to be a frustrating way to go about it since you would not be able to see it in action visually.
The XML files for each level make sense as you already are exporting most things in that form anyway. It is better than writing a new scripting language for it that is for certain. Why double the work when you can use something premade and easily parseable?
I have tried converting some BWD files to XML, but the results need some brushing-up. ATM, it seems that I think I should pay attention to few tags: INCL, OBJ, REPR, ENDR, NAVP. INC includes other BWD files, OBJ includes geometry from the POLY directory. The REPR/ENDR tags seem relevant, too, because they group object parts into object groups, for example, destructible buildings. Perhaps it will be best to import the levels the same way I do it with the mechs: the objects inside REPR/ENDR tags are exported to XML files describing an object. I will need XML files how objects are exported, and further files that control how the exported objects must be assembled to form levels. Nav points could be imported in the same manner, but AI mech positions, goals and mission objectives should be hand-coded in XML. Minor variations might make the game more interesting.
+ Most flexible approach
+ (Relatively) Easy to produce mods by editing XML files or by editing 3D models exported in OBJ format
- Requires lots of code to export levels and load them later
Alternative: quota4stupid's documentation adds almost all the knowledge needed to load everything from the PRJ as needed. PRJ access would need to be sped up to be fast enough to handle this, or users will be bored to tears. This would lead to 100% conformity with the original game.
+ Less coding overhead
- Difficult to mod: any deviation from the original game requires developing much of the XML toolchain outlined above or altering the PRJ directly
- Requires optimization
I value the ability to mod the game over recreating the original game to the letter. The arguments above lead me to believe the XML toolchain for MW2 level import is the approach to pick here, but I'd welcome any arguments our readers might have. quota4stupid, do you see other tags worth preserving closely?
Texturing:
It might be possible to the x/y coordinates as texture coordinate for mountains as long as they are not too steep. This would allow texturing the MW2 DOS levels. When this does not work, we (I?) will need to edit things in a 3D suite, or we may have to live with the textures offered by the sim and objects in a single color.
As far as sim design goes, my intention is to work directly with the original files.
In the next couple of days I'm going to get a nice big piece of paper and try to draw a diagram of how all the chunks relate to each other to give myself a clearer picture. What I will say now is that there's definately a lot of superfluous information in those chunks, definately a lot of stuff you could discard.
