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.
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!
Comments
Post a Comment