Once again, sorry for the lack of updates. I have a lot I need to write about and post :-).
But in the meantime, I’ve migrated the website from syntheti.cc to
sean.cm, cleaned up the look a little bit, and moved from AWS to GitHub Pages
My old system for publishing articles was eerily close to how Jekyll works (posts written in
markdown, filtered through a templating engine), so it’s been nice to use a more fully-featured
tool than maintaining my hacked together suite.
Plus I don’t have to muck with AWS anymore. It wasn’t a huge pain or anything, but it’s a load off
I posted a new project on GitHub that has C99 source code to simple audio filters (lowpass,
highpass, notch, etc).
Researching these filters has been a huge pain, but the code is really simple. Hopefully this helps
a few people out there who just want the final answer without digging through insane math and large
and ugly codebases:
23 Oct 2016
Paranoia Game Engine and Placebo Editor
Sorry for the lack of updates – I’ve been busy working.
Around mid-September I decided the best way forward was to create a game engine. That might sound a
little crazy (because game engines are usually huge and take large teams), but I’m scoping the
engine specifically for the Delusion game series.
It is not an Unreal or Unity style of engine, that is capable of making any game under the sun…
it is closer to
SCUMM. These types of engines are for fairly specific types
of games, with a lot of built-in assumptions.
I’m calling the game engine Paranoia. It will be closed source, at least for now – but people will
be able to develop games against it if they want.
I’m making an open-source game editor, specifically designed to output games for Paranoia to run,
and it’s called Placebo. It is still very early in
development, but it’s moving nicely.
Placebo Room Editor
I’m currently hoping to have a workable Paranoia+Placebo codebase by the end of the year, so that I
can start creating episodes for Delusion beginning January 1st. As I create episodes, I’ll keep
updating and improving both products. By the time I launch Delusion, they should be ready for
other people to use as well.
Sink is the primary scripting language used inside both products, so I’ll be updating that as time
goes on too!
I want to take a moment to talk about how terrible I am at estimating how long I need to finish
something. I don’t think this problem is strictly a personal failure – most programmers are quite
bad at making estimates – but it certainly feels like a personal failure :-).
On July 19th, I estimated I only needed 14 work days to finish Sink. Instead, it took me 24 work
days. That’s an error of 70%.
On July 19th I also estimated I have 122 total days worth of work until my game engine is complete.
That meant I could finish my game engine by the New Year. If my error rate is consistent, that
means it will instead take me until May of 2017. That is a serious problem.
It’s something you consistently hear from other game developers, because it is true:
Game development is hard. It takes significantly longer than you expect. Cut your features by 75%
and extend your project schedule by 200%.
Sorry for the lack of updates – I have been working hard, and updating the website takes time away
from building my tools and games. The latest article also took a long time, with lots of false
starts and frustration, but it’s done now :-).
I’ve been experimenting with ways to generate quality content quickly.
Delusion, the game series I’m working towards, is based on the idea of releasing weekly episodes
like a TV show. I want to maintain the pace of producing one episode per month – I am roughly
estimating having three seasons per year, where each season is four or five episodes.
In order to do that, I need to be able to produce content quickly.
Attempt 1: Blender
My first attempt was to model everything in 3D, using Blender. Here’s the start of a level:
Attempt 1: Blender
I think I spent roughly 3 hours modeling the desk and computer. It would probably take me another
6 hours to texture map it. That means for 1 day of effort, I would be roughly 2% done with the
In order to fit this technique into 24 days of labor, I would need to use a lot of canned content,
cut my levels in half, and basically do nothing else except model and texture the entire time.
So I gave up on 3D modeling the levels. Not fast enough.
Attempt 2: Pixel Art with Filtering
My second thought was: maybe I could do pixel art? Lots of indie developers use pixel art.
I spent some time mucking around with pixels, and thought the only real way I could get away with it
was if I produced really low resolution pixel art. The lower the resolution, the faster the
So maybe I could cheat my way to higher resolution?
I created a filter for upscaling pixel art in real-time, just to see what sort of quality I would be
Here is someone else’s art running through my filter:
Before Filtering / After Filtering
Not bad… I guess.
Here’s my art running through the filter:
Attempt 2: Pixel Art with Filtering
Boy, that looks like crap :-(.
Attempt 3: Vector Art
It seemed weird to be spending time manipulating pixels to get certain shapes out of the filtering
process. Can’t I just input the shapes directly?
So, now I am attempting vector art.
But I had a little idea at the same time.
I’ve been working on another programming language I call Sink (because making programming
languages is a time sink :-P).
I know I need a simple language in order to do scripting inside the games – I could use Lua, but I
don’t really like Lua all that much. While working on Kong (my old language, that I eventually
ditched after 7 months of development), I had an idea for a much smaller language.
Sink is extremely simple. The first full Kong compiler was roughly 9,000 lines of code. Sink’s
compiler is 2,000 lines of code.
Kong has 12 types (void, null, bool, num, str, blob, code, list, map, handle,
task, worker). Sink has 4 types (nil, num, str, list).
I took 5 months to create the Kong compiler. I took about 4 days to create the Sink compiler.
Sink + Vector Art
Since Sink is done, I thought it would be cool to make a vector art program with Sink embedded
inside of it:
Attempt 3: Scriptable Vector Art
There are some reasons why I really like this idea:
I can write programs that create art. Nearly all other techniques involve manual creation of art
from start to finish.
Programs are powerful. I can store colors in variables, calculate geometry, create functions,
etc. This (hopefully) translates to speed of creating content.
Text programs are easy to store, diff, track, change, etc. Binary image formats – not so much.
Vector art has infinite resolution.
The editor in the screenshot above is actually pretty cool too – I can point to things in the image
and push a button to have the coordinates pasted into the script on the right side. I can highlight
any color and use a color picker to change the values in the script.
So I’m going to be using this for a while and see if I can produce content quickly with it.
I had to make a difficult decision about 3 weeks ago. I gave myself 6 months, from July 2015 to the
New Year, to make my programming language, Kong.
I worked on it the entire time, through several major refactors, and had a pretty solid product by
January – but it wasn’t complete. I spent another month trying to fill the holes, and had a cube
The problem was the speed.
It just isn’t fast enough for game development.
So, all wasn’t lost: I knew of a lot of ways I could speed it up. I could rework the virtual
machine bytecode, to make it more efficient for execution; I could write a partial JITer; I could
write a Kong-to-C transpiler, or an LLVM backend, etc.
But I was out of time. My next deadline for having a game developed is only a few months away, and
my first experimental changes to Kong would take another 2 months. And then, what if it still
wasn’t fast enough? I would be way over schedule without any games.
So I ditched it.
One good thing about writing the VM in C is that I became really comfortable with C. I used to
program in C++ a long time ago, and I had spent most of December and January working on the VM in
C99, which is a pretty nice language, all things considered. It’s much better than C89, and is
What sucks is that I’m basically throwing away 6 months of work, and giving up on the dream of
creating a programming language – at least, for now.
I didn’t make the decision lightly, but I also didn’t really have a choice. I could let Kong
consume all of my time, and never ship a game, or I could let it go, and focus on game development
on a proven platform, C.
So, starting around February 15th 2016, I chucked the majority of my codebase, and started over,
using pure C.
The bad news is that I’m behind schedule (and if I had skipped Kong completely, I would be
ridiculously ahead of schedule!). But I’m not that far behind, and I’m making up ground pretty
And instead of meditating on how to improve the Kong codebase, and how to speed up compilation, and
how to speed up the garbage collector, or speed up the VM execution: my focus is now (correctly!) on
how to make a game.
I’ve learned Blender, and have a pretty cool setup so far. I’ve written around 8,500 lines of code
the past 3 weeks, and have the start of an animation engine:
What’s nice too is that I can now post a lot of screenshots of my progress, since I’m working on
graphical things, and not compilers :-).
Follow me on Twitter @velipso to see random screenshots as I do
actual game development :-).
I know it doesn’t look like much, but at this point, it’s more about how that cube is being
rendered, rather than the impressiveness of the cube itself :-).
Here is the code:
import gfx.sdl, gfx.basic3d, gfx.basic3d.node,
var width: 640, height: 480
var win: sdl.CreateWindow(
'Hello, from Kong',
var b3d: basic3d.new(win)
var root: node.new('root')
var cam: camera
.newPerspective(num.tau / 5, width, height, 1, 1000)
.position(10, 10, 30)
var boxGeo: geometry.newBox(10)
var boxMat: material.new()
var boxMesh: mesh.new(boxGeo, boxMat)
var done: false
var ev: sdl.PollEvent()
while (ev != false)
if (ev.type == sdl.QUIT)
done = true
If you don’t recognize that language, that’s because it’s my language :-).
It took a lot to get to this point… and I still have a lot to go. But this is where I am today.
boost: 40x faster.
There is no garbage collection yet, so I’m just allocating and leaking like crazy, but it’s nice to
know the magnitude of the speed jump.
I’m thinking I’ll just skip that entirely, and do all the low-level stuff in C. Maybe some day in
involve compiling to asm.js, which I don’t care to do right now.