How complex must hit detection be for sports games?

I'm planning out a game of modern roller derby. The game must keep track of 10 player objects (technically, blocker objects could be controlled as one object in many cases) and those objects must be in bounds. The track line is considered as part of the track. If a player objects' skate touches outside the line, you're Out of Bounds, in which a set of rules and possibly penalties apply, depending on your subsequent actions. Generally, the bulk of them won't be OOB unless pushed outside. Here's an example of that happening in a real-life bout.

WFTDA rules specify a track to be 15' wide at the jammer line, and 13' wide at the pivot line; a relation which repeats at the opposite side of the track. This is not only to compensate for centrifugal forces, but has also become an important tactic. It is easier for the jammer to pass where the track is wide, so you'd want your teams' jammer to pass there, and the opposite teams' jammer to engage where the track is most narrow. Therefore whichever team controls the pacing of the laps at the moment has the upper hand. It's an important dynamic and i want to keep the track relatively as is for this reason.

I'm almost 98% positive i'm going for a two-by-three screens big, parallel projected, isometric view for this design. It has some pros, including providing a good view sense of the playfield and player positioning, and less likelyhood that player object sprites stack up, exceeding the 8-sprite limit. I had originally planned 2x2 screens, but that made the track feel too small. I might roll back if the meta-sprite size is too much.


A perfect geometrical representation that looks ok at low resolution took way too many unique tiles to make, so i scrapped it. This is a fairly decent compromise, although i'm concidering scrapping different colours for inside-bounds/out-of-bounds (it would conserve ~50% of track tile space and leave enough room for off-track decorations).



What would require the least computation? I don't know much about what my options are when it comes to hit detection. I was thinking of identifying Out of Bounds as contact with colour 0 (the one used off-track), but that goes down the drain if i am to conserve tile space and skip the off-track colour being different than the on-track one. Which leads me to think i should check for a special out of bounds clause whenever the player object is in contact with the line colour. It needs to be convincingly precise. The game would be ruined if this condition was off the mark by too much. Something like "if block containing line is touched, check LUT. if horzposition this then vertical must be at leat that". Am i on the right track? What options are there?

As a bonus, here's a still pic of 4 out of 6 frames for flag animation and a victory decal i made. You'd collect decals and stars, much like mario kart for completing tournaments at different difficulties.

Note: 8-way scrolling and a status bar means this would use cheapocabra's 8kB nametable RAM.

Even though, visually, you see isometric... I would have all positions represented in memory "as if it were a top down view", and then calculate every position using some rough trigonometry LUTs, to draw them on screen.

Collision should be 1.when object touches object, and 2. when object touches collision map bounds. All should be abstract in memory, and unrelated to what you see on screen.

I like it so far. Good idea.

Detecting whether a point is within an arbitrary polygon shouldn't be that hard: a bunch of adds and two multiplies per edge.


Or if you have an interval timer, plain old vertical mirroring can make a stable status bar.

If the shape of the track is constant throughout the entire game, I see no problem in storing a collision map as a 1bpp bitmap. At 3x2 screens you'd need 46080 bytes to represent the entire background, which is not exactly convenient when you can only address 32KB of ROM. Personally, I'd reduce the resolution of the collision bitmap in half, horizontally and vertically, so that only 11520 bytes would be needed, not an unreasonable amount of space for something that will be used during the whole game. I would simply check a point at the bottom center of each character against this map to tell whether they're outside the track.

As for player X player collisions, I'd use regular AABB collisions of rectangles at the base of the characters.

and This sounds like the least computational way to do it, thanks! Considering that a good portion to the left and right of the three-screen width is just there to pad the actual track with surroundings (the current total track width is ~2 screens wide), the bitmap size could be made a bit smaller and a bounding box could be used for the rest, if needed. So those 11k could be reduced even more.

The size and layout of the track is always the same, so there's only need for one map. What changes (from a gameplay perspective) between locales is the floor material, which affects parameters like hardness and friction. Hard floors mean more speed for less energy spent, and vice versa. Friction plays an important role in curves and stops. Common materials include concrete, wood with different coatings, and polyutheran/vinyl/rubber mats. I'll probably boil them down to 3 to 6 variations.

I searched and found this SE thread. Is this what you meant? Sorry, my education didn't involve much math so i find myself googling/wikiing/guessing my way through these concepts way too often.

I also found this article on point-in-polygon methods but weren't able to determine whether that'd be useful or not (looking at ray tracing).

Here's a sprite doodle.


(edit: updated the attachment)

Forming a triad is a common tactic for blockers when the opposing jammer is engaging. when the triad rotates and moves sideways, it becomes more difficult for the jammer to pass. I'm experimenting with merging the player objects' sprite groups into one common, 4 tiles wide sprite group, which helps keeping the count down, at cost of tilemap memory.

Not much of an update, but i thought i'd share this simple tile conservation technique:



The skater's body was redrawn a little so it could conveniently use the same 8 tiles for three frames; using the mirroring bit. I hope that's how sprite mirroring works. The rest of the frames excepting the yet not drawn neutral front facing one would be mirrored to be used twice (l/r direction).

The north-facing, half-mirrored frame would in real life result in what is called a "plow stop" if held for more than a split second, but i think it's convincing enough for a fast change of directions.

The skate tiles are meant to be permitted to be a little off-positioned relative the skater position, to create some more fluidity between frames. Likewise, i hope relative positioning will help me a little with simulating stopping, jumping, etc, but we'll see.