WIP: Dodgeball

[tschak909]

Hello, everyone.

 

I am currently working on getting to a playable state as fast as possible, a game of Dodge ball for the VCS. It has been on my life list for a long time to do, and now I am finally tackling it.

 

It is a 2K cart, done in homage to the original launch titles, in that the graphics are simple, there will be multiple variations around the core game, and the focus is on solid two player gameplay.

 

It will require the joystick controllers.

 

Latest Release:

 

Latest build can be found here: https://github.com/tschak909/dodgeball/releases/tag/playtest1a

 

Basic rules:

 

* Two players, in a playfield, with or without obstacles.

* Players can move freely around field and obstacles

* There is a computer controlled ball (using BL object) which will bounce around the playfield freely using PONG physics.

* Each player also has at their disposal, a ball which can be thrown by pressing trigger (using M0 and M1).

* Ball will automatically retract to player after user settable decay time (short, medium, long)

* if Computer ball hits a player, point is subtracted (unless 0).

* if P0's ball hits P1, P0 gets +1 points, P1 gets -1 (unless 0), and vice-versa.

* if P1 presses trigger at just the right moment when the ball is colliding with player, the above point rule flips, vice versa with other player.

* in both cases, ball is returned to the player, to be used immediately.

* Game ends after timer lapse (the classic 2 minutes 16 timer lapse)

* Game score blinks when timer is about to expire

* Game will indicate ball capture with color cycling display and sound effects

* Each ball bounce will be an appropriate ping.

 

The idea is to have game variations, which will vary the following:

 

* Playfield shape/obstacles

* Player ball retract time

* differences in player movement physics (dodgeball on ice?)

* difficulty switches will set _something_ ... either player size, or the addition of holes on the horizontal ends of field so that ball can wrap around?

 

I am working on the code publically in github:

http://www.github.com/tschak909/dodgeball

 

Once I have the first playable ROM, I will post it in this thread.

 

Right now, the kernel is stable, and the motion code is roughly 30% done. Once the motion code is roughly 90% done, I'll put in the collision detection, and that should be enough to get feedback.

 

-Thom

 

p.s. a picture of the kernel with a playfield that I am borrowing from Combat:

 

[Jinroh]

Oh sweet man, more 2P Games is always welcome and I love me some dodgeball.

 

Can't wait to try it out.

[+save2600]

One of my favorite "sports" of all time, glad to see it's finally coming to the VCS!

 

If starting from scratch doesn't work out for whatever reasons, I wonder if a dodgeball game could be hacked from RealSports Volleyball? Like the player sprites and animation in that game anyway.

[tschak909]

This is more than doable, I have a 2LK that is spitting out playfield (PF1, PF2), two players, two missiles, and the ball. This part works, and right now, I'm trying to get the player control to work right,

 

That is,

 

I want a little bit of speeding up before hitting full speed, and I want a bit of inertia left over when the joystick stops...not too much, just a little...

 

-Thom

[+atari2600land]

I love 2k homebrews. I love seeing how homebrewers can cope with such small a limit.

[tschak909]

For what I'm doing, 2K is more than enough.

 

I'm studying the original titles to see how they did that...Honestly, I'm still about 1200 bytes away from the end of the cartridge, so I still have enough to finish implementation of the motion and collision routines...then I can see how to divvy up the remaining space (mazes, motion tables, etc...)

 

-Thom

[tschak909]

Working on the motion control. Horizontal works, with one bug...

 

 

-Thom

[tschak909]

OK. Workable build here, I have a first pass of velocity motion, no collision detection yet, wanted to get some feedback from people.. It's a little weird, for sure, I will keep tweaking it until I like it, and it's okay, with you guys...

 

Basically, The decay function only decays when no directions are pressed, which, I suspect, needs to be changed to be more granular (when a particular direction ceases to be pressed)...

 

I've attached a bin here, and the source code is available in the 'velocity' branch of the dodgeball project on github:

 

https://github.com/tschak909/dodgeball/tree/velocity

https://github.com/tschak909/dodgeball/blob/velocity/dodgeball.asm

 

Thoughts, guys?

-Thom

 

dodgeball.bin

Edited June 20, 2016 by tschak909

[tschak909]

Ok guys, have an interesting problem.

 

I decided to code a quick bit of Player/Playfield collision detection (CXP0FB,X) and integrate it into the motion code, basically preventing a given bit of motion in a direction if the collision register is latched. This has a problem however, because I may be going more than 1 pixel clock with each change in movement, as I go faster, so I will find myself being embedded into walls, and unable to move... I need to find a more elegant solution to handle this problem...

 

...any thoughts on this from anyone?

 

-Thom

[Arenafoot]

OK. Workable build here, I have a first pass of velocity motion, no collision detection yet, wanted to get some feedback from people.. It's a little weird, for sure, I will keep tweaking it until I like it, and it's okay, with you guys...

 

Basically, The decay function only decays when no directions are pressed, which, I suspect, needs to be changed to be more granular (when a particular direction ceases to be pressed)...

 

I've attached a bin here, and the source code is available in the 'velocity' branch of the dodgeball project on github:

 

https://github.com/tschak909/dodgeball/tree/velocity

https://github.com/tschak909/dodgeball/blob/velocity/dodgeball.asm

 

Thoughts, guys?

-Thom

 

FYI - both links above don't work............

[tschak909]

FYI - both links above don't work............

 

oop, I've merged the velocity branch into master... so...

https://github.com/tschak909/dodgeball

https://github.com/tschak909/dodgeball/dodgeball.asm

 

-Thom

[tschak909]

No thoughts from anyone?

 

-Thom

[Mr SQL]

I checked it out, like that you changed the palette when the BW switch is thrown!

 

The player controls pretty well but doesn't bump into the walls - no collision implemented yet I guess.

 

Looking foward to trying the next build.

[tschak909]

I'm not happy with the motion controls yet, I will have to rethink it, as it's a bit weird, when you're already moving in a given horizontal direction, and you add a diagonal direction, you tend to 'arc' ... I'll deal with that once I get some collision detection working...

 

As for re the B/W switch..yes.. I am trying to properly implement all the switches, etc... including the difficulty switches (which will set the player size).

 

Thanks for trying the build.. more coming!

 

-Thom

[Kiwi]

Hopefully I can give you some idea how the collision could work. When you're colliding into a wall,and the hw collision pick it up. When it picks it up, push your Player's x or/and y position out of the playfield block so it doesn't get picked up by the hw collision on the next frame. based on the velocity it is. And then flip the velocity.

[tschak909]

Yup, my goal is to use a form of PONG physics, but I need to deal with the player bits, first. The collision detection is made a wee bit more difficult by the fact that my motion code has some Newtonian acceleration/deceleration bits in it.

 

-Thom

[+atari2600land]

I just looked at this. I would make player 2's color different than player 1's in B/W mode. Having them both be the same would be confusing.

[tschak909]

I just looked at this. I would make player 2's color different than player 1's in B/W mode. Having them both be the same would be confusing.

 

Yes, it's a bug on my list.

 

-Thom

[tschak909]

Added start of collision detection, starting with P0 and P1. The velocity decay code is making it do interesting things, at the moment, so that's on my list to squash.

 

(I'll also go ahead and fix the black/white palettes)

 

As always,

 

Main Code Repository: https://github.com/tschak909/dodgeball

Main ASM code: https://github.com/tschak909/dodgeball/dodgeball.asm

Commit with collision detection code: https://github.com/tschak909/dodgeball/commit/973120acb004130e2fb85221a11efe37a66cc86f

 

And latest code attached.

-Thom

 

dodgeball.bin

[tschak909]

Hi everybody. I've done some refactoring on the kernel to try and make the output closer to Combat (the display now fills the entire frame in Stella). I would love to know if this display rolls on a real system??? (I am according to Stella outputting 262 lines @ 60.00Hz, but I'd love to know 100% for sure)

 

I've also fixed up the B&W palette a bit.

 

-Thom

 

dodgeball.bin

[+atari2600land]

I just tested this on a real 2600. The screen rolls when the color changes and you're using the joystick. Also, I was able to get my way out of the playfield.

[tschak909]

Yup. collision and motion are going to be wonky, for a while, as I work through some stuff.

 

I am hopefully getting my Harmony, this week, so I can test on my newly acquired hardware.

 

-Thom

[tschak909]

Am losing...my...%#@%@#(..mind...

 

the velocity/decay routines make for smooth motion, but correction from collision detection is nothing short of a fucking nightmare! Need a second pair of eyes to see where I'm screwing up.

 

-Thom

[Omegamatrix]

Are you doing hardware collisions? If so then consider switching to software collisions.

 

1) Have a variable for the X position, as well a Y position.

2) Read the joystick, add in your velocity, and come up with the next X and Y positions. Store them as temp variables for now.

3) Check if there are any playfield blocks between the old position and new.

- If no blocks were in the way, store the new positions and exit.

- if blocks were in the way, either:

a) Place the object directly in front of the playfield and kill all velocity (dead stop). Update new positions and exit.

b) Bounce off the playfield (reverse direction, and figure out how many pixels the bounce should be). If motion is in two directions, You can bounce off a wall while keeping one direction (i.e. traveling up-left ----> hit wall ----> travel up-right, so direction changed only for the x-axis). What's important about two directions is you have to be aware that rebounds like this can end up back in a wall. So you have to program to avoid that. Then update new positions and exit.

c) Hit wall and slide (this is for traveling in two directions only). Finally update new positions and exit.

 

 

Example of bouncing off a wall into a wall:

 

 

 

That should get you started.

 

Before you start remember that how you store the playfield blocks in rom are not always how they appear on the screen. Some will be reflected. You need to figure out which parts are reflected and which are not. (ie which parts of left side PF0,PF1,PF2, and right side PF0,PF1,PF2 are reflected when compared to how it's stored). When checking the date you have to flip the playfield bits which are reflected in rom, or write some convoluted code just to chose the right bit.

 

One thing you might consider is making a copy of your playfield data that is already correctly orientated so you simply don't have to deal with any of the flipping, or figuring out if it needs to be flipped. You can also overlap the data to save bytes, and it is very fast. It also might not waste as many bytes as it first appears. Often with the 2600 you will spend a long time writing some code only to realize it takes more bytes then a look up table and way slower.

[+DZ-Jay]

I don't know your code, and I haven't seen your game (and as a matter of fact, I'm not even a Stella programmer). However, I would like to help if possible. One alternative mechanism for ricocheting objects off walls is to consider a table of outcomes for each possible state. This is very useful if your angle of incidence and velocities is not arbitrary (e.g., you can only go at specific angles, say, 90, 180, 30, 45; and at specific velocities).

 

 

 

Am losing...my...%#@%@#(..mind...

 

the velocity/decay routines make for smooth motion, but correction from collision detection is nothing short of a fucking nightmare! Need a second pair of eyes to see where I'm screwing up.

 

-Thom

 

I may not be able to help with your code (I really have no time or inclination at this moment to learn an entire new platform); but if you describe your algorithm or provide a low-level description of your post-collision correction mechanism, perhaps I can assist.

 

-dZ.