Hello, I'm interested too. I'd like to share my short experience in the domain. I've implemented a command line system before that I, too, use in video games implementations. The one I wrote at the time might have big design flaws, but at least it was easy to set custom outputs. (example: http://www.youtube.com/watch?v=VHFu6q1twtE ) The design was basically: - some functions insert inputs (taking characters or strings, manipulating the cursor position) - some virtual pure functions to implement the output rendering: in the video, it generate a javascript expression, send it to an embedded browser that will display on the 3D texture you see flying - that is in fact a web page. It is the third output rendering I've wrote using the same console base class, the first was simply standard output, the second was raw font rendering on some 3D textures (but it was slower than the 3rd solution). - some functions to add/remove "commands" that are the "applications" available to the console instance (I use several different consoles, like in the video) - a special mode that allow a command to be "modal"(I can't find a better term), meaning that the command will keep getting the inputs until it shut down, without having to loop inside the command code - to allow rendering to still happen. Having an implementation better designed and reviewed by boost people might be more reliable than my current code (that I already tagged as to be refactored - this version is opensourced online but I don't think it's good enough to check it). About the swig/boost.python thing, one thing to understand is that command line don't work like a programming language. You don't use it for the same purpose, even if it's tempting to just let a scripting language as the implementation of the console. For example you might not want command line to be able to create/destroy objects. If you do, it's far better to plug your scripting language inside your console as a command/application like I did. It's far more extensible this way. In the video, I used Falcon (http://falconpl.org) as a scripting language. I could have used any other language (Lua, Python, ChaiScript) without changing the console class. I could also have added several other scripting language, as they are only commands/applcations from the console point of view. I plan to have different consoles for different contexts in my current game, and different commands to manipulate different scripting language VMs. So I don't think it's a good idea to plug directly a specific language inside a console. About the interface, I'm not sure if a command should be defined only by a simple std::function. I've tried it before but I wasn't able to make it work as more information were required. My 2 cents. Joël Lamotte