Design, first draft

[Adrien Grandemange]

I made a first draft about the API design.
There are 3 parts in the document:

- 1st part is a general use case diagram. It is very general, as
we didn't list all the aspects of the game that should appear in the
API yet.

- 2nd part is an architectural diagram illustrating what are the
modules and plugins and their possible interactions.

- 3rd part is an example of module interface and implementation,
and a possible use of this module.

http://lbapi.googlegroups.com/web/LBAPI+-+Design+1st+draft.pdf?gda=RgbzvE8AAAALPI3RTSm6C0jYn1h4LW6Ol1hYF3TCHuREG32Wr6Q9D6h3GFVTW2IwMNdPk5COFXY4MlporabrO1LfO53AvDIznHMhSp_qzSgvndaTPyHVdA&gsc=pzxwcAsAAAChp1zJqT5IUh5JG9QKKDJn

Remember that the goal here is to outline the GENERAL architecture of
the API, not discuss the details of the code I present. Tell me if you
have better ideas about the plugin system and the module separation.
If you think the word "module" is not explicit enough, suggestions of
a replacement word are welcome.

Once we come to an agreement on the general architecture, we'll start
listing the different aspects of the games and where these should
appear in the API.

[alexfont]

Great diagram start Link. You passed the exact idea how it could work.

I have some inputs regarding your Packaging example.

Entry:
- It shouldn't have those definitions about Model, Scenes or anything
else. If we need it, just extends that class and add proper members
for models or scenes. It should have imo only few things. This class
should allow be extended like ImageEntry, SpriteEntry, EntitiesEntry,
etc..

Package:
- Here, I'll suggest this being a Generic Package which could receive
an Entry type. It Could be a generic Entry object or a ImageEntry,
SpriteEntry, etc.. Also, with only the necessary members. This could
be extended like you did with HQRPackage.

PackaginSystem:
- I'm not yet sure about this. The idea is great, but I think it is
misplaced. I don't want to specify the system I'm using everytime I
want to extract something. I think this must be an api configuration
where we set which system we want to use or not. Also for the package
identification. We need to think better on how to prevent typing
everytime the engine packaging we're trying to get files from.

Got to thing better about this points and see if I came with something.

[Adrien Grandemange]

Well, I didn't dig the details as I said, because I wanted to have a fast example to support the general architecture. I'm sure we can improve this a lot.

About the entries, that was precisely my idea. In fact, I also thought about doing something like Qt's QVariant class, for those who know it.

About choosing the packaging system in a configuration, why not, but I was thinking of the mods programs which could use many packaging systems at once. You can easily make the configuration part in your own program, it doesn't have to be part of the API.

There is a serious problem about how to locate the actual files in an unified manner though.
Maybe a solution would be to use URLs with a convenience class to handle the different parts of the URL. Possible example: "lba1://myLba1InstallationFolder/scene", where the scheme would refer to a game engine and it's specific packaging layout, the domain name would reference a particular dataset, like for example if we work with lba1, a specific installation folder for LBA1 (the domain name would have been registered before by another part of the API), and the last part would reference a particular package.

--
Adrien Grandemange / 郭啸天 (Guo Xiao Tian)
Epitech 2010 / Tek4 Chine / Chongqing University student

[Rincevent]

Yes, this is already nice design we have there. The diagram is clear,
the architecture also.

For this Entry class, I think the use of such a "builder" pattern
would actually fit well in this case.

I would also not be in favor to choose the packaging system in a
configuration as it is possible to use
multiple packaging system in the same application. And since you are
using a singleton for the pluginmanager we also can not specialize
this class.

An idea of what you could do is to replace the string by a small
"packagetype" class which could contain:
-package name
-package version
-other infos?

Then if you do not want to provide the string everytime you call the
function, you would just need to instanciate this packagetype class at
the beginning of
your application and always refer to the class anytime you call the
getPackagingSystem function.

On Jul 13, 10:08 pm, Adrien Grandemange <itsmea...@gmail.com> wrote:
> Well, I didn't dig the details as I said, because I wanted to have a fast
> example to support the general architecture. I'm sure we can improve this a
> lot.
>
> About the entries, that was precisely my idea. In fact, I also thought about
> doing something like Qt's QVariant class, for those who know it.
>
> About choosing the packaging system in a configuration, why not, but I was
> thinking of the mods programs which could use many packaging systems at
> once. You can easily make the configuration part in your own program, it
> doesn't have to be part of the API.
>
> There is a serious problem about how to locate the actual files in an
> unified manner though.
> Maybe a solution would be to use URLs with a convenience class to handle the
> different parts of the URL. Possible example:
> "lba1://myLba1InstallationFolder/scene", where the scheme would refer to a
> game engine and it's specific packaging layout, the domain name would
> reference a particular dataset, like for example if we work with lba1, a
> specific installation folder for LBA1 (the domain name would have been
> registered before by another part of the API), and the last part would
> reference a particular package.
>

[Adrien Grandemange]

Ok, let me get more specific about how I imagine the Entry class.
Entry is meant to be subclassed, but not by ImageEntry, SpriteEntry
etc types.
These types are what I describe as LBObject (LBImage, LBSprite would
be subclasses of LBObject).
Entry is just an abstract way to read the content from the packaging
system, so each PackagingSystem would have its own implementation of
Entry.
Then probably provide a stream to LBObject to read its content, the
type of stream depend on the packaging system.
In case the type of content in an Entry is unknown, then getContent
throws an exception or just returns an invalid LBObject.