Week 66: Post-jam work on Meteor Power

I created a new system for outlining sprites.

tl;dr: Last week, I wrapped up my Ludum Dare game-jam tasks, and I started working on a post-jam version of my game Meteor Power.

What happened last week?

Highlights

• I started working on an updated post-jam version of Meteor Power, which I'll release as a mobile app.
• I did some follow-up promo, publishing, and bug-fixing tasks for my game-jam submission.
• I rated and reviewed other game-jam submissions.

Laundry list

Some fun with simple particle effects.

• LD50 promo and publishing:
• Create a devlog post for LD50.
• Create a portfolio post for LD50.
• Update GitHub LD50 README.
• Update ldjam.com submission post.
• Create an itch.io post for LD50.
• Create a YouTube trailer for LD50.
• Fix a broken export of Meteor Power.
• It was broken on all platforms.
• I figured debugging the Windows export might be the easiest.
• So I installed the Rcedit tool, to make Godot happier about Windows exports.
• Though, this had nothing to do with my export problems.
• The problem was that there was a dependency on the type “EditorPlugin” from the exported code.
• This leak happened because I have a check in the Sc global to help warn folks when one of the plugins isn’t enabled in the editor.
• The fix was very simple! I just removed the type annotation from Sc.
• But apparently no one else on the Internet has had this problem before. I could find no helpful documentation relating to this!
• Fix another game-breaking bug, where a crash could happen if a meteor hits a powerline shortly after it was attached.
• Add a new "recording" release mode.
• This disables music (since I usually want to add that manually to a trailer).
• This sets a good window size for a 16:9 video.
• This disables some HUD overlay elements.
• Rate and review other LD games!
• Create a post-jam version of Meteor Power under the SnoringCatGames repo.
• Plan my goals for a post-jam release of Meteor Power.
• Create a constructor bot building animation.
• Create a new OutlineableSprite scene.
• I looked into a few different ways to render outlines around my sprites.
• I ended up implementing two of them:
• Shader-based outline:
• This is simple, and works with any image.
• BUT, it’s expensive. It is polynomially more expensive, depending on the thickness of the outline.
• Texture-based outline:
• This requires the sprite-author to create an extra copy of each sprite. The copy contains the outline.
• This then renders both the original sprite and the outline sprite.
• This has pretty cheap performance, but is more work for the sprite author.
• Add support for toggling whether a character animator is rendering an outline for the character.
• Start adding support for changing sprite outline color with a separate nested sprite.
• Add a sprite outline system, supporting two methods of outlining: extra-texture, and shaders
• Finish implementing ShaderOutlineableSprite.
• Add support for centering the window.
• Fix an issue with AnimationPlayer bypassing the getter/setter for the Sprite.frame field.
• Add support for tracking whether a navigation was triggered by an explicit player selection.
• Add support for emitting navigation_canceled when starting a new nav while an old nav is still in-progress.
• Update parallax background to not scale with camera zoom.
• Add meteor-tail particles.
• Fix meteor collision shapes.
• Fix camera stutter when switching between moving bots.
• Update Behavior._on_physics_process to accept delta_scaled rather than delta.
• Fix an issue with character jitter in slow-motion.
• The problem:
• The character jitters in slow-motion.
• This is because of my forced-edge-trajectory-matching.
• My edge-trajectories were calculated with a fixed (non-slow-motion) time-step.
• So when I enable slow-motion, I no longer update the character's position to the next precalculated trajectory frame on every actual render frame.
• This makes the character's position seem to jump forward every few frames, while staying still during most frames.
• The fix:
• I can smooth this jitter by calculating an animator-position offset based on the current physics-frame relative to the edge-frame.
• Follow-up problem:
• That fix didn’t actually work, because I’m still applying the default character physics-based movement when the time-step doesn’t move into the next trajectory frame.
• That means that the character is actually still moving between trajectory frames--they just get forced back to the expected trajectory position on each new frame.
• This is probably the main actual cause for the jitter in the first place.
• Follow-up fix:
• Override the default physics-based movement and force the character position to match the latest trajectory frame each physics-frame.
• Follow-up problem:
• This breaks my navigator, since it thinks that if navigation is active, but the character didn’t actually move between physics-frames, they must be stuck, which means something must be broken.
• Follow-up fix:
• Instead of interpolating an animator-offset position between trajectory frames, interpolate the actual character position between trajectory frames.
• This should fix the original jitter issue, and could also fix possible edge-case navigator stuck-state errors I sometimes see.
• Follow-up problem:
• I was _still_ seeing jitter.
• This turned out to just be a simple logic/math bug.
• My progress-within-trajectory-frame value was only ever within the range 0.0 to 0.0159.
• Follow-up fix:
• I just needed to divide the remainder value by the time-step duration.

    var progress_in_current_trajectory_frame := \

            fmod(trajectory_elapsed_time, PHYSICS_TIME_STEP) / \

            PHYSICS_TIME_STEP

What's next?

• I'm going to pause work on finishing a handful of framework, plugin, and surface-tiler improvements.
• Instead, I'm going to work on releasing an updated version of Meteor Power as a mobile app.
• I've got a long list of little improvements I wanted to add during the jam, and didn't have time for!

🎉 Cheers!