EggVenture 2600 (Beta testing feedback WIP)

[+ZeroPage Homebrew]

On 5/26/2011 at 8:48 PM, ScumSoft said:

Thanks to ZPH for getting me back here.

The game is now back in active development.

 

....

 

EggVenture 2600 (V3) is being fixed up, lot's of bugs were introduced in the remake.

That's amazing news!! Can't wait to play V3 on the show when it's ready

[+ZeroPage Homebrew]

We'll be featuring the alternate version (V2) of EggVenture 2600 LIVE on tomorrow's (Friday) ZeroPage Homebrew stream on Twitch at 6PM PT | 9PM ET | 1AM GMT! Hope everyone can watch!

 

Twitch Stream: https://www.twitch.tv/zeropagehomebrew/

 

Games:
- EggVenture 2600 (2011 WIP Update / V2) by Jurell Silks aka ScumSoft
- Go Fish (2005) by Bob Montgomery aka vdub_bobby
- Sky Jinks (1982 Patch Challenge) by Bob Whitehead of Activision

 

EDIT: Archive Video of Stream

(SET VIDEO TO 1080P60 FOR FULL QUALITY)

Edited September 1, 2019 by ZeroPage Homebrew

[ScumSoft]

Updated first post, the game is complete! demoted to Beta Feedback Version!

Bumpity bump bump!

Enjoy everyone, there is a strong possibility of a cartridge release provided that this plays properly on everyone's real hardware,

so in the mean time I'll be optimizing the game and getting it to running 100%.

Edited January 3, 2021 by ScumSoft

[+Philsan]

Hi Jurell!

 

It's been nine years since we knew each other and I am glad you're ok!

 

[ScumSoft]

Great to see you're still around and ok also! I popped in every now and again till 2016ish then was away till ZPH roped me back in

I'm really glad they did, because it's time to finish what I started 11 years ago!

I'll be around much more often now.

[+ZeroPage Homebrew]

Welcome to 2021 and Happy New Year! ZeroPage Homebrew has the Exclusive WIP Update of EggVenture on Friday's (Jan 8, 2021) stream LIVE on Twitch at 6PM PT | 9PM ET | 2AM GMT! Hope everyone can watch!

 

 

Twitch Stream: https://www.twitch.tv/zeropagehomebrew/

 

Games:

• EggVenture (2021 Exclusive WIP Update) by Jurell Silks @ScumSoft
• Q*Bert (2021 Exclusive WIP Premiere) by Silvio Mogno @Silvio Mogno
• Tap-A-Mole (2020 WIP Update) by @quohog

 

(SET VIDEO TO 1080P60 FOR FULL QUALITY)

 

Edited January 10, 2021 by ZeroPage Homebrew

[ScumSoft]

It's a pretty hefty update at that!

Changes quite a few things and tons of performance optimizations, runs about 90% at 262 scanlines now, but there are still a few areas that need some adjusting.

Looking forward to the show!

[Thomas Jentzsch]

After playing myself and watching last night's ZPH show, I feel that I should add some feedback too.

 

I really tried to play this update, but currently IMO it plays (much) worse than the old version. It looks great and promising, but the controls and the bouncing are totally killing it for me. And I am a great fan of gravity games.

 

The playfield bouncing is just too much and also feels more like being inside a pinball than a real world. E.g. when I fly to the right and down and bounce at the bottom, I should bounce to left and up, not right and up. Also the bounce must not add energy but at least slightly reduce it.

 

As much as I would have liked the game (lots of potential), currently it doesn't work for me at all. Sorry.

Edited January 9, 2021 by Thomas Jentzsch

[ScumSoft]

7 hours ago, Thomas Jentzsch said:

After playing myself and watching last night's ZPH show, I feel that I should add some feedback too.

 

I really tried to play this update, but currently IMO it plays (much) worse than the old version. It looks great and promising, but the controls and the bouncing are totally killing it for me. And I am a great fan of gravity games.

 

The playfield bouncing is just too much and also feels more like being inside a pinball than a real world. E.g. when I fly to the right and down and bounce at the bottom, I should bounce to left and up, not right and up. Also the bounce must not add energy but at least slightly reduce it.

 

As much as I would have liked the game (lots of potential), currently it doesn't work for me at all. Sorry.

I appreciate the feedback, this is why testing is very important. The level geometry does not simplify the collision detection and makes it much harder to deal with, the reverse bouncing is also part of the games puzzle mechanics and as stated in the first post "might" be required for the more advanced modes areas. However I do agree that it can get out of control and hard to recover from and this is something I am looking into tightening up, if the players wish to bounce on a trajectory off the floor that is something I can probably do without breaking some puzzle mechanics, however as it stands right now the old version would kill you on playfield collisions, I do not really understand how this was "better" as it was deemed too difficult?

 

I will probably post a video showing how the mechanics are intended to work, but I also don't want there to be a massive learning curve involved with the game.

Thanks for the feedback, in the upcoming updates things will be balanced and improved to avoid frustrating any players.

[Thomas Jentzsch]

7 minutes ago, ScumSoft said:

I do not really understand how this was "better" as it was deemed too difficult?

Flying was easier there too. So it was easier to avoid the collisions.

[ScumSoft]

In the original 2011 builds there were no joystick/D-pad velocity adjustments so it was demanded from the player that you control the characters movement precisely, there was no room for sloppy control when the playfield would kill you on contact. This is akin to your game Thrust. 

In my game the level geometry is very jagged and there are tight spots to fly through, so during initial design my family found it very frustrating to play and wanted it to not kill the player on contact.

I initially added a health meter that would deplete on playfield contact before killing the player, but they didn't like that the playfield was sucking in the player due to the complicated collision code not reversing the players directions on hit. The first builds did have real world trajectory physics! but this lead to complications in collision detection, normally 2600 games have very flat surfaces which greatly simplifies the collision detection and/or prevention, something that was NOT easy to do in this games complex level geometry with its multiple collision points.

After lots of testing and changes, the collision code was doing a much better job preventing the player from getting stuck, however this made the world VERY bouncy.

 

I am still fine tuning it to not go so out of control, so that is still WIP and not final  I had added a few puzzle mechanics that make use of the bouncing, so if I get rid of it entirely or tone it down then those elements will have to be changed as well.

 

I'll see what I can do to balance everything out, I want everyone to enjoy the game without it being too frustrating.

Thanks for the feedback, it is greatly appreciated!

Edited January 9, 2021 by ScumSoft

[quohog]

I love the look of the game--awesome chicken animation and beautiful cave! The promise of it being a puzzly version of Thrust + Adventure. But I was also frustrated with the controls, mostly with how they reversed your direction when you glanced a wall. That just feels wrong. Like not how physics would work, even for a chicken in a cave.  I hope you can find a way to make the puzzles still work and not have the direction-reversing bouncing.

 

Also, from the video I assumed the flight controls were based on Joust, but I think I was wrong about that. But I feel like that might have been fun and challenging if they were.

 

Good luck!

[+Karl G]

It seems like the physics of correct bouncing against an irregular surface like that would be difficult to pull off, though. Maybe there could be some heuristics to simply it, but having it still feel mostly correct or intuitive.

[ScumSoft]

[edit] Allow me to correct myself here, the solution is not nearly as complicated as I thought it would be. There is no need for pfreads at all in my case. All I need to do is seperate out my velocity checks.

Edited January 12, 2021 by ScumSoft

[Thomas Jentzsch]

41 minutes ago, Karl G said:

It seems like the physics of correct bouncing against an irregular surface like that would be difficult to pull off, though. Maybe there could be some heuristics to simply it, but having it still feel mostly correct or intuitive.

Yes, that's not easy. It would already help if the player looses significant speed when bouncing.

 

For the correct bounce angels, you need to know if you hit a playfield vertically, horizontally or both. But maybe you can (roughly) determine by using the position and the speed of the chicken? On a collision, you subtract the x- and y-speeds for the current x- and y-position. If the collision happened horizontally, the old and new x-positions must have crossed a 4 pixel (PF block width) interval. If the collision happened vertically, the same is true for a 8 pixel interval. If both directions cross the interval, the chicken has hit a corner and bounces back.

 

The idea is untested, but at least at first glance it might work.

 

The irregular shape of the chicken makes things more complicated, but e.g. a bounding box or checking collisions each line can improve the detection.

 

 

[Thomas Jentzsch]

Here is a quick, rough test program which seems to work quite well.

PF_collisions_000.bin

[ScumSoft]

I've written this game in 99% pure bB, so your example would have to be adapted to that. I'm not opposed to assembler at all, just trying to stay in bB as an exercise of the language.

 

Currently the variables are defined as 8.8's 

Quote

    dim P0posX       = player0x.a
    dim P0posY       = player0y.b
    dim P0velX        = c.d
    dim P0velY        = e.f

 

and the collision code is done simply as: (With SafeX and Y set when there is no collision happening)

Quote

        P0velX = 0.0 - P0velX
        P0velY = 0.0 - P0velY
        player0x = SafeX
        player0y = SafeY

I did not entirely understand what you were talking about, so could you explain in a bit more detail? It looks like from your example that this is a very elegant solution to the problem I have here.

 

Edited January 12, 2021 by ScumSoft

[Thomas Jentzsch]

6 hours ago, ScumSoft said:

I've written this game in 99% pure bB, so your example would have to be adapted to that. I'm not opposed to assembler at all, just trying to stay in bB as an exercise of the language.

That might become a problem, because I haven't touched bB at all yet. And I am much better with coding than explaining.  

In my example I am also using 8.8 (hi/lo) math. So your P0posX is xPosLo/Hi in my code, P0velX is xSpeedLo/Hi etc. So that's pretty similar.

The basic idea is, that in case of a collision, I convert the sprite position into a PF position (simply by diving by 4/8) and compare that with the converted positions of the previous frame. When the converted x-position has changed, the sprite bounces horizontally (P0velX = -P0velX). In case of the y-position it bounces vertically. And if both have changed it bounce in both directions.

 

Now when moving left (or up) I can use the sprite position directly for the conversion. When moving right (or down) I am using the right (bottom) pixel. So I have to add the width - 1 (height - 1) before converting.

Also I move the sprite outside the PF by using the previous positions. I suppose that what you are doing with SafeX/Y.

 

My code is also adding friction to the movement, by subtracting a fraction (e.g. 1/128) of the current speed from the current speed each frame. Which means the friction is not constant but depends on the speed. IMO this feels pretty realistic and also automatically limits the maximum speed. E.g. if I add 0.12 each frame when accelerating and use a fraction of 1/128, then the maximum speed is reached when 1/128 of the speed equals 12. Therefore the theoretical maximum speed is 12 * 128 = 1536 = 6.0. This speed is reached asymptotically, the faster you already move, the slower you accelerate. 

 

[ScumSoft]

Thanks for explaining your solution. I only need to make a small change then in my code and it should work similar to your example then. I do track the prior frame positions with SafeX,Y. The velocity rolloff is subtracted each frame at a constant value, along with limit checks.

The only thing I wasn't doing was seperating out the velocity changes based on which direction we were moving, I thought pfreads would be required and those are too expensive to use. I wrote a gravity bouncing ball test just fine in other languages, but the code was simplified to a box, so I had trouble adapting the principles to the complex geometry in this.

Looks like I only need to add two checks and we are done with the collision issues.

 

Thanks for the insight.

[Thomas Jentzsch]

Sorry, but there will be (a bit) more. Your shape is not a square like in my example. I am currently experimenting with my code to make it work with more random sprites.

[ScumSoft]

4 hours ago, Thomas Jentzsch said:

Sorry, but there will be (a bit) more. Your shape is not a square like in my example. I am currently experimenting with my code to make it work with more random sprites.

Not at all, in fact it was rather trivial to get working properly last night. I had been referencing my old bouncing ball demo written in Pascal long ago and overlooked that I did conditional checks on the velocities, something I did not do in this code. It matters not if the Sprite isn't a bounding box, the non active pixels clipping into the playfield make no difference since the player sprite is fully reset into a safe area after collision is detected.

My code was already setup for working with this properly, I just needed to separate out the X and Y velocity assignments and not set them both at the same time.

Thanks for your interest in this issue though, you are a great coder for sure. You should look into bB sometime, its just a stepping stone for new users to get into 6502 assembler. Though it has it's shortcomings, its fun to push the limits of it.

 

I'll post the next build of the game sometime soon, I had my cousin playtest the latest changes and he found some issues that I am currently correcting.

Edited January 12, 2021 by ScumSoft

[Thomas Jentzsch]

11 minutes ago, ScumSoft said:

It matters not if the Sprite isn't a bounding box, the non active pixels clipping into the playfield make no difference since the player sprite is fully reset into a safe area after collision is detected.

Hm, actually I would be surprised if this works without problems. But I am looking forward to the next build to stress test.  

[Thomas Jentzsch]

Attached is a small update for a randomly shaped sprite. The basic idea is the same, but with two modifications:

• If in case of a collision no bounce is detected, both axes are bounced (this is not 100% correct but works well).
• When moving the sprite out of the playfield by using the previous positions, the sprite bounced at double speed for one frame. Now any speed change is blocked for the next frame and the sprite is moved by the normal movement code.
  Note: This would need good testing, there might be corner cases where a sprite gets stuck. Then the old way would be better.

PF_collisions_003.zip

[+Karl G]

29 minutes ago, Thomas Jentzsch said:

Attached is a small update for a randomly shaped sprite. The basic idea is the same, but with two modifications:

• If in case of a collision no bounce is detected, both axes are bounced (this is not 100% correct but works well).
• When moving the sprite out of the playfield by using the previous positions, the sprite bounced at double speed for one frame. Now any speed change is blocked for the next frame and the sprite is moved by the normal movement code.
  Note: This would need good testing, there might be corner cases where a sprite gets stuck. Then the old way would be better.

PF_collisions_003.zip 3.21 kB · 1 download

Cool stuff! I may have to, um, "borrow" some of this for my R.C. Sumo Bots game, if I ever pick that back up.  ?

[Thomas Jentzsch]

2 hours ago, Karl G said:

Cool stuff! I may have to, um, "borrow" some of this for my R.C. Sumo Bots game, if I ever pick that back up.  ?

You are more than welcome.