Skip to content
Cross-platform gaming kit in the D programming language
D Shell Other
Branch: master
Clone or download
ikeycode context: Code style cleanup
Signed-off-by: Ikey Doherty <>
Latest commit e4572ea Nov 9, 2019

Serpent Game Framework


A game framework from Lispy Snake, Ltd.. This is not exactly an engine.


This is very much a work in progress and will continue to change daily. As such the document provides a rough roadmap and vision overview. Note this is a restart of efforts after our lispysnake2d repo (also public)

Do note that we're initially only focusing on Linux development, with a strong bias towards Vulkan. After some initial stability begins to appear, we'll focus on OpenGL, then other platforms such as Android, macOS (Metal) and Windows (DX/OpenGL/Vulkan).

Whilst we develop, it will appear we're developing a mini game in-tree. This is to help steer direction of the project. Eventually however we're looking to build more of an SDK out of the core serpent runtime and associated tooling, to help others very easily build their games.

Support Development

This framework is being developed by Lispy Snake for our first games. While we would love to develop it full time, basic economics says we must reinvest any contract-work revenue to support development in any remaining time.

To accelerate development (and time-to-market) for our framework and first game, consider buying a Lifetime License from us ($20!) to have lifetime access to our games.


We build serpent with the ldc2 (LLVM-based) D compiler. To test the included demo, build the demo subcomponent in release mode.

git submodule init
git submodule update

Note you will need to have serpent-support built in a directory parallel to this checkout. This is a bit janky but we're focusing more on code right now than the runtime support project. Building it will enable components such as bgfx.


Please note any modifications must be hygienic - compiling with neither warning nor error. Additionally you must have run to ensure consistent code-styling before sending in changes.

Design Considerations

Provide the best possible functionality required for simpler 2D games at minimal technical debt, both for us, the framework developers, and you, the library consumer.

Our previous engine implementation was an all-inclusive engine written in C with a WIP rendering pipeline. Long story short, way too much debt for us and for new users.

D Language

Whilst some may argue the merits of D, we've found it perfectly suited to our game development requirements. Consider the built-in concurrency support when dealing with batches of SOA entities.

Additionally, we wanted to avoid a few pitfalls (despite being C lovers)

  • String issues (\0, mutability, UTF..)
  • Forced to reinvent all the wheels (to avoid linking to beastly opinionated refcount libraries)
  • Time to market. It hurts.

Cross-platform support

We need to support, at minimum:

  • Windows (Vulkan/OpenGL)
  • Linux (Vulkan/OpenGL) & X11/Wayland
  • Android.


The framework simply wraps a bunch of libraries together, and provides utilities to manage the game loop and do stuff. Thus, we'll provide utilities for lifecycle management and actually loading/drawing stuff.

2D Focus

We want to disguise the pipeline under a 2D front. This framework is currently designed for 2D games, that benefit from an accelerated 3D pipeline. To that end, we'll make it possible to make awesome 2D games with UIs, sound, tiling, etc. But you can still get slick bloom shaders..

Reuse Where Possible

Where it is feasible we will reuse other projects to save us from significant technical debt, such as rendering pipelines, etc.

Below is the current list of projects we know we WILL reuse. This may be subject to modification.


We will reuse bgfx / bimg / bx projects for our rendering pipeline. This will allow us to support all relevant graphical subsystems. The project also has a super modern architecture which allows us to just expose it to consumers so they can basically do anything they want.


We'll use SDL for our basic windowing, OS integration and input handling. This allows consumers to leverage the advanced controller support found within SDL (some would say a USP).

Newton (??)

The downfall of many a framework is to needlessly reinvent physics. We plan to integrate a proven solution. Currently we're checking some numbers and will revisit physics integration in the near future.


Need decent sound, right?

Invent Where Unavoidable

Some areas we're going to be forced to do a small bit of reinvention. This will involve basic UI support in the framework, primarily because the main available libraries are explicitly locked to OpenGL. We very much need to support OpenGL and Vulkan.

You can’t perform that action at this time.