This is a template, includes a guide to code games in blender only with python. I hope this helps to achieve better quality games in the future.
template.zip (397 KB)
1 Like
Mostly agree with this. Am I allowed to nitpick?
-SCA is not allowed except for running the main loop.
I like keeping this open as a means for artists/designers to add simple effects. Like animating a windmill & testing in the engine. Not much reason to stick with BGE otherwise. If it sucks or does too much, I’ll delete the bricks and write some codes.
-An overlay scene for the GUI is mandatory.
I would say this is a game-specific problem, depending on what sort of GUI system you use. Maybe it shouldn’t be?
-All games contain 3 packed scripts, “main.py, constant.py and object.py”.
Any particular reason to pack them? A script in version control is a happy script.
-A model should come in a blend file with all resources packed
This one kinda depends. I prefer artists to pack before transport (they tend to have files scattered all over) but in development it’s easier to modify external textures.
There’s some conflict between what belongs in core vs what belongs in engine. Often we’ll write our own Python libs that don’t need BGE to run, it seems silly to hide them elsewhere. My opinion is that all non-default libraries should go to core, and anything that requires re-compiling blender should go to engine.
There’s a few grammatical errors but that’s not really important. English can be a jerk.
Lots of game-specific stuff under scripting practices. I guess that’s not the end of the world. Full examples would be better but who has the time?
EDIT - Didn’t realize you had included a sample. Gonna have a look…
Another edit
So here’s that template feedback. You probably know these things already, but it’s late and I don’t feel like being productive right now.
-interface.py line 8, list is a builtin used for constructing new lists
-Some style choices I don’t agree with. Looks more like C than Python. To each his own I suppose.
-The aud wrapper can only play one sound at a time.
-Renamed script to scripts because I like plurals
-Renamed sound to audio to reduce the S population (tab completion)
You don’t have to take any of this to heart. It’s just my observations based on personal preference. The naming convention stuff is especially silly.
I think that’s all for now. Overall - good initiative, obviously bound to get both positive and negative feedback here and there. I hope you continue working on this.
No SCA?
poll everything?
that is terrible design.
sensors are your handles to events.
stuff happened ----> do stuff.
Going back and forth between sensors and code is both tedious and un-trackable by version control. Classes can be designed with getters and setters, so there’s no need to poll everything.
Sadly the Python API doesn’t give us event-driven keyboard input, so you’d still have to poll for that. At least there’s keyboard.active_events so you don’t have to do expensive lookups on the larger keyboard.events.
just have 3 controllers
Joystick
Keyboard
Xbox
or something,
have them serialize there output, and send it to a object running your code?
The whole idea is to avoid logic bricks as much as possible. While you could hack together a solution with bricks, it makes far more sense to update the Python API - as was done with collision callbacks.
Imagine something like this:
keyboard.onPress('w', player.forward)
But I’ve gone too far off-topic.
This is a possible design, things could be done differently but I’m purposing this for various reasons. The no SCA is because while it may be useful to artists it is a headache for coders, this design is obviously not for artists. It’s true that, with the current API, events are a lot more difficult to implement in python. The ideal thing would be to do that from inside blender source. However that’s a lot of work, so a clean alternative is to implement that system in the core package with python and the current API.
The absolutely no SCA is also for another reason. If SCA is allowed you could put logic bricks in a object that almost nobody would think it does anything. That part of the logic of the game will be “hided”, really hard to find. Only selecting all objects on of the game you will find it, but if you do that with multiple objects a spider web appears.
An overlay scene for the GUI is mandatory.
You can also read this as: “If there is any kind of GUI, which if your game is decent should be, put that GUI on a separate scene.” It’s only a matter of organization. You can use more than one scene, but at least one.
-All games contain 3 packed scripts, “main.py, constant.py and object.py”.
Any particular reason to pack them? A script in version control is a happy script.
Those are files that, with this design, should always exist in any game. You could make a game all in the main (bad idea), but you can’t do it without the main. To ensure that they’re always there they are packed. You also don’t need to have them in a version control, they look almost always the same. The other reason is because I don’t want to fill the data folder with python scripts, there should only be subfolders and the main game file.
-A model should come in a blend file with all resources packed
This one kinda depends. I prefer artists to pack before transport (they tend to have files scattered all over) but in development it’s easier to modify external textures.
Once the model is done, both of us agree that resources should be packed. While working on the model there is no need for that, but you should work outside the game folder to maintain clarity. I’ll add this to the guide in the future.
There’s some conflict between what belongs in core vs what belongs in engine. Often we’ll write our own Python libs that don’t need BGE to run, it seems silly to hide them elsewhere. My opinion is that all non-default libraries should go to core, and anything that requires re-compiling blender should go to engine.
Well basically a Python lib that doesn’t require BGE and that’s not related to BGE or games in any way (somthing like numpy or twisted) should go to engine, a library that is related to the BGE like BGUI, should go to core.
-interface.py line 8, list is a builtin used for constructing new lists.I didn’t realized I was hiding the name, well I always use x = , people using this design will also have to.
And, by the way, it says list but it’s actually a dictionary. I know…
Actually all the interface.py should be a package, it stills needs a lot of work.
-Some style choices I don’t agree with. Looks more like C than Python. To each his own I suppose.I’m on the few that likes C++, I know its contras but I still like it. Same with BGE I guess.
-The aud wrapper can only play one sound at a time.I know, it’s WIP, like all in the template.
-Renamed script to scripts because I like plurals.Hahahaha. That choice was to avoid confusions, but it’s fine.
The absolutely no SCA is also for another reason. If SCA is allowed you could put logic bricks in a object that almost nobody would think it does anything. That part of the logic of the game will be “hided”, really hard to find. Only selecting all objects on of the game you will find it, but if you do that with multiple objects a spider web appears.
That’s a really good point. I encountered this exact problem when looking over someone’s file earlier today. Literally had to go to the outliner and click through every object, despite knowing the exact string I was looking for.
You can also read this as: “If there is any kind of GUI, which if your game is decent should be, put that GUI on a separate scene.” It’s only a matter of organization. You can use more than one scene, but at least one.
I’d argue against that when using bgui/etc because there are no ties to the scene other than calling the update function. Seems like more overhead than it’s worth imo.
Those are files that, with this design, should always exist in any game. You could make a game all in the main (bad idea), but you can’t do it without the main. To ensure that they’re always there they are packed. You also don’t need to have them in a version control, they look almost always the same. The other reason is because I don’t want to fill the data folder with python scripts, there should only be subfolders and the main game file.
I’m not quite sure about this. Specifically object.py, correct me if I’m wrong, appears to contain game-specific definitions that will undoubtedly change as the game is developed. I wouldn’t want to constantly flip to the gimped internal editor just for that file. If the files aren’t present, the game won’t work at all. That should be enough to ensure they’re not forgotten. Python modules can also be placed in subdirectories so pollution shouldn’t be an issue.
Once the model is done, both of us agree that resources should be packed. While working on the model there is no need for that, but you should work outside the game folder to maintain clarity. I’ll add this to the guide in the future.
I still prefer external textures within the game dir to avoid hidden duplicates, as is often the case with “generic_sheet_metal.png” etc. This typically means re-unpacking the file, but it’s only a few extra clicks. In a perfect world everyone would use relative paths so you’d never have to pack, not to mention lose the timestamps. Maybe with enough training…
Well basically a Python lib that doesn’t require BGE and that’s not related to BGE or games in any way (somthing like numpy or twisted) should go to engine, a library that is related to the BGE like BGUI, should go to core.
I can sort of understand that, but it’s still a fuzzy line. Maybe the real answer for engine is “anything you install with setuptools”.
Anyway. That took 15 days for me to reply back. Hopefully the context is still fresh.
idea, text editor displays list of all objects using a python script, even if they are not ever ran.
with this you could tag all objects you want to keep track of in a document?
so
A. Debug is easy
B. you can add a python controller, and not link it to anything
and link to a textfile, like engines, or swords, or ninjas
for organization almost using hyperlinks from the text file?
Ok, yes with bgui/kxgui it’s not nescesary. The only reson it is not nescesary is becouse they don’t use game objcts to work. The interface.py file however, does. So in case you are using a GUI library that works with game obejcts then you need at least one GUI scene.
I’m not quite sure about this. Specifically object.py, correct me if I’m wrong, appears to contain game-specific definitions that will undoubtedly change as the game is developed. I wouldn’t want to constantly flip to the gimped internal editor just for that file. If the files aren’t present, the game won’t work at all. That should be enough to ensure they’re not forgotten. Python modules can also be placed in subdirectories so pollution shouldn’t be an issue.
If you add/modify/delete a game object, you will do that with blender open. Since it is already open I think is faster to move to the text editor than changing to the python ide/extranl editor. This doens’t happen with the main.py nor the constant.py but then the argument is like before: You’ll hardly modify them and you’ll have them a little hided when distributing the game.
I still prefer external textures within the game dir to avoid hidden duplicates, as is often the case with “generic_sheet_metal.png” etc. This typically means re-unpacking the file, but it’s only a few extra clicks. In a perfect world everyone would use relative paths so you’d never have to pack, not to mention lose the timestamps. Maybe with enough training…
Well I’m changing a little the standard, probably there will be a GUI folder inside “data/”. The gui contains fonts and the textures for GUI elements. It’s useful to have them outside so you can modify them without opening blender. However for wierder textures like normal maps or anything that uses UVwrap I would pack them. I usually use another folder outside the game folder and there I store the gimp files and other resources that won’t be sitributed with the game. You can put there blend files without the textures packed and when the model is ready pack it all and move it to the game folder.
I can sort of understand that, but it’s still a fuzzy line. Maybe the real answer for engine is “anything you install with setuptools”.
Yes, something like: {“setuptools”: "engine/2.75/python/lib/, “downloaded from blenderartists”: “data/core/”}
With this template there is 1 and only 1 object using a python script, no matter how big your game is.
Ok so real world problem: Games often have multiple levels in separate blends. Devs would have to open a separate instance of Blender just for using the internal text editor. Also I’m typically using that screen space for UV editing / whatever. It’s kind of a pain to switch when I could already have a text editor open on another monitor.
With this template there is 1 and only 1 object using a python script, no matter how big your game is.
The whole premise breaks the idea of using group instances for prefabs. But I guess not many people use them anyway. Funny because a lot of people complain about the BGE not having prefabs.
My opinion Get rid of object.py Add something to __init__ that scans all objects for behavior properties Emphasize the use of group instances <insert clever idea for handling prefabs>Good point. Ok, you got me there. New it seems more evil to have those scripts paked. But you know, the whole purpose of this template is to have one, and only one, way to do thigs. So, no packed python scripts anymore, from now on all external. Those 3 files should go inside the script subfolder. The main loop goes in the init.py so you wouldn’t need the main.py file, you can however, have something like “def loop(): script.main.loop()”. Therefore the python controller sould be “script.loop()”
The whole premise breaks the idea of using group instances for prefabs. But I guess not many people use them anyway. Funny because a lot of people complain about the BGE not having prefabs.
My opinion
Get rid of object.py
Add something to init that scans all objects for behavior properties
Emphasize the use of group instances
<insert clever idea for handling prefabs>
From the guide: “The behavior/others instances can be done in 3 ways. In the child class file, In a specific file, With game properties.”
Here you are suggesting the third. It says not recomended becouse:
- You need blender open to enable/dishable a behavor in an object.
- It creates lag at startup.
- If you ever change the behavor name you’ll need to update all game properties that use it in the game. If you declare the instances in files you can do a replace all in files and problem fixed.
So, basically if the object is not created at runtime you can just specify its behavor in a decl.py file or in the child class file. If it is created at runtime you’ll have to specify its behavior when loading it. E.j.
object.car = scene.addObject(“car”, object.reference)
script.behavior.Car(object.car)
All of this needs more thinking tought.
From the guide: “The behavior/others instances can be done in 3 ways. In the child class file, In a specific file, With game properties.”
Must have glazed over that
It’s the problem of the day with Blender, figuring out a standard workflow for level designers. For a procedural game this works great. Also fine if you’re working with a custom in-game editor, but that sort of breaks the whole reason for using this engine.
Definitely something to think about. It’s a problem I’ve been struggling with for years.
I’m releasing a new version. The guide is not update tought. In this version I’ve changed some important stuff:
- One and only one GUI scene is mandatory. If you use BGECore you must use it’s interface. You can however use other interface libraries on top of that.
- There is only a main.py file paked inside the main blend. It’s part of BGECore and it will never need to be modified. All other game scripts are external.
- Added a gui folder, it contains textures and fonts for various GUI elements.
- Added Menus and TextButtons to the GUI.
- Added some useful tools external to the game. For now ResourceHacker and JBFT.
- Added the behavior system. Two kinds of behivors, scene behivors and object behivors. There is only one scene behivor for scene and only one scene (beside the GUI) running at the same time. Scene behivors contain object references (no more objects.py) and object behivors.
- Thought you could build all your game in the update method of a scene behaivor, object behivors will help you organize you code better.
- Sine there is only one scene running at the same time the logic.addScene(), scene.remove() and scene.replace() are forbidden to use. Those functions breack the automatic scene managment and behavior system. Instead use the function utils.setScene().
- The GUI scene contains the python controller that calls the main loop. Any other scene can optionaly have another python controller that calls the function autoStart(), this functions restarts the game from the GUI scene to guarantee that the GUI scene is always present. Any other logic brick is forbidden. (GLSL shaders may be a exception, I still have to check it).
- Besides the update() and init() methods of each scene you can also use the init() and loop() functionts of the control.py file, those are independent of the scene. The init is called at the start of the game and never again (unless you want to restart) and the loop() is called at every frame no matter in wich scene you are. It is probably useless but who knows.
Here the file, I will update the first post when the guide is ready:
BGECore.zip (3.4 MB)
Does this improve the framerate for openworlds videogames?I would like an example if it does.
No it doesnt but yes you can create huge open worlds with this system just as you create with any system speed will depend on implementation because this is only a template for creating blender games with python you can still use any system and it wont matter for performance or sliders on computers running the blender game engine sorry for the bad formatting I typed this with my face
The problem with open worlds in blender is not the framerate, you already have LOD for that, it’s the lack of a terrain editor in Blender that supports LOD terrains. Without it all the terrains of your open world game will have to be planes. Therefore the only open world that could be done in BGE are in water (all the world is water) in space (all the world is nothing) or in sky (all the world is air, then there are little floating islands).
What?
I have several questions