Kai Sterker <[EMAIL PROTECTED]> writes: > PDF seems to be a good choice for documentation that describes a > final state and which does hardly change.
In my experience stuff is hardly ever in final states, there are always bugs, missing information or simply open question left, with a Wiki one can easily add the necesarry information, fix the bugs or use the 'Talk' page associated to ask questions. PDF are nice for printing, but I find hyperlinked documentation far more usefull in general. architecture.pdf for example isn't really all that long that it can't be read confortably on screen, especially not when you take each section for itself, yet it still might need an edit here and there which would IMHO make it better suited to be placed in a Wiki. Stuff like scripting_guide.pdf contains lots of empty section, gfxdoc.pdf seems to be mostly useless when switching to PNG and some of the other docs also might grow along the development of the engine and gfx. >> There also seems to be some secret repositories for story and >> artwork floating around somewhere not directly linked from the >> webpage. > > Yes, but that is somewhat intentional. I know, but I still don't consider it a good idea. It should be made clear that after a certain link you enter developers territory and probally get some spoilers for the story and such, but first of that link shouldn't be that hard to find and secondly any obscurity you add just raises the bar for new developers, a lot. Most players will only know about the game once its finally released anyway, so the number of players who accidently spoil the story should be quite small. > We'd need some suitable webspace for that first (although we should > be able to set up a PHP Wiki at linuxgames.com. If it requires Perl > though (or Python or anything else) we'd need a location for it > first. Mediawiki can be easily installed at http://developer.berlios.de/, they also provide SVN repositories if needed. > In brief, it's not tilebased; instead objects of arbitrary size can > be used. A 3D model is used internally to allow different height > levels, but all objects are 2D. Objects themselves can be composed > of multiple graphics, respectively animations. All this needs to be > properly coded though. I am still not really sure if I understand this one. 3D model or navigation-mesh sounds like overkill, but then it depends on what you exactly mean by that, since you can more or less easily mix tilemap based approached with different height levels and the like. You can have multiple tilemaps layers and such. Different sizes for objects themself should be doable even with a tilebased approach. Are there any more details on the planed map layer, pictures, sketches or the like? Or is architecture.pdf and mapengine.txt all there is currently as documention? >> IRC Meeting: Just for the record, I have added back #adonthell to my autojoin, so in case anyone is intersted in joining, I'll be there ;) -- WWW: http://pingus.seul.org/~grumbel/ JabberID: [EMAIL PROTECTED] ICQ: 59461927 _______________________________________________ Adonthell-general mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/adonthell-general
