A Component-based GUI with Functional Flavour

An example of the GUI in use.

There are plenty of existing GUIs -- why write my own?

Two technical reasons:

1. To have a rendering back-end which is compatible with my game.
2. Limiting dependencies to SDL and OpenGL, which are widely supported.

For me, the most important reason, and not a technical one, is that whenever I look at GUI APIs my brain wants to jump out of my skull. Mind you, my own mess here might have the same effect if I were to encounter it afresh. Maybe let me know what your outside perspective is?

Oh, oh, Gooey -- or is it OO GUI?

I once believed the standard claim that OOP is natural for GUIs -- the one thing OOP might really be suited to. My initial take on a GUI in OCaml was based on objects: defining widget classes and layering complexity with inheritance. There were some issues... composition of functionality rarely works well with objects because they're wedded to internal state, and that is frustrating. But there was another pitfall lurking in the shadows. Initially a lot of details were hard-coded: font, colors, borders, etc. The day came when I wanted to control these details... A default font for everything... maybe setting another font for some group of things, and overriding that in specific cases... well ain't this a mess!

Update: Leo White, in the comments, has clued me in to using OCaml objects with the mixin technique -- which seems to offer similar composability and inheritance, but retaining the power of the type-system. I'll make a future post comparing the approaches. An early impression/summary: nearly identical expressiveness, while the differences are similar to the trade-offs between static and dynamic typing.

I'm Destined to Use Databases for Everything

(to atone for disparaging remarks about DB programmers in my past)

It didn't take too long before I realized that I want properties: arbitrarily aggregating and inheritable properties... a.k.a. components. (The component system I'm using is described here.) Well then, what if all of my "widgets" were just IDs with associated components? What would it look like?

Here's the "default font" I wanted...

  let normal_font = new_id ()
    |> Font.s fnt
    |> Fontgradient.s `Crisp

Now "normal_font" is something to inherit from: a convenient bundle of properties. If I set the Font to something else during runtime, everything which inherits and doesn't otherwise override Font will get the change.

I'll set a bunch of global defaults called "gui_base"...

  let gui_base = new_id ()
    |> Anchor.s Vec2.null
    |> Color.s (0.5,0.5,0.5)
    |> Shape.s rounded_rectangle
    |> Gradient.s `FramedUnderlay
    |> Underlay.s Default
    |> Border.s 6.

So far, these properties are just data -- mostly related to rendering options.

Next we'll use inheritance, and add an event handler. This sets up properties for a particular class of buttons:

  let hover_button =
    new_child_of [ gui_base ]
    |> Fontsize.s 18.
    |> Fontcolor.s (1.,0.95,0.9)
    |> Shadow.s (`Shadow,black,0.5,1.5,2.)
    |> Event.s [ Event.Child (hover_fade (0.8,0.7,0.5)) ]

Now anything inheriting from this, and placed on-screen, will respond to pointer "hover" with an animated color-fade. Event handlers aren't masked, so I usually keep them near "leaf" nodes of inheritance. As a silly test, I made a right-click menu for color-changing in gui_base... so everything could have it's color changed. It worked, if a bit heavy handed. Still, something like that could be useful to create a configuration mode.

You might realize by now that there are no specific button, label, or textbox widgets. Any GUI element is defined by its cumulative properties. In practice, there are convenient "widgets" which I build functions for, like this color_button:

  let color_button color name =
    new_child_of [ hover_button; normal_font ]
    |> Color.s color
    |> Text.s_string name

I'm using components with multiple inheritance, and this function creates a button by inheriting both hover_button and normal_font, as well as adding a given color and name.

Well this looks promising to me. Properties, via components, provide a reasonable way to build GUI elements, ample support for hierarchical styles, and there's no need for optional parameters on every creation function -- a free-form chain of components serves as the optional parameters for any/all creation. For example, I can use the "color_button" above, but override the font, almost like a labeled parameter:

    color_button red "LAUNCH" |> Font.s dangerfont

Furthermore, when new components are created to implement features... there's no need to update functions with new parameters. I've often been running competing components in parallel, until one is deprecated. Purely modular bliss.

Model-View-Controller... or something else?

GUIs which separate declaration, control, and behavior all over the place drive me nuts. This would be the typical implementation of a Model-View-Controller pattern which is so beloved.

With MVC, and the numerous other GUI-pattern varieties (MVVM, MVP, etc), the principle notion is separation of concerns. Each particular pattern identifies different concerns and separations. I'm usually rather keen on separation of concerns -- modular, composable, understandable, no stepping on toes. I find with GUIs that I desire tighter coupling. An extreme in this regard is ImGUI, which goes too far for my usual preferences -- with it, view is stateless and coupled to execution-flow.

What I want, is to declare everything in a stream. We can break things down into sub-parts, as usual with programming. What I don't want, are code and declarations scattered in different places, files, or even languages... held together by message-spaghetti. Using the color_button again, here's a larger GUI object:

  let framed_colors =
    let blue   = color_button (0.1,0.1,1.0) "Blue" in
    let red    = color_button (1.0,0.0,0.0) "Red" in
    let green  = color_button (0.1,0.9,0.1) "Green" in
    let yellow = color_button (0.9,0.9,0.0) "Yellow" in
    let black  = color_button (0.0,0.0,0.0) "Black" in
    new_child_of [ gui_base ]
      |> Pos.s (Vec2.make 40. 20.)
      |> Dim.s (Vec2.make 240. 120.)
      |> Pad.(s (frame (Layout.gap 4)))
      |> Border.s 12.
      |> Layout.(s
          (vspread
            [ hcenter (Id blue);
              hbox [ I green; G (gap 2); I yellow; G (fill 1); I black ];
              hcenter (Id red) ]))
      |> Event.s
          [ Event.Child (drag_size RIGHT);
            Event.Child (drag_move LEFT) ]

Layout uses a "boxes and glue" approach.

All in one, an object is declared with nested elements. It has a defined (yet flexible) layout, and responds to move and resize operations; the buttons have their own event handlers. The event handlers (as I'll get into in another post) are just functions. The point is that the composition of this is as for any typical code: functions. No out-of-band stuff... no layout in some other file keyed on string-names, no messages/signals/slots. There are events, but event-generation is from outside (SDL), so the only part we're concerned with is right here -- the event handlers.

I guess what I'm trying to minimize, is spooky-action-at-a-distance. To jump ahead a bit, when I call a menu function, it returns a result based on the user's selection (pausing this execution path while awaiting user response, via coroutines), rather than changing a state variable or firing off a message. Functions returning values.

Parts of a GUI

1. Renderer
2. Description/Layout
3. Event Handling

Oh hey... View, Model, and Controller. D'oh!

I'll go into more depth in future posts, leaving off with just a note about each...

The renderer is a thin layer leveraging the game's renderer. It mows over the GUI scenegraph, rendering relevant components it encounters. It's entirely possible for the renderer to have alternate interpretations of the data -- and, in fact, I do this: to render for "picking". Effectively I render the "Event" view, including pass-through or "transparent" events. Some details about render layers and stenciling will be their own topic.

Declaration of elements leverages "components" as in the examples given above. For layout, I've always had a fondness for TeX's boxes and glue -- I ride Knuth's coat-tails in matters of typesetting. A hint of this is in the Layout component for the box of color_buttons. I'll probably cover layout or line-splitting in another post.

Event Handling. One of my favorite parts, and a separate post: GUI Event Handling with a Functional Hierarchical State Machine.

There's something missing still...

      4.  The UI Code

What I mean is the flow of code which triggers GUI element creation, awaits user responses, and does things with them. This could be done as a state machine, but I prefer keeping the flow continuous (as if the user always has an immediate answer), using coroutines. This is yet another topic for another day.

I haven't made a complex UI, so there might be a point beyond which I have to rely on messages -- really, I keep anticipating this, but it hasn't happened... yet.

Database - radiation hazard

Now that I've shat on mutability in prior posts, let's talk about how it pervades my game code.

I'm a fan of the component model for game-objects. Basically, an object is a unique ID, and there is a database of properties associated to IDs. This isn't a disk-based database. Rather, it's an in-memory key-value store, often implemented by hashtable (though anything fitting the STORE signature can be provided).

This database is where most mutation is, hence the title of this post. So far this has been a nice fusion — functional code for the most part, with game-state held in a database. Updating/setting values in the database is typically done by high-level code, based on calculations performed by all the workhorse functions.


Components (a.k.a. properties)

Here's a character (pruned for brevity):

  let make_severin () =
    Db.get_id_by_name "Severin"
    |> Characteristics.s {int=3;per=0;str=0;sta=1;pre=0;com=0;dex=0;qik=0}
    |> Size.s 0
    |> Age.s (62,35)
    |> Confidence.s (2,5)
    |> Nature.(s human)
    |> Fatigue.Levels.(s standard)
    |> Virtue.(s [
        TheGift;
        HermeticMagus;
        PlaguedBySupernaturalEntity( Db.get_id_by_name "Peripeteia" );
        ])
    |> Ability.(s [
        of_score ArtesLiberales 1 "geometry";
        of_score Chirurgy 2 "self";
        of_score (AreaLore("Fallen Covenant")) 3 "defences";
        of_score MagicTheory 5 "shapeshifting";
        of_score (Language(French)) 5 "grogs";
        of_score ParmaMagica 5 "Terram";
        of_score SingleWeapon 3 "Staff";
        of_score Survival 3 "desert";
        ])
    |> Hermetic.House.(s Tytalus)
    |> Hermetic.Arts.(s (of_score { cr=8; it=0; mu=6; pe=6; re=20
                                  ; an=0; aq=0; au=0; co=6; he=15
                                  ; ig=0; im=0; me=0; te=8; vi=0 }))
    |> Hermetic.KnownSpells.s [
        Spell.mastery 4 "Acorns for Amusement"
          Hermetic.([FastCasting;MultipleCasting;QuietCasting;StillCasting]);
        Spell.name "Carved Assassin";
        Spell.name "Wall of Thorns";
        Spell.name "Circular Ward Against Demons";
        ]
    |> equip_and_inv ["Wizardly Robes";"Staff"] ["Small Pouch"]

Each of the modules here represents a component which objects may have. So Severin's Age is (62,35) — that is actual age and apparent age (Wizards age slowly).

The function make_severin will return an ID. The first line Db.get_id_by_name "Severin" looks up an ID for that name, or generates a new ID if none exists. Each component module has a function "s", which is the same as "set" except it returns the given ID. It's a convenience function for setting multiple component values at once for the same ID — which is exactly what's happening here, with Severin's ID being threaded through all of these property-setting calls.

This is the signature common to all components:

  module type Sig = sig
    type t
    val get : key -> t             (* get, obeying table's inheritance setting *)
    val get_personal : key -> t    (* ignore inheritance *)
    val get_inheritable : key -> t (* permit inheritance (overriding default) *)
    val get_all : key -> t list    (* for a stacked component *)
    val set : key -> t -> unit     (* set value on key; stacking is possible *)
    val s : t -> key -> key        (* set, but an alternate calling signature *)
    val del : key -> unit          (* delete this component from key *)
    val iter : (key -> t -> unit) -> unit
    val fold : (key -> t -> 'a -> 'a) -> 'a -> 'a
  end

I've used first-class modules so I can unpack a table implementation inside a module, making it a "component". For example, in the file hermetic.ml I have this:

  module House = struct
    type s = Bjornaer | Bonisagus | Criamon  | ExMiscellanea
           | Flambeau | Guernicus | Jerbiton | Mercere
           | Merinita | Tremere   | Tytalus  | Verditius
    include (val (Db.Hashtbl.create ()): Db.Sig with type t = s)
  end

Now the Hermetic.House module has functions to set/get it's values by ID. In the definition of the character, earlier, you can see Hermetic.House.(s Tytalus).


This manner of database, organized by modules, has been very pleasant to use. It's easy to create a new component-module, adding it's own types and extra functions. It doesn't need to be centrally defined unless other modules are genuinely dependent on it. In practice, I define these components where they make sense. There's no need to "open" modules, thanks to the relatively recent local-open syntax of: Module.(in_module_scope). Variants and record-fields are neatly accessed while keeping them in their appropriate module.

One of the rationales behind a component-model like this is that you can process or collect things by property. This is where the iter and fold are useful. It's easy to grab all entity IDs which have a Wound component (and is therefore able to be injured), for example.


Database

The database, conceptually, is the collection of components. In practice though, I want the components to be non-centrally declared otherwise all datatypes would be centralized as well — so instead, the database is ID management and table-instantiation functors.

First, you create a database of a particular key type...

(* Gamewide 'Db' is based on IDs of type 'int' *)
module Db = Database.Make (Database.IntKey)

The resulting signature has functions related to IDs, and table-instantiation, something like this (I've removed the generic table interfaces, for brevity):

  module Db : sig
    type key = Database.IntKey.t

    val persistent_id : unit -> key
    val transient_id : unit -> key
    val find_id_by_name : 'a -> key
    val get_id_by_name : string -> key
    val get_name : key -> string
    val string_of_id : key -> string
    val delete : key -> unit
    (* <snip> module type Sig *)

    module Hashtbl : sig
      val create : ?size:int -> ?default:'a -> ?nhrt:bool -> unit ->
        (module Sig with type t = 'a)
    end
    module SingleInherit : sig
      val get_parent : key -> key
      val set_parent : key -> key -> unit
      val del_parent : key -> unit
      (* <snip> Hashtbl.create... *)
    end
    module MultiInherit : sig
      val get_parents : key -> key list
      val set_parents : key -> key list -> unit
      val add_parents : key -> key list -> unit
      val del_parent : key -> key -> unit
      (* <snip> Hashtbl.create... *)
    end
  end

Creating a component (aka table, or property) can be as simple as:

(* A basic property is just a table with an already-known type *)
module Size = (val (Db.Hashtbl.create ~default:0 ()): Db.Sig with type t = int)

A common alternative is shown in the House example earlier, where the first-class module is unpacked and included within an existing module.


Inheritance

There are three kinds of tables which can be instantiated: no inheritance, single inheritance, and multiple inheritance. Oh, did that last one make your hair stand on end? Haha. Well, multiple inheritance of data or properties can be a lot more sensible than the OO notion of it.

The way inheritance works is that an ID may have a parent ID (or a list of IDs for multiple). If a component is not found on ID, it's parent is checked. So if I: Size.get target, then target might inherit from a basic_human which has the size (among other "basic human" traits).

Multiple inheritance allows for the use of property collections. You might see the value of this when considering the basic_human example... say you wanted to also declare foot_soldier properties which imparted some equipment, skills, and credentials. To make a basic_human foot_soldier with multiple inheritance, they're both parents (list-order gives a natural priority).

On the other hand, if only humans could reasonably be foot_soldiers, then you might be okay with single inheritance for this case — setting basic_human as the parent of foot_soldier.

Currently I'm not using inheritance for the bulk of the game, but the GUI (work in progress) is based on components and uses multiple-inheritance. This is a fragment of the GUI code, so Prop becomes the module used for instantiating components, and it also has the parent-related functions. I've included a few of the components too:

(* GUI uses multiple-inheritance (of data), so style and properties may be
 * mixed from multiple parents, with parents functioning as property-sets. *)
module Prop = Db.MultiInherit

let new_child_of parents =
  let id = new_id () in
  Prop.set_parents id parents;
  id

module Font = (val (Prop.Hashtbl.create ()): Db.Sig with type t = Fnt2.t)
module Pos = (val (Prop.Hashtbl.create ()): Db.Sig with type t = Vec2.t)
module Color = (val (Prop.Hashtbl.create ~default:(1.,0.,1.) ()):
               Db.Sig with type t = float*float*float)

Delete

It's not all roses. One big pain-in-the-tuchus is deleting an ID. This means removing every entry it has in any of these tables. To do this, when a table is instantiated, it's also registered with the database. The delete operation for any table only needs to know ID, the signature being key -> unit. The real ugly part is what this means at runtime: doing a find-and-remove on every table - every time an entity is deleted. Various optimizations are possible, but for now I'm keeping it brute force.


The Source

If you want to see the source, or to *gasp* use it, here is a gist of database.ml / mli. It's very unpolished, needing fleshing-out and useful documentation. I intend to release it at some future point, along with some other code. But if you have tips or suggestions, please share them! I've been going solo with OCaml and suspect that's limiting me — I could be doing crazy or nonsensical things. Well, I'm sure I am in a few places... maybe right here with this code!