MBGE and MUTIL

Game Engine Game Engine Resources
1

Hello all,

Monster presents:

[INDENT]Monster’s BGE and Monster’s Util[/INDENT]

What is that?

It is an alternative API to the bge. It is based on bge but provides a different approach.

What? Why would I need that?

I do not know if you need it. I often stumble across the (in my eyes) overloaded BGE API. MBGE focus on the single aspects of the game engine. Therefore it contains more modules than the BGE API.

Some functions are encapsulated in Python properties:


import context

...
owner = context.owner

… some function get rid of the chaotic combination of arguments


from mbge import loader

loadResult = loadFile("//demoLibrary.blend", loader.DATA_BLOCK_SCENE, async=True)

… some results are structured classes


from mbge import physics
...
hit = physics.detectHit( (0,0,+10), (0,0,-10), property="ground", xray=True )

owner.worldPosition = hit.position

… and some functions are just placed under a different package.


from mbge import path

assetPath = path.expandPath("//assets")

How should I find anything in this chaos?
There is an online documentation at GitHub.
In difference to the BGE API, all modules come with Python Documentation.


import mbge

print( help(mbge) )

shows some meaningful results:


Help on package mbge:

NAME
    mbge

PACKAGE CONTENTS
    context
    loader
    logic
    mouse
    path
    physics
    render
    stereo
    storage

DATA
    context = <Module 'mbge.context'>
    loader = <Module 'mbge.loader'>
    logic = <Module 'mbge.logic'>
    mouse = <Module 'mbge.mouse'>
    physics = <Module 'mbge.physics'>
    render = <Module 'mbge.render'>
    stereo = <Module 'mbge.stereo'>
    storage = <Module 'mbge.storage'>

AUTHOR
    Monster

FILE
    [hidden]\mbge\src\main\python\mbge\__init__.py

and the single modules can do that too:


import mbge
print(help(mbge.loader))

showing:


Help on Module in mbge object:

mbge.loader = class Module(builtins.object)
 |  Methods defined here:
 |
 |  __repr__(self)
 |
 |  copyMesh(self, targetLibraryName, meshNames)
 |      Copies an existing mesh.
 |      :param targetLibraryName
 |      :param meshNames - a list of meshes to be copied
 |      :return: a list of KX_MeshProxy with new unique names
 |
 |  injectData(self, libraryName, dataBlockType, data, **flags)
 |      Injects blend file data into the scene.
 |      :param libraryName:
 |      :param dataBlockType:
 |      :param data: bytes from a blend file
 |      :keyword load_actions: Search for and load all actions in a given Scene
 |      :keyword verbose: Print debugging information
 |      :keyword load_scripts: Load text datablocks as well
 |      :keyword async: Asynchronous loading - DATA_BLOCK_SCENE only
 |      :return: bge.types.KX_LibLoadStatus
 |
 |  loadFile(self, blendFileName, dataBlockType, **flags)
 |      Loads data from a file.
 |      :param blendFileName:
 |      :param dataBlockType:
 |      :keyword load_actions: Search for and load all actions in a given Scene
 |      :keyword verbose: Print debugging information
 |      :keyword load_scripts: Load text datablocks as well
 |      :keyword async: Asynchronous loading - DATA_BLOCK_SCENE only
 |
 |  unload(self, libraryName)
 |      Removes a library.
 |      :param libraryName:
 |      :return: True if the library was unloaded
 |
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |
 |  __dict__
 |      dictionary for instance variables (if defined)
 |
 |  __weakref__
 |      list of weak references to the object (if defined)
 |
 |  usedLibraryNames
 |      The names of the loaded libraries (readonly)

While MBGE focus on restruture, MUTIL focus on often used operations. With that you can easily perform the often forgotten sensor checks and actuator activations:


from mutil import sensors, actuators

def activateWhenAllPositive():
    if not sensors.allPositive:
        return

    print("All connected sensors are positive - activating actuators")
    actuators.activateAll()

Yes, but … I do not like it

This is up to you. If you like it you can use it. If not … just do not use it. This is no change on the API, it is a wrapper around the existing one. This also means that any flaws and issues of the BGE API still exist (e.g. reading gravity is not possible).

Btw. this wraps around bge.logic and bge.render but not around KX_GameObject and other types.

There will be updates in future, so have an eye on the GitHub repository.

Have fun
Monster

2

You can read/write the current scene’s gravity from scene.gravity

3

That is good. I did not know that.

… this takes it into the scene context. So I think the best is to remove it from the MBGE as this is game context. Thank you for that hint.

[Edit]: removed gravity from physics context