Upbge: Run `blenderplayer` in headless mode

Created on 3 Oct 2018  路  11Comments  路  Source: UPBGE/upbge

It comes use cases where it would be nice to run a blender game without any window, maybe just a console at most.

This would allow the creation of proper game servers, where the simulation would be using the same environment as client blender games.

design feature request

Most helpful comment

For me the second version (upbgeplayerw) would be the most aceptable due to its compatibility

All 11 comments

Do you mean without window or without drawing context ? Hidden or disabling drawing ?

The easiest way to have a build running without drawing context is to build a new version with a option macro disabling any part using OpenGL.

it's the same and most probably simpler if you program a little python executable as your server, if this is the scope. the server listner open the connection and receive and send information in a json format. without touch blenderplayer.exe maybe we can create an upBgeServerPlayer.exe with a simple console and settings ready to process and distribute informations from clients and include the exe in the distributable release

@RomStef but this way you lost the capacity to run the physics simulation (and others things) in a server without graphycs capabilities

Do you mean without window or without drawing context ? Hidden or disabling drawing ?

The best would be to disable drawing altogether, and only keep logic/physics/animation tics.

The easiest way to have a build running without drawing context is to build a new version with a option macro disabling any part using OpenGL.

Yes, but it would really be better to pass a flag when we start blenderplayer, like blenderplayer --headless. Something similar to Chrome.

But I guess it wouldn't be too bad to do like Python does on windows, with 2 executables: python.exe and pythonw.exe, where the w version is the windowless version. Maybe it would also allow to have an executable that is built to not depend on any drawing library, would that improve compatibility for some devices?

For me the second version (upbgeplayerw) would be the most aceptable due to its compatibility

The best would be to disable drawing altogether, and only keep logic/physics/animation tics.

How would behave on bgl calls or shader compilation ?
I can ask plenty of questions like them, but they all target one common question:
If the goal is to have clients and a server simulating a part of the client, would you run a very specific file for the server which is not the same than the clients ?
By not the same, I mean not adding script, but removing AND adding.

If yes, then we can provide a upbgeplayerw without all options targeting rendering (bge.render, bgl, shaders, filters)

If no, it will be very dangerous to define fallback behaviour.

If no, it will be very dangerous to define fallback behaviour.

Agreed.

If the goal is to have clients and a server simulating a part of the client, would you run a very specific file for the server which is not the same than the clients ?

Conceptually yes, in my case I run the same blend file that serves as an entry point, but the scripts are triggered differently and it libloads what is needed in the new context. So it amounts to what you call removing and adding (=replacing) a script :)

For sure blend files being run in headless mode will certainly need to be conceived for this purpose. But it would be nice to be able to run them with the non-headless version (with rendering) in order to troubleshoot issues, if any. But any rendering-specific code will fail once run inside the window-less blenderplayer (bgl, shader modifications, ...), this is to be expected in the same way that the bpy API causes trouble in standalone too.

If yes, then we can provide a upbgeplayerw without all options targeting rendering (bge.render, bgl, shaders, filters)

+1

But would it be a good idea to add to bge.app a boolean like headless to detect at runtime if needed?

For some reason I thought this already existed. But +1. Will definitely be necessary when/if I get to multiplayer.

It is also useful if we try to make integration tests, unlike unittests that cannot work if you import anything from UPBGE in your scripts. Wouldn't be simple to make a small test framework for it, it should also work in normal mode before, but once the headless mode is in one could setup pipelines on their server to test whatever is made.

This to show that it isn't only good for multiplayer, but for testing too. Although it would be really useful for multiplayer.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

NatGazer picture NatGazer  路  7Comments

vlad0337187 picture vlad0337187  路  7Comments

RomStef picture RomStef  路  4Comments

EndSSgamesStudio picture EndSSgamesStudio  路  4Comments

cederom picture cederom  路  7Comments