I'm innnnnnnnnnnnnnn

DDRKirby(ISQ) here, reporting that I'll be in for LD45, this time in the solo Compo division! My partner-in-crime @xellaya is out for this one so I'll be doing my first solo LD since LD37 where I made Ludum Dare: The Game back in...2016!

I've been super duper busy over the past couple weeks, partly trying to get a bunch of other stuff taken care of, but mostly because I've decided to try out Godot Engine for this entry! My previous 11 games have all been done in Unity, but I know that Godot has come a long way since I first tried it out (wayyyyy back when) and wanted to give it a spin.

I spent a good portion of the past week ramping up on Godot and GDScript with a fun little Mega Man platformer demo, called "Mini Mega Man"! I know we don't do official warmup game submissions anymore like we used to, but if you'd like to play it, you can try it out here. (soundtrack download will be out later)

Doing an actual full warmup project was a lot of work, but taught me a ton of things and helped me sort through numerous issues and quirks that would have bogged me down during LD otherwise. Things like:

• How to set up integer pixel scaling
• How to setup Autotiling for tilemaps
• How to best utilize the built-in kinematic physics APIs
• Whether testing for input works properly during physics updates
• How to handle playing sounds from objects that are destroyed
• Whether the WebGL export actually WORKS
• ...

Not only have I been ramping up on Godot as an engine (and GDScript as a scripting language), but I've been frantically trying to put together a lot of base code this week as well. My base code comes in two parts: a project template with a bunch of predefined project settings and some boilerplate for an intro/menu screen/etc., and a library of reusable scripts/scenes that are common things that you end up needing.

For Unity I built a similar library of reusable components and scripts, everything from 2D platformer physics to Audio management, rhythm game timing functions, scene transitions and fading, text outlines, an easy way to flash or pulsate text, site-locking copy protection, and more. This kind of stuff comes in super-handy and is ultra-reusable so I've been trying my best to at least build SOME of it out in the remaining time that I have.

Here's a nice shader-based screen transition effect that I implemented, for example:

So far Godot has been really good to work with! I'm impressed with how clean, lightweight, and snappy it is, (no more having to have a separate machine around just to chug through the WebGL export process for infinity hours). Even more than that, I'm surprised by how much game functionality WORKS with so much less of a hassle. Things like basic kinematic platformer movement, automatic pre-rendered text outlines (though the opacity seems to be iffy), LOOPING AUDIO SEAMLESSLY IN WEBGL (thank the heavens, it JUST WORKS), 2d tilemap lighting with occlusion and more. All of these things are more or less =possible= in Unity, but they require a ton of effort to set up correctly (hence the need for so much library code to deal with everything). If you're experienced you can definitely drive your way around to make something polished, but it just takes so much work....Godot is such a breeze to work with in comparison

It isn't perfect however. There are certain pain points that worry me a bit, namely things like:

• There's an unfortunate inconsistent issue where sometimes the WebGL export just fails to start -- refreshing the page and trying again usually makes it work though, it's very intermittent.
• Neither the built-in script editor nor external integration are super great even when static typing is used. I get that it's a scripting language but I really just want to be able to have intellisense autocomplete/documentation show up everywhere, it helps a lot in the coding process.
• Although on-the-fly script hotloading works way better than it does in Unity (partly thanks to GDScript just being a scripting language), interacting with the running game instance to debug and tweak parameters is way more cumbersome than in Unity, so in order to test things I basically should assume I need to restart a scene almost all the time. (On the plus side starting playback is way faster...)
• Everything is very decoupled...I mean VERY decoupled. This is neither a bad or a good thing, flexibility is nice too, but we're talking about passing around strings referencing method names everywhere and dependencies on nodepaths, etc. It should be fine, but it warrants being a little more careful.
• The feature-to-feature documentation is pretty sparse at times, the docs have a lot of good info there but if you come across a random property on some node type it's very likely that it's not documented at all.

All that said I'm really thinking that this is probably going to be the way to go moving forward. I'm pretty excited!

Since I'm working solo for this project, I also just want to focus on something old-school and fun. Whatever it is, it should feel like some old gameboy game with awesome chiptunes and such...

My overall goals for this compo:

• Have a good time using Godot :D
• Try to make a nice aesthetic using a limited palette -- maybe 4 colors, or maybe 8 or 16 if I'm feeling adventurous.
• Make something fun in the oldschool way :)

I unfortunately still have a couple things missing from my starter code -- things like site locking, etc. that I might try to cram in, but I've also gotta catch up on sleep at some point...........

I'm also practicing speed-composing tonight at One Hour Compo in a bit! I'll try putting together a dummy soundtrack in a single hour for practice.

Phew...thanks for reading. See you all at the starting line!