gryLib - Coding framework for UpBge

gryLib - Coding framework for UpBge

Theres is currently little documentation for this library. Information about its capabilities can be found in the example blend and in the code itself.

KeyBinds, SystemSettings, and ErrorLog are stored in //system.
CharacterSheets are stored in //stuff.

Some examples of how to use it.

import gryLib as gry

# get more information

# subclass an object.  can be called from a controller
obj['sub'] = ''
obj = gry.sub()

# get a child object by name
# self is named 'SomeObj'.  child is named 'SomeObj MyName'
gry.child(self, 'MyName')

# get information from a sheet defined in //stuff/someThing.ini
uId = 'some_things_uId'
sheet = gry.sheets[uId]
properName = sheet['Description']['properName']

# load a blend file
path = '//path/to/some.blend'
path = gry.expandPath(path)
gry.load[path] += 1

# unload it
path = '//path/to/some.blend'
path = gry.expandPath(path)
gry.load[path] = 0

# unload all of them

# load a level from a sheet defined in //stuff/levelNine.ini
uId_of_level = 'level9'
sheet = gry.sheets[uId_of_level]
path = sheet['Path']['path_of_blend']
path = gry.expandPath(path)
gry.load[path] += 1

# send arbitrary objects through the message sensor
gry.msgr.say('currentCharature', [self])

# print a setting defined in //system/settings.json

# check a keybind defined in //system/keybinds.ini
if gry.keys.someButton.activated:  doIt()

# roll a die
roll = gry.dice.d6
success, margin =, bonus, penitaly)

CC BY-SA 4.0
direct link
to read the files

1 Like

Hey, nice little thing!

What is the goal/scope of this project?

Are you releasing it because you feel like moving on? Or do you plan to keep developing it?

If you want to keep working on it, why not versionning it using Git and some hosting platform? (GitHub, GitLab, BitBucket, etc…)

If you want to try something else, did you see another framework that I am trying to develop for UPBGE?

Posting this link in case you were interested in collaborating on something, either GryLib or BGEz, maybe something else?

I always find interesting new tools that people make, it often stems from a will to fix some subtle issues.

what does it do different then configparser does?
i mean as i read this it does the same thing? writing or reading .ini files?

First of all, let me tell you this. I have only been coding for a few years and I am completely self taught. I have no experience coding as a group or in a formal setting. I tried using GitHub but I could never really figured it out. I switched to DropBox when GitHub started complaining about file sizes and quantity. I don’t really know what I’m doing in this regard.
The primary reason that I posted this particular iteration of my library right now, at this exact moment in time, is so that I can use it in the upcoming Bge competition. I absolutely refuse to code with out it. I cant imagine how ya’ll are making games the way that you are, but I would rather be disqualified then try to function with out some sort of tool set. That being said, it has always been my intention to release my work in some form. As far as I can tell, the Bge community consists of midgets standing on the shoulders of other midgets. I’m prepared to get shoed in the face so long as we get at the cookie jar eventually. Even if my game never makes it, I would like to help other people along the way. I thought, “Put it on the forums and maybe someone will get some use out of it.”
So I’v read some of your previous posts, as well as some of BgeZ. It appearers that we are looking at the same object, but from different perspectives. If we were able to triangulate our efforts, the results could potentially be quite strong. I know nothing about team development, tho.

The main benefit of the configparser that I’m providing, is that you retrieve the ini by the ini’s uId as defined in its text, rather then by the ini’s file path. This, in it self, would hardly be notable.
GryLib provides many small tools. Each tool is not very significant, but when used together, they allow you to code in a completely different way. Weather or not you would prefer to code the way I do is questionable. If your interested, then look at the provided blende file to compare any differences in structuring style.
Another important aspect of this is that the configparser could be considered to be intermediate Python. This allows you to use it with only basic Python knowledge. Truth be told tho, the configparser is probably not the most important part. The LibLoader is far more useful. Regardless, adding structure to you code is not necessarily a good thing. I present this library to you for your intelligent consideration. You may find the code to be intrinsically interesting, even if you do not find the library to be particularly useful.

Tooling is really important indeed, try making a house with only your bare hands, see how it goes.

That’s most software development really.

ok i did that now, and it’s looks like an other way of making a script with functions to use (like i do with my own things) it speeds up game scripting in my case.

Ok this is totally understandable and allowed.

I was just asking because of the sample you posted, and i thought hmm reading/writing to .ini’s can be handled with configparser…so why build something around it? But i see it’s more then that.

line 310+311 check for obj.getPhysicsId() before doing that else you get into trouble

line 310+311 check for obj.getPhysicsId() before doing that else you get into trouble

I probably wont fix it until theres a problem, so I can see whats happening. I added a note in the script for when it comes up. Thanks for the tip!