New game uploaded: Flappy X16

[ZeroByte]

11 hours ago, kliepatsch said:

can say I'd call it "Exponential Decay Simulator".

Hahaha - that's amazingly funny. Thanks for the feedback. As it stands, the forced delays / taps required to cycle through the gameover sequence aren't correct and feel a little jarring - I'm gonna tweak those, but last night's mission was "fix the damned keyboard routines." Glad to hear that you find that it plays well. I spent quite a while tweaking the parameters to get it like this. I'm a stickler for details.

[SlithyMatt]

Like you say in the description, the physics make it even harder than the original Flappy Bird. You need to be able to slow down the falling. It's like gravity is about 50% too strong. Also, the original FB was kind enough to make the first few gaps a little wider.

[ZeroByte]

3 hours ago, SlithyMatt said:

Also, the original FB was kind enough to make the first few gaps a little wider.

It definitely didn't do that. I've watched very much footage of original iOS Flappy Bird to replicate it as faithfully as possible.

 

3 hours ago, SlithyMatt said:

t's like gravity is about 50% too strong.

I know what you mean. The main problem is that if I reduce gravity then the opposite problem occurs: it's too hard not to smack your head on the top pipe. Ideally, the gap would be about 8px wider, but I'm using 16x16 tiles right now. I've told myself several times that I need to change that, but I just haven't felt like going through refactoring that much code and graphics assets. It'd be worth it in the end, but I've always had more pressing things like un-implemented features to contend with.

I'm facing certain challenges in tweaking the physics, stemming from some design choices.

• 
  My current "collision" check method breaks if I vary the horizontal spacing of the pipes - I should just check screen tiles, whereas instead I'm cycling a queue of the gaps' Ymin Ymax values and applying them at certain values of the scroll register. I need to just check screen tile values instead so that's not a problem anymore.
  


• 
  The tiles are 16x16 which severely limits how many vertical placements exist for a pipe gap (only 8 valid heights) and also limits the vertical sizing options for the gaps. I should probably re-do my tiles in 8x8 mode and double the vertical resolution for gap sizing / placement, and of course, update the drawing routines. The end result would be a screen that looks identical, but allows for more fine-tuned placement of the pipes.
  


• 
  My "subpixel" behaviors are chaotic - for instance, gravity / Vy act as a sort of "fixed point" value, but the bird Y position is a hard screen X Y value, where I should probably just switch to using subpixel screen locations as well - it would give me much more granular control over the affects of gravity and thrust. Yet the pipes' scroll value is "subpixel" (I use 2 bits of subpixel placement to give more granular scroll speed control).
  


• 
  The bird movement is updated every frame, and if I were to refactor the code a little to allow for gravity and movement to only happen on even frames, then the game could be slowed down considerably.
  

In the end, all of these factors intertwine with each other, and it's only going to be some messing around that lets me find the right mix. I think my next step on this front is probably going to be to make joystick controls that let me vary the parameters in real time, with the current values output in hex so I can just play with them live until it feels right. Then just write down the values I ended up with and set them in the #defines. If I can manage to slow the game down w/o having to overhaul these things, then that's going to be what I choose to do, because in the end, this project has been more about getting some experience with C projects - using makefiles, using multi-file projects, organizing everything in a way that makes sense, etc. Having said that, though, I -do- want to produce as well-polished of a game as I can, so now that things are roughly in their final states, flow-wise, I should be able to start focusing on the gameplay tweaking some more.

My ultimate "anchor point" in all of this is the cadence of the pipe gap clearings... i.e. the cadence of the "ding" sound as you successfully clear pipes. Whatever tweaks I make to the physics should result in roughly one pipe gap per second, as that's the rate the original game threw them at you.

 

p.s. - My record on this is something like 32.

[ZeroByte]

I need some feedback from some volunteer play-testers. I've gotten good enough at the previous game settings that this version is insanely easy to me, so I don't think I can be a good judge anymore of the difficulty factor. I've attached what I think might be "normal" difficulty mode now, but I think it's too easy.

What kind of scores can you achieve, and do you think this is too easy to bear the name "Flappy Bird?"


flappyx16.zip

[kliepatsch]

In that version, it definitely isn't as much of a challange anymore, to get past the first obstacle! In 15-20 mins of playing, in the end I regularly got past 10-20 pipes. My high score was 27.

I went back to version 1.1 and tried again. I have definitely improved over yesterday. I raised my highscore to 5, and was able to get 4 multiple times in a row! ? But still, the first obstacle was where I got stuck most frequently. I think I suck at this type of games, but it is simple and enjoyable, and I think training pays off.

I would definitely include the 1.1 degree of difficulty, because it is a nice challenge. I remember the satisfaction when I first got past the first obstacle. Life could be so simple ?

Edit: By including it I mean that an easier mode should also be included.

[ZeroByte]

5 hours ago, kliepatsch said:

Edit: By including it I mean that an easier mode should also be included.

Thanks for the feedback. I came to a similar conclusion last night as well: “Why not have selectable difficulty?”

So last night’s coding session was me moving the game parameters out of #defines into runtime variables and putting the hooks into the loop for selecting between them.

I also had to refactor some code to support variable gap sizes in the pipes, as that’s one of the parameters I tweaked. Fortunately the randomized still feels like it has enough variety with a gap size of 4, so I won’t need to redo everything in 8x8 tiles. Whew.

I WILL need to create a full font for text on the title screen and implement some raster line IRQ code to allow me to have a non-scrolling tile region for the “select difficulty” menu tho. That or else use the copious sprites to draw short amounts of text.

[BruceMcF]

On 5/12/2021 at 6:30 AM, ZeroByte said:

I know what you mean. The main problem is that if I reduce gravity then the opposite problem occurs: it's too hard not to smack your head on the top pipe.

Then have settable wind resistance, which reduces the speed of movements both up and down.

The cute thing about settable wind resistance is you can have a bird that looks more or less fluffy for the different levels.

There is a maximum playable wind resistance, of course, since it also increases the minimum time for a given vertical traverse, so if set too high, the bird cannot make it between pipe openings that are too far apart.

[ZeroByte]

Wind resistance is a much more complex feature than gravity. It varies on the square of speed, and essentially cancels or enhances the effectiveness of other forces.

in last night’s tweaking session I recalled (in a facepalm moment honestly) that if I reduce gravity and thrust together, it will produce the same trajectory but slower, which is how I was able to reduce the difficulty without too much hassle.

im happy to say that my “normal” difficulty settings now produce the same floaty yet rapid fall behavior as the original, and that I was able to make the pipe gaps wide enough to accommodate this.

I think I’ll make another dev vlog on the game where I demonstrate the parameter tweaking and their effects on the game.

[BruceMcF]

4 hours ago, ZeroByte said:

Wind resistance is a much more complex feature than gravity. It varies on the square of speed, and essentially cancels or enhances the effectiveness of other forces.



in last night’s tweaking session I recalled (in a facepalm moment honestly) that if I reduce gravity and thrust together, it will produce the same trajectory but slower, which is how I was able to reduce the difficulty without too much hassle.

You can still make the bird fluffier the easier the settings get, and sleeker the hard the difficulties get, even if it's not PROPERLY wind resistance changing.

[ZeroByte]

Hmmm changing the bird based on difficulty is an interesting thought. It’d mean spending lots more time in Aseprite tho...