I am going to be starting this week coding up the framework for our panda 3D game and was looking for advice on an Architectural model or recommendation to follow. I Searched on the forums and didn’t really find anything to helpful and the examples panda came with are mostly one script files that show how to do something specific. Any advice web pages or forum posts I may have missed on this topic related to panda would be greatly appreciated.
PS. If your interested in knowing where making a 3rd person herding game.
Well, the architecture I use in my Panda project uses a plugin-based approach: All of the Panda-related code (i.e, code that makes calls into Panda) is kept in a bunch of plugins loaded at runtime. The plugins each use custom datatypes (instead of Panda’s built-in ones, like Vec3 or VBase4) at the interface/API level. They also each have a non-Panda-specific interface.
This way, if Panda breaks backwards compatibility, or I want to change the way the plugins talk to Panda, only the plugins have to be modified. No other code has to change. I can even make my game run on top of another game engine just by writing another set of plugins!
The primary disadvantage of my approach is that I have to add new code/classes to the plugins whenever I want to use a new feature of Panda, since calling directly into Panda would defeat the purpose of this approach.
However, in return, my code becomes a lot cleaner, I can easily port my game to Panda 2.0 when it arrives, and if I want to port my game to another platform Panda doesn’t support, I can do that easily, as well.
EDIT: You can take a look at the plugin that implements Panda-based rendering for my project here. The plugin framework (the code that handles plugin loading/management) is here. You see how they’re used together in this snippet.
Yes, my approach isn’t the best for everyone - it involves creating a lot of new code for things like custom datatypes, and plugin management. However, if you want/need that sort of separation between Panda and your game, it’s the way to go, IMHO.
If you want, you can make calls directly into Panda throughout your code. You won’t have to make all of that plugin stuff (so you won’t have to write as much code), and you can immediately use new/different Panda features, but if/when Panda changes, you might have to go hunting across your code looking for changes you’ll have to make. For small projects (like yours might be), this isn’t a problem; but I’d recommend my plugin-based archectiture once your project grows to around 2,000-3,000 lines of code, because hunting across all those lines for necessary changes would be a real pain otherwise.
I’m not trying to say my architecture is the only good architecture in the world - far from it, there are probably better - but in my experience, the flexibility and separation it brings far outweigh the cost of having to write all that plugin management code and custom datatypes.
object oriented approach is very recommended.
make classes where stuff that logically belongs close together is an the same place. try to make the classes so they only require as few as possible calls between classes. easier said than done. one example (altho not the best one) can be found here http://thomaseg1.p3dp.com/samples/Cuboid-Clone%20rewrite1.zip
it might give you a rough idea.
the less calls between classes / the more separation between them, the better. it allows you to test single parts independently and rewrite whole classes if necessary without getting into too much trouble due to breaking everything else in your game.
So you’re looking for examples on OOP (Object-Oriented Programming)? Do you know OOP? Are you looking for how to program with Panda in this way? Or are you looking for resources on how to program using OOP?
If it’s a one men project, then stick with ‘Do Simple Things’ and ‘You’re Not Gonna Need It’. If you have a team then oop is a good way to keep the code sane. Unless you have a very good idea how all parts of the game will work, I’d say to make classes that control the ‘what’ not the ‘how’. So classes for bullets, doors, creatures, items etc, not collisions, input, movment and suchlike.
wezu this is not a one man project so this is why it needs to be oop. I’ve done traditional Software OOP but I wasn’t sure how objects should be organized and structured in Panda projects. So that Kinda what I’m looking for examples and documentation of.
I do not think there will be any documentation on it because it is all up to the coder(s) to decide how they break it up. For me I have classes for everything and then run the classes from my main.
An example is a World class that when it is created it loads the world objects such as models, background, etc. I am working on a Character class that will be used by AI and players. It will have basics such as attack values, defense, etc and I will then extend that class to add how they move either through player controls, AI, predefined path, etc.
When it you get down to thinking about this it can be done however you want it to. A suggestion would be to create a coding style that is not complex and confusing but one that everyone on your team can feel comfortable with.
Panda doesn’t impose any particular codding style on you. The API is flexible enough to allow you to make all kinds of code design mistakes you can imagine . Or, for the better of it, structure your code to best fit your needs and be a pleasure to develop. It’s all up to you which one it is.
Thus, I don’t think anyone can tell you exactly how to structure your game. Evey game is different, but luckily Panda allows you to embrace that and code what works best for your game. You just need to figure out what you need.
If you’re coming from other OOP-oriented software engineering my suggestion is to be Practical rather than Proper. Some kinds of OOP practices and design patterns make sense for scalable enterprise software but don’t always make sense for games.
One example is deep, incremental inheritance, ( i’m sure there’s a real term for that, i just made that one up ), where you try and have a very structured inheritance taxonomy and only add small bits of functionality at each subclass to avoid duplication of code and control object access. this can get unnecessarily rigid for games, and isn’t as necessary in python as it is in something like java.
object access itself is another example. some oop approaches call for strict interface control, but at least for me I find I’m always running into cases where much more needs to be public than I realized in the beginning.
another general thought: in oop you often make verbs part of objects, so all the things a critter can ‘do’ are its methods. move, eat, sleep, attack, die, etc. sometimes, though, you’ll find cases where an action involves multiple critters, or critters and other items and the overall environment, all at once. you may find it better to handle it at a higher level, in a ‘world’ or ‘xxxxManager’ class, because proper handling requires knowledge and manipulation of lots of different objects and it’s also important to precisely control execution order.
last thought, pythonTag is a very, very useful thing.