It is currently Thu Aug 17, 2017 11:42 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Mon Jan 02, 2017 3:00 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 774
Location: Gothenburg, Sweden
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.
Attachment:
map_sketch02.bmp
map_sketch02.bmp [ 240.73 KiB | Viewed 754 times ]


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).

Attachment:
trackportion2b.bmp
trackportion2b.bmp [ 30.12 KiB | Viewed 754 times ]


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.
Attachment:
15589670_369908930025669_2267255078865519873_n.jpg
15589670_369908930025669_2267255078865519873_n.jpg [ 25.48 KiB | Viewed 754 times ]


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

_________________
http://www.frankengraphics.com - personal NES blog


Last edited by FrankenGraphics on Mon Jan 02, 2017 11:43 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Jan 02, 2017 11:20 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1681
Location: DIGDUG
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.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Mon Jan 02, 2017 11:43 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18793
Location: NE Indiana, USA (NTSC)
WheelInventor wrote:
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?

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

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

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


Top
 Profile  
 
PostPosted: Mon Jan 02, 2017 12:12 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9880
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Jan 02, 2017 5:51 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 774
Location: Gothenburg, Sweden
tokumaru wrote:
storing a collision map as a 1bpp bitmap
and
dougeff wrote:
I would have all positions represented in memory
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.

tepples wrote:
Detecting whether a point is within an arbitrary polygon shouldn't be that hard: a bunch of adds and two multiplies per edge.
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).

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Jan 03, 2017 9:12 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 774
Location: Gothenburg, Sweden
Here's a sprite doodle.

Attachment:
triad pack and lead jammer.bmp
triad pack and lead jammer.bmp [ 30.12 KiB | Viewed 553 times ]

(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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Thu Jan 05, 2017 6:50 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 774
Location: Gothenburg, Sweden
Not much of an update, but i thought i'd share this simple tile conservation technique:

Attachment:
animation frames.bmp
animation frames.bmp [ 127.35 KiB | Viewed 526 times ]


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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group