So I’ve kind of been using the screenshot thread as a devlog (and posting videos, not screenshots, but whatever). I spent all morning fucking around with shader code to draw meters. It is a real “don’t know why I’m doing this” tangent. The superficial justification is that it seems dumb to have to create empty textures for things where I just literally want to draw everything in the shader, but it turns out that just not using textures is inordinately difficult/weird in Godot, You’re supposed to use polygon2d for this purpose but if you do there isn’t any built in local to the object coordinates to use in the fragment shader, and even if you set the UV coordinates yourself they don’t come through. You have to set a texture to get UVs, which does make sense conceptually (since they are UV coordinates, after all) but why not just give me a reasonable representation of the local fragment coordinate instead?
Anyway, figured it out eventually. I am just creating a texture dynamically. Back to working on the audio input system.
Using a microphone to control a character sucks! That is kind of the joke with this game, but part of the reason it sucks is that microphones and rooms are all different and its just hard to know what situation a player will be in. So I’m trying to work on some kind of autocalibration system. Here I’ve got myself making some ghost sounds with a background of a cafe ambiance. I break the input down into frequency bands, each of which has a running normalization that basically tracks the maximum volume at that range and uses that as the top value for the scaling. The tracked maximum gradually decays so that it kind of ignores very loud transient sounds.
Then I sum up a set of normalized frequency values and track that value in 5 tiles, calculating the mean of the top and bottom quantile to use as a scaling range. That is the blue vertical bar. The purple bar is the raw sum of the frequency bands and the green bar is the raw mic output in the vocal range, roughly.
i remember in uh frog fractions 3 maybe there was a bit that needed mic input and even though i had a fancy lil audio interface it just wasn’t picking up at all… i cheesed it somehow but i feel like maybe that’s a challenge to just get working maybe
Totally. Ghost game can be controlled with a controller if you want, of course. You need to be using a controller for everything but the ghost thrust anyway.
A real win for “try the simplest thing first.” The new yellow bar and time series plot shows a simple normalization scheme based on the total power in the range 150 to 3000 hz. The normalization basically pushes down the minimum a bit each time the input is lower than the current minimum and raises it a bit each time it is higher. The maximum is also managed in a nearly identical way. Then I apply a constant and quadratic smoothing (eg, the current value moves more rapidly towards the latest measurement if the difference is larger) and it seems to be a good result. It was also fun figuring out how to pack the time series data into a texture to send to the plot shader.
I spent an hour this morning tuning the ghost physics. It is surprising what a delicate balance there is here. In the initial prototypes of the game the ghost could float freely but without the auto-scrolling of Balloon Kid or the natural diegetic device of popping and refilling balloons (mostly the former) level design proved to be pretty challenging (note to self: play kirby games). So I’m been experimenting with limiting the ghosts “float juice” so that I can design a little more aggressively but this goal kind of contrasts directly with the audio control gimmick, which is really imprecise!
This morning I tried out reducing the Ghost’s float thrust a fair amount, decreasing the burn rate of juice to make the timing less sensitive, allowing pick ups to fill the meter over 1 so that you have more generous time in the air where I want but not where I don’t and reducing the thrust bonus associated with thrusting when the ghost’s velocity is pointing downward (there used to be no such bonus but it feels very natural to be able to arrest one’s fall faster than one rises). I also tweaked the brief delay one faces after jumping before they can begin thrusting. Because of the way the terminal velocity calculations work one can time a thrust just right at the peak of one’s jump velocity and get a substantial boost to the total height one can reach on a single charge.
Writing it all out it seems hopelessly complicated!
This morning I worked on buoyancy. This is the set of systems that let the player put rectangles in the level editor that represent water or other fluids that things should float in and get additional drag inside of.
This strategy here is to create a custom Area2D sub-class which notifies objects which enter it that they have entered or exited into a region of Buoyancy. A second helper class, meant to be used on Buoyant objects keeps track of which Buoyant areas an object is currently in and calculates the appropriate Buoyant force based on those regions customizable Buoyancy and the intersecting area. Because of that latter bit objects naturally float at some level on the surface of a buoyant area because the buoyant force is proportional to the submerged area and so approaches zero as the object leaves the area.
The BuoyancyHelper class is a good example of “composition is better than inheritance” (I think) and I’ve used this strategy in this version of the Ghost game a lot. A lot of functionality that many nodes might want to use is just split off into nodeless classes.
I guess next on the agenda here is a splash effect.
Per my desire to take level design much more seriously this time around I started working from the get-go with an abstract tile set that marked out 8x8 boundaries. This makes it easy to lay out a stage knowing “the ghost can reach a height of N blocks jumping from the ground” or whatever. But once you have a level design you want it to look a certain way. So this morning I added a new Node type called “TransmogrifyArea” that knows how to remap the base abstract tiles in a region to a different AtlasTexture when the level is loaded.
I’ve seen other people do this for an entire TileMap on load, but I don’t want the Map to be just one sub-tile type. Ideally we can lay out a whole level abstractly and then modify the tiles that show up using these areas.
The custom node lets you select a Tilemap to work with and which sub-tileset you want to use to replace the tiles with. Once I’ve got the kinds worked out I’ll probably let this work in the editor too, so you can get a live preview but there are issues with this having to do with having to keep track of the original tiles at each point if you want to revert and when to revert (if the node is deleted from the editor?).
I’m feeling really comfortable with Godot now and its starting to feel a bit like Emacs for Game Development - most of what you might want in the editor can be added by creating the right tool nodes.
I think I’m doing sufficiently non-trivial (or at least non-documented) stuff with Godot now that it would probably be useful to create Godot Tutorials/devlogs on Youtube but since I do 90% of my work on this at 5 am while the rest of the house is sleeping, I can’t record anything.
Working on a lot of stuff. Many invisible changes to the hitbox/hurtbox mechanism after somehow fucking it all up again. Now there is a custom resource for HitBox and HurtBox configurations so I can change all the monsters at once by just editing the appropriate resource or create custom resources for specific cases.
I’ve also added a p-switch style thing that can talk to spawners or other meta-game entities. Spawners are nice: they are just regular nodes and when you add children to them, they remove them on start and spawn duplicates back in when they are told to (eg, by a button or switch).
Finally, I’ve implemented StageRegions, which are just rectangles with meta-data attached to them. When the player enters or exits, they raise events that other objects can listen to (spawners, for example, but also my custom camera class).
This allows me to snap the camera in place or within bounds for certain sections of the level.
At a slightly higher level its beginning to feel like I am procrastinating by imlementing game features. I probably should start designing levels.
Also, there are multiple pick up types and a shader to customize the sprite for candy pick ups. Right now there are just candies that don’t respawn after pick up (for one time challenges) but I’m going to build a few more types (moving ones, for example). Since the candies recharge the ghost’s juice they are a major handlebar in the design space so they need some expressiveness.
squeezing in time when I can to polish black magick power upgrades to Spoopy’s core move set. much to be said about how that works…I should do that in the game’s dedicated thread though…at some point
bad repetitive music loop but I am working on a new tune for the next little playable thing focusing on these powers for (hopefully) September (tho I could see this slipping and then justifying to myself that actually October is more thematically appropriate actually actually) the vibe’ll be more hellish and the tune pretty laidback ~juxtapositions~ but I’m gonna try to add some backwards/pitch shifted voice samples which might creep it up a bit…really hoping “suck” in reverse sounds like “cuss” but I haven’t tested this
this patient is nowhere near being ready enough to leave the operating table but:
(also I’ve yet to figure out how to eliminate the occasional frame stutter recording in OBS oh well, someday)
I’ve written some custom startup code to replace static tiles in my tliemap with the appropriate waterfall shader tiles when the level is loaded. I’ve also fiddled with the waterfall top shader to improve the foamy look.
This is a subtle thing I guess, but you can see in the above movie that the foam at the top of the waterfall forms a complete white line between it and the waterfall itself. This isn’t the effect I want - it makes the top of the waterfall look more solid than I wanted.
The foam is generated by sliding a window around a noise texture, quantizing to screen pixels, and then thresholding in proportion to the distance from the top of the image (thus, foam is more likely at the bottom of the texture, where the threshold is higher). The effect was too linear, though, so made the threshold quadratic in the distance from the top of the image and this helped some. As I am writing this I think I also need to set a max threshold to make sure the foam is never too dense.
Here is what I have now:
And with a max threshold in addition:
Which is a lot closer to what I was going for.
Shader code looks like:
void fragment() {
float r_time = round(TIME*time_round_scale)/time_round_scale;
vec2 offset_pos = vec2(8.0,8.0) + round(4.0*vec2(sin(r_time*20.0),cos(r_time*20.0)));
vec2 UVq = qvec2(UV, TEXTURE_PIXEL_SIZE);
vec2 ntpsz = 1.0/vec2(textureSize(noise_texture,0));
vec2 uv_scale = vec2(textureSize(noise_texture,0)/textureSize(TEXTURE,0));
vec4 ns = texture(noise_texture, UVq/uv_scale + offset_pos*ntpsz);
float x = ns.r;
float y = (1.0-UVq.y);
if(x> (min(maximum_threshold,threshold + y*y))){
COLOR = white;
}
// Called for every pixel the material is visible on.
}
The final wing of my second map is far in development. The blockout is nearly finished. I’ve figured out the rhythm I want it to have and eeked out an encounter design that I feel pretty good about. Still need to really tend to the subtle work of level design to point the player into the right direction, at least with one part of it. Sharing some screenshots just because it’s been a while.
Are these placeholder graphics or have you more or less locked in the style? I do tend to like dev placeholds, but I like the look of this to be honest. It’s very clean, like you can see through it, and it reminds me of transparencies you’d place ontop of a projector.
The orange tiles are placeholders but the waterfall is meant to eventually go into the game. I’ve modified it slightly since I last posted so you can specify a color in the shader.
I have like started thinking about this longer term project I’ve wanted to do for like 10 years now. Worry that it’s been in the mental oven too long and once it’s in playable form I’ll go “oh” but I am planning on building it out in stages instead this time and getting around the bigger technical problems that keep me from starting. However I need to play death stranding eventually
for the 3rd time in my life I have made a 3d model of an Ekranoplan but this time i actually used some reference materials. This means it’s the third or fourth attempt at making this thing
