Your "Pros & Cons" about the BGE

See the last point in post #7.

The benefits of having (hardcoded) visual tools and features to allow for such effects quickly and easily (as opposed to downloading someone else’s version using Python in combination with planes and textures)…

  • Far less risk of your effect breaking due to an API change or due to commits changing the core
  • Far faster (the backing of it would be C++ instead of Python).
  • WYSIWYG in the editor itself, no need to start the game to see if it’s the way you want
  • Piggybacking on point 3, rapid iteration time
  • Less risk of said effect breaking due to some lesser known case (which you need to hunt down and fix yourself)
  • Far less setup to do beforehand (just create an effect, change parameters and go).
  • Far less work in customizing it via an API (you don’t need to mess with the guts, just use a set of Python functions that connect to the parameters).
  • Far easier to create many variations for many different cases
  • No need to trawl through endless forum threads

Just because you personally don’t need such tools for Wrectified doesn’t mean one should conclude that nobody else needs them (your workflow preferences do not represent the desires of the community as a whole, remember that).

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.

Careful - you’ll end up writing a level editor inside of BGE if you follow that route… To be fair, I’ve ended up doing that a few times.

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

Been tried in the past by people like Monster, elmeunick9, myself and probably several more.


Frameworks are a nice thing in theory, but there’s a reason why none have succeeded: the required architecture or each game is different. It is very hard to identify what the framework should provide because where does the framework turn into the game’s architecture? Over the past several years I’ve done first person, third person, RTS, racing, 2d sidescrollers and a whole bunch of other games. To date virtually none of them have been able to share a framework. Each have had different requirements resulting in different input handling systems, different methods of managing resources and so on. Is there a solution that will work for all of them? Sure - probably. But after working with the GE for a couple years, I haven’t found it. (May be my own fault. I have some very strange opinions on modern computer systems)

Building a framework on top of a tool is a stop-gap measure - not a solution. I typically build a couple abstraction layers around LibLoad to handle things the engine could (should?) do for me. Sure, I could make a python framework for this, or perhaps BGE should be improved so I don’t have to. Agoose pointed out to me the other day that there is a progression here on the forums from game developers to python scripters to framework developers to engine developers to those who go elsewhere. Seems accurate from where I’m standing.

I can’t say I disagree with anything you’ve said.

But I’m pretty confident that there is a way to provide a standard framework.
I’m struggling too with “what to add next, how to add it to the framework…”, but I’m starting to see a bit through.

The thing when making a tool, is to acknowledge that there are things that the dev should do, not you as the tool dev. But you should ensure that the end dev has the right tools if he want to do something. I do place myself in that situation right now, so that I have a couple test projects where I’m just asking myself “how would I want to implement this using a good API ?”, so I just write how I would want to have to write it, then I modify the framework to comply to the desired final implementation. I tweak things either in the desired API or in the framework, but so far I’m pretty confident there is potential. Its just a very long process…

Right now I spent around 3 month almost full steam on it, today I’m having a bit of down time but I know it and try to work my way up to feel “inpired” again :slight_smile:

Even tho frameworks might be stop-gaps measures, when you think about it, you can emulate what the GE lacks using the Python API (this what I tried to do with “bgez”). The point is to make devs feels that something that would look hacky at first now feels strong because of a good implementation of the “hack”. I have my stage concept replacing Blender’s scene in mind: Blender scenes in a nutshell dictates what object is where, and when you load it, it just erase all previous objects, add the new ones, execute the logic and there you go. This process is what the GE devs had to develop in cpp in the Blender’s sources, but in this case nothing prevents us to make our own implementation of the scene system. Having to do it from scratch on every project would be a pain, so the idea of giving a framework abstract enough to manage this kind of problems only and provides tools is viable IMO.

Now of course the line I would be walking on trying to get this project to be useful is very thin, but I think it would really expands the potential of the GE, in terms of usability. Now for any actually missing feature of course something should be changed in the actual sources of the GE…

I’m struggling to make my point clear tbh, but if I were to recap:

  • frameworks are tricky to develop because its rather hard to indentify what should be implemented to comply to any game format.
    > Hopefully enough I acknowledged that, and tried to provide more of an “alternative” API, I call it a framework but really its more of a big ass wrapper around the old API that would ensure that your logic is more coherent, I’m not coding for you, its a frame around your work. I think right now even tho its not perfect, it has a pretty good shape, and it can change in the future to fit unexpected needs. This is what I’m striving for.
  • I think that this would be one of the step to take in order to make the BGE better. This kind of “alternative API” or framework can provide a strong proof-of-concept that if trully bulletproof, could be then implemented in parts within the BGE source to speed up some things. What I’m talking about is really a “better API”, I really aim at a more maintainable way of using the BGE, not giving some magic stuff that would do any game in 2 lines.

Deleted due to errors

If you can please share a way to get the Build Modifier animation going in BGE , I badly need it.
One way I can think of is the replace mesh actuator, but converting each frame of the Build Mod anim into a seperate mesh increases load time and filesize of the game.

can you post a video of the effect you need?