What does 2.5 mean for the Game Engine and its Community?

Well, The question was essentially there, but… The new animation system, will it work for the game-engine?

How about those so-called Operators I have a hard time grasping what they actually are? :stuck_out_tongue: Would logic bricks fall under the new “Operators”, meaning, I think a lot more flexibility?

How about the node system? is it being preserved?

I just can’t seem to find any info on 2.5 and BGE :frowning: Anything you know, please post here

yea I’m a little worried about the changes. What if I have a game which is half done, will I be able to complete it in 2.5 or it will not work? will I have to stick to 2.49? Maybe I’ll have to “adapt” some stuff wo 2.5?

I think that there’s nothing bad finishing a game on a previous version. (I think KRUM is still being developed on 2.48a or something). If you always want to keep up to date with blender release, you may have to finish your projects faster OR plan some refactoring in your development timeline.

Personally, when 2.49 came out I didnt waste time looking for the reasons why my tank game on 2.48a wasnt working anymore on 2.49. The physics was all screwed up. Maybe it would have been easy to fix but I prefered to switch on 2.49 from scracth and improve my code with what I learned on 2.48a. My game was still in an early stage, otherwise I wouldn’t have switched to 2.49

On the other hand, if you guys plan making games on 2.5. You should start by writing a good rule system for your game in pseudo-code which can be integrated in any game engine.

And sorry if I don’t anwser to any of your questions haha :slight_smile:

Graphicall.org has the alpha stages of 2.5, no game engine in them but its worth it so u can get used to the new UI.

I think there will be a lot of improvements on the GE in 2.5.
AAA Game Company Twilight 22 To Develop BGE Into A Full Production Game Engine

As far as Im concerned 2.5 BGE means…

  • dropping Sumo/Solid Physics
  • removing API functions deprecated in 2.49
  • removing retardard ‘ME’ and ‘OB’ prefix from names.
  • removing attribute access gameOb[“prop”] only.

Incase your reading and think its all about removing!

  • Improved IK (from benoit)
  • LOD system (from benoit)
  • Dynamic data loading (from me as with other python features)
  • using Mathutils types by default. ob1.position + ob2.position, ob2.position.x=1 (currently works in 2.5)
  • allowing you to subclass any internal BGE type, add your own functions and customize - (currently works in 2.5)

As far as I know this is all thats planned but there will be more smaller improvements allong the way and maybe some bigger ones.

Really 2.5 is not going to be much more then an incremental update to the BGE, and a good excuse to drop old stuff.

  • removing retardard ‘ME’ and ‘OB’ prefix from names.
  • removing attribute access gameOb[“prop”] only.
  • using Mathutils types by default. ob1.position + ob2.position, ob2.position.x=1 (currently works in 2.5)

Those all sound cool, the OB and ME prefixes have always annoyed me.
As for removing attribute access, does that mean that things like object.getDistanceTo(), object.rayCastTo() and sensor.hitObjectList will disappear as well? (They all currently give me deprecation warnings, telling me to use object[‘prop’] instead, but I don’t have any good alternative methods) Also… I’m kind of sad at ob.name being read only now, I liked being able to change an object’s name (it makes it easy to find the object in an objectlist in case of instances)
Similarly, object.replaceMesh() reminds me a lot of the syntax of .setPosition() and others in that it’s uncool… object.mesh = newmesh seems more logical to me

Ideasman42 don’t get me wrong I already think what’s happened with the BGE is amazing, I was just hoping for something big, like a rework of the logic brick system, or linking properties to nodes or other game data, straight into the node system such as coordinates, but if those things will help speed up the engine all that’s great too :slight_smile:

And LOD? GEIF!!

EDIT: Got any more info on the LOD system? is it one of those weird ones that automatically reduces vertexes? that could lead to some really creepy stretchyness in textures… Or is it one of those that automatically switches to a different LOD mesh you’ve designed? I’d infinitely prefer the latter… or actually a choice of both! :stuck_out_tongue_winking_eye: just depends on the object

@Almost object.getDistanceTo(), object.rayCastTo() and sensor.hitObjectList will be kept, I was refering to accessing properties. like gameOb.SomeFloatProp = 1.0 must be gameOb[‘SomeFloatProp’] = 1.0

I know what you mean about object.replaceMesh() but it should be kept, especially since you can optionally replace the physics mesh :), object.replaceMesh(mesh, True, True) # graphics replace and physics replace.

object rename could be supported again, but theres less reason to need it now with objects being hashable and being able to reference other objects.

@Mimterest AFAIK there are currently 3 blender devs working part time, you can only expect so much from this.

I didn’t know it was that few but I wasnt imagining an equivalent of a full branch of EA game studio on it :wink:

sort of off-topic, but is it possible to control node values on the fly by linking a Dynamic into the node editor and loading a python script, sort of getting it to work as a feed into the node system? That’d work for what I was hoping.

2.5 additions to Blender sound great. Big important release. Gradually filling in all the gaps…

Don’t all older projects open into newer versions? The whole DNA/RNA thing you hear about from time to time. If 2.5 is expected to break this, they would already know and I’d hope someone would say something…

Have to admit, I don’t really use blender much as I’m waiting for 2.5. With the murder of trueSpace by Microsoft, Daz’s horrible upgrade pricing and the cost of Messiah studio, I know that eventually basing my workflow on blender is more of a “when” than “if” with every new version.

Wasn’t Ben going to look into making the BGE multithreaded as part of the work with EA Research? I remember him saying that.

Are they using a special Blender build with tons of stuff that hasn’t been commited to trunk yet? When should we see the release of those commits for trunk if so? Is the project even still going (with no communication from MatrixNAN for a while some aren’t sure)