A lot of progress this weekend. I put together some larger objects, such as this pharmacy cabinet:

And built out an interior test environment to figure out the built-in physics system (mainly collisions) and develop player movement/control and object interaction. Not sure if I have the best practices down there (e.g. the walls are separate planes, when I should maybe use an inverted cube. But I’m happy with out it turned out:

The player movement and control still need a lot of tweaking. I’m not sure of the best relationship between the player direction and camera direction…this is easier to figure out on console because you have joysticks to control each separately, but not so clear on PCs.

The object interaction using raycasting (key for object interaction/talking to NPCs) was very straightforward, as was object proximity detection (for triggering events when you come near something, for example).

In general I’m getting more familiar with Godot and the workflow with Blender. So far I’m really enjoying Godot; a few small snags here and there but overall it’s been intuitive and powerful. I haven’t yet felt like I needed to do any clunky or hacky; there’s always been a clean solution.

I originally anticipated using Rust as the foundation for the game (was looking at bevy originally as the framework for the game). I even set up an integration between Godot and Rust (using godot-rust). But I’ve found GDScript to be really nice, and probably performs well enough for my needs. The game logic is straightforward; any bottlenecks would probably come from graphics/rendering/etc which the scripting language wouldn’t help much with. Anyways, I’m using relatively small textures and simple models, so I’m not worried about that.

I’m currently sketching out the dialogue system. There are many different scenarios that it needs to handle; I’m hoping to design it so that it basically can run “cutscenes” (really just sequences of dialogue, animations, audio cues, etc) in addition to a more conventional choice-driven system. So I’m taking care to design a system and schema for representing dialogue scripts that will avoid painful re-writes in the future.

I’m using one of my favorite bitmap fonts here, UW ttyp0. Unfortunately it doesn’t get much bigger than this, so I’ll eventually need to find an alternative.

For the past few months I’ve been sketching out the world and rough game mechanics/experience for a new game I’m working on called Fugue. I have a big dump of notes and memos to turn into something more coherent, but because the world, game mechanics/experience, and story are all going to be constrained by development considerations, I want to start getting that whole infrastructure and process in place before going any further.

There are two main fundamental and related constraints:

• Time: I have a job and other obligations, so anything that can smooth out workflows, minimize clicking and pausing and looking for the right folder and so on is ideal.
• Expressiveness: Ideally whatever I set up now is enough to cover whatever ideas I might come up with down the line, and to allow me to express them quickly and intuitively.

Right now I’m thinking the core development pieces are relatively simple and robust once in place. Most of them time will be creating assets (modeling, processing textures, animating, etc) and writing the story and dialogue. I’m really just putting together a custom authoring system for this particular game.

The game framework and other decisions

Probably the biggest starting decision is what game development framework to use. I initially was looking at Bevy, which is a Rust ECS (Entity-Component-System) framework that looks very promising. Unfortunately it’s still in development, which would likely lead to a lot of headaches down the road. In the meantime they suggest Godot, which is well-supported, open source, and mature, something like to the game world what Blender is to the 3d modeling world. I was a little hesitant at first, based on my previous experience with this sort of game engine. When developing The Founder I initially used Unity, but had such a frustrating time with it that I ended up developing it as a web game. Godot fortunately looks better; after playing around with it a bit I feel somewhat confident that it’s the right choice.

The other big decision was what modeling software to use. I’m already familiar with Blender so it was a no-brainer to keep using that (I did take a brief look at picoCAD, which looks great). I did hit a snag because I was using Blender 2.7 and upgraded to 2.9, which has a huge set of changes (which I think were mostly introduced in 2.8). Though it took a bit of re-adjusting to the UI, overall some of the annoyances I had with Blender feel more or less resolved in the update. I did struggle with the program crashing and locking up my system frequently. It seems like that might have been due to an older version of Mesa; after upgrading it things might be working properly (fingers crossed).

There were some other important housekeeping decisions to make: like folder hierarchies, how to keep process notes so that if I have to hit pause on the project for a few weeks (extremely likely), I can easily get pick up where I left off, and so on. These are likely to change as the project starts to pick up and I have a better sense of what the needs are, so I’m not too worried about getting them exactly right at the start.

Art style

The other major set of decisions to make are around the art style. A few years ago while prototyping some ideas I used a very quick-and-dirty modeling and texturing approach that gave really good results. It’s basically a low-poly approach and uses internet-sourced images as textures:

It’s close to the sweet spot of visually interesting but not too labor intensive. But I want Fugue’s graphics to be a bit “crunchier”, achieved through lower-res graphics (more pixelated) and no anti-aliasing. That would kind of locate it in PS1 graphics nostalgia, which is also appropriate because the game draws from FF7 and FF8 (or at least the mood those evoked). Most of the PS1-inspired games I’ve seen are horror, so they typically have very dark and gloomy atmosphere and more of an industrial aesthetic. In terms of color I’m drawing more from Chinatown, Buddhist thangkas, and Ghibli/Miyazaki, so in general brighter, more saturated colors and more evenly-lit environments, so the end result should (hopefully) be more visually distinctive.

I have no idea how well this will work without trying it. So as a pilot I modeled and textured a maneki-neko (lucky cat) to work out the process in more detail.

The texture processing pipeline

The general pipeline is:

1. Find a suitable image. Can be really time-consuming, because it’s a combination of licensing requirements and if the photo’s lighting/angles are good.
2. Process the image. This includes cropping the image and then color-correcting and adjusting the saturation, contrast, etc. It also includes the pixelation (“crunching” the image).

Ideally this pipeline is as automated as possible, since this can be very time consuming. Cropping isn’t the worst, it can be done quickly by hand, and because of the pixelation, the cropping doesn’t need to be especially tight: the texture sizes are small enough that leftover background in images doesn’t take up too much space. But I did explore image segmentation models to see if it could be automated at all. Unfortunately the output quality just isn’t reliable enough.

There are a lot of different ways to crunch the image. In all cases they require some post-processing to bring out features that might have been lost in the crunch.

Here are the approaches I tried:

imagemagick: The simplest is just to downscale the image to a very small size (e.g. to a max dimension of 32px) using nearest-neighbors. I’m applying this technique with the following bash script:

convert -auto-gamma -auto-level +contrast -modulate 100,150 -interpolate Nearest -filter point -scale $1x$1 "$2" "../${2%.*}.png"

This also takes care of some of the color correction and contrast/saturation adjustments. This is the fastest; I just run the script on an image after it’s downloaded.

pixelator: This one looked promising, but sadly there’s an incompatibility with newer versions of pango so I wasn’t able to try it. I didn’t want to go through all the trouble of getting a set of older libraries to run it.

pixatool: This one works pretty well. The page there says “Windows only”, but there is in fact a Linux (and Mac) version in the zip that you download after purchasing it. The dev says it’s too much effort to support Linux and Mac, which it probably is! But I appreciate that the binaries for Linux are still included. So far I haven’t had any issues with it.

For touchups, I used pixelorama which is a nice, straightforward pixel editor. It looks like you can work very quickly in it once you get accustomed to the shortcuts.

Here’s a comparison of the two crunching methods (with minimal post-processing):

It’s hard for me to judge which of these textures is better from just this. They are fairly similar except that the pixatool one is more saturated.

Playing around with the models in Godot (after a very confusing import process) led me to stick with the imagemagick one:

It looks like Godot does not enable anti-aliasing by default, which is great.

It looks great with this PS1 post-processing shader, which fills in “detail” where ever the texture is itself not especially pixelated: