As a longtime user of the Blender game engine, I have become well aware of its various strengths and shortcomings. I do not believe that the current game engine was designed with the requirements of complex modern 3D games and simulations in mind. I do believe that there is a certain niche accommodated by the Blender game engine in its current state, but large projects in the engine quickly become cumbersome and incomprehensible, with numerous logic bricks and Python scripts and no way to organize them or visualize a hierarchy of their interactions.
I propose an alternative, cross-platform (Windows, Mac, Linux) game engine designed specifically around the requirements of modern games, and released under an open-source license. There will be an exclusively graphical programming environment; my experience with National Instruments’ Labview software has lead me to believe that a correctly implemented graphical language renders scripting extensions unnecessary. It will be completely object-oriented, with code reuse a top priority. Polymorphism, inheritance, and virtual functions will be supported. There will be functionality allowing classes to be exported in an independent file format so they may be shared with other users. This way, common functionality such as FPS cameras, path finding, and object selection can be written by various users and uploaded to an online database, thus saving a large amount of time typically wasted by developers implementing features that others have written hundreds of times before.The idea is that developers can produce commercial, closed-source games but still contribute back to the community certain elements that could be useful to others.
The implementation itself will retain the dataflow programming paradigm to some extent. There will be a class browser with a hierarchical view. Each class will have a property sheet defining local member variables, with a static option, à la C++. All of the typical built-in types will be implemented. Member functions will each have a discrete inputs and outputs. On the block diagram (programming space for functions), users will have the ability to access any member variables and instantiate local objects that will be destroyed when the function exits. All class instances will be passed by reference; member functions will be like traditional function blocks but will need the class instance wired to them as an argument. The concept of passing data through a sequence of functions on “data wires” can be difficult to understand for a traditional text-based programmer, but it quickly becomes intuitive.
The language will be integrated with the development environment. In addition to the programming space, a 3D view will be provided. It will allow for translating, rotating, and scaling in-game objects and will provide a viewport to immediately test the game. Movable 3D objects will be referred to as scene nodes, and the 3D view will allow the user to grab a handle to them in the code, along with visually managing node relationships in the scene graph (parents and children). The 3D view will also contain an interface to the state manager, allowing easy implementation of different game/menu states. There will be a fully-featured GUI layout manager for easy creation of menus.
I have already developed the basic 3D framework behind this system. It makes use of numerous open-source libraries, including Ogre3D, MyGUI, and Bullet Physics (<333 bullet!). It also contains preliminary artificial intelligence functionality, including path finding and steering through OpenSteer. I intend to make use of more open-source libraries in the development of the graphical environment, such as wxWidgets and Cmake.
I am a programmer, musician, artist, and *nix geek. I’ve been using Blender since version 2.28 for both 3D rendering and game creation. I have experience developing games, websites, and scientific applications in a variety of languages. The main problem I face when creating games is that I am forced to waste huge amounts of time developing functionality that has been done countless times before, but due to the closed-source nature of games has never been released. Oftentimes released code is incomprehensible, and is far from the plug-and-play solution that I wish to achieve with this proposed software.
I’m looking for criticism or suggestions on my ideas here, as I’m sure there are a lot of people on these forums facing the same issues that I am. Also please keep in mind that I love the Blender game engine and have used it to create lots of games. My latest game is in RTS (like Starcraft), and creating a game with that level of complexity in the Blender game engine is impractical, if not impossible. I strongly believe that there is a segment of people who wish to create complex games, but not have the time nor the resources to code hundreds of thousands of lines of C++ code, and this is the segment of people that I’m attempting to accommodate.
Also, I know this isn’t directly related to the Blender GE so I’m sorry if I’m in the wrong place, I’m just trying to reach people similar to me so I can get feedback on my designs. And if you read all of the above, I heartily thank you for your time.
TL;DR: I’m writing a game engine that you program graphically like the Blender GE. Give me ideas or tell me if you think this is stupid.