From BlenderWiki

Abstracting the Blender Game Engine Interface

Koay Zi Hao (email) alexkoay88@gmail.com (irc) n0va

Synopsis

   * Objective
     Decouple the Blender game engine from its logic brick concept
   * Method
     Implement a lower-level event callback API that replaces logic bricks, actuators and sensors as the logic layer, and subsequently exposing this functionality to Python.

Benefits to Blender

   * Logic without logic bricks
   * Alternate logic editor interfaces 

Having an lower-level API devoid of the various small details of the logic bricks would allow for logic scripting entirely in Python, or any implementation that interfaces with either C or the Python API or both. This also paves the way for entirely different editors, namely the nodal logic editor (http://wiki.blender.org/index.php/Dev:Source/GameEngine/ NodalLogic), to be implemented upon the API instead of mucking around with logic bricks.

Deliverables

   * C/C++ API
   * Python API
   * Logic brick rewrite (optional, if feasible) 

First of all, the completion of this project requires the C/C++ interface to be completed. These functions will be exposed to Python, allowing it to be used directly in logic scripts. This would be the most apparent user-level feature, as any clear benefits from the C/C++ API will emerge only after the completion of the nodal logic editor. Finally, it would be good if the logic bricks could be rewritten to use this new API as its base, so that future maintenance/bug-fixing can be done in only one codebase, and also as a proof that the new API has feature parity with the logic bricks to help the transition for current users.

Project Details

The idea for this project was contributed by Benoit Bolsee, the lead developer working on the nodal logic editor. In order for nodal logic to function, a new API that is detached from the logic bricks is required.

As we know, Blender has a very powerful game engine that can be used to develop any game under the sun, making full use of Python’s scripting abilites. However, the engine has a very large drawback: it requires a lot of mucking about with the logic brick editor to get anything done. This unfortunate situation prevents the game engine from ever realising its true potential, as the flow of logic cannot be easily visualised when the game gets slightly more complicated. I believe this drawback is due to a design choice at the beginning, that is designing the game engine about the logic bricks.

This project aims to separate the game engine and logic bricks. This provides two-fold benefits. In the short-term, advanced scripters thus work with only Python, and no longer need to deal with logic bricks. In the long run, this allows developers freedom of choice to use whatever editor they want to create game logic with. This would become more evident after the completion of the nodal logic editor. Another possible alternative could be a Python interpreter for Lua scripts.

Presently the logic brick paradigm consists of the sensor-controller-actuator relationship, along with a property manager that is present only in every object. I propose that this paradigm be replaced with a logic manager that consists of both a property manager, and an event callback manager. This logic manager would then be present in every level of the .blend file: the root, scene, object, and recursively in its children.

A property manager at the root level allows variables to have longer lifetimes, enabling data retention across different scenes, similar to global variables would in normal programs. The scene level property manager on the other hand can facilitate value passing across objects.

The event callback manager is responsible for notifying functions of the firing of a particular event, for instance, keyboard input. Having this at all levels as well allows for event bubbling, permitting a broad handling of events in general cases, and replacing them with more specific handlers where necessary.

As such, the logic manager would cover most of the functionality that the sensor has, and introduces more powerful mechanisms to handle them. Secondly, I propose to not have any implementation of controllers in the API. Controllers are actually simply conditional expressions with a lot of limitations. Thus, it would be far better that such behaviors are implemented with native conditional expressions.

Lastly, actuators are replaced with callback functions that are registered with the event callback manager at their respective levels. The existing actuators would be ported to Python as standard actuators, while new ones can be scripted by developers themselves. To facilitate the coding of the actuators, I predict that a lot more of the properties and methods in each of the classes will have to be exposed.

Project Schedule

   * First week– Exploration of different interface solutions
   * One month– Coding the lower-level interface, logic brick re-implementation
   * One month– Python API for the interface
   * Last two weeks– Systems testing and final touch-up.
   * Testing and documentation is done parallel to the coding

I intend to take the first week or so to explore variations of the interface, to enable a minimal and concise structure. Before the mid-term evaluations, I expect to be working on coding the lower-level interface and implementing it in logic bricks. After that, I think the work should then shift to exposing these functions to Python. I am planning to allocate about one to two weeks to do systems testing, making sure that everything works fine as a cohesive mesh. Also, during this time, I aim to do some final touch-up to better present the work.

   * May– Finals until the first week of May
   * July– Orientations and extra-curricular activities throughout the month (estimated down-time: 10 days)
   * August– School resumes

I will be having my finals up till the first week of May. In this period, I doubt that I will be able to produce any code, as I do have to concentrate on my studies. I have set aside May and June for most of the work. In July, I will be attending and organizing orientations and fairs for the incoming freshmen, and might not be available all the time. However, the events are short and few, so I do not think that it will affect my participation that much. School resumes in August, and I think that while I can still code, the amount that I can produce during that period will be much lower.

Biography

My name is Koay Zi Hao, but most people call me Alex. I come from Penang, Malaysia. However, I am currently studying Computer Engineering (B.Eng.) in the National University of Singapore. I enjoy puzzle-solving, math, and programming, reading, gaming and most intellectual pursuits. Game design is something that fascinates me very much, and I have been dabbling in producing games for almost a decade now.

I have used Blender for a game design module in the previous semester, where I created a complete game using the Blender game engine. Before that, I have looked at Blender once in a while, but did not use it extensively. I am currently taking a computer graphics module this semester, and I have experience coding in both OpenGL and DirectX. I started coding a game engine back in 2004 but stopped halfway due to design issues and a lack of time.