This is the start of the thread in which I will be documenting my progress as I work through the 20 Games Challenge (https://20_games_challenge.gitlab.io/how/). The idea is to re-create up to 20 classic games increasing in complexity/difficulty with few/no tutorials to learn the nuts and bolts of gamedev and bootstrap my ability to make games! I've committed to at least 1 game a month, but I will likely get more done, depending on what else is going on in life and how complex the game is.
It's been a long-standing dream of mine to make games, since highschool, but life happened (as it does) and I put the dream on hold, and now over a decade later I realized I've been waiting for ideal conditions that may never manifest. It's my intention to break this cycle of complacency I've found myself in by participating in this challenge, and to have fun!
I'll be using these hashtags to help folks tailor what they see from me: #20GamesChallenge, #cr20gc
If anyone would like to join in, I'll be following the main hashtag and would love to see other folks' progress!
[#]gamedev
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]cr20gc So, the first game I decided to work on is Flappy Bird, which I'm creatively calling "My Flappy Bird".
I'm using Godot for the first time, prior to this I've used Unity once for maybe an hour a long time ago, so the learning curve has been a little steep. I followed the Getting Started tutorials from the documentation and it definitely helped! Also been getting a lot out of thumbing through the best practices articles (https://docs.godotengine.org/en/stable/tutorials/best_practices/index.html).
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]cr20gc A few days ago, before starting this thread, I made a rough draft of the sprite art, and I have the physics of the player modeled and tied to input. The parameters are wrong (too floaty) but the fundamentals are there!
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]cr20gc #devlog yesterday, I realized I hadn't actually played Flappy Bird recently and was entirely relying on my memory to mimic it. So I conducted a little study of the game by finding the most reliable clone online and playing around with it, taking notes on my observations. Turns out there were a lot of details I had misremembered! Definitely going to be a first step for follow-up games.
I also spent time trying to figure out how I wanted to manage the pipe and ground entities to get closer to something resembling a game.
Unfortunately, I had to share my time with troubleshooting my environment to get my HiDPI display to play nicely with Godot in Sway (just Linux things) so the interface isn't so fuzzy, so no real visual progress to share.
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]cr20gc #devlog I kept sitting down to work on this throughout the week but kept bouncing off of Godot's interface, and my lack of familiarity with the engine in general. I took some time trying different layouts today and discovered that splitting the code editor out from the rest of the workspace really helps! So with this improvement (and a lot of docs read) I was finally able to put together a rough prototype of the gameplay!
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]cr20gc #devlog
Got a lot done on my rendition of Flappy Bird over the last couple of days!
I'm just about at my limit of how much I want to work on this, but I think today I'll add some sound effects, maybe visual effects (subtle "flash" when hitting a pipe for instance), and then call it good enough to continue to the next game, which I've decided will be Jetpack Joyride!
Here's some gameplay from it's most recent state.
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]cr20gc #devlog
I moved on to Jetpack Joyride yesterday! Still might come back to improve the Flappy Bird clone, but probably not. :)
I started with my "study" of the game, in which I play with it and observe/record the behaviors, mechanics and design.
Then I moved on to implementing the basic player mechanics and got something that felt similar to the real deal. This step was satisfying as I could already feel my practice with Godot paying off, as I didn't have to glance at documentation or prior projects to remember how to simulate physics and handle input.
Later, I started thinking about how to implement hazards. It looked to me like Jetpack Joyride was entirely composed of hand-designed patterns, or "segments" as I'm calling them, in which hazards (or coins) have been arranged in interesting and/or challenging shapes on a grid and presented to the player one after the other at random. So my thought was that I'll build a handful of scenes as segments and then, using some kind of "SegmentManager", cycle through them randomly, queuing them up to move on-screen for the player to face. But not all segments are spatial, some conclude after a set amount of time (laser timing challenges) and not all of them are even exclusive (missile clusters), meaning they can be presented on top of some other segments. So these will have to be handled appropriately by the manager logic.
As I started to design the individual hazards, I encountered an inconvenience where the SegmentShape2D I was using as the collider for a beam wasn't resizing in the editor preview when I would alter the length parameter I had exposed. This is because the code for applying the length only runs in _ready. I figured there had to be some hook or mechanism to allow me to alter the editor behavior, and that's how I discovered the [@]tool (minus brackets) annotation!
https://docs.godotengine.org/en/stable/tutorials/plugins/running_code_in_the_editor.html
So I used this newfound technique to update the beam length preview in the editor, after realizing I needed to duplicate the Shape2D instance to ensure uniqueness across instances. This makes it very quick and easy to design segments where I need the beams to line-up or block certain regions.
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]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.
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]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).
=> More informations about this toot | More toots from crenfrow@hachyderm.io
For those unfamiliar with the game, the missiles featured in this video are what I'm trying to emulate: https://youtu.be/sLqG0M4vMqE?t=26
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]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.
=> More informations about this toot | More toots from crenfrow@hachyderm.io
[#]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
=> More informations about this toot | More toots from crenfrow@hachyderm.io
Here's a video of the new and improved missile smoke particles, improved mostly through changing the alpha settings on the color curve, among many other tiny tweaks and fiddles.
=> More informations about this toot | More toots from crenfrow@hachyderm.io This content has been proxied by September (3851b).Proxy Information
text/gemini