#despair engine

[kyleondemand]

DEM Cube

my Blender Exporter result

[kyleondemand]

Dev Update to Despair Engine

1. Uh.

So, haven’t touched it. Truth be told I’ve been enormously busy with day job related work matters and several offline life related matters, I haven’t even TOUCHED my computer in a week.

The blender exporter is my top priority for this project. If nothing else comes of this, a custom model format is something I want to be proud of accomplishing,

But I’ve also been passively looking into how I’d like to author the dialog database.

Waaaaay back like 400 years ago, when Flash was still popular I made a little thing called “CourtEngine”, which if you’re so inclined can see footage of in action here

That’s right, this isn’t ya boi’s first rodeo with visual novel engines.

Anyways, this little flash program would read an XML file for the dialog flow for Scenes.

I was extremely proud of his thing those 15 or so years ago. It was way more configurable than you might think at first. There was the characters folders that contained all of a characters static sprite work and animations (arranged in swf file sequences) and sounds. There was a .chr format “Character Definition” that was a pointer manifest and animation sequence registry. This is also where you’d register their name, default pose, what sound file to use when objecting, all that jazz. And to tie it all together was the Scene XML file.

Now I wrote that format with the intent of hand-authoring the xml in mind. I wanted it so easy to whip up a scene in a matter of minutes that I setup that CourtEngine demo in just a few. So you’d have a tag for text events like “<Dialog>this is some dialog</Dialog>” and to make it ridiculously simple you could simply supply a “for=‘phoenix’” attribute in the Dialog tag. That’s all the engine needed to determine what name to put in the on screen dialog box, loop the characters mouth animation registered to default pose, and EVEN automatically transition the camera over to the character speaking. All in one tag!

It made construction of dynamic scenes enormously easy to author. But y’see I learned a LOT when trying to reconstruct scenes from even the first game… one of those things?

Phoenix Weright breaks the rules ALL. THE. TIME.

Characters talk when not on screen. Random color events take place. Characters speed up and go on multi page auto ramblings. Camera focus is just arbitrary and does whatever it wants to do. Don’t even get me started on the bonkers amount of shocking implementation diversity when it comes collecting and presenting evidence.

One thing my format lacked too was proper interaction. Simply there was no mechanism for branching dialog. So CE I would brand a “playback Engine”

What it comes down too, is that I don’t know what kind of authoring system the Phoenix wright devs used when making the game. I have a feeling it was a general purpose scripting language because while it flows like normal 80% of the time, the last 20% treats everything as if it were completely malleable elements just floating in space to do whatever the devs wanted in the moment.

Doki Doki Literature Club isn’t all that different either.

And that’s my lesson. However my dialog engine works, Danganronpa isn’t that different when it comes to scriptable dialog moments.

I have a visual in my head of a Node Graph based approach. I like node graphs for a lot of data representation. But treating a dialog flow like a node cloud where dialogue can flow conditionally along edge traversal makes a whole lot of sense to me.

Ok that’s it for now

Till next time

[kyleondemand]

Making a format

Last week I indulged in a thought

For my Danganronpa style engine, I need a 3d model format. It’s after all not just flat sprites but actual 3d geometry everywhere. Looking over the collection if formats there.. I mean.. FBX is a mammoth closed source proprietary 3d scene interchange format with all kinds of crazy nonsense packed inside I’d have to learn to deal with by hand. Collada is a complicated xml based format with all kinds of crazy scene and object graph nonsense packed in, and deprecated to boot. glTF2 is a great format but then I’m dealing with parsing complicated hyper-related json structures and reading binary blobs, and my brain just doesn’t want to deal with it. You know I did want to deal with? OBJ.

Oh it’s an excellent simple format, and I got excited about it too… until I watched some more footage and noticed… there’s animation in them thar scenes.. not complicated animation mind you, but everything from the pop-up book style scene-transitions, to background elements like calling fans and even as we saw your 3d avatar.. walking/running/sprinting.. ya.. need animation. And guess what obj doesn’t support?

On top of that, all these formats have a big thing in common… none of them are FOR games. They’re for Scenes. The big engines support them not because they’re popular.. But because their editors are essentially scrpted scene assemblers with many of the same tools packed into an fbx.

So I’m over here.. demanding simplicity. Man oh man why couldn’t there be a format as simple as OBJ, but supports skeletal animation, and designed for single models? What if you didn’t need to download some bloated SDK or spend 50 hours writing a parser that only supports a subset of what the format packs in?

That’s when I had an idea.. What if I simply extended OBJ?

Oh, but if I’m gonna take the time to extend obj, why don’t I fix some of the stuff that indeed bugs me about it, like keeping all things 0-indexed, and providing the whole vertex buffer object for each vertex on the same line, neatly arranged? Because at the end of the day, even obj is more interested in data-exchange between 3d suites.

Ok, so if I’m going to do the whole line prefix denotes data type thing complete with a state machine that dictates how to deal with the data found on each line.. we may as well make each line as useful as possible, right? That’s when I came across the tagline for the format “because I respect your time”. I was going to pay extra special attention to make sure the entire format stays the course and is predictably, and disgustingly, easy to read; without the need for anything else. No you don’t need json reader, pikl sdk, fast toml, or speed yaml. No you don’t need to make some kind of tokenizer or look for brackets or line endings, nor are you going to need to worry about quotes.

There’s two primary ways to read this format:

1. Read a line in, scan character by character; detect the unique line prefix and that prefix will explain all there is to know; or

2. Read line in, split it by space char, match the first element to some parsing mode, and use the rest of the elements as needed by index value

This all sounded great to me… But like I said, obj isn’t designed for use in games, in fact the format has its own annoyances to walk through. There’s got to be a bett- I got it. MD5.

You know, Id Software is known for their engines. And their tech is hyper fixated on performance, even at the cost of flexibility. The MD2 format is frustratingly limited, but it’s a very purpose built format that did the job And did it well for usage in a video game. MD5 is their last model format to be open sourced and with luck it also happens to be an ASCII format. But what it also supports is skeletal animation and in such a way that makes a lot of sense too. But I find the format plagued by a weird C-like syntax that I definitely didn’t come here to try and deal with.

So my idea was simply this: what if obj had a baby with md5?

That’s where I’m at right now.

I have the whole thing specced out and now I’m just learning how to write a blender plug-in…

[kyleondemand]

Hello, Despair Engine 👋

And hi, everyone stumbling upon this blog. Please excuse the cobwebs, I haven’t blogged about Tech in a very hot minute.

So just “What in the heck is goin’ on here?” I hear you ask. Why, I’ve been inspired. I haven’t felt this inspired, in quite a while; well technically since I shelved Black Lotus, anyway.

I’m embarking on something a little new, and a little different from my usual exploits.

If you’ve been able to surmise by the title and the hints I’ve been dropping… That’s right. I’m making a visual novel engine. But not just your standard ren’py style visual novel engine, we’re going all in on the Danganronpa style explorable first person pop up book style visual novel engine. Hence the name: Despair Engine. The name also fits in with the language I’m choosing to write this in: D. And with D, it’s common to name your stuff you make with it to start with that letter. It works out tantalizingly well.

Years ago, in the ancient times of the early to mid 2010’s, I started a project with a friend of mine deeply inspired by Hotline Miami. It was a super fun project, but I sorely lacked experience as a gameplay or ui programmer, so I fell discouragingly behind all the time. And as a new dad with a full time salary job, my “free” time was minuscule, to say the least.

What made that project super interesting was the language we decided to try out: D.

D is a fascinating language. It’s like C++ on steroids, but with many cool and interesting features. First of all, D ditches the Header/Source coupling and uses a module based dependency approach like Java. This means no more cyclic dependency issues, forward declarations necessary, nor compile time defines or mscros. The language cranks up the syntactic sugar up to 11 with all kinds of fun toys to play with designed to make your life easier and just get the heck out of your way as a developer, as such It’s a language designed for productivity and respects your time. Speaking of which, the language toolchain also features DUB, which is an early example of a project definition and configuration file but also a build tool AND fully realized package manager. No more pissing about with a linker or messing with cmake or makefiles, dub was your one stop shop for all things D. It also came with DMD out of the box, which is the default compiler, meaning you could just get up and running from nothing to everything you need and compiling and running programs within a couple minutes. Not to sell it any harder, but I also really appreciated that D was compiling down to native binaries, which means whoever needed to run the program didn’t need to install some extra run time environment or some virtual machine either.

Now, with the lenses of 2024 on, it can be easy to draw comparisons to modern languages and toolchains challenging the C and C++ throne, such as Rust, Zig, and the upcoming Carbon. However, D pre-dates these things while offering the same features, by many years. It’s been around so long, that GCC and LLVM offer their own D compilers out of the box and do a much better job than DMD does. Crazy right?

Anyways we shelved the game because frankly I couldn’t keep up at all and most of the work fell on the shoulders of my partner and it just wasn’t fair.

But that language. This D thing, it made a lasting impression on me. I never quite forgot about it, ever. But I had to go on a long programming journey with C++ to finally understand how to appreciate what D really had to offer me.

On top of all of this, D has access to the “Derelicht” binding packages, which provides me with easy and direct access to SDL2 and OpenGL. As if I were using them in C. It’s brilliant.

It may not feel like it at first, but Danganronpa is 100% a 3D game, don’t let the popup book flat visuals or the 2D avatar portraits fool you. So that leaves just one question, just what in the heck am I gonna use for asset data, like models?

That’ll be another topic for next time. Right now, I’m in deep R&D mode, making tools and defining ideas. So until the next post, see ya

~Ninja Ghost