Your "Pros & Cons" about the BGE

Hi,

I’ve been blending since before highschool (2.49b R.I.P.), and tried numerous times to make a game using the BGE. At first I thought it was simply a daunting task. Always hacking there and there to achieve whatever goal I had in mind. At first I even tried to make a mouselook-system with Logic Bricks only (speak about whacky…).

But with time and more and more studies in Computer Science and getting more and more into more general software development, I came to realize what might be wrong with the BGE as of now… Take this with a pinch, because I’m opening this thread to also get your feeling on this tool that is the BGE.

The idea is to expose as much “problems” that might stick to the BGE despite the decade of service, but also to get the current “good points” that would make it competitive compared to other Game Engines.

This is my point of view:

Pros:

  • Blender builtin: Your modeling app is your game-making environnement. Profit from the power of Blender as a 3D tool and run the game right in there. You can even use the animations that you made with Blender itself, almost everything you model/configure within Blender run in the BGE !
  • Free: No financial requirement, just download the software and start working.
  • OpenSource: People can work together to make it greater every commit ! Although it seems to me that the 3D editing part profits way more of the collaborative work, amazing projects are still done on the BGE (UPBGE).
  • Logic Bricks: Even if I’m not fond of it anymore, its something very appealing for beginnners ! Give a free and powerful software to noobs, let them make silly objects, give it physics and run the thing with “P”, and now let them add basic logic. It feels awesome, with self-descriptive bricks, you can make things move like in games ! I started this way too :slight_smile:
  • Python ready: When you need to do more edgy things with the LB, what about programming your own logic ? Python is the perfect language for beginners again, there is little overhead when writing Python scripts, the general syntax is really simple, and provides really complex mechanisms when you get to know more about it. Its truly a good language for logic control.

Cons:

  • Logic Bricks: Sure, everyone starts with this, and even Python lovers MUST use at least a few bricks to get their scripts running (not with UPBGE components tho). But these bricks are just… Too limited. I’m not saying we should get rid of it, but development towards this brick pattern is not gonna make it for more serious future uses… Its a pattern that was thought of 10 years ago, before Visual Programming really took off (UE4 nodes or whatever), and it sure contributed to the appeal beginners had for the BGE, but come on… There is a node editor that was developed and used for materials, but the logic never grew there. You might ask why I think the current bricks system is bad today tho… Well, when you make programs, are say you want to design some general logic, you must control some kind of flow that the system will go through.
    Logic Bricks despite the good idea of “events(sensors) to be processed(controllers) and produce actions(actuator)” lack of a more general awareness, which can be granted using Python scripts in the controllers, but in practice it feels whacky as hell, and you might have a little bit too much scripts left and right at the end of the day. LB sucks, but they’re cool, so its fine. We should move on from LB to something better.
  • Workflow problems: This is a consequence of the LB problem IMO: because they are so whacky to use, the few pattern really efficient using the LB are just exhausting and completely off of the way we would naturally do things (even when Python is allowed, it has to be executed with the bricks design in mind, its hardcore). Making a game is hard, you could make one from scratch if you want, don’t mean its a good idea. You could use Blender/BGE even if the workflow is hard to handle, don’t mean its a good idea. I think it got to the point where it also explains why the BGE is threaten to disappear from Blender, because the BF just don’t GAF about this decade tech that is so difficult to get working well that they don’t want to bother anymore. They are right to give up, because if no BF dev is willing to fix things, why would they bother ? Blender/BGE is a collaborative project: no one wants to work on something and people can’t use it properly anyway ? Drop it. It makes total sense.
  • Generally passive community: The thing is, all the “pros” appealing beginners is a double edged sword, because now the core of the community is people looking to use the BGE and make a game, thinking that the devs are mighty programming-gods and could do anything to improve the BGE, so just relax and ask for cool features. But the amount of people actually contributing to the BGE is almost fearsome because of how few they are. Because of their inexperience maybe, the BGE users tend to not see how incomplete the BGE is, and try to use it in a state where a lot of work has to be made to finally “fix” the engine, rather than actively using it. Don’t get me wrong, people should use the BGE in its actual state, but they should also realize that a lot is missing (not just render-wise), and should take action to improve the tool if they want to get serious (instead, people usualy go to other engines because they are more game-making-ready).

To conclude my observations, I will say that I whine a lot. Be it because I’m French or because I’m lazy and want free shit despite not being worth it. But I’ve acknowledged this. So this are some of the improvements I think could get rid of some water leaking in the hull of the BGE, and some of my involvement:

  • Better workflow: IMO Logic Bricks sucks. But what to use instead ? This is experimental still, but I’m tinkering with making a Logic Node addon, a bit similar to the former Netlogic addon, but more maintenable. I hope. lol. I also want to try to lay solid foundations so that it could be continued if I want to move to something else after, because I still think that nodes should replace bricks. 10,000 times over.
  • Real framework: Logic Bricks even with scripts are hard to maintain. The API allow you to almost do anything you would want, but it lacks of a good groundwork to standardize the design of logic. What I mean is that the API is pretty low-level when it comes to game logic, sure you can control your 3D world, but in order to actually create a flow and manage events within the game (not just a simulation), it really lacks. People will find their own way to arrange things, but hell do two people don’t think the same way. The BGE should profit from the same enthousiasm the web had: frameworks. The basic idea is that in the case of web applications (website, webapp, webAPIs, etc…), you could make something out of Apache and PHP, use the API provided to make a server or a client, but you would need to reinvent the wheel everytime… “Here goes the auth system, now the content management system, now the persistence system, now this, now that…”. People worked around and became WAY more productive using the same basic technologies, by designing frameworks. Now your task within the framework is to develop the actual logic, not the system running your logic. You could think that Blender is already a framework, but IMHO its a rather crappy one right now. Its more in a state of Apache/PHP/MySQL and not much more. My contribution on this problem is that I’m tinkering with a framework of my own (named “bgez”) that would allow gamedevs to have a full-Python project right next to their main .blend where they would organize as they wish the logic, providing a vast array of managers so that you would describe your logic, rather than trying to make something from the ground up. I will publish on the forums something once I will have some demos to better illustrate the gain bought by using it.

Sorry for the lot of text, but its something rather important do discuss about as the BGE is meant to die soon if it continues to be unproductive. If something is so good nobody has to use something else, then why wouldn’t they use it ? I think the BGE dying is because it is not so efficient and thus is meant to die if it stays as is. A better renderer is really good. But until the “guts” are fixed, I think fixing the appearence won’t be effective enough to keep it alive (although its a really awesome project).

Thank you for any of your inputs too ! :smiley:
Be sure to be accurate about your point of view, so that we can discuss and work from it !

So I use BGE both as a hobby (for many years), and for my full-time job. As part of that, I discovered that a to-be-released, very-cutting-edge-high-tech-robotic-system is using BGE for it’s primary visual interface. They also use BGE for several of their in-house testing tools for their robot.
So as I work around 40 hours a week with the BGE, and many of the systems I work with exceed 4kloc (python), and some have over 100mb of models, I feel I can give a reasonably in-depth response.

Model Pipeline
Zero pipeline from models to in-game. This is actually a mixed blessing. It makes it very easy to go from nothing to something. It means that you can bootstrap a game incredibly fast. However, it also leads to the illusion that managing the assets for a big project are easy. Heck, even for a small one, managing the assets is a big of a challenge. Particularly when you have multiple people working in a team, you can’t have everything rolled into the same blend-file.
Fortunately you can use blender’s linking tools (easy) or libload (harder). This allows multiple people to work on the same project but for some reason I’ve never seen many BGE projects on these forums use either of these! Couple this with the ability to pack textures, sounds and, well, everything into the same blend file and you’ll see that most BGE projects are limited in scope because:

  • Multiple people can’t work together
  • Hard to version control
    As I mentioned, these are easily rectified by simply using blender’s linking system - but for some reason no-one seems to!

    The ease of inserting logic/scripts

    The “I’ll just throw a script here” or “if I just use three logic bricks here” really throws a damper on any planned system architecture - particularly in teams where someone can do something without telling you. Logic bricks are impossible to search, cannot be version controlled meaningfully, and as such are a pain to work with on any more than an individual project. In a current project at work, 99% of the code is handled fine, but the 1% of logic bricks has been a big nuisance recently - it evades profiling etc. No visual logic programming system is exempt from this as far as I know.

    Hard to test code:

    This is one of my current areas of investigation, and I think it is a universal issue across game engines. However, this is more an architecture issue than anything else. With a good system architecture this can be worked around. But none-the-less, testing code written for the BGE is a royal pain. In the robotic system mentioned above, they’ve ended up using the numpy module everywhere as opposed to the (in this case) faster mathutils module simply because it allows them to run tests on their code outside of the BGE. For a commercial product, testing is a huge topic and one that I have only seen 2-3 posts on BA about over the past 8 years.

Python as a second-class-user
Agoose is more against this than I, but I do see his point. BGE calls into your python scripts rather than your scripts calling into BGE. This prevents python from being able to construct scenes from a collection of models (has to be done through blender’s GUI). Additionally, python’s API is hand-constructed, and is thus limited. Every time I need even a tiny bit more access into BGE’s internals (eg to force the shaders to recompile), it has to be developed into blender itself.

Multithreading is not-possible
Even with python, using the multiprocessing module has issues on Windows - opening up blender instances instead of python threads! This makes BGE rather poor on current hardware. At work we’re rock bottom into this problem. We’re running one of the most powerful single-core processors that is slightly overclocked, and we suffer from performance issues. The GPU is at 10% utilisation, and a single CPU core is virtually burning up. Our three most time consuming tasks (physics mesh animation, calculating the physics itself, and an almighty 11 render passes - three of them of about a million polygons) could in theory all be split out to separate cores. Oh, and animations start to stutter at about half a million animated vertices.

Big limitations on custom GLSL shaders
For one they are hard to preview as they can only be applied in-game, and for two you don’t have access to internal shader “chunks” to speed up shader development. Part of the second one means that using things like shadows with custom GLSL shaders is nearly impossible. This resulted in Martins to develop an anistropic specular reflection system inside the node editor! And I think Adrians has done GGX specular inside the node editor as well. While it is impressive (woah, look at all those nodes), it isn’t maintainable or version controllable.


The most important things in a commercial setting are:

  • Can it produce maintainable products?
  • Can it produce scalable products?
  • Does it use the hardware effectively?
  • Is it easy to work with?
  • Does it co-operate nicely with version control systems?
  • Can it produce testable products?

BGE scores: No, Can, No, Yes, No, No

Most other engines at least score: No Yes Yes Yes Yes No

The other thing that most people underestimate - particularly with BGE, is that making a game is hard. BGE allows a beginner (including myself many years ago) to create a game very fast and in a very simple manner. You can take someone with nearly no understanding of computer systems, and within two weeks, they can have a simple game. I personally have taught people how to make simple games in BGE in that sort of time period. This is because of the lack of a model pipeline and because of the logic bricks.

Because of this ease, BGE can create decent games in the four-hour WNG contest, and you can even make a not-too-bad game from scratch in a single hour. But as soon as you try to scale to a larger product, you start running into issues. There isn’t anything that isn’t work-around-able, but it simply stops being “nice” relatively quickly.
You can see this in my recent project Dreamrider. The original was made in four hours, and I’ve spend more than four-weeks recreating it with a better architecture (still in BGE, but using a more complete set of programming paradigms). BGE allowed an extremely rapid prototype - but it is somewhat awkward for continued development.


So what are the things that would need to be developed to make BGE more relevant in the game development scene:

  • Promote linked assets
  • Provide a way to get progress on loading things (seriously, loading 100mb of models does take time, and in BGE cannot have any progress reported to the user if you use the linking tools rather than libload)
  • Give python far far more control over the engines internals
  • Provide systems to allow testing of code outside of BGE (eg a dummy bge, aud, bgl module).
  • Multithread to allow it to take advantage of modern hardware
  • Improve GLSL shader workflow

Unfortunately, that will require a huge amount of effort that is (in my mind) beyond the current development teams ability.

Thanks for your input sdfgeoff!

I’m pretty amazed that if not fully at least a part of your full-time job is using the BGE ! I must say that I pretty much resonate with what you said: The current “obvious” workflow is not maintenable. Nodes would be a problem too, unless they are only meant to “write” logic that would be compiled outside. Then the output if put outside the .blend would be versionnable. Its weird but could work.

  • Promote linked assets
  • Provide a way to get progress on loading things (seriously, loading 100mb of models does take time, and in BGE cannot have any progress reported to the user if you use the linking tools rather than libload)
  • Give python far far more control over the engines internals
  • Provide systems to allow testing of code outside of BGE (eg a dummy bge, aud, bgl module).
  • Multithread to allow it to take advantage of modern hardware
  • Improve GLSL shader workflow
  • Linked assets: In the framework I’m tinkering with, you have 1 .blend that is the root of your project, and should have only 1 empty with 1 always brick triggering 1 python controller invoking the framework. From there you do everything in a side Python project, so its very very maintenable and can be versionned.
  • Progress on loading: As I said, in my framework you should have a main.blend (or any other name, nvm) that invoke your logic from the Python project, where you would also put all your .blend with the actual models. The framework would then LibLoad things as they would be required (kinda dep system). But as far as I tried, when you LibLoad files with a HUGE mesh in it, the loading progress from the KX_LibStatus is not updated :confused:
  • Python control over internals: I spoke briefly with TwisterGE about just having the possibility to execute scripts at Engine level, outside of scenes. Because right now every script is running as logic from an object inside a scene. Swap scene, loose your logic. This is only one of the problems, one other would be creating scenes as you mentionned. Having the possibility to run scripts along-side the BGE without being stuck in a scene would be a great opportunity indeed ! With my framework I tried to give the feeling that you actually pilot the BGE, where as you said again, the BGE is invoking your scripts, you are not really “piloting” the BGE.
  • Multithreading: Never played with this tbh (mutliprocessing), and afaik the threading module works given the correct setup, but its Python threading, which is not real threading :confused:
  • Python testing: Well, I don’t use this for tests, but I wanted just in case to be able to run my framework outside of the BGE (in order to define “program” like modules that could do actions without the game running), and come up with this: https://gist.github.com/WKnight02/bfc46388a6dcad1a6a09a2bb315da6c5. Now you won’t be able to make calls to Blender modules because well, they are not accessible if you aren’t running the engine, but at least you can import files and not expect them to crash over missing imports :confused:

Now is it beyond the actual team ? Well, I can’t say, but us as users can proceed one step at the time to work around these problems… Making an addon replacing bricks ? Doable. Making a framework so that everything is outside of just 1 .blend and can be versionned ? Doable.

Now there are trickier points, but hey, one step after the other :slight_smile:

Well i started back in 2009 with Blender 2.49b (R.I.P) ohhTBH that was my best BGE experience !!! I started out as a Hobbyist and still a Hobbyist i self taught my self how to do modeling and creating Games on BGE I WAS Never an advanced or even experienced blender user, and ive never done professional paid work ,i made over 50 mini blender games which were like mini sequels the game projects that i have now actually originated from those old Games eventually i will upload them when my current projects get done. So all these years ive just been using BGE and making my own games i started Speed Racer A Whole New World 2 back in 2014 as a Reboot of my old speed Racer games which were blender games and have nothing to do with the actual Speed Racer movies or Games !!! So they were all titled Blender Game Speed Racer Racing !!! Which were all my racing games with shapes and cubes BGE really worked well for me even up until now i still model on BGE and also i do test and make my other projects on BGE however BGE weaknesses had me working around them instead i decided to go for BGE POWER TO DO ANYTHING which was my new entry to UPBGE and learning it i only started with UPBGE this year and so far sit runs all my optimizations very well , one of my friends said that i should go about and make an open world however i fo not mind making one my new approach towards UPBGE is the way BGE was and i will always work around its limitations and bugs be it anything im not perfect iam not a professional im only a college student who wants to create all i ever wished to see for the Blender Game Engine. I will work and dedicate myself to making Good looking and playable BGE and UPBGE games just for Free.

If anyone wants to make AAA products using the BGE theres no problems at all all you need is PYthon and run C++ Typed level codes and scripts that can push your project or product that far otherwise im happy with BGE’s current state but still we’ll always need improvements to it and i mean ALWAYS . otherwise creating free. Content is the way i dont see BGE as a game Engine that is designed to make AAA EA styled games we already have Armory and Unreal Engine and Unity for that otherwise i would recommend blender for Education or for beginners i think that beginners will truly be satisfied and will be happy to easily create their first 3D work or games or even animations. (BGE is a great learning tool however it has all capabilities that can create AAA content)

I SAY THE BETTER THE CONTENT/RESULTS/PRODUCT THE MORE POWER AND BACK UP YOU NEED TO DO FOR THATON BGE !!! hence thats why we have UPBGE and Armory. But i still say anything’s possible to do on BGE you will need to be a Pro or really clever in your techniques to create AAA content.

I think that blender is a Great software and its all about being creative and using that knowledge to create something that people will appreciate and play for free and for fun.

Importals Adventures was my approach to making an open world adventure with quests and mission objectives however i paused that for Speed Racer A Whole New World 2. (Atleast the official Demo’s commin Alright)

(BTW im only a Hobbyist who’s just trying his best at using The Game Engine, so far my experience is what is saving me so far with my current projects) BGE’s cons is what has pushed me this far as far as my Game projects are concerned. The limitations push you to work around them to create better results than what is expected (of you and the viewers) thanks for this thread i think that this will inspire other aspiring artists to use blender and do the same.

Fred/K.S

Thanks Fred/K.S :slight_smile:

BGE’s cons is what has pushed me this far as far as my Game projects are concerned. The limitations push you to work around them to create better results than what is expected (of you and the viewers) thanks for this thread i think that this will inspire other aspiring artists to use blender and do the same.

Yes, that’s inspirationnal, for sure :smiley:
But the problem is that when you always have to hack around your tool so that it fits use cases it was not correctly fiting before, well… You can easely tell that there are things to change, right ? :slight_smile:
People hacking around is awesome, but after a decade, what still amaze me is that no real solid tool is used.
I mean, by now there should be some kind of lib/framework compiling the major bottlenecks, right ?
Well, I don’t know of any commonly used today. Its still the same struggle with bricks and one shot Python scripts…
In conclusion, in a 10 year time, artists were inspired to try and hack the engine, and one of two things happent:
1 - They managed to make something, but its not scalable and/or flexible. Its a 1 scenario tool.
2 - They did not manage to make something at all, because when attempting a n°1 solution, they failed midway because of the complexity.
This needs to be addressed :confused:

I would say that yes i agree with you bro alot has to really be changed i must say that it really annoyed me at the most having to re-create things that were done but not properly and yeah hacking in to blender helps a hell of alot ohh and a BIG thanks to the community for the constant help that always seems to get me going. (Forward)
We really need to expand and update our Python ways of approaching Code. (Or should i say improve our ways of python coding atleast to try and C++ our ways of coding but in python) therefore we’ll have the desirable results really as good as UE 4 or even better to a Frostbite level hence i say anythings possible in the Development of BGE.
Alot of tools have to be re assessed as far as modeling is concerned to me everythings pretty fine although some things need to be updated.

What really buggs me is the fact that in almost all the 2.70 or 2.60 versions of blender the GE has not changed that much there isnt as much progress than the way Cycles has improved which kills me because upbge has it all updated altogether which is how These 2.70 Versions should have been. Now with Eevee making an entrance in 2.80 i feel as if they want to remone the GE which can still be of Good use to any user even beginners. (BEGINNERS CAN GET GOOD KNOWLEDGE OF BASIC 3D AND GAME DEVELOPMENT THROUGH BLENDER !!!)

Its a Great learnimg software tool for everyone and i hope BF keeps atleast its GE but allows the UPBGE team to update it or atleast start with UPBGE in official blender releases. Instead of these separate independant versions which have me constantly switching all the time !!!

Fred/K.S

Fully agree on the lack of multithreading and clunky custom GLSL workflow. A few things…

The multithreading unfortunately may not come at all because it is dependent on the dev. team behind Python itself. Considering the fact of the lead’s now infamous “it’s fast enough for me” quote, there may be little chance of seeing substantial speedups in the Python API that will translate to better game performance (barring the implementation of a JIT compiled version, which even UPBGE may not see anytime soon).

The GLSL workflow is worse than simply needing to run the game to see the results, you also have the fact that there is a clunky setup phase to do in new projects before you can even test it (no custom UI ability or anything of that sort doesn’t help).

The same is true for the workflow if you want any kind of effect from video textures. Out of the box, it doesn’t clear properly when the scene reloads, so you have to do some workaround to prevent a broken shader or (worse) a crash.

The same is also true if you need to make objects or material instances unique while the game is running. Consider that you currently have to do some trick with the Lib functions (with no guarantee it will work) vs. the easy way in Godot which is simply preloading a resource and adding .duplicate().

The BGE tends to make it pretty easy for game levels to have one-off objects, but it does not have an optimal workflow for re-usable objects. Right now, the way to do it is to have group instances, but you would have to make one scene for each instance due to Blender’s over-reliance on global coordinates for various functionality (though it’s possible that Bastien’s work on asset management may help things here).

One final thing is that the BGE lacks a lot of tools that assist in creating important components such as UI’s (which if done right can deliver an easy-to-use solution without feeling like a black box). Simply put, a lot of tools which users of other engines take for granted (even Godot) is missing in the BGE (and UPBGE as well). I do think that the community around it may be in part responsible for that situation, as some of the more active users strongly favor a ‘build it yourself’ ideology and oppose the development of such tools (never mind the possibility of that completely undermining the GE’s “ease of use” claim).

A better renderer is really good. But until the “guts” are fixed, I think fixing the appearence won’t be effective enough to keep it alive

I felt like that was directed to UPBGE :wink:
Our work doesn’t have the focus exclusively in that, it’s been over 2 years and BGE is almost unrecognizable code-wise. Just to make things clear!

I agree 101% with the “Generally passive community” point. We are far from being wizards, I wish! You ahve no idea about the stress we get with all the particular requests almost every day.

I also agree that the API for game logic could be easily improved by a framework, and I do blame the community for not spending time working on something (Apparently everyone just want to start flame wars and controversial threads every day). I am also working on something I’ll release soon and it’s an UI framework.

Agreed, but you have that with pretty much any engine. When the problem gets too complex, you are more likely to break it than fix it. so they will have to take their time. Its a necessity.

Its a necessity once you get to specific mechanics or anything that comes to your game design.
The problem actually is that you need to hack around right from the start… It feels like things that should be there already are not.

This was my feeling too, this “do it yourself” ideology. I wonder how many serious BGE users there are out there, really caring about the tool and its efficency rather than actually wanting to make a game, because well, IMO if you want to make a game with the BGE, a lot has to be made to fix and add what is missing to the engine…

I never used this things, how bad is the workflow/setup phase ? Do you think it would be possible to have an easier UI for it ?

Yea, I spoke without really knowing :stuck_out_tongue:
But the fact is even with PythonComponents I didn’t see a lot of change logic-wise. Although I stumbled across LibLoad’s scene argument, which is cool ! That and other fixes I found around :slight_smile:
By the way, isn’t it better to put the LibLoad functions in the KX_Scene object ?
I mean it heavily depends on the scene to libload right know, right… Would have made more sense IMO to put it in the scene rather than in the logic module… (maybe keep it there for back-compatibilty, but I wouldn’t care if it was for the better good lol)

Now for anyone posting there, do you have ideas of what we could do, not necessarly going in the cpp code, but with addons or resources, to provide a strong or good fix for these issues ?

I mean I’m tinkering with a full Python framework and logic nodes, Twister made a simple UI framework, what are your ideas ?

Many custom GLSL surface shaders that use VideoTexture for instance require you to make sure you have created the right objects and the right properties to actually make it work. It’s really not Plug’N’Play at all. Other engines allow you to create a straightforward UI for custom shaders (where you have slots for textures and all of the other things you need to make it work).

Now certain effects like reflections should become far easier with Eevee in UPBGE because you can then just use a reflection probe and a shiny surface. Eevee in general should at least get rid of most of the reasons why you might need a custom shader script to begin with (due to the node-based nature), so at least you won’t need the clunky and slow workflow near as much.

Many custom GLSL surface shaders that use VideoTexture for instance require you to make sure you have created the right objects and the right properties to actually make it work. It’s really not Plug’N’Play at all. Other engines allow you to create a straightforward UI for custom shaders (where you have slots for textures and all of the other things you need to make it work).

Do you think it would be something doable given a proper framework/lib ? I mean, when I say that the Blender API is kinda low level, despite all the useful functions, its because you often need to make a wrapper in order for everything to fall in the right place…

I have no idea how to works with video textures and such, do you think there is a way to put safe guards with a good wrapper around it ? Maybe even addon with it to have something in the UI ?

One of my point is that people are ready to criticize, but rather than looking for fixes they are looking at the problems only. If it is such a problem, do you think you can provide something to work with it ? For you own sake and others in a seconde time ?

I don’t really know how to word it like I want, I’m not really asking you to make something, but I would rather strongly suggest it.

Do you think doing a wrapper/module around these tech could benefit you and other ? Do you want to make it ?

This is part of the problem mentioned earlier about “do it yourself” ideology… People able should indeed do it themselves, but in order to get out of the loop the tools shall be shared :slight_smile:

Pros:

  • Fast Real time rendering
  • Integrated within Blender
  • Python based
  • Easy to compile for Windows

Cons

  • Lousy API. The API is badly organized.
  • No Halos, Particles and other special effects
  • No way to display Modifier Animation like Build Modifer or Ocean Modifier
  • No compilation for Android and iOS other than exporting to Unity or other game engines

I think the component API in UPBGE allows this sort of thing. I made some neat components for lights to disable shadow rendering when far away, and for setting up real-time mirrors and camera’s really easily. The component system has the potential to act as a user-side interface for custom GLSL shaders and other thing only exposed in the python API (Eg mesh batching)

Yes, I think your right that the component system is pretty useful when it comes to interfacing with script users, because you would have per-component parameters.

Its cool, even if we had game object properties before that were accessible in the same fashion from old-way Python scripts/modules.

Now even with components, one thing that miss for sure would be a strong script made once and covering 99% of the use cases. Right now nobody made anything as such, or kept it for themselves ^^"

  • Lousy API. The API is badly organized.
  • No Halos, Particles and other special effects
  • No way to display Modifier Animation like Build Modifer or Ocean Modifier
  • No compilation for Android and iOS other than exporting to Unity or other game engines

you can do anything you want with vertex, planes etc you just have to think about it

about android port - there is using a JIT for android and going that route I think for logic(not 100% sure), and immediate mode / core compatibility in the render is eminent

Now even with components, one thing that miss for sure would be a strong script made once and covering 99% of the use cases. Right now nobody made anything as such, or kept it for themselves ^^"

I did release some in my node shaders thread. The issue isn’t in releasing resources - there’s a forum for that, but the issue is getting people to use them. There’d need to be a wiki or some way to collect them without the user having to scroll through lots of threads/google search for them. There’s also the issue that they aren’t supported in BFBGE which places a damper on their usefullness.

I also found after about a week and a small project, and making a moderate size project using just components, that the ECS (Entity Component System) requires some rather awkward side-steps to get working properly. I don’t think it’s a limitation of BGE’s ECS implementation, but when you have interactions between components it quickly becomes inconvenient. It also suffers from their only being a single layer of hierarchy, and that you can only have object-associated components (not scene or game level). Finally it suffers from a bigger issue: If different people write them, then services are handled in a different way. Services are (what I call) things like audio management, keymapping, settings, event routing/signalling, and so on. If every component handles these differently then there will be issues when assembling a larger system out of components. And it’s not like you can make a keymapping component - it doesn’t fit the paradigm.

If engine A required people to cobble an effect together with planes and several hours of coding, and engine B allowed people to set something up in 10 minutes using a GUI and a visually-based workflow (possibly node-based), most people would prefer the workflow in engine B.

One of the core issues with hacked together particles and effects in the BGE is the same as with custom shaders, and that is how you have to run the game to even check if it’s working the way that you intend. Almost every other 3D engine in contrast has a way to preview effects while working in the editor (allowing for very fast iteration).

I cobbled together the effect, and dumped it in resources,

so no it does not take hours of coding.

it’s kinda documented,
:stuck_out_tongue:

and no it took me about 2 hours total, and the same system will be making me roads along splines soon enough I think :smiley:

To be fair, I dropped the idea of using Blender Scenes. Right know scenes are just a collection of items, so instead of using the Blender scenes, I do manage objects my way. This can allow for custom scene loading, from an XML or any other format, so that you do need to LibLoad blend files to have the models, but the setting is made like a web page is made, with a basic descriptive language.

BTW I made the GitLab repository public for bgez: https://gitlab.com/WKnight02/bgez
All I need now is make more documentation and demos, then I will be able to post a more official release thread maybe.

This framework is meant to be worked on by people to develop standards, so that everything is more coherent when working on the bge.

@AceDragon: I agree with you, but people keep saying “but you can do it if you are perseverent” :confused:
This is exactly how not to get things going. “I won’t update or improve the tool because you can already do things in weeks, who really needs to do things in hours instead, really ?”.

What I notice the most in all the things I read so far on this thread seems to be the fact that indeed, people do not make the right tools for others to use, or at least they are badly shared. Everyone starts everything from scratch everytime they use the BGE :confused: