We recently launched Pocket Pulp - check us out!
My partner and I have been working on a puzzle game over the past year, and it’s finally ready to be released!
You play as Inky, a flapjack octopus, who has been abducted by aliens and put on display in their aquarium.
It will release on Kickstarter with both physical and digital versions.
posted by Sean
I released a new tool for creating chiptune music on the Game Boy Advance, called gvsong.
The gvsong tool will take text-based music patterns and output high-resolution .wav files or even a test GBA ROM.
Here’s a song from our upcoming game, running in an emulator:
posted by Sean
In my spare time, I’ve been porting an old game Everybody Edits from Flash to HTML5.
I didn’t make the original game, I just loved playing it, and the only way to play it today was to download a Flash executable for Windows. That seemed like a shame, so I made a web version!
Play my port of Everybody Edits!
I also put gvasm on the software page, for those interested in Game Boy Advance homebrew.
posted by Sean
My partner and I took this past weekend to do a little game jam, resulting in Bombs and Blobs.
It’s a quick little puzzle game – we designed it together, then she made all the art while I coded the behavior. Enjoy!
posted by Sean
I have two updates today!
I’ve released the whisky library into the public domain. This is a library of high quality hash functions, which can be used for random number generation or procedural game development.
In pursuit of improving my own pixel artistic skill, I took a look at Batman on the NES, which has beautiful dark pixel art.
Enjoy!
posted by Sean
I announced my next project, Spook Show Studio! It’s still under active development, but you can follow along by subscribing to my mailing list.
Sorry for not updating in so long – I work full-time now, so I haven’t been investing energy into my website. Any free time has been going towards game development.
posted by Sean
Today I built a WebAudio node that generates an ADSR curve. Enjoy!
posted by Sean
I just posted a new tutorial on the FABRIK algorithm, in 2D.
It’s a wonderful and clever algorithm for solving inverse kinematics. Enjoy!
posted by Sean
I just posted a game I made back in August, As Luck May Have It.
It was a fun game to make, and I was originally saving it for a different project that didn’t work out, so now I’m making it available here :-).
posted by Sean
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 using Jekyll.
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 my mind.
Stay tuned for more updates.
posted by Sean
Sorry for lack of updates, I’ve just been working on my game engine.
If you’re curious, I’ve spent some time refining and updating Sink, my scripting language. The core language is finished and it works great.
I also just posted a new meditation:
posted by Sean
I put together a library for numeric, vector, quaternion, and matrix operations, with implementations in C99, JavaScript, TypeScript, and Sink:
Enjoy!
posted by Sean
I decided to take a small break from working on my game engine to make a stupid game. I succeeded! This game is quite stupid! :-) But it was fun, and hopefully a few people out there like it.
posted by Sean
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:
posted by Sean
I added a new tutorial, this time on NaN-boxing, which is a technique for implementing dynamic types in a language:
posted by Sean
I decided to share meditations under the About tab. I love writing, and I’ve been writing for years, so it doesn’t take much to share publically. If it’s not your cup of tea, that’s okay.
Posted a new meditation today:
posted by Sean
As a fun side project for today, I thought it would be cool to create a page where you could code an animation in sink (my scripting language), and have it output an animated GIF.
It only took a few hours of hacking away to get it to work – it’s pretty fun!
Here’s the result of the simple 19 line script pictured above:
BW Wave Example
posted by Sean
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 SCI or 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!
posted by Sean
I’ve reached a point where Sink (my latest attempt at making a scripting language) is actually usable. It’s published on GitHub, here:
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%.
posted by Sean
The previous polygon clipping algorithm turned out to fail at common cases, so I was forced to research and develop a different one:
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 :-).
posted by Sean
I had to implement a polygon clipping algorithm for my game, so I thought I might as well take the time to write an article on the subject:
(Writing an article also forces me to deeply understand it too!)
posted by Sean
I’ve been working away in C. I decided to start cataloging some of the tricks I’ve stolen from other C coders. I’ll continue updating this document over time:
posted by Sean
Had a few short stories laying around, so I figured I might as well post them. They’re under the About section.
posted by Sean
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.
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 level.
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.
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 development time.
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 looking at.
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 :-(.
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.
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:
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.
If not, I don’t know what the hell I’ll do :-).
posted by Sean
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 rendering.
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 widely supported.
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 quickly.
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:
Person Animator
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 :-).
posted by Sean
Decided to take a day to write up how Kong’s garbage collector works:
Enjoy!
posted by Sean
Kong is rendering a cube!
Kong Application
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:
kong:v1.0
import gfx.sdl, gfx.basic3d, gfx.basic3d.node,
gfx.basic3d.camera, gfx.basic3d.geometry,
gfx.basic3d.material, gfx.basic3d.mesh
sdl.Init(sdl.INIT_EVERYTHING)
var width: 640, height: 480
var win: sdl.CreateWindow(
'Hello, from Kong',
sdl.WINDOWPOS_CENTERED, sdl.WINDOWPOS_CENTERED,
width, height,
int.bitor(
sdl.WINDOW_SHOWN,
sdl.WINDOW_OPENGL,
sdl.WINDOW_RESIZABLE
)
)
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)
root.add(boxMesh)
var done: false
do
do
var ev: sdl.PollEvent()
while (ev != false)
if (ev.type == sdl.QUIT)
done = true
exit
end
end
while (!done)
b3d.render(root, cam)
end
boxGeo.destroy()
b3d.destroy()
sdl.DestroyWindow(win)
sdl.Quit()
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.
posted by Sean
I’ve finished creating my website! Yay!
I migrated the articles that I liked from my old website (smashware.com), and beefed up a few sections.
The design itself is new (obviously), and the high level pages (Latest, Creations, etc) are all new.
I also programmed some nice scripts to help me update the website easily. Creating an article just
takes writing a Markdown file, then running ./publish. Easy peasy :-).
posted by Sean
Kong (the programming language I’m creating to write games with) is done.
Well… not quite :-P. The core language is done. I have a compiler, virtual machine, and garbage collector, and together they are passing my entire test suite.
This means I can move onto library design (specifically, getting SDL and OpenGL wired into Kong), and game development.
Hurray!
posted by Sean
In totally-obvious-news, moving my interpreter from JavaScript to C has produced a siginicant speed 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 was originally thinking I might target Kong to the web, via my JavaScript interpreter… but now I’m thinking I’ll just skip that entirely, and do all the low-level stuff in C. Maybe some day in the future I’ll revisit the JavaScript stuff to see if I can make it better, but it would likely involve compiling to asm.js, which I don’t care to do right now.
posted by Sean