Ideas for a BGE GSOC projects

Ideas for a BGE GSOC projects

Adding interfaces so that you could integrate different renders like bgfx or ogre3d.
A build in GUI.
A build in Ai (Ai with states: idle, walk, attack::melee or range, patrol, runaway).
A build in object pool manager.
A build in particle system.
Luajit for a second scripting lang.

Having this features could bring more users to the bge and make it more usable for a commercial games. What is your believe on that?

Add an Assets manager, good GLSL shaders (Bloom, hdr :3) and finally implement Inferred Lighting and i’m totally in :wink:

Those ideas are also pretty good too, lots of things the BGE has been lacking these days. The particle system can be used with the easyEmit addon. Other than that i agree.

I agree with all proposals. I will add:
-Better lighting and clear setup.
-Force instances (like wind)
-Terrain LOD

I have a basic Ai hull that hunts with a vision cone, it does not have projectiles or waypoints but I can code that tonight, its called basic Ai hull, and it is in resources.

I plan on developing it more in wrectified.

The LOD now can manage terrain, you just have to have the terrain in chunks.

I would love to see some rendering speed ups and a liberary of shader examples for in game use.

What would you mean by an object pool manager?

My suggestions involve under the hood cleanups to data, how it is managed. This might involve exposing scene.meshes to the python api. I might participate informally over the summer, to provide full python support for the engine.

Sent from my Nexus 5 using Tapatalk

I mostly want optimisation on lighting and shadow, different kind of rendering for it maybe.

Why not some news build in 2d filter like bloom and dof, and a buid in ragdoll for armature.

I have a armature based rag doll, but it’s not automatic at all,

I am using Jackii’s rig, It could be autoGenerated from using the IK limits to generate rigid bodies that are representative of each bone,

Check out “rigged ragdoll” in resources,

— Better shadow support (like finishing up the work started by Kupoman)
— More robust occlusion culling
— Animation optimizations
— Built-in node-based pathfinding to go with the Navmesh stuff (node-based systems have the advantage in that they can be changed in a dynamic way by adding or removing nodes during gameplay)

— GLSL Box mapping/Blended box mapping/Multi vertex color channel support
— Support for Blender’s animation constraints
— Full display list/VBO support for objects using modifiers
— Small, but useful features (like giving proper support for creating lamp instances via the add object actuator)

Feel free to pick one :slight_smile:

BluePrintRandom, yes I already searched about rigged ragdoll and looked into files to see how it can be made.

But like 2d filters, ai, gui, and others, I just talked about buid in things here even if it can be made with brick or script, like the build in lod.

this isn’t like the lighting system for example, we can trick it a little by baking and move lights but this can be heavy even with this kind of trick.

I can add the cost of transparency and armature too.

Better surely to permit mesh creation in game?

I’d like that as well, but there’s so many other things that could be worked on that would be useful for a lot more users, he can’t do everything unfortunately.

The complexity of mesh creation depends on whether you would do something like create a new mesh for an existing object or not (so you don’t have to construct properties and bricks during gameplay), but that would assume we also have a system in place that allows for the re-instancing of non triangle-mesh bounds and even an in-gameplay switch to a new type.

Those were just things off the top of my head, so not surprising I didn’t think of everything at once :slight_smile:

Parent to nearest object with a paticular property for a minecraftlike game.In built animation library with a menue of selectable animations that would automatically be applied to the armature when you select one and the armature.
And a advanced dialogue system built into the game engine.

I forget to mention the inclusion of a toon outline in realtime (like freestyle)

If we are going to implement a nodal based system it would be more sensible (to my eyes) to overcome the primary limitation. Recast & detour would share very little in common with this, and it would require additional maintenance.

I agree that it would be a feat to implement, but not wholly unrealistic. Collision bounds are Bullet’s problem, and it doesn’t seem improbable that we’d just isolate the physics conversion code and allow updating the physics mesh to reflect mesh changes. If we did implement this, it would likely be first for editing meshes, later would come instantiation. I suspect that this would tie in with updating the mesh API and LibNew.

People making suggestions ought to be aware of the criteria for projects. Anything that can be done in Python (in other words, doesn’t require engine-data access, or C++ speeds) should be left to do so. Only generic and useful features need be considered for working on, or internal work.

Ops, it was really too rush before bedtime.

Just to add: The Android does not like python, does it? Today engines support all this features build in and also speed, draw calls is important. Not to mention the api can break with every new version so its getting hard to maintain it. most studios use their own plugins/addons, but if you are a single person, you would like to have the necessary features build in.

I thought there was once a proof of concept build of an actual BGE scene running on Android (as part of that one GSoC project), if Python was really a problem in this case then I doubt that project would’ve gotten very far.

Getting your game to sell big on mobile is pretty much like playing the lottery now, you slave away for months on a game that doesn’t sell yet someone makes a game in less than a day and strikes it rich, I even read on the Unity forums that one of the only ways to make it big now is to scrap your original idea in favor of cloning the popular games because that is what the people want O.o

My wishlist is:

  • bpy in the bge (?)
  • Blender’s physics (advanced softbodies and particles. Unified UI maybe?)
  • Proper, clean geometry shader support
  • Asset management (?)
  • Ability to use BI’s rendering capabilities in bge

That’s all I need, I guess.

@Ace:

Getting your game to sell big on mobile is pretty much like playing the lottery now, you slave away for months on a game that doesn’t sell yet someone makes a game in less than a day and strikes it rich, I even read on the Unity forums that one of the only ways to make it big now is to scrap your original idea in favor of cloning the popular games because that is what the people want O.o

This sounds rediculous, why I hate FPS games (or shooting genre generally) is because that they’re all copying famous ones ( or even each other ). In my opinion, good marketing = clean presentation. Meaning no glitchy demos, … etc. And spending time on the game itself instead of spending it on naming the game or the “studio” creating it.

BPY is a blender module, and should remain separate from the BGE. There should be little purpose for it.
Blender is moving towards Bullet softbodies. We can probably clean up and improve the BGE implementation though.

The unfortunate truth though is that neither Google nor Apple have any system in place that rewards innovative developers unless you’re a big company with plenty of money for marketing or have the means to build a large following ready to download your new game at a moment’s notice.

Complaints about lack of discoverability have been commonplace for a while and countless Indie devs. have lost a lot of money trying to break into the market. It doesn’t mean that I don’t think the BGE should allow Android deployment (due to how it’s free and would be a low risk in some respects for game creators), but I do think people should be realizing that the chances of hitting it big are low now and getting lower with the thousands of new games seen on a monthly basis.

Here are some of my thoughts on some of the ideas listed so far:

The BGE already has an interface for this, it just hasn’t been properly maintained. There have been some cleanup work in progress to get things back in their right spots.

What are you looking for? A library to handle GUIs? If so, give Bgui a shot. If you want some sort of integrated GUI editor like Qt Designer, then I wonder if Blender is really the best place to develop such a tool. It would probably be better to add a GUI editor for Bgui that isn’t constrained by Blender’s UI.

This sounds like you want a built-in state machine library for Python (this sounds too complicated for logic bricks). I think this would be better as a separate library similar to Bgui.

Not sure what you mean by this.

As mentioned, we have addons that can do this, but something built-in would probably be nice. Unfortunately, Blender’s existing particle UI doesn’t lend itself too well to game particles. Some thought would have to be put into this to make a good user experience instead of some hack.

No. Adding a second scripting language is a huge amount of work and a pain to maintain. If the BGE had a better encapsulated scripting layer, then maybe. But as it is, the code for handling the Python layer is spread through-out the whole code base. Also, what benefits does Luajit have over Python? Speed? Python isn’t the bottle-neck in most BGE games I’ve seen. If it is, there are usually optimizations that can be employed to speed things up (i.e., there is usually some poorly written code).

You’d probably have to be more specific about what this assets manager would do. For better built-in shaders, we really want to cleanup the BGE’s shader pipeline, which has been slowly been worked on. Same for inferred lighting.

You’d need to specify what you mean by “better” and “clear” for this to have meaning. Maybe give some examples.

Yeah, that could be useful. Especially for platformer games.

Could be useful, but really you’re looking for a render system specifically for terrain. Right now terrain is rendered like everything else, which causes some problems.

Which parts in particular would you like to see? I think Kupoman has mostly given up on those changes since they cause some user experience problems (too many twiddly knobs for users that require too much knowledge of the underlaying systems).

You’ll need to give examples of what is wrong with the current system and how it could be better.

These are on the way. :wink:

More AI tools could be nice if added properly.

Yay, some thing specific. These could be nice to have.

These could be nice, although a list of which animation constraints make sense in the BGE would need to be made.

I’ve gotten display lists working on shadows before. This actually doesn’t help out a lot of games since they tend to be bound by the shader part of the graphics pipeline and not getting the vertex data to the GPU. However, it would probably be good to add.

Creating lamp instances via the add object actuator isn’t exactly a “small” problem. You’d have to re-write how GLSL lights are handled in the viewport and the BGE. Or, at the very least, recompile all shaders every time a light is added to the BGE scene, which would be slow.

These sound rather game specific and can be easily handled in Python. The built-in set of animations is a bad idea. Not only would you have to have a specific rig for the animations to work, but then everyone’s animations would look the same.

This would open up some interesting possibilities, but is has a lot of issues behind it. For example, the BGE keeps track of it’s own data structures separately from Blender. If you use Bpy to change, for example, a mesh, how do we get the BGE to update that mesh? Using bpy as a read-only tool could be useful though. Another issue you could run into, is if you allow for bpy in the BGE, there could be a lot of bug reports generated around things not quite working the same in the BGE compared to using bpy with Blender. This would draw focus away from other issues to fix how a library interacts with a system it was never designed to interact with. Allows bpy to be imported in the Blenderplayer is easy, dealing with the ramifications is not so simple.

Yeah, I would like to see this become more unified. Especially as Blender makes use of Bullet already for some of it’s physics. I’d like to see the BGE dropping its Bullet integration and just going through Blender’s Bullet code.

Yeah, that could be useful. In general our tools for controlling the render pipeline could be better.

See my earlier response on asset management.

This is vague and potentially a huge task. It would be better to list out individual features you’d like to see supported in the BGE. Also, keep in mind that a lot of BI’s effects are unsuitable for real-time.