From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Reviewed Proposal v1: BGE - Cleanup & Support

This is the most recent version (30/May/2014).

See the Original Proposal


Synopsis

This proposal targets some of the currently identified problems with Blender's Game Engine. These issues include a high number of unsolved bugs, bad consistency of the user and python interface, lack of support and maintenance and poor performance for now-a-days standards. All these were acknowledged in Blender's 2.7/2.8 roadmap, along with plans for better integration of the GE as an interactive mode.

This proposal aims to be a first step in that direction by addressing the bug tracker and known problematic parts of the GE.

By the end of this program, the results should be: less bugs and pending patches, parts of functionality/code more suitable for integration and less prone to more bugs, happier users, and a document identifying problems that need to be addressed next.


Motivation

As of the beginning of this project, there were 217 open bugs in the game engine's tracker, some of them years old and some of them with no response for the user. Others actually have patches submitted for them, but they were never reviewed, making a total of 41 unreviewed tasks with generally more than one patch each. All this gives the users and the interested developers a sense of abandonment and lack of support. The module owners page shows modules with no owners, inactive developers and developers whose main focus is elsewhere.

The game engine did not undergo the massive redesign as of v2.5 and, thus, still has the 90s design and an old and patchy code base that is separated from the rest of Blender. The GE has been drifting away from main blender, not taking advantage from existing and planned features such as generic improvements, optimizations and all kinds of functionalities.

The separation and old design has an impact in the user and python interface. As an example, consider the following image displaying the World Panel for Blender Internal, on the left, and for the Game Engine, on the right:

Brita-GSoC2014-proposal-world2.png

Notice that, although some things will always be engine specific, there are a lot of features missing in the GE relative to BI. The consistency problem is also evident in the interface for the mist functionality. Furthermore, the python API has the same kind of problems. In this mist example, controlling the settings as if from the world panel and as it would be done in BI, does not work:

bpy.data.worlds['World'].mist_settings.*

There are a few specific functions, such as

bge.render.setMistStart( 5.0 )

that should cover this functionality, but barely work: the properties in the panel are not used by this set of functions (if only the above command is used, the result will be a solid yellow everywhere independently of the BG color, etc), only 'start', 'end' and 'color' can be set through python and the results are not very predictable. There are a series of patches (D12, T37492) that address these and other mist problems, but they're only half reviewed.


Benefits to Blender

This proposal aims to provide the currently missing and needed support, giving first priority to the users that invested in the game engine and then to the interested developers. By providing them better conditions, these developers can support users and the GE as well.

The project would help bring the interactive part of Blender to the expected standards of the rest of Blender and other real time engines. It would be a first step to put BGE back on the map.

Finally, the project should also have an up-to-date document with the current problems and ToDo list as an outcome. The purpose of this document is to help the future integration process of a component that is so important to Blender and many of its users.

In short:

The goal is to considerably reduce the number of current bugs, review the design issues and improve the code so as to start the process of making the game engine not-separated for the 2.8x series.


Deliverables

  • bring down the bug count
  • clean up some parts (code/design/python API/interface) so that they are more understandable, less bug prone and more ready for the upcoming integration
    • initialization of the bge python module and submodules
    • consistency of the properties panel
  • document existing problems producing a roadmap/ToDo list


Project Details

With this proposal, I don't mean to re-design and re-implement BGE completely in 3 months. That would not be a reasonable time-frame and I would be totally out of my depth. What I propose are more shallow cleanups with focus on better organization, readability and integration. This is a feasible goal and, besides the immediate benefits, would result in a much better insight on what needs to be addressed next to accomplish the GE integration.

Breaking it down, this proposal includes:

  • bugfixing & support
  • overview of patches waiting review and existing branches: previous overview
  • document the existing problems into a roadmap/ToDo list: page being worked on
  • cleanup of functionality/code areas
    • Besides the regular practices, orphaned comments and commented code should be removed if possible. By this I mean commented code with no explanation and outdated, forgotten comments, because these really difficult code readability. If the reason for the comment no longer stands or is long lost, the comment can not be understood and it should be dropped, if it is a ToDo, it should be included in the document.


Project Schedule

The planning roughly lines up as bug fixing and triaging (there are many duplicated and invalid entries in the tracker) while documenting while documenting all design issues. Later, some contained areas may be picked for cleanup.

  • 1st week: bug fixing and triaging, adding categories back to the bug tracker is important (T37522). Connecting with mentors and stakeholders. I will be mainly unavailable this week.
  • 2nd week: setup documentation. bug fixing with focus on VideoTexture bugs and proposal reviewing. I will only be available as of half the week.
  • 3rd - 5th week: bug fixing and documentation of existing branches and design issues.
  • 6th week: (midterm) new review of the tracker and the proposal, including planning and goals for the second part.
  • 7th - 13th week: i will define clearly later, for now only generic bugfixing and cleanup is defined
  • 14th week: (firm pencils down) wrapping up.