Gearing up

It’s time to start work on Animated Chatroom. It is a monumental project; the largest project to date that I have ever desired to undertake.

My resources are somewhat scarce, but it could be worse. The two resources which I am in great scarcity of are developers (human resources) and energy (something which tends to be inversely proportional to time). The developers I seek are either not competent enough to produce modular code, or they live in a very different time zone that complicates any coordinative effort. My energy is drained from playing with my brother or doing real-life tasks which I have been postponing for too long, such as cleaning some things up.

There is another question that compounds a desire to do everything other than work on Animated Chatroom: where do I even start?

Well, let’s see what Torvalds has to say about his success:

Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don’t think about some big picture and fancy design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to jump in and help you. That’s not how these things work. You need to get something half-way useful first, and then others will say “hey, that almost works for me”, and they’ll get involved in the project.

Okay, Benevolent Dictator Linus…

You start with a small trivial project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage.

All right, so we started with a small trivial project. It was called Attorney Online 2. It was good. And then it tanked because of poor design. I want Animated Chatroom to not go through that pain again.

Or worse, you might be scared away by the sheer size of the work you envision.

Which I am.All right, so what features do we not need? Let’s cut nodes until we get something less overwhelming.

Better. That’s almost the bare minimum that I need.

In list format:

  1. Core animation engine.
  2. Asset loader.
  3. Basic network.
  4. Basic UI.

That’s all, I guess I don’t care about anything else right now. So let’s cut it down even further.

Okay. So version 0.1 will barely have a UI. It’s just figuring out how stuff should work.

It’s clear that VNVM is at the center of this entire project. If I can design VNVM correctly, then this project has a chance; otherwise, a poor execution will lead to a shaky foundation.

The Visual Novel Virtual Machine

What is the purpose of the Visual Novel Virtual Machine project? The purpose is to bring sequences of animations and dialogue sequences, the bread and butter of visual novels, to a portable environment. From reverse engineering performed by others, it turns out that major visual novels also use a bytecode to control dialogue and game events. In the VNVM world, this is called VNASM (Visual Novel Assembly).

Within characters, emotes are simply small bits of VNASM, which are then called by the parent game (which also runs in the VNVM). Recording a game is just a matter of storing what code was emitted and when. The point is that essentially all VNASM is compiled or emitted by a front-end, rendering it unnecessary to understand VNASM to write a character. (But, it would kinda be nice to be able to inline it, wouldn’t it?)

This makes VNVM satisfactory for both scripted and network environments. In a network situation, where the execution is left open, there is a simple wait loop that awaits the next instruction from the network buffer. New clients simply retrieve the full execution state of the VNVM to get going. The server controls what kinds of commands can be sent to it; most likely, an in-character chat will look something like this as a request made to the server:

{ emote: "thinking", message: "Hmm... \p{2} I wonder if I can get this to work right..." }

The \p marker denotes a pause of 2 seconds, which the server parses out to emit a delay of 2 seconds (of course, limiting the number to a reasonable amount). The server then pushes the reference to the character who wants to talk, as well as the message to be said, and calls char_0b7aa8::thinking where 0b7aa8 is the character’s ID. This denotes that the named subroutine thinking is located in a segment of VNVM code named char_0b7aa8.

More to follow later.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.