Folder structure - what should be cleaned up here?gui folder content - i assume you are working on thatfonts folder - yes, we could probably do thatsetting default font - will fix this once the new gui is up in the repos "example" programs - it is the shader programs that we use. Currently we use the default ogre ones. We could possibly do a rename, though we will have to look at how exactly we deal with the shaders after this release is out and we are going to look more into normal mapping.development - can probably be deletedmedia.cfg - have to check that, if it's not used it should be removed"ExampleApplication" - There is another class "MapEditor" that inherits from this one. These two classes should be merged, and cleaned up.Plugin directory - if you mean the ogre plugins, yes it is like that on windows currently, we should probably create a plugins folder, this should be easy to change.

Yeah, my local OD installation already uses the cleaned up gui/font structure. For the last steps there's also code changes needed.Yup, the Ogre plugins on Windows.If there's something called "example" this always looks so "cobbled".

edit: The folder structure: remove the "Media" folder. Now it's od\Media\gui, it could also be "od\gui".There's no other folder besides "Media" in the od root directory.

I agree, the media folder, especially the textures folder, could use cleaning up. Personally, I'd like to see folders for each creature, which would make it slightly more sane. Also, what's up with those material preview images? Surely they aren't used for anything?

TheAncientGoat wrote:I agree, the media folder, especially the textures folder, could use cleaning up. Personally, I'd like to see folders for each creature, which would make it slightly more sane. Also, what's up with those material preview images? Surely they aren't used for anything?

Regarding the textures folder, It's more convenient for me to have everything in one folder. I often have to make a lot of changes to the materials and textures and it would be rather annoying to switch the folder everytime I have to adjust something.

What do you mean with material preview images? I think everything (or almost everything) in this folder is used.

I agree, nobody will look at this. And the few people who will (Skorpio) should have it their way to be able to work efficient. When we make a new release it is automatically compiled and packaged anyways. And players of the game could not careless about file structure in the game folder, they will never look at it.

I agree, nobody will look at this. And the few people who will (Skorpio) should have it their way to be able to work efficient. When we make a new release it is automatically compiled and packaged anyways. And players of the game could not careless about file structure in the game folder, they will never look at it.

The clean up should benefit us the developers, not be a hassle.

I have a different view point. All structure should be designed to allow for collaboration and joint development. Whichever way is chosen, it needs to be documented. A new developer poking around in the project files should be able to understand almost everything from developer documentation and the folder structure, rather than having to ask the project devs how things are structured.

The content grouping is one aspect (the graphic guys can sort their stuff as they like it). But another aspect is the folder "deepness". The folder structure should not be unnecessary deep. That's why I suggested removing the Media folder. It's an unneeded level of deepness (because there are no other folders on the same level). That's like putting a multi-panel bookshelf in a one-panel cupboard.

blablub wrote:The content grouping is one aspect (the graphic guys can sort their stuff as they like it). But another aspect is the folder "deepness". The folder structure should not be unnecessary deep. That's why I suggested removing the Media folder. It's an unneeded level of deepness (because there are no other folders on the same level). That's like putting a multi-panel bookshelf in a one-panel cupboard.

This also has a technical reasoning behind it - NT based Windows systems struggle with long folder paths. The MAX_PATH is set to 260, with a realistic maximum of 248 and apparantly the windows API in unicode can address 32,767 character paths. However, when creating directories, it is not possible to exceed the MAX_PATH.

Regarding the use of ExampleFrameListener, ExampleApplication, etc in the code: changing these is not conceptually difficult but would take quite a bit of doing and I don't really know what to change them too anyway. OpenDungeonsFrameListener is not any more specific or informative. Also, the only place those names are actually really used is in the 100 or so lines of Ogre code which creates them and calls a few of their functions. The bulk of the actual game code doesn't do anything with those names anyway (or shouldn't once I get things reorganized a bit better). I am not opposed to changing the names in principle I just don't think there is much to be gained anyway. Additionally: those are the names Ogre tutorials, etc, use so other Ogre coders will immediately know what those classes are used for and what methods they should expect the classes to have.

There has been much discussion about this. I basically consider the file Media/levels/Test.level to be more a part of the source code than I think of it as "art content". When the game loads it automatically reads this file and if the format is not exactly correct it will crash without giving you any kind of useful error message. So if I change the code and the file format changes I want to make absolutely sure that anyone who downloads the new code also gets at least one level that will load properly when they run the game.

Presently, the format that is stored in the file and the format that is sent over the network in multiplayer games is identical. This makes coding the multiplayer system much easier since the same code used to read the level files is used to talk over the network, and any changes to the code for one automatically bring the other up to date. If I used XML for the level file it would mean that the network would either also have to use XML (which would slow it down significantly), or I would have to use separate code for network and level file loading. Since the level file is not meant to be edited by hand when the game is finished, I opted to go with this format which is more like the binary format that will be eventually be used on both the network and the level files.

I do not know exactly how you have made the network code so it works using the games code for loading levels, but with XML you could make a visitor that translate the XML into the corresponding network format, which is then sent. That way you do not have to send more data over the network?