mud is a general purpose c++ library for rapid development of live graphical apps and games.
mud is made of 6 small libraries/modules intended to be usable independently:
- immediate declarative UI and declarative graphics blocks to bootstrap interactive applications in a few lines of code.
- lower-level c++ reflection, serialization, scripting, and ui inspection blocks generically extend your c++ code.
- additional components include a visual scripting language, and a physically based rendering add-on
Try some live examples in the browser (full description after the break):
Links: github - official page - twitter - patreon
mud contains all the essential building blocks to develop lean c++ apps from scratch, providing reflection, low level generic algorithms, an immediate ui paradigm, and an immediate minimalistic and flexible graphics renderer.
mud aims to provide the quickest idioms to build functional and lightweight c++ graphical applications. It tackles the problem of the code you don't want to write, and should not have to write when prototyping an app. One core principle in mud is : don't repeat yourself: we take this aim very seriously and we believe it's a principle that is way too often disregarded.
mud consists of a set of 6 small, self-contained libraries rather than a single one: 6 building blocks essential to prototyping any c++ app.
The first set of blocks, consists of low level c++ programming tools, which purpose is to avoid duplicating code over and over, by providing generic algorithms instead, operating on generic objects. Their purpose is that ideally, each line of code you have to write is only concerned with the problem domain you are trying to solve, and not lower-level auxiliary concerns.
Three low-level generic c++ blocks in mud rely on applying generic operations on arbitrary types:
- reflection of any c++ code to a set of generic primitives
- generic serialization of any c++ objects to any format (currently json)
- generic script bindings for any c++ objects, methods, functions, seamlessly, and a visual scripting language
Two blocks consist of the the interactive/graphical foundation of an app:
- immediate/declarative UI to draw skinnable, auto-layout ui panels in few lines of code
- immediate/declarative graphics to render 3d objects in a minimal amount of code
The last one ties the ui and the generic c++ blocks together:
- generic ui to edit and inspect c++ objects, modules, call methods, edit text and visual scripts
mud stems from a strong programming philosophy: it wagers that the future of application and game coding lies in small, self-contained, reusable and shared libraries, and not in gigantic tightly coupled engines of hundreds thousands of lines of code.
For our shared knowledge and our programs to progress, the building blocks have to be small and understandable by most (which is essentially the same thing). There are many such blocks already in many domains (network, pathfinding, database, graphics).
I started writing mud because I discovered some of the blocks I needed were missing. The common thread between these blocks, is an unrelenting thirst for simplicity. With the building blocks mud provides, one can create live graphical apps in few lines of code, but also, anyone can potentially create a game engine.
mud is open-source, and published under the zlib license: as such it is looking for sponsors, funding, and your support through patreon.
In theory, mud compiles to any desktop, mobile or web platform, mud graphics relying on the bgfx library which supports them. In practice, there is some work ahead to make that happen and refine the build system for each of them.
To be able to quickly together c++ apps, but also for educational purposes, the following blocks needed to exist in the open-source ecosystem:
- a small generic c++ layer (< 5 kLoC): c++ primitives that allow manipulating generic objects at runtime, and precompilation of any c++ code to an initializer for these primitives.
- a small generic serialization layer (< 1 kLoC): serialize generic c++ objects from and to different formats. mud does only json (and previously sqlite), but some binary formats like flat buffers should be studied (although they usually have their own code generation).
- a small generic scripting library (< 3 kLoC): manipulate generic c++ objects through scripts. all reflected primitives: functions, methods, members can be used seamlessly. mud does only lua, and a powerful graph based visual scripting language.
- a small UI library (< 10 kLoC) that does: immediate-mode widget declarations, logic/layout/styling separation, fully automatic layout, css-like skinning, image-based skinning, style sheets, input widgets, docking windows and tabs, allows to define complex widgets easily.
- a small graphics library (< 6 kLoC): immediate-mode rendering graph declaration, with the following basic primitives: meshes, models, shaders, programs, materials, skeletons, animations, render targets, filters, render passes, render pipelines. It is minimalistic in design, and is NOT a game engine nor does it try to be.
- a small ui inspection library (< 3 kLoC): generic ui components: inspector panel, edit an object fields, call a method on an object, inspect an object graph/structure, all these are generic ui components operating on the reflected primitives.
- a small pbr rendering model (< 4 kLoC): a sample implementation of a physically based rendering model for the above graphics library, demonstrating it can be simple (it's the research behind that is complex).
In each of these domains, simplicity and DRY is always favored over other concerns: performance, for example, is only ever considered under the prism of global simplicity and conciseness. If a performance improvement involves obscuring the mechanics of the system significantly, it is not even considered.
To get a more in-depth look at how using these features looks, in code, you might want to have a look at the main page of the github repo.
The building blocks are just starting to fall in place such that writing mud c++ apps feels thrilling and liberating in its simplicity. That means, I believe, the moment has come to start communicating about this project in order to, if anything, get collective help into pushing it to maturity: there are still many aspects to improve and flaws to iron out. With proper support, I believe a first stable release could happen before the end of the year.
Creating mud has been a huge time investment over the course of a few years: the only way I can pursue that effort and make it thrive into the programming ecosystem of our dreams, is through funding and sponsorship: you are welcome to have a look at our patreon.
Feature-wise, most of the core features are in place, the remaining work being to improve robustness, error-handling, fix bugs, add more platforms. This leaves an open roadmap to investigate more advanced graphics topics: real-time global illumination, clustered rendering, distance field shadows. But these are all just slightly outside the scope of mud, so they might come as extensions.
And then, of course, there's a game engine. More on that in a few weeks :)
If you are interested in following the development, it's mostly on my twitter.
If you want to try it, you can just clone the sample github repo, or check out the main repo.
If you want to learn about how it works, check out the documentation and the quickstart guide.
And once again, if you want to support it, mud has a patreon.
Aside from polishing the existing examples and documentation (as people start using the library and opening issues), I will spend the next few weeks adding new samples to demonstrate how simple applications can be built with mud, and posting articles to go more in-depth concerning the different topics that mud covers.
So stay tuned !