BGEz - Full Python game projects

[elmeunick9]

My point was that in "def update(self):" you're in complete control of all state of the program (if not using threads). X may be modified before or after the execution of your function but only you can modify it inside it.

But yeah, I don't like generators neither.

[WKnight02]

My point was that in "def update(self):" you're in complete control of all state of the program (if not using threads). X may be modified before or after the execution of your function but only you can modify it inside it.

In a nutshell, you could write a shitty coroutine/generator allowing outside variable modification, when any object's member can also be accessed from outside and would put your "controlled state" out of order

[elmeunick9]

In a nutshell, you could write a shitty coroutine/generator allowing outside variable modification, when any object's member can also be accessed from outside and would put your "controlled state" out of order

And that's exactly why I don't like them. If you don't ever use them in your project, then you can garatee this controlled state. But, well, after all I supose it's just a matter of preferences.

[WKnight02]

And that's exactly why I don't like them. If you don't ever use them in your project, then you can garatee this controlled state. But, well, after all I supose it's just a matter of preferences.

But what I meant is that even with an object oriented state controller you can access its inner variables from outside (Python's lack of private/protected/public). Not that its bad, but the problem is exactly the same, and the fix relies on your ability to write code that makes sense.

Indeed it seems like a matter of preferences. So I implemented something people could prefer in place of an other system, I think it will be a good point in the long run.

Also, the system is currently hybrid: you can work full callback, and/or use coroutines. Pick what you prefer

[Benny_Flex]

@WKnight02 Thank you for sharing the .blend. If I understand well you link a python script to an alway brick instead of using the logic bricks?

I am eager to see more.

[WKnight02]

@WKnight02 Thank you for sharing the .blend. If I understand well you link a python script to an alway brick instead of using the logic bricks?

I am eager to see more.

I'm happy to see you interested !

Basically, the thing is that I am trying to propose a way to make your game using Python only, using a higher level API than what is currently available. But as of now, the BGE needs at least an always brick and a Python controller to trigger any script. But once the framework entry point is executed, everything can flow in Python.

I'm currently trying to make a demo for the BGMC, but I hate doing game assets lol. So I don't know if I'll come up on time, but I will certainly have something to show !

[BluePrintRandom]

go with sintel assets WKinght
also Jonny Blacks dead project assets -

1 original - https://blenderartists.org/forum/sho...etc&highlight=

Current / https://opengameart.org/content/3rd-...er-sci-fi-pack

[WKnight02]

go with sintel assets WKinght
also Jonny Blacks dead project assets -

1 original - https://blenderartists.org/forum/sho...etc&highlight=

Current / https://opengameart.org/content/3rd-...er-sci-fi-pack

Thanks for the resources ! Although I was more looking for a Tron ambiance

-----------------------------------
UPDATE NOTES

Ok, so trying to keep the weekly devlog, this week was mostly about house cleaning of the code. I also tried to make something for BGMC 26, and it made me learn some few things about bgez:

1. Despite having thought about stages and logic execution that would be scene-specific, some transition behaviour were undefined: stage transition for example is not quite possible as things are right now. The question is how we should see a stage, should I allow multiple stages objects to be running at once, or making it so there is only one stage at any time. Also I need to manage the libloading/libfree between the stages, I just didn't implement it before hand. Time to do it this week !

2. The event system is not so bad, but it's really feeling like JS when using it, which in my opinion is not a really a good point. I need to iron it out a bit to understand how to properly use it. Right now it gets things done, its really useful, but I've been using it a bit in a silly way, so the blame is on me as a user.

3. The framework allowed me to think about how the game should play, and not really how to implement it, so that's exactly what I was aiming for ! Success there.

With this in mind, I think I know where to work from now on:

- Continue for a bit my BGMC game in order to get to the point where I need stage loading, so that I can encounter the "right problems" in order to implement a good way of managing libloaded resources.

- Keep thinking about the pattern I'm using where each manager functions are triggered once per scene, from the same object. This is a good idea in the way that it allows to have access to the context of each scene, but the filtering is a bit weird to do. From entities its as easy as:

def post_draw(self, scene):
    if scene is self.scene:
         print("myScene!")

But in other cases its not really clear for me how to correctly use it, its definetly usable, but it feels a bit weird. I think its just a matter of finding the right way to think about it.

- The past points are the rather boring stuff. In order to have a bit of fun, I'm also thinking about gameobject serialization. The idea is that we can't really store gameobjects, although we can store some defining properties, like position, scale, speed, gameprops, and maybe other user values. I'm looking at it.

- Also, networking. Thanks to the event system I implemented last week or so, and some Python builtins modules such as "selectors" and "struct", I really feel like it is at hand's reach ! Although I still prefer to really smooth out the things that would need it before working on networking, being as close as bgez is now is really tempting me to think about it. I would expect some first iteration during the next month.

-----------------------------------
BGMC 26 - Prototype:

Thread: https://blenderartists.org/forum/sho...C-26-Prototype

[WKnight02]

Hey again !

So, the past 10 days I've been experimenting with quite some things, and here is the progress:

- Blend file loading / freeing: Implemented a way to load and unload levels dynamically. Also ironed out some functions to delete objects in the scene before loading a new one. The framework will load the relevant .blend via LibLoad, and free the files which are no longer required with LibFree. All you have to do is to specify what you need, the management is automatic.

- Improved event handling: I added the possibility to add sub event handlers, because in order to trigger events on each tick, what I was doing was this:

class EventManager(Manager):
    ...

    def post_draw(self, scene):
        events.trigger("post_draw%d" % utils.getTick())

And I had to register my events like events.registerCallback(callback, "post_draw%d" % desiredTickNumber)... which was a bit silly.
I mean, it got the job done, and I could make so the callback could be triggered on the next frame by doing desiredTickNumber = utils.getTick() + framesToSkip.

But instead, I made so that you could add sub event handler, on specific events, and make them dispatch calls from the paremeters of the parent ones. Its not clear, I get it. Here is an example:

# Getting the "main" EventHandler
events = Service.GlobalEvents

# Create a sub event handler on the "post_draw" event.
# You can still register callbacks
events.addHandler("post_draw")

def testA(*args):
    print("A:", args)

def testB(*args):
    print("B:", args)

# Registering the callback on an event
events.registerCallback(testA, "post_draw")

# Registering the callback on a sub event event
# (test is binded to the "more" event of the "post_draw" sub event handler)
events.registerCallback(testB, "post_draw", "more")

events.trigger("post_draw")
# prints:
# A: ()

events.trigger("post_draw", "more")
# prints:
# A: ("more")
# B: ()

events.trigger("post_draw", "more", "extra")
# prints:
# A: ("more", "extra")
# B: ("extra")

This allow you to bind certain callbacks on "general" events, still allowing you to get the full event argument list, or binding on more specific sub events !

- More documentation: I wrote a bit of document, its far from perfect, but again I would love feedback.
https://gitlab.com/bgez/bgez#bgez-blender-game-ez

Also I uploaded my BGMC game and the improvements I made on GitLab too:
https://gitlab.com/bgez/demos/BGMC26...mc26-prototype

--------------------------------------------

I think the thing that took me the longest was the libload / libfree stuff. I got Blender to crash, with absolutly no error. Like, nothing was written to stdout / stderr. Just a plain crash. This made the debugging extra boring, but I finally got through it. I think I took 3 or 4 days before I got Blender not crashing, trying every line permutation possible, using "prints" everywhere.

At the end of the day, one of the things that was crashing Blender was to end the active camera. As in: "scene.active_camera.endObject()". This just makes the BGE stop. Not even crash. Stop. Nothing happens past this.

You may ask why I was ending the active camera, well... I was just trying to clean the scene, removing every object blindly.
Turns out you should test if you are not about to remove the current cam. Now I know.

--------------------------------------------
What comes next ?

So far I don't really know. I want to use the framework for a bit on the BGMC game I made, keeping using it and pushing it as far as I can until I get something to break in some way, this should allow me to strengthen what's already there, and maybe show me what to add next.

I would really like to think about the way to get networking going. I have a pretty solid foundation as far as I know, with automatic links between Python classes and actual GameObjects in game. I think a system allowing to serialize a particular live object and send it to a server, just to pass it down to another instance of the BGE and trying to synchronize the two could be cool.

I mean, the base seems ready to implement such an abstraction layer around networked ingame assets.

But I'm thinking about the role that the event system will play in all of this. Should I go full callbacks ? I wonder a bit, because sure, supporting entity synchronization is cool, but what if people have other stuff, more general networking messages to send ? The implementation should permit to setup a legitimate server in the BGE, and then on top of this I should build the entity synchronization.

A bit of work here.

I might just chill and try to make levels for the BGMC game, this would free me a bit from this Python frenzy lol.

[Dr. Binary]

I think you're on the right track with encoding vital data into a serialization, then sending it across the network. The little research I've done into most networked games work that way, the other players and their objects are actually representations of their literal objects, rather than porting the actual object to every rendered instance connected by the server. It's kind of like a crazy detailed mini-map. So if you take that data and encode it in a fast to transfer method, you can immitate any condition the object may be in.

Anyway, super cool stuff! I'm probadly going to port my current project to this once it gets better footing underneath it.

[WKnight02]

I think you're on the right track with encoding vital data into a serialization, then sending it across the network. The little research I've done into most networked games work that way, the other players and their objects are actually representations of their literal objects, rather than porting the actual object to every rendered instance connected by the server. It's kind of like a crazy detailed mini-map. So if you take that data and encode it in a fast to transfer method, you can immitate any condition the object may be in.

That's the idea: only transfer what is relevant !

Anyway, super cool stuff! I'm probadly going to port my current project to this once it gets better footing underneath it.

Glad to see you interested !

Although what do you mean by "once it gets better footing underneath" ? Just so that I know what you are waiting for precisely

[Dr. Binary]

Although what do you mean by "once it gets better footing underneath" ? Just so that I know what you are waiting for precisely

To be 100% honest? Hearing you mention that certain parts feel like JS spooked me out. Hahaha, I loath JavaScript, almost as much as I hate HTML altogether. So, the farther we can get from that the better.

At this time, porting the game over would grant me some benefit, since I've gotten used to writing my own engines in python for my projects, so working in BGeZ seems to be more similar to how I used to do things. If you do get networking up and running though, that would probably cinch the deal, I've got a multiplayer mode planned that would greatly benefit (obviously).

[WKnight02]

@Dr.Binary: Ahah, well, it does not look a 100% like JS, but it was about the way I implemented the event system using callbacks that made me think about it

-----------------------------------
Update:

I mostly worked on side projects rather than directly on bgez this time.

Also a friend of mine was interested about trying to make something using Blender and bgez, so we worked for less than a week now, and we are already seeing results !

We got a first person view character, some map made out of blocks: road, grass and building, and some enemies following the roads to a target to defend.

blender_2017-12-11_00-19-06.png

I'm really happy at how we could split the work together thanks to bgez, because .blend files mostly are for assets only, and then every single game logic is put outside of the .blend, we can version the code and not have a single problem when merging or anything.

Super happy with that

-----------------------------------
Now what does this mean for bgez ?

It means that by trying to use the framework, we are able to see flaws with the way things are.

So far, here is what I was considering:

- Manage sub-dependencies: so far, you can write in a stage what files you are gonna need, based on the classes you wrote, like "Player that refers to <player.blend>". But what if the player depends on a weapon for instance ?

- Better inputs: As I'm trying to avoid bricks, I end up running lot of processing in the pre_draw/post_draw events, but you lose the ability to check for events such as JUST_ACTIVATED or JUST_RELEASED because the logic frame finished a bit before. I'm considering having to manage this, which will come at some little cost, but it will be constant and not depend on your project (in terms of processing cost), so its cool.

- Logic definition: Right now, when you write classes defining an object behaviour, you are describing actual GameObjects. This means that your player's logic lives as long as the gameobject lives, but the logic would die with the object if you happen to end it, for instance. The concern I'm having is about switching this concept to a different one, where your "work classes" defining your entities would be actual Python objects, and Blender's GameObject would be a property like "instance.view", acting like a a pure display, mostly. My problem is that I don't see the actual pros/cons compared to what I'm doing now, as anything done with the current concept did not bring more troubles, at least not right now... I would also need to change a lot of the inner workings of the framework, hence my will to ensure for the move to be really beneficial for the future.

- Events also are not quite where I would want them to be, but its coming to a very efficient form, still a little bit of work to do there

- Networking is paused while the bigger concerns are addressed, though from the few tests I ran everything is ready and works fine, all it would need is some solid abstraction layer. Thinking about using asyncio transport/protocols concepts, but as I said this part is paused until the ground work is done.

If people want to test things using the framework, you can inspire yourself from the different little projects online on the GitLab, just make sure that you have every file from the project and the submodules when you download it (downloading a git repo as a zip file will not pack the submodule content AFAIK).

Here is the game prototype repo, its rough but its a prototype. It is meant for us to learn from experience
https://gitlab.com/bgez/games/TowerShooter

[WKnight02]

Plop.

I won't have as much time as before to work on this little project, but basically I was just restarting in order to fix most of the things that felt like duct-tape.

The part that took the most time was the whole "trial and error" in order to get things to work. But now that I have some more experience with this, it should turn out better.

Goals of the reboot:

1) Simplify the modules / classes / imports.
Before, when you were importing `bgez`, there was some kind of waterfall importation cascade with side effects that took place. It worked, but really you don't want that. I don't want that. Also I think I can simplify most of the API.

2) Add some more sugar
Was playing around with ways to make the code editing funnier, so I made a little prototype that allows to edit the sources and see the changes live, while the game is running. It's not a recommended pratice, but it's really cool if you do small sessions of live coding to tweak things here and there !

3) Provide some project management capabilities:
The idea would be to have a little CLI interface to manage the project a bit. Think `npm` for node kinda. I don't think I will come close, but I want to see if it would help.

4) I know the BGE is on the deathtrack, but its a good little environment to perform such experiments, and so far I'm having fun, so lets keep rolling !

If people have any technical insight on anything, feel free to share !

The project is hosted at the same place as before, although right now it is no longer usable while I keep working on the core.
https://gitlab.com/bgez/bgez

Next commit should clean the `loader` module, and revamp the live coding system, so that its less about metaclass and more about wrapping and decorators: so more versatile ! We'll see.