Proton SDK is an all-in-one framework solution optimized for writing games in C++ and deploying them on many platforms.

Feature list

• Engine is just source files included in the project, no separate libraries to link for debugging ease (not including system libraries like zlib and gles in some cases)
• “near zlib” free/open licensed GL/GLES optimized alternative to libraries like SDL - can be used and shared everywhere without worries
• Components designed to be modular and loosely linked, should be possible to understand and fix bugs when you find them yourself
• Created to be easy to compile on many systems, a single .mak should be all that is required, avoiding the automake/configure tools
• Device specifics abstracted out, native UI usage avoided. Games look and play the same on all devices, but you won't see the standard iOS buttons or dialog boxes in your game for example (with some exceptions, for instance, the native pop-up keyboard is invoked for text entry if needed)
• Can write raw GL/GLES code and use existing C/C++ source you have
• An (optional) entity/component system that is designed to combat “entity bloat”, subclass hell and complexity creep - an entity can be anything, an entire game, a widget, a non-rendering sound that plays every ten seconds or something that detects when the Escape key is hit

• Not one size fits all - if I haven't personally needed a feature or used the SDK in a specific way, it probably won't work right and you'll have to fix/tweak it yourself
• Not easy to use for everybody - This is a bad choice if you aren't already very comfortable with reading C++, as the code is the main documentation (hey, it's always up to date!)
• Not a one button solution for putting your games on Android and iOS. You still have to understand these platforms and get your hands dirty to release to these platforms. Otherwise when something breaks, you won't know how to fix it.
• Not every platform is supported yet. Looking for volunteers! Or, send me a device/SDK and I'll see what I can do
• Doesn't look and “feel” like a native app. For games, this usually isn't a problem. But if you are writing a spreadsheet or twitter client, this would be the wrong thing to use
• Not a full game engine, more like a toolkit. For example, you won't find built-in pathfinding or a level editor like with Novashell
• Made by one guy who isn't charging so adjust your tech support expectations accordingly

• It can be slow. It's mostly boost:signals fault.
• If you have 200 entities, you should not be using entities and components for them, you should be using one component that handles all your entities in a faster more logical form.
• It's complicated. If you aren't organized the ability to create variables and functions on the fly (and schedule same) can get out of control fast!
• The syntax is sucky. Forcing C++ to approach the features of flexible languages like lua and python just isn't a perfect solution, you'll have to decide if the trade-offs of being able to stay in glorious C++ at all times is worth it.
• The good news is you don't really have to touch that stuff at all, it's optional. But especially for GUIs it's very useful.