This is something I’ve been worried about for a while, will blender 2.5 be able to play the game projects I’m working on, because I know they were changing some stuff in it, and I’m just afraid that my game will be ruined in the transfer.
I can almost guarantee you that 2.5 is capable of playing whatever games you’ve been working on. However, it’s more than likely that you’ll have to do some changing of things to make everything compatible.
One of the biggest changes is likely the move to Python 3.1, so all your scripts will now need to be modified (which really isn’t too much work) to be 3.1-worthy. Also, your animations could (but it’s unlikely) need a bit of tweaking if the animato conversion doesn’t work properly.
The only way you’ll find out what you need to fix is to try it! Download a copy of 2.5 (from graphicall.org if you don’t feel like building yourself) and try to run the game in it. If you have any errors that you can’t resolve, just post them here (in this thread or in this forum) and myself and the blender community will work our magic!
Happy BlenderGaming!
2.49 will still work when 2.5 is released 
you will be able to finish your game
Assuming he used the 2.49 API in his python scripts, the transition should be seamless.
My suggestion is to use the 2.49 api. If you’re getting deprecation warnings, fix them or your scripts will break in 2.5. Also, you’ll have to be careful about making the jump from Python 2.x to 3.x (which Blender 2.5 uses). I’d avoid using anything that Python has deprecated, and make sure to always use print as a function, like so:
print("foo")
# Not this
print "foo"
If you keep those things in mind, porting to 2.5 may still have some bumps, but the transition will be a lot smoother.
Actualy some thing in 2.49 python dont work like they should. For instance if a used,
obj.position = [0, 0, 0]
in 2.49 it wont do anything, so i use obj.setPosition([0, 0, 0]), even tho it says its deprecated.
but in 2.5 it will move the object. if i wrote
objPos = obj.position
objPos[0] = 10
in 2.5 it will still move the object, but it 2.49 it wont. So , my point is, if you have alot of scripts in your game, its going to take awhile porting them to 2.5
I thought 2.49 was meant to be the transitional version from the 2.4x to 2.5 -onwards??
I thought that was the point of the depreciation warnings, to tell you which scripts were running right and which ones needed editing to work ok in the 2.5 environment.
Ive run my wip game in 2.5, it runs fine, except theres issues with ALL the scripts, which there is about 15 of so far, many more to come…
Im not so great at python, so relearning all the 2.49 stuff has been a pain in the ass, and now I have to learn it all a 3rd time for 2.5?
That’s what I thought also? What was the point of changing the python API in 2.49, if it was going to change again in 2.5? It doesn’t make any sense? People told me that if I fixed my code right now, in 2.49, then my game will run nicely on 2.5, but I get a bunch of issues, most of my scripts donm’t work. 
It has been a pain in the ass.
I remembered there was a thread, and I asked, that it would be a pain if I had to re-do all the code, and someone said, it’s ok, it’ll be worth it for when 2.5 comes out! If I find the theard I’ll post it here
Not cool guys not cool…
The API changes from Blender 2.48 to 2.49 have nothing to do with the changes we have from 2.49 to 2.5.
The first one was a big direction change in the way internal variables were handled (now we have direct access to the variables instead of having to use get/set statements). The second one is part due to python changes (thanks God we have only one Python version now), big fixes (eg Mathutils) and of course the opportunity that 2.50 brings to make things right.
So I’m not sure it brings some peace to your heart, but all the changes you did from 2.48 to 2.49 would still be necessary from 2.48 to 2.5. Therefore there is no wasted work.
Unfortunately there are other changes (most due to python 2.6->3.1 transition but some due to bge itself) that will require you some extra work. Extra work is different from work from scratch. I hope you get that.
Some of the changes Py2.xx to Py3.1 brought:
- print should always have parenthesis (eg print())
- has_key() doesn’t work any longer. So if you want to check for a property in your object you do: object.key(key, default=None). If it has the property named key it returns it value. Otherwise it returns None (or the value of the optional default value). object.getPropertyNames() can work well too.
- no more need for int to float conversion (eg float(2) / 3)
Some of the changes BGE 2.49 to 2.5 presents so far:
- all the instance variables use Mathutils modules whenever possible. That means object.orientation is a Mathutils.Matrix, object.position is a Mathutils.Vector . . .
- a lot of the Mathutils module operation was fixed. (e.g. Vector multiplication and some Matrix were using the wrong order of the arguments).
- No more OB in front of your object name (eg my_obj = scene.objects[“Cube”] is the correct now.
- Stereo eye separation defined in the UI, focal length using the camera focal length as default (this may be used by a few, but it serves to illustrate features that have been broken so we can have them working better).
GENERAL BOTTOMLINE:
It’s not recommended for any serious project to migrate to Blender 2.5 any time soon. Maybe not even after the first Release Candidates. Therefore I don’t see what’s wrong with sticking to 2.49 and already getting familiar with the new API, and later to learn a few more tricks. This is smooth enough in my opinion. Better than simply having a lot of changes only when 2.5 comes out.
No one is happy with the fact that we couldn’t make a smoother transition from 2.49 to 2.50, but so many things changed internally in Blender, that I bet no one predicted beforehand the extension of the changes to come. Things like the Mathutils fixes or removing OB should be done sooner or later. I’m glad 2.5 was the time for that.
It’s not so hard to migrate existent files to Blender 2.5. I’ve been doing that to some of my projects and so far nothing extraordinary came out (despite a bunch of bugs I’ve been spotting and reporting). Download a recent build from Graphicall and give it a shot. It’s really not hard to do the transition.
Last and probably least: I’m loving all the changes. No exception. I’ve been doing mainly BGE related works to live (as a freelancer and fulltime employ) and I’m very glad BGE is become better to work with. It may take time for newcomers (or people not so confident with python?) to get used to the changes. But in my opinion it pays off.
Also, anything that returns a degree value in 2.4x now returns a radian value.
thanks for all that well described info dfelinto. 