Blender Modules

[BluePrintRandom]

I think that having “plug in and go” resources like unity, will allow for a artists to use the engine without initial frustration.

all of these systems are required, some may even need to be hard coded into the core (dynamic light manager, particle system)

[MarcoIT]

@battery

I’m with Monster. Make bits you need and then make them more modular if you need to, once your game is finished.

I used to believe in building nice generic modules until recently. I’m currently working on a particles tutorial and I’d built an extensive particle class and manager that could create all kinds of wonderful effects. Anything the user desired. But it ran appallingly. Most of the logic resources were going towards checking off features that the user never asked for with a long API for additional confusion.

The other problem I see in many modules is that they tend to require particular set ups, or certain objects hidden or empties dotted around the place. Which isn’t very modular.

Re-writing the same bits of code again can be a bit of a pain. But these days it takes me less time to write a player control class than it does to copy in one I’d previously written and get that to work with my current project set up. Also, I don’t have the additional performance costs generic key mappings or key timings that the project was never going to use.

If you’re going to go down a modular route I’d suggest thinking more in component terms. Small blocks of code that do one particular job that’s independent of what’s going on around it. For example, I’ve written a game time module that manages years, months, days, hours etc in a game. It’s completely independent of the BGE (I also use it pygame), requires no particular set up, tiny API (3 functions, 7 attributes to play with). You just import it and off you go.

Each game is unique and there’s so many edge cases you might as well write just what you need.

This is a good read.

“Program to an interface, not an implementation.”

i want try to make a game starting from pure python , the rule is that the objects in python NEVER for any reason
can know the gameobjects.

so the pure python objerct should be extremely “abstract” , then the gameobject have to understand what is the right action to do. (for example play an action ,change mesh, sound etc).
the thing that seem sure is that is not usable the physic, otherwise the pythonobject is forced to ask something to the gameobject.

the right way: the code do the rules -> the models follow the code

[BluePrintRandom]

That sounds like a bad idea…

how will you make it run fast?

is the whole game 1 script?

Events? / callbacks?

Polling for controls?

What is the nature of the beast you are birthing?

[MarcoIT]

BPR, mountains and mountains of polling , in the horizont
this seem pretty mandatory

this is the minimal (each frame of course)
own.worldPosition = pythonobject.position
own.worldOrientation = pythonobject.direction.to_track_quat(“Y”,“Z”)

then… if pythonobject.stuff!=mystuff … etc etc

all in this way should work

i not have problem with performances, my more complex game can have 1.0ms of logic
i want give serius work for the CPU this time

anyway can be problem that actually not keep in count, for now see only the physic …

why? the actual way that i know to make a game not go far, really nothing… i need to found some trick