Project Structure

[AndySmile]

Hallo there,

I've looked through the file directories and have tried to compile that demo and it's really not that easy to just simple
compile and run it but also to find all that things u maybe need if you want to implement a new feature or even just find
a point to start with. I little chaos so, I'm just curious how it's planed to organize that project and if it's done that everything gots its logical place, how we share it, that everyone can use it for his part of work?

I'll try to find some time to get it compiled and try to organize it a bit. Because, I think if everything find its place it's simpler
to redesign parts for new features or something, what do u think?

See ya
Andy =)

[Urfoex]

I'll try to find some time to get it compiled and try to organize it a bit.

I had problems compiling it myself (and haven't got it yet because of nvidias physx ...).
Look inside that one if you haven't:
viewtopic.php?f=19&t=3565

The hint from alt_turo to take that and make a how-to or readme out if it should be followed some day that other people good get faster into it ^^
(I could have done it but stupid nvidia won't give me there physx-sdk (partly my fault for not giving them as much information about me as the wish ...) so I don't know if anything else is missing or so. For now following what alt_turo said should work quite well.)

Good luck!

Because, I think if everything find its place it's simpler
to redesign parts for new features or something, what do u think?

Do we need to redesign the engine?
Shadowgrounds and Trine is made on top of it and the prototype of Jack Claw. It is working.
Do we need to change the engine to create the Jack Claw we want?
It is said that e.g. the engine is not made with multiplayer-support in mind. So there could be a hacky-dirty way to implement that in the current engine but with a redesign it could also be integrated in a more wanted kind of way.
But do we need that?


On the other hand:
yeah, I would love to play Shadowgrounds on Lan or over Internet and I would be glad to see physx removed .

Are there any technical documents about the engine and how it is build? Any diagrams or stuff like that?

@AndySmile: Do you have a better structure in mind for it? Or at least some ideas? ^^

[AndySmile]

Hey @all,

no, I didn't ment to redesign the entire project. I just want to reorganize the files and folders, so that u find the parts u
need. For some parts it already exists, but if I open that game folder, lots of files comes out and then u have to search for the part u need. Here we could put them again into folders like "Level", "Enemies", "Buildings" and so on.
Split the engine code in its parts like, renderer, maths and so on. I think it helps to read that code. Sure, someone who have read the entire code and have worked with it, probably knows every corner of this project. But I think to keep the overview
of every part some of those structure changes could help to make it easier and save for the future and new project member.
Next think is documentation. As example, using doxygen, that's available at linux, mac os x and windows, is really great to
document that project. I think that would be really helpful.
Next thing, that makes it easier to assign other members to specific parts of this project like editor, game, ai or engine
development would be to split the code in libraries. On this way everything got a logical part. But I already started this subject
in another thread .

I must say that I'm working on Mac OS X, so I want to reorganize that project a bit, so I'm not afraid to do a lot of work.
I know that this need some time, but I think it worths it in the future and we as community have a big advantage, we don't
have any milestones or deadlines or limited budgets, so we have the time, to make a really good code base to make a really great game . Just tell me, if u have other opinions .

see ya
andy

[StevenT]

On the topic of actually compiling the codebase I've been having some success getting things working using Visual Studio 2010 on Windows. Not my preferred platform but I cannot use Linux since Nvidia do not offer the Linux PhysX SDK for the version of PhysX that Jack Claw is using on their download site. In another thread alt_turo said that you have to ask Nvidia directly for the Linux SDK. I would use Mac OS X as a second choice but I could not get the Xcode project to compile - probably just my fault for not being too familiar with Xcode.

As for radical restructuring of the engine/project, I think we should just try and get productive with what is there first. Yes, the code is rather chaotic in places but as Urfoex says, what is there does indeed work and has done for other released Frozenbyte games.

I think it worths it in the future and we as community have a big advantage, we don't
have any milestones or deadlines or limited budgets, so we have the time, to make a really good code base to make a really great game

To be honest, I think those are actually bad things. Milestones and deadlines can help to push things along. Perhaps we should think about creating weekly, bi-weekly, monthly milestones for the project and just pretend that the world will end if we don't hit them?

Hopefully we will change many things as the project continues, but I think that will happen as pieces that need to be replaced for a good reason are rewritten, library dependencies are updated/replaced due to being outdated or hard to access and so on.

[alt_turo]

Next think is documentation. As example, using doxygen, that's available at linux, mac os x and windows, is really great to document that project. I think that would be really helpful.

Good idea and there's already some support for it. Someone needs to create a Doxyfile and then start adding comments. The generated documentation itself does NOT belong in the repository because it's 1) automatically generated and 2) huge.

Next thing, that makes it easier to assign other members to specific parts of this project like editor, game, ai or engine development would be to split the code in libraries. On this way everything got a logical part.

Not a good idea. Libraries are useful when code is not tightly coupled. PhysX and OpenAL are good examples of this. Splitting our code into libraries would bring nothing but problems:
1. Since we don't have stable API you would have to remember to update all libraries at once. Forget and you get nasty crashes.
2. On x86 Linux library code is slightly more inefficient.
3. When ASLR is enabled on Linux (most current distributions) stacktraces with library addresses become almost entirely unusable.
4. On windows there's the msvcrt issue (detailed in some other message I wrote) so trying to split the current code into dlls would create a HUGE mess.

I must say that I'm working on Mac OS X, so I want to reorganize that project a bit, so I'm not afraid to do a lot of work.

You can do almost anything you want to the OS X project files as long as you follow the golden rule: Thou shalt not break the build. If you move files around then you must also update the Linux and Msvc project files. For Linux this is pretty trivial since the module.mk files are plain text and trivial. Msvc files on the other hand are XML (yuck) so you need help from someone with msvc to update them.