1. Star Child
  2. News

Star Child News

Star Child Dev Log #15

Jay Ingle - lead developer, designer, and artist:

Last week I worked a bit of overtime to get our first playtest build to a state of functional and fun. I got to slow down some this week, and make some cool new stuff; including mechanics and graphical adjustments for a new, spicy, environment.

Welcome to Fire Mountain. Have some breakaway blocks.



Rise, pillar.



And I also updated the rocket graphics. Now with spinning action!



Stay tuned for more cool new stuff.

Star Child Dev Log #14

Jay Ingle - lead developer, designer, and artist:

This week, we got a Star Child first playtesting build ready to be played by people other than myself and Janne! Does that mean the game is nearly complete?! No! But here are some screenshots to keep your appetite thoroughly wet.





This week, I created a mini-episode, including most of the enemies and mechanics that we have so far. There is still some placeholder art, but everything functions! (And you really want that key).



The episode can be started from the main menu. You can save the game. You can load the game. And you can finish the game!



So we have a functional video game. Now we just need to make more of it, and make it more fun!

Star Child Dev Log #13

Kyle aka Anthrocarbon - music and sfx

Ahoyhoy, Kyle here.

2024 was a great palate cleanser on the music side, with me re-listening to many songs I thought were nearly ready only to notice many irritating and distracting samples and tones that require a little more than polish. Fortunately, Jay supplied me with a juicy list of required sound effects, so I was able to “oh shit” myself and forget all about that lot for a while.

Working in a DAW to create SFX has been far less expedient than I expected at the outset, not due to a lack of tools, but an overdependence on or habit of turning to filters and wrapper tricks as a first port of call. I also found that my usual approach toward balancing and pacing was suitable for music, but didn’t translate particularly well to one shot sounds. SFX which are expected to be heard throughout the game can be clustered in bunches as often as heard alone, and unlike a song SFX must sound coherent no matter which one or group of them are played in whatever order are necessary.



Distortion, bit crushing, equalising for sharpness or backgroundising, all very quickly became distracting and punished the player for taking actions. "Old school" sounds might well be a style, but amongst elements rendered at modern fidelity, the ugly truth emerged – I was imitating retro sounds without the requisite experience of working with 8 and 16 bit limitations like the progenitors at ID, Apogee, and Cygnosis. (Not to mention adding constant revisions to the list of sounds grew the channel count beyond expectations.)

And so I went back to where I should have been doing most of the work, which is where every Foley artist will turn with glee; smacking and scrunching a bunch of random shit from around the house in front of a mic. (Annoying bird chirps outside the window and all.)



Among the most difficult of sounds to pin down, and unsurprisingly one of the most critical, has been the basic exploding of rockets on surfaces and against enemies. For something one might imitate vocally to a recognisable proficiency, making a good ‘bang’ or ‘pop’ that doesn’t sound like it came from somewhere else had me grumbling (and napping) at the keyboard for a couple days. A creator’s choice – as I see it – in situations like this, is to go with something iconic and memorable, or generic and forgettable. I believe I’m capable of iconic sounds, but just not quite there yet, so I’ll carry on as many times as necessary until Jay says a sound is just right. Any sound heard constantly throughout the game must be just right, lest the start-to-finish gameplay feel a little bit wrong.

SFX is an area which suffers from a “that’ll do” mentality, which can sometimes be an unintended result of “oh shit” planning. Another pain point is the temptation to try and infuse a bit of awesomeness or coolness into sounds that don’t really call for it. Just like world-class BGM, sometimes the fact a soundscape compliments a scene so perfectly that it makes the scene come alive – then seems to evaporate after the audience moves on, indicates that everything was just right. Sound effects are difficult entities to carry narratives and moods on their own, but in something like a video game where they are the environmental information feedback, the artist responsible has a duty to produce a language for the world within the frustum to speak through.

SFX are far more challenging than I bargained for, and I worry about them far more than I think I ought to. Ultimately, though, whether they are the best possible sounds or not, they belong to Star Child in whole. New game; new assets. Star Child already looks and plays like nothing else; I’ll have it sounding is unique as it deserves and nothing less.

Now, I’ll allow myself a sound recess to revise an unfinished song I recovered.



The key samples I accidentally purged from my bank have been found in my backup archive after almost 12 months, and I get to try I remember what all these knobs did!

Star Child Dev Log #12

Jay Ingle - lead developer, designer, and artist:

I have done a lot of research into 2d platformer game structure lately. I found 3 primary types of game structure in sidescrollers.

1. Level Select. These are mostly old school, or very retro-inspired games, where you choose your level either from an overworld (Super Mario World), or from a simple level select screen (Mega Man, Super Meatboy). These are mostly linear, but you are often given some choices in your path.

2. Pure Worlds. Every modern Metroidvania plays it straight. You are put into the world, and ALL mechanics are inside the world itself. A level select screen is from a VIDEO GAME. This is not a video game, this is a REAL WORLD. No video gameyness here.

An alternate version of the Pure World is where you have a hub area that you move around in, like a more interactive overworld level select screen, that your character can freely more around in. Hard to think of examples right now but uh, Quake 1? This is the same as a level select overworld, but presented as part of the actual game world itself.

3. Roguelikes. Randomized dungeon runs. Often with an in-world hub area where you shop and prepare for the next dive (Dead Cells).

The plan for Star Child from the beginning was for a Pure World. Your standard Metroidvania world. Somewhere between Metroid and Super Metroid in terms of complexity. This is a crowded genre. How can 1 indie dev compete with the giants of indie platformers? If I try to do the same, Star Child will only end up being a less-good version of bigger games.

When I recently started serious level design for Star Child, ironing out the flow of the experience, the game really started letting me know what kinda game it wants to be. Star Child wants to be a fast, fluid, action platformer. But Star Child does not want to be a pale imitation of giants. Star Child wants to subvert, surprise, and delight.

Star Child Dev Log #11

Jay Ingle - lead developer, designer, and artist:

Last week I talked about creating a Door that will open if the player has collected the appropriate keys. We have the Door object, and also the Key Altars, which activate themselves, and display their key, if it has been collected. If the Door then acknowledges that all Key Altars have been activated, the Door opens.

When I try to think about how I would have handled coding this situation in the past, it hurts my head to even work through it. Thankfully, I have improved a little.

Initial setup needed: Add Door to a scene. Add all Key Altars into a parent node, and set that parent node as the Key Altar Container in the Door's corresponding exported property. Also set which key each key altar needs, in their properties.

No further setup needed. Can setup be simplified even further? Maybe a tiny bit. But I definitely need to set which key corresponds to which altar. And I feel that dragging the Key Altar Container node into the exported property on the Door isn't too much trouble.

At run time, each Key Altar checks the player's current inventory, looking for its match. If it does, it shows the key, and sets Activated to True.



The Door then uses the Key Altar Container to set up an array which contains all of its children nodes, then checks each one to find out if Activated is True. If all Activated in the array are True, the door opens!



I don't feel that this code is perfect. I don't feel like it is the BEST way to approach the situation. But I am happy with it. Feels like I am using the tools available in a decent manner. Feels like progress.

My apologies if some of this language was too Godot-specific for the casually interested observer!