And, as always, here's the accompanying video
https://www.youtube.com/watch?v=p132jLQWoNQ
#IndieDev #DevLog #GodotEngine #GameDev

#cr20gc #devlog #gamedev #godot

Okay, getting to the end of the week. I want to have this game wrapped-up in some state of "done" before then - there's one last glaring set of issues which once dealt with I will force myself to call it wrap before I get sucked into another round of improvements. After that I can finally move on to the next game to keep building my game-dev skill-set.

Speaking of the next game, I decided to toss things up by swapping out *River Raid* with something I am more interested in and played a pivotal role in developing my love for video games as a kid. Here's a (maybe too obvious) hint as to what game that is:

As a mini-recap, here's what I learned and achieved from this current project:
- I learned a bit about Godot project structure and how I (don't) like to organize things.
- I designed a system which allowed me to dynamically (i.e. recursively load from a path) add segments/levels to the game.
- I learned about and used `@tool` annotations (i.e. running code in the editor) to assist with level-design.
- Learned when to use signals, and maybe when not to.
- I learned a bit more about UIs in Godot (still a long way to go).

And here are some things I wish I got around to learning, but will try and catch next time:
- Audio and sound effects
- Save states and storage
- Scene transitions and loading states

I'll be writing a blog post on this project over the weekend which will include a summary of my process, lessons learned, and the challenges I faced, and of course, a playable version of the game. :) You can expect that on Monday!

#cr20gc #devlog #gamedev #godot

Alright! After lots of state and signal wrangling today and fiddling around with Control nodes, I have a fully working game-loop with menus now! I think I'm finally getting the hang of Godot UI, maybe.

Next up, highscore storage, maybe a scoreboard? I at least want to see what my best score is, and maybe... maybe adding some sounds since I've been avoiding it.

There's so much I *want* to add to improve, for example, some basic transitions between states would be nice. But if let myself keep going I'll never be done. :)

#cr20gc #devlog #gamedev #godot

Ha, I found the source of the problem with my segment system in the first five minutes of work. It came down to a rather silly design pattern I thought I had phased out already but hadn't and was causing my hazards to randomly never arrive on screen, therefore they would never despawn which really gummed-up the works!

So that's fixed now, and some of the segment spawning behaviors are a little more refined and predictable now too, so tomorrow I'll be moving on to the other items on the agenda.

#cr20gc #devlog #gamedev #godot

Oof, fell out of the saddle with these updates, or making any progress to speak of for that matter. But I'm getting back into it now and trying to get Jetpack Joyride wrapped up and pushed out along with its accompanying blog post by the end of this upcoming week at the latest.

The key items on my agenda are (in order of importance):
- Fix my very broken segment system once and for all.
- Get the menus in place (Start, Game-over/restart).
- Implement scoreboard.
- Finish player animations.

And, as always, here's the accompanying video. In addition to covering January/February work, this one also looks back on development across 2024 as a whole https://youtube.com/watch?v=6m7wTKxROVI
#IndieDev #DevLog #GodotEngine #GameDev

#cr20gc #devlog #gamedev #godot

I finished the blog post for the first game on Sunday (https://www.veryth.ink/blog/20gc-flappy-bird)!

It took longer than I wanted it to take, partly because I got distracted trying to reduce the final size of the web version's exported .wasm from 35MB, which just seemed large to me.

I think I got about 90% of the way there but was blocked by some compiler issues when trying to pull off a leaner Godot build. I settled with 35MB this time, but for the next one I hope I can figure out how to slim things down as much as possible (advice welcome).

As for the current game, the segment system has continued to evolve. I realized the way I was attempting to spawn new random segments was flawed.

See, I have several different types of segments which contain hazards or items of a certain type (e.g. zapper, laser, coin, etc.) and they each have rules excluding them from spawning when another segment is active.

The problem was that many times a second I was "rolling" a type of segment and then seeing if the segment could be spawned, if not I would **discard the result**. So naturally, the least restricted segments would occur more often than intended.

To fix this I used a simple queuing system to roll once, waiting for the correct conditions to emerge before spawning and queuing another segment. I also implemented a more robust weighted choice system. This gives greater control over the frequency of different segments and offers more predictable results.

Later I ended up adding a lot of features in preparation of finally getting a gameplay loop in place. The player now has a game over state when hit by hazards - the game gracefully stops, there's a simple HUD for tracking distance and coins collected, a simple start state with a button to get things going.

But in adding these features they revealed yet another issue with my segment system which I have yet to isolate.

I'm going to try and get these posts out more often so it's less of an info dump and more log-like. I have an Obsidian devlog I keep privately, but I could probably just start mirroring what I write there with minor editing.

#cr20gc #devlog #gamedev #godot

Whoops! A whole week went by.

I had to take care of some life stuff, but I've found some time to keep working on this rendition of Jetpack Joyride (doesn't feel accurate to call it a "clone").

There was an obstacle which I didn't entirely foresee as being an obstacle which was implementing the system responsible for queuing-up segments of hazards. I didn't take the time to come up with multiple approaches and as a result ended up with something way too complex. I imagined a use-case I was unlikely to actually, er, use. That use-case being "putting different kinds of hazards in the same segment". I also tried too hard to generalize my code and it just became a brittle mess. So after spending way too long on this I ended up throwing most of it out and replaced it with code that assumes simple non-hybrid hazard segments, and it works really well!

I've been writing my blog post for the last game and am looking to publish that before the end of the week, but outside of that I plan on finally getting some kind of menu/gameplay loop in place for the current game.

And as always, here's the accompanying video
https://www.youtube.com/watch?v=2YhVjhfl00k
#IndieDev #DevLog #GodotEngine #GameDev

#cr20gc #devlog #gamedev #godot

More progress in the last few days! I kept at adjusting my settings (and not fractionally scaling my sprites ) and managed to mostly mitigate any subpixel rendering, which makes the sprites look much more crisp IMO. I decided 64x64 was too big for my sprites and scaled down to 32x32, which is more manageable and gives me fewer pixels to fret over. So after redoing the laser and missile sprites I was back on track. I then blocked out the player animations and jetpack and then proceeded to, you guessed it, go crazy with particles again by adding the bullets, some smoke, and the casings ejected while firing.

Code-wise I polished up the laser behavior and made it possible to choreograph fancier arrangements and timings for more interesting segments. Then I got the zapper behavior in place.

And with that I have all the base hazards in place and have no choice but to work on the main game loop and UI.

As usual, here are some visuals.

#cr20gc #devlog #gamedev #godot

Today I threw down some logic for lasers along with some slightly-more-than-basic art. On that note, I'm still getting used to how to pull off tiling (animated, no less) sprite textures, but I think I've got the gist of it.

For the laser beam I ended up using a `Sprite2D` (not animated) with the texture set to use an `AnimatedTexture`, then I set each frame by exporting the animation from Aseprite as a series of PNGs. After that I had to set Region > Enabled to On, then scale the rect width and height as needed.

Why not use `AnimatedSprite2D`? Because it doesn't have the Region parameter, for reasons?

Also, I couldn't help myself and played with the missile particles more, they look way better now imo.

I kept noticing my pixels not being rendered the way I wanted ("sub-pixel rendering" I later found it to be called) and ended up falling down the rabbit hole of managing resolution and scaling. So many pages of GitHub discussions. Eventually I found this page from the Godot documentation which seems to have a lot of good advice, but somehow I doubt that will be the end of it. https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html

#cr20gc #devlog #gamedev #godot

Last night I got tired of looking at debug colliders and threw some art at the missiles. Got to play around with particles a bit and achieved something close to the game's style. I'm not certain how to make the smoke particles fade gradually, perhaps with a shader? But for now I don't think I should spend much more time with this, I've got a couple other hazards to implement, not to mention the actual game loop!

As usual, here's some visuals. I'm testing a variety of speeds in this scene, mostly as a way of seeing how the particles behave.

#cr20gc #devlog #gamedev #godot

Continuing to have a lot of fun exposing parameters to the editor to make future balancing easier! Yesterday and this morning I worked on adding the missile to my growing collection of hazards, both the homing and non-homing variants. I made it so that I can delay when the alerts come on-screen, making it possible to present a "cascading" set of missiles as seen in the original game.

Here's a video showing the result, still using debug visualizations in lieu of sprites (still not sure if I want to take the art/theme a different direction).

#cr20gc #devlog
(cont'd)

Of course, it would be even better if there were two points I could click and drag around the scene editor rather than having to set the length and rotation separately. I feel this should absolutely be possible, so I might come back to it later, but for now this is a nice improvement.

Today, I plan on getting some art in a rough draft stage so I'm not just playing with debug colliders as visuals, and I might get a prototype implementation of SegmentManager complete.