Re: [Adonthell-general] Some general suggestion

[Ingo Ruhnke]

Kai Sterker <address@hidden> 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: address@hidden 
ICQ:      59461927