I think from all a little:
The Physics we have now is absolutely enough. Only a litte more stable would be nice. Boosting Blenders Graphics up to Date is nearly impossible. But I don’t need Shaders and realtime Shadows. My Favorites are: High- Light- and Shadowmaps -> MultiTexturing. At last some new Sensors and Actuators for more Python flexibility.
Logic-Bricking have no more importance to me. Normaly i have some Sensors left and more Actuators right, and in the middle one single Python Script. 
I just encountered some odd bugs in my game that I fixed making a new object out of the flawed area, collision faces not working and getting stuck on flat planes like the engine put invisable faces there.
So I too agree to any of you that we need to get rid of the bugs.
Ok the main thing I was talking about is, having the ability to load custom maps(either from .bsp, .scene, whatever) or models on the fly so incase if anyone wants to add their own content, they don’t have to go edit the entire blend file to do it.
Ok the main thing I was talking about is, having the ability to load custom maps(either from .bsp, .scene, whatever) or models on the fly so incase if anyone wants to add their own content, they don’t have to go edit the entire blend file to do it.
I don’t know any way to load models on the fly, but you can load maps on the fly. You could have a structure something like this:
main.exe - a simple exported runtime with an empty that has 3 logic bricks:
- an always sensor (not pulsed, only needs to run once)
- a python controller that determines which map to load on the fly
- a game actuator that loads a .blend file (determined by the python)
map1.blend, map2.blend, map3.blend, etc. - any .blend files that you want to use as maps. These have LINKS* to a shared data library (objects and other data shared by multiple maps.)
library.blend - a .blend file that contains the data used by multiple maps, so if you have massive data like armatures they don’t have to be duplicated in every map.
- “Link” is an option when you “append” data in Blender. You can’t modify linked data. If you have a linked mesh object, you can’t edit it’s logic bricks or vertices. If you have a regular mesh object with linked mesh data you can edit it’s logic bricks, but not it’s vertices. (Of course you can open the source .blend file containing the linked data and modify it there.)
But it should load models on the fly, the way it’s running now it should.
I voted for speed. 6 armatures max in a scene? I mean come on… There are plenty of 3d RTS engines that can handle hundreds of fully-rigged characters. Other than for character animation, I can’t ask for too much more. However, speed should be the first thing that developers work on. (I’m way to lazy to try to do something like this.)
I think that they should also sort out the physics bugs. Like if you drop a cube on the ground, it keeps rotating, while it should really stay static. (People have already mentioned these, I’m just stating my opinion :P)
Graphics seem just fine if you include Tuhopuu. It has GLSL and shadows. While both could be improved upon (a lot), they provide a very good start. I’ve been playing around with it and made some pretty cool images in the GE. I really hope that Kester will port GLSL and shadows into the main Blender tree.
A lot of people will look at the GE and say “It doesn’t have feature x! I’m switching to engine x!” Most of these people probably are not that experienced with the GE. How the game plays is much more important than the graphics. For example, go play CS:S. While the normal maps and HDR lighting might look good at first, they don’t add to the “fun” factor. I realize that modern games usually do take advantage of high-end graphics hardware and software, but I would bet that you could get away with selling a game if it was extremely entertaining and used the Blender engine. People aren’t going to go out and buy a game because it has normal mapping and bump-granularity self-shadowing using spherical harmonic maps. People (excluding us geeks) will buy it because it is fun. 
Also, here are my feature requests:
- Armatures are faster and you can have 20+ of them in one scene at a time.
- GLSL, multitexturing, and shadows are ported from Tuhopuu 2 to Bf-Blender.
- As other people have stated, the ability to load levels on the fly. For example, you could have a python script that would look like:
map = GameLogic.getBlendFile("./map.blend")
map_obj = map.getObject(“Cube.001”)
GameLogic.loadObject(map_obj)
Or something like that. I just made that up as an example and I’m tired so please don’t comment on how useless it would be or how it would be impossible or all the other flaws it has. Basically you could just append objects from a .blend file on the fly. This would be incredibly useful.
Ok well this is just my $0.02
i have a game that has 150 armatures (12 bones each with full animation) and it runs at 32fps! where are you getting that info? 
Well, the lack of logic and smooth rendering is what get’s my complaint mostly.
Just a Question of Time, now here it is: first Hardware accelerated Physics for Games
Just if someone is interested.
definately some graphics improvements like multiples uv sets (for lightmaps and detail textures) on the fly textures loading (for IN GAME video) and render to texture capabilitie…a stencil shadow could be cool for characters.
the other thing is to make a LOD system and improve the armatures performances.
As said logic/physic is very important, it should be fixed and improved.
But as i have already said, it would be better to make a plugin structure for graphics/physics and concentrate to the gui and logic scripting…cause the engine is really outdated and i think it will be a lot of work to update it to today standards (like ogre, irrlicht…) 
Whats irrlicht ?
Believe it or not I actually had 2 dreams before of blender’s game engine having shadow capibility, both including soft shadows as well. Now this might be an indicator for me that there should be realtime shadows in the engine.
I know there is a script for shadows. But in my opinion, I think the game engine rely too much on scripts, scripts should be save for something that’s impossible not a basic feature that should be in Blender Game Engine by now.
i have a game that has 150 armatures (12 bones each with full animation) and it runs at 32fps! where are you getting that info?
Really? Do you think you could post a .blend or example? I would love to see it.
sorry maybe i should have said i worked on a game that had 150 armatures (12 bones each with full animation) - it was OIF that i made with 150 of the players duplicated - it only ran in wire mode and only at about 480x320 resolutioon with all frames enabled - so maybe what i said sounded a little unbelieveable - it was just to show that 6 isn’t the limit (practically speaking 30 is about the limit). I’d get you the file but i wasn’t the one keeping them - BlendedMagic was and i doubt he ever got that file - if i recall right it was 15MB!
for proof though you could download Project Underwater beta test (www.realfxstudios.hostmatrix.org/forum/index.php) which has something like 15 mines that are animated with armatures…
once again…i would be more than happy if blender had saving/loading functions.making it with python is a pain and using the scripts available to do it,takes too much time.
Damn right :<
ok this is what i want
right now i dont care about graphics or speed
if its runnin at 8fps check every poly and everything else to try to make it run faster.
what i think it needs are easier ways to just get stuff done (a little to general I know)
But for example, lets say we have a vehical with 4 weels, a suspension, a gun in the back, and the main body. the easyest way to make this work for realistic vehical motion would be to parent the wheels to the objects for the suspention, and parent that to the main body (we all know it is more complex than that so i dont think i need to get any more in depth). lets say these are all physical objects, that just aint gona work they just gona fly off alover the place.
And lets say the vehical gets destroyed and it needs to respawn somewhere. so you have a new type of object called a spawn point.
the spawn point would simply spawn a system/group of objects when told to.
when i say system or group, I mean, instead of spawning individiual objects, you group all the objects of the vehical into a system/group and the spawn point, spawns the indicated system/group.
this was just an example of what it could be used for but there are other uses.
Ok another thing I think we need is the use of prefixes and sufixes…
so you can get more specific with objects that you want to use for certain things.
lets say I have “Cube”
I copy cube to get “Cube” and “Cube.001”.
the name of both objects is still “Cube” but the second cube has a suffix of “001” and the " . " would separate the name and suffix (the same would go for the prefix and name)
This could also be used for a LOD system “LOD1.Cube, LOD2.Cube, LOD3.Cube, etc” ya get what i mean right???
now lets say you have a python script that moves or rotates an object, but you have several copies of this object and you all want them to run off of the single script, but the script is made to only work on the object with the specified “name”.
Well all the objects have to same “name” but different suffixes so your all good.
once again there are many uses for this.
And lets say the vehical gets destroyed and it needs to respawn somewhere. so you have a new type of object called a spawn point.
the spawn point would simply spawn a system/group of objects when told to.
That can be done with a python script. Just have an empty add the necessary objects into the current scene. (To avoid having them respawn at the same place, make it so that the empties position is varied around the main spawning point after each character is added).
now lets say you have a python script that moves or rotates an object, but you have several copies of this object and you all want them to run off of the single script, but the script is made to only work on the object with the specified “name”.
I may be misunderstanding you, but there aren’t very many cases where python scripts are written to be object name specific. (Hmm, I do have a couple that are though). Usually it’s just better to avoid writing it to be object specific.
Jason Lin
If you have any feature requests please add them here http://wiki.blender.org/bin/view.pl/Requests/GameEngineFeatures
If you are intrested in joining the game engine dev crew please add yourself to the list here
http://wiki.blender.org/bin/view.pl/Blenderwiki/GameEngineTeam