Blender Modules

I used to build games in a rather haphazard manner, but when I started my current project I realized that many of the things I was writing I had written before, and unless I took effort in doing them in a modular way, I would end up writing them again and again. So I put the project on hold, and split game making down into a bunch of functionality to build on top of the BGE. The idea being that instead of having a project where progress seems slow because all these little programming things are built up under the hood, to make individual ‘projects’ out of them so that I could see definite progress, even in the boring bits.
My list currently looks like

[TABLE=“class: grid, width: 800”]




Game Starter
Provides patch/update ability as well as configuring screen resolutions

Fixes blenders mist functions, and adds some!

Allows events to be scheduled at regular intervals

Provides a way for all input (joysticks, mouse etc) to be mapped
Delayed till I get a joystick

Provides LOD for lights including loading them at game start
Delayed till I learn bpy

Manages sound effects and music, can preload sounds (somehow)
Not Started

Provides a lowish level way of sending messages from A to B using host-as-router
Not Started

Handles button clicking, inputting into text boxes etc.
Not Started

AI Toolkit
Provides a slight extension on raycasts, getting angles between objects etc.
Not Started

Loading Screen
Provided a list of executable functions will execute them one per frame till ‘loaded’
Not started

Takes all of the above as they are made and integrates them into a single ‘project’
Waiting for more…


These are all python-only things, and most are not accessible from logic bricks at all. Many of them can run standalone or be integrated into each other (ie the BGEinput module can be run by an always sensor, or by the scheduler.
As each module is finished (and while I’m working on them), I write up the documentation, so each module is nicely documented.

So my questions is:
What have I missed? What utilities do all games have in common that could be made into modules? I’m generally aiming for these to take 2-3 weeks to make each, so if you think it’s bigger than that, split it into something smaller.

I usually create (over and over) a “scenegraph” module that:

finds objects starting from a scene or another game_object (with childrenRecursive) by name-query (prefix, postfix, infix, equality)
adds object from libraries, loading the blend if necessary, at certain positions (using scene.active_camera as “hook” for addObject)
ray casting (like scenegraph.ray_cast(point, point))
space management (place stuff in a cubhashtreelistmap that I don’t trust at all)
path finding with ray casting - too lazy to create navmeshes.

by the way, it wouldn’t be bad (or too hard) to add those in a new bge api - maybe starting with a clean namespace, like bge.lib. That way it would be possible to take advantage of the native code for the heavier parts.

particle system done completely with code , using bgl???

starting from fire, smokes , to build object complex as explosion prefabs
and function with very fews arguments, or just optionals, since the name of effect include already al lot of info .


def granade(position, range=5.0, time=5.0):

def gunshoot(position, vecdir): #time prefixed
def rifleshoot(position, vecdir): #time prefixed
def lightningtunderstorm(positionstart, positionend)#time prefixed

user - end - code

if click and ammo and stuff:
    bge.emitters.gunshoot(gun.worldPosition, gun.worldOrientation.col[1])

i added recently ->
it return all stuff of keyboard and mouse with few code ,and more FPS (we say the actual API is a bit hugly)

then (selfexplanatory i guess) (mouselook orbiter)
and different modules a bit dirty(need to be rewritten) for armature, actions, customconstraint

Modular inventory, and or weapon system,

Animation control system

Temporary action over time = add a empty that does x over time.

what you mean with “Animation control system”

what should be the code to write?
or what you think not work or can be better of the existent system?

“Temporary action over time = add a empty that does x over time”

this is not already doable with -> spawner
delay[x tic] -> and -> add empty

Animation control = plays actions based on a actors heading, velocity, sensors and keypress or ?

like a aI can run backward, while facing you, or a airplane needs to pitch the rudders while steering etc

and the temp action over time
would be some sort of empty that has many functions, and a slot for two targets,

like bring together with force, or navigate to , or ,higlight for x, or?

anything that has a set duration, FX maybe?

you see there a bunch of conditions ,
unless you found an “algoritm” as ->
action = key+vel.y*heading/sensor
or something but mhh seem hard.

very simple instead manage a group of action based on velocity.

main reference = own.parent.localLinearVelocity
x,y,z = own.parent.localLinearVelocity
if on_ground is positive:
    if y>3: run
    elif y > 1: walk
    elif y > -1: idle
    else: walk_bacward

if on_ground is not positive:
    if z > 0.0: jump

the implementation cannot be much hard.

is simple because you had just 2 stuff to check,
and each action can be a loop… is linear, few exceptions.

<b>and the temp action over time
</b>would be some sort of empty that has many functions, and a slot for two targets,

like bring together with force, or navigate to , or ,higlight for x, or?

anything that has a set duration, FX maybe?

seem just one state where the timer is the more matter condition to ends the state , or the unique.
can be done in 100 ways different , but not seem nothing of hard.

How about a universal dialog/conversation manager? It’s not 100% needed for every game, but many games have NPC conversations and others’ have simple interactions, such as “pull the lever” “yes/no”. it’s something I’m working on at the moment.

I usually use a simple particle manager, as it’s a bit inefficient to have dozens of maybe hundreds of simple objects flying around which have their own always sensor and python controller. I find it’s better to put new particles in to a list and manage them centrally, using properties on the objects to define behavior. So how about that one?

A tileset placer/level designer/loader? No easy to make a generic one, but can be a massive time saver if it works well.

A game saving/loading system?

How about a bullet time/ time control system? Things are getting a bit specialized now. :slight_smile: Maybe you don’t need all of these…

There are quite a few suggestions at the wrong ‘level’ of the game. an inventory or weapon system is a feature, not an underlying ability. The particle system manager is a good idea, but it wouod be far more generic than simply adding preset types of explosion. It’d also need to learn bgl…
The animation manager also has potential, but they tend to be object-based, and I can’t think of any generic systems that couod be writte around blenders current system

Save/load is a good one. I’m not sure about the generality tileset level editor though. Time control also seems a bit specific.

I just thought of another one: logicLOD. You pass it an object and it will manage logic running on it so that it runs less often when the object is far away.

So, I’ll add:

  • save/load
  • logicLOD

I usually use just normal objects for particles, and have some general behaviors such as grow, fade, drop, spin, track_and_follow, glow, random spawn etc…
Adding them to a list or dictionary as they are created and then managing them until they are removed is much faster than giving them all individual logic. It means that coupled with a light manager you can have light emitting particles, or you can handle bullets and rockets that way too. Once your system is set up it can be quite flexible and can be used again and again on new projects to handle things like rain or snow, sparks, lightning, smoke, fire or anything else.

I don’t think you need to track and render virtual particles with bgl. There wouldn’t be that much improvement in logic and the end result probably wouldn’t look as good.

Yeah, when I was doing the music visualizations back in the day,
I noticed huge improvements in speed from just managing a list of objects , for particle spawner, as well as particles.

One nice trick, using a Wireframe quad polygon as a particle and moving the mesh so all of it is on one side of the origin, then you can scale it to make a line that stretches, use velocity to scale the line and it can make some neat looking effects.

[TABLE=“class: cms_table_grid, width: 800”]

Allows events to be scheduled at regular intervals


you had some snippet ?
it can be very powerful if reliable, well designed, easy to use and robust.

for example -> “camera shock” (due movement in the current camera giving the illusion of some impact (ex bomb) , but it require more frames and the camera must be replaced in the original position at the end of effect…
also should be some check to see if the camera is object invalid etc.
how is removed the event? (i suppose is inside some list?)

another thing (i not sure if and how somehone has already done this) :
day-night cicle (maybe also this can be managed from the sheduler?)
this has not much dependendences, just one light, and a bit of code (i tried to do time ago but i missed in some blend)

ok, i’m pretty agree, the idea of bgl was to not have dependences.(ie: scene.addObject(“ParticleX”, own)
-> error ParticleX not exist

will be good have some Library STANDARD , EVER PRESENT , stored somewhere as “bge.prefabs” or something like this
so you can add you particles writing :
scene.addObject(bge.prefabs[“ParticleX”], own)

I don’t think you need to track and render virtual particles with bgl. There wouldn’t be that much improvement in logic and the end result probably wouldn’t look as good.

unfortunely i not see even half code of example (anyway the syntax seem pretty hugly :D)

Well, you could use empties and get their screen position (I’ve got code for that), then render some image or other visual effect at that screen position. You could use distance to the empty from the camera to set visual scaling.

But I haven’t done any work on that because using planes with halo type texture seems to work well enough for me.

I suggest you create such “components” when you need it for your project. Then you have at least a single use case and “target market” ;). This enables you to decide how much effort you want to spend on a particular aspect.

Everything else (e.g. developing it because it is interesting) will distract you from your own project. This happens to me quite a lot.

Yeah, me too. :slight_smile: But I think that’s not such a bad thing.
I’d really like to finish my projects, but more important is to learn transferable skills so that I can work much faster on the next project (or the next reboot of the current project).

Each time I start working on a project after a period of experimenting with other aspects of game design I find it easier and faster to make progress.

Also I’m not deleting my old resources, so there’s always a back catalog of old resources (art assets, experimental code etc… that i can use for the next project).

I suggest you create such “components” when you need it for your project.

I already did. Most of the code for these components is being straight copy/pasted from previous projects, given a nicer API, and having documentation written.
The only one that I won’t be able to copy 90% of the code for is networking. Everything else I’ve done before at least a couple of times.

This is essentially just a code restructure of my current game, trying to make it presentable as I do so. That said, I have a tentative estimate of over 100 days before the listed modules are completed. The game itself that I’m building these from/for has a much longer life-span than that. I can be said that it is just a continuation and restructure of DEEP Space, which was a restructure of Defender, which was a restructure of a game I made in logic within months of starting blender. I once had the project history somwhere, but I think it’s safe to say that if this projects already been in development over 6 years, it can afford to wait another 100 days.

Interestingly, each iteration of the project, the end goal gets simpler. Give it another six years of stripping down and I may have something simple enough to finish it in a weekend, well, twelve years and a weekend…

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.

There are a few things I get from that article:

  • Define a stopping point for your ‘generic’ code.
  • Make it do one thing, and one thing well.
  • KISS (keep it simple stupid)

When you write code with those in mind, it is … reusable!

The common failing with blender resources is, as battery says, the complex setup. I aim to provide these modules in one of three formats

  • A script that can be accessed from other scripts. No logic requirec
  • A scene that needs to be imported

Unfortunately this isn’t always possible. Things like the scheduler need to have code executed every frame, so require an always pulse sensor. But after that, much less code requires actual logic. The lighting manager, when imported in another module, looks for the scheduler and makes itself run when required (or can be run with it’s own always oulse sensor). Same with input, mist, and networking.
The menu code will be able to be run only when required, through a simple API, as will the AI toolbox, save/load, sound, etc.
The hard ones will be the loading screen, which will probably require a little setup, the game starter which is a separate blend, and the lihting manager which requires a small external library of lights.

Where does this leave us? Each of these modules has clearly defines goals. Each of them has a detailed plan for how to use them. They are built with simplicity of use in mind.
Agoose has written a fantastic networking script. It does networking but it is so complex to use that I’ve never figured it out. My networking setup is going to be a python script you can import that has the following functions:

  • Host(port)
  • Join(ip, port)
  • Send(message)
  • Check()
  • Stop()
    Anything game-specific (such as movement) is built on top of that for the game it is intended for. In this way the code is made to be simple to use. It doesn’t provide oodles of functionality, just the small, boring to write bits.

Previously I made the generic game template. It’s sitting in the resources forum somewhere. It doesn’t provide much, but it allowed me to built Neon Ball in a weekend. Along with several other projects I’ve never show here. Reusable code is useful. It just has to be simple to use and well documented.

We use blender game engine. That’s re-usable code common to all the games we make. It’s not even that simple to use. It doesn’t provide everything that’s common between all games, so I see no reason why it isn’t possible to create some small reusable libraries.