How does a 'good' architecture for a jPCT-AE project look like?

[say-V]

Hi!

I develop kind of a realtime game for Android with jPCT-AE and after my project gets bigger and bigger I am very concerned about how I should partition my code. I know this is kind of a big question, but maybe there is somebody around that already did some big jPCT-AE projects and is willing to post some advices how to engineer the code/classes best. I think a lot of people would be gracefull for that.

Some words on my situation. I use a class that implements the android.opengl.GLSurfaceView.Renderer interface. In the onSurfaceCreated() method I create all my objects and world and stuff. This are already around 300 lines and it is very unclear. First I also had navigation code in this class. But after it gots soo big, I created a new class that implements Thread where I put all navigation things. But now I have a lot of cross-references and I have problems to synchronize both threads. In short, it's all a mess. No way to even think about putting something open source in this state.

I'm exited for your tipps, and thanks in advance!

[firstdeathmaker]

ha, I think you hit a nerve. Lots of people have thought about this problem. The result is:

There is no perfect structure. But there are some methods that could help you:

Architectural Pattern

Especially : Model-View-Controller

As some general advice I would suggest: Split everything in smaller peaces, implement Data-Controllers that manage your data for you, work with ini-files (XML is great for that). Especially when I read

In the onSurfaceCreated() method I create all my objects and world and stuff. This are already around 300 lines and it is very unclear.

If you have a lot of similar stuff to to, you could write yourself some helper functions or classes to get that better done. Example: If you need to load a lot of different 3D-Models, Gameobjects with additional information (like Cars or Gameitems) than write some Managers for thoose, so that you only have to write the name of that object and the Manager is doing the rest.

But its a big topic, so you might want to read a book about it.

Another good helper might be UML-Diagrams, where you can model your Software beforehand.

[EgonOlsen]

I wouldn't put too much into different threads if it isn't really needed. I also know this video from Chris Pruett at Google IO about separating logic and rendering in different thread to improve performance. I disagree with this (or at least i don't agree 100%), because the GPU can already do stuff in parallel to the CPU. I tried this though and it didn't help performance wise (as expected), so i don't think that it's needed in most cases. For the sake of simplicity, i would put the game logic into the rendering thread just not directly but in form of some game logic object whose methods get called right before the rendering or something like that.

Model-view-controller might be a good start. If you are familiar with Swing, you'll already know about it. However, i don't think that it's needed in all cases. I used it for Robombs, because i had to separate the network related parts from the actual rendering, but i haven't used it for other games. Like firstdeathmaker said, it's an open field...

In your case, i would start with moving/grouping code out of the Activity/Renderer class and into more specific classes. If you go with the manager/factory approach (which i personally like) or create more "intelligent" objects instead is up to you. Just don't take my Alien Runner sources as a good example... It's ok for some parts, but with others, i was just lazy...

[Andrey8000]

Hi all.
I need to split the render and logic (because the FPS to render can drop to 15-20, but the logic should be carried out smoothly at 30 fps in any case). To begin, I just create the logic of the movement of objects in a separate thread. But the picture is bad - it shakes (because one object at the time of rendering may have to be moved, and the other is not). How can I synchronize the thread of rendering and logic thread  in this case?

[EgonOlsen]

The better idea in this case is to separate your game logic from the view, i.e. create simple game entities and contain the needed attributes and a position and rotation and stuff like that and to only update the views (which are real Object3D instances) with this values. That way, you only have to synchronize the part that does this copying with the game logic and not the whole rendering. There might be some overlapping between view and model in case your are using jPCT's collision detection methods, that may need additional synchronization.
That said, my advise still is not to do it. You can build your logic time or tick (which i prefer) based and so it doesn't matter if it runs at a steady 30 fps. You might be able to keep that rate on lower end devices anyway. That will save you the whole synchronization process.

[Andrey8000]

Ok, thank you.
I really need to separate, because in the future I will have interaction over a network.
Yes, I understand that it is possible to use a low setting and I do it, but it's not a reliable way in my case.