From BlenderWiki
Original Proposal: BGE - Cleanup & Support
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 this moment, there are 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:
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 and improve the code so as to prevent new ones and make it more ready to start the process of making the game engine not-separated. This proposal should also result in a document with an overview of current problems and a ToDo list to function as a roadmap.
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 to the upcoming integration
- 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 2 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 more feasible goal and, besides the immediate benefits, would result in a much better insight on what needs to be addressed to accomplish the GE integration both for me and for those involved in the project (my mentor, at the very least).
Breaking it down, this proposal includes:
- bugfixing & support
- overview of patches waiting review and existing branches
- document the existing problems into a roadmap/ToDo list
- There is a previous list that should be incorporated and descriptive commit messages with explanations and ToDos that shouldn't be lost (ex: text objects commit)
- review feature, user and python interface consistency
- cleanup of functionality/code areas
- Besides the regular practices, orphaned comments and commented code should be gathered and 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.
- As a bonus, I expect to remove scary comments like the following one, before their 4th birthday :P
source/gameengine/Ketsji/KX\_WorldIpoController.cpp:52:45441c07 (2010-04-18 09:12:18 +0000) /* TODO, this will crash! */
Project Schedule
I plan to get up to speed by fixing bugs until the program's official start. Then, a complete review of the tracker is in order, including open tasks. The process should result in a survey of existing bugs and patches needing review, broken down into categories, related issues, quick-fixes and non-quick uncovered problematic zones of functionality/code. All tasks pending on user response will be bumped so they can be solved or closed.
On the following weeks, the resulting overview can be used to direct the work. This type of proposal allows easy replanning according to on-the-go priority assessment. With about 60 days to work on the program (excluding the 1st and last week), the bug count alone would yield a rate of 4 bugfixes per day. Knowing that most bugs are stalled because they're not easy-quick fixes and also considering patch reviewing and cleanup, I foresee more than enough work for the given time.
Line-up considering 14 weeks:
- (i) bug fixing
- (1) tracker review resulting in an overview of troublesome areas
- (2-5) bugfixing and cleanup
- (6) mid-term, new tracker review
- (7-12) bugfixing and cleanup
- (13) tidying up, have document with engine roadmap and ToDo list ready
- (14) firm pencils down and final evaluation
