Discussion: ModSurfer

[arcanist]

Title:
ModSurfer

Genre:
Rhythm

Original concept:
No. Heavily inspired by the PC game AudioSurf ( [ Show youtube player ]), which builds a track with synchronized bends/hills and items to collect from an audio file. ModSurfer will derive the track from a MOD file.

Expected game size:
Each game will last up to the length of the selected MOD file (or until it loops). MOD files will be provided by the player from their collection.

Team members (Real or forum names):
arcanist

Targeted spec:
A500 with 1MB. Larger MOD files will need more chip RAM.

Tools to be used:
GCC and VASM. ptplayer to handle audio playback.

Description of game:
From the title screen the player selects a MOD file from their collection, through a simple file browser with a MOD header decoder.

The track and sample data is pre-processed to build a 3-lane pseudo-3D (Lotus-like) track with synchronized curves and hills. Items will appear on the track in time with the beats to collect. Hazards may be added later but the goal is to keep the experience as relaxed as possible.

Scoring is based on the total percentage of items collected. Difficulty will vary with the speed of the MOD file and its samples.

[Ian]

Looks like a good little game will probably live or die on the mods though.

Best of luck to you

[roondar]

This sounds quite interesting, though for the final product I'd suggest offering a few example modules that get good results

[arcanist]

Originally Posted by roondar

This sounds quite interesting, though for the final product I'd suggest offering a few example modules that get good results

Yes, I'll definitely link to some tested tracks on modarchive.org to get started.

I hope to get compatibility good enough to work with any ProTracker mod. The tricky part will be tweaking the algorithm to adapt to mods with different speeds and instrument density. Hopefully it'll work out, or at least produce some hilariously broken tracks.

[saimon69]

i could help you with custom mods

[arcanist]

Originally Posted by saimon69

i could help you with custom mods

You'd certainly be more than welcome to.

I couldn't offer much guidance yet for making a ModSurfer-friendly mod. Samples that fit ADSR envelopes would probably work better than composites of multiple beats, as the attack strength is how I plan to identify good candidates for pick-ups on the track.

Or you might enjoy making music for one of the other entries here, to save our ears from the inevitable "programmer music".

[saimon69]

If you find a way to use four channel XM that might help, since there are ADSR parameters for instruments there

[arcanist]

This is a prototype of the "track" on which the player moves. I've added keyboard (A/D left/right, release to center) and mouse control. This method trivially supports track bends left and right, by shifting scanlines, and can also show hills.

On each scanline the copper programs a 3x1 pixel sprite to appear at the left and right stripes, loading data manually to avoid DMA. The positions are calculated using an integer Bresenham algorithm with perspective-correct lines.

I did some limited optimization to get it running on an A500 at 50Hz but haven't rewritten the code in assembly yet. I ran into an issue with ptplayer's timer interrupt on the emulated A500 causing an odd delay when it coincides with the vblank (I have VERTB interrupt disabled). For now I recorded on an emulated A1200.

The next step is to decide between this approach and Lotus's method, which blits from a precalculated image on each scanline. I'd guess the copper method is faster (six CPU word writes per scanline) for a bare track.

However, next I want to introduce the "blocks" the player will try to hit. There may be quite a few on screen; certainly more than the sprite channels I have. Reusing channels down the screen is one option but difficult to pull off when the blocks overlap. Displaying them as bobs would be asking a lot out from the blitter. The upside is the blocks could be displayed as vertical objects.

I'm considering a different idea: making the blocks flat on the track. It's less visually impactful than hitting a vertical object but I could spruce it up with sprites when the player hits one. The advantage of this is I could merge it with the Lotus approach; on each scanline there would be 1 of 8 configurations (0-3 blocks across the lanes) and the program would pick a line from eight pre-calculated images to blit. The blocks would also have perspective depth with this method.

[ Show youtube player ]

[mcgeezer]

That is really really cool!

Brings me back to my Guitar Hero days!

[DamienD]

Yup agreed

Well done so far arcanist, looks like you've got the basics working well so now it's just a matter of building upon this

...not that it matters one bit, but there is a similar game (in concept) already on the Amiga, but it requires AGA: Tracker Hero

[arcanist]

Originally Posted by DamienD

...not that it matters one bit, but there is a similar game (in concept) already on the Amiga, but it requires AGA: Tracker Hero

I hadn't come across that one in my initial search. Will take a look after I've finished the game so it doesn't influence me too much.

Until I saw the coder contest announcement I was planning on trying something like this on the C64. Obviously a lot more limited but I wanted to see if I could derive a track from a SID program, or by sampling the volume in real-time. I might still try that later on.

[ReadOnlyCat]

Nice idea! Keep it up.

[arcanist]

Here's a bonus failed attempt!

I had an idea to implement perspective by drawing the track stripes and blocks into an image, with the camera centered, offline. I then programmed the copper to set the bitplane fetch/scroll on each scanline with a shift corresponding to camera movement. The shift is calculated as a line extending from the near plane to the far plane.

Objects could then be shown/hidden per scanline just by writing color/black to the four color registers. Genius, I thought!

It turns out that drawing lines in the centered camera image "bakes in" sub-pixel errors. When it's shifted by another Bresenham-calculated line the combined error becomes super-pixel and the lines, while following the correct paths, go all wibbly.

I went to YouTube to see how Lotus 2 solved this and apparently they didn't! If you watch the road markings there's a lot of artifacting. They just move everything so fast I never really noticed.

Guess this approach isn't going to work out. Back to sprites!

[ Show youtube player ]

[Nightshft]

This could get fun

Just an idea: For the game to be enjoyable the tracks/levels have to be good. Maybe it would be better to separate a level (track) editor and the game itself. People could create tracks to their likings then - which could be a manual or half-automatic process. I guess I'd even prefer manual if it's easy to use - which in turn, also would mean one problem less to solve for the coder.

For example stepmania, which is a pc freeware dance-dance-revolution clone has a level-editor. And it makes perfect sense.
Action in the video starts at 4:30
[ Show youtube player ]

[arcanist]

This week I added some more graphical elements and fixed/optimized for the target A500 platform.

I've settled on the 3D display implementation. The tracks and blocks are pre-rendered to a bitmap with each lane in a different color (1 = lane markings, 2/3/4 = blocks across lanes). The copperlist looks like this, repeated for each scanline:

 0001ea04: 7201 fffe          	;  Wait for vpos >= 0x72 and hpos >= 0x00
                        	;  VP 72, VE 7f; HP 00, HE fe; BFD 1
 0001ea08: 0108 0004          	;  BPL1MOD := 0x0004
 0001ea0c: 010a 0004          	;  BPL2MOD := 0x0004
 0001ea10: 0102 0066          	;  BPLCON1 := 0x0066
 0001ea14: 0182 0000          	;  COLOR01 := 0x0000
 0001ea18: 0184 0804          	;  COLOR02 := 0x0804
 0001ea1c: 0186 0000          	;  COLOR03 := 0x0000
 0001ea20: 0188 0000          	;  COLOR04 := 0x0000

The first three lines set up bitplane shifts for the next scanline (BPLxMOD) and the current scanline (BPLCON1). Both work together to shift each line of the pre-rendered display into a perspective-correct position for the current camera view.

The COLOR register writes show/hide the lane markings and blocks in each lane. During each frame the CPU updates these entries to reflect the state of the track as it moves towards the camera. This is where the bulk of CPU time is spent; currently 2/3rds of a frame but I think I can optimize it further. The copperlist is double-buffered so that the CPU can work outside of the vertical blank.

This approach makes it trivial to curve the track left/right (shifting the scanlines accordingly) and even add hills/dips like Lotus, by compressing/expanding Z increments down the image.

I plan to add sub-pixel anti-aliased lines to the bitmap to soften the visual artifacts but right now I want to implement all the basic game elements. Instrument selection for blocks on the track is the biggest piece of work remaining.

In the video below I've manually selected three lead instruments to give a rough idea of how the game will play. I expect I'll add non-collectible blocks to make pathing a little harder.

[ Show youtube player ]

[alpine9000]

That's looking awesome!!

[arcanist]

I've started work on instrument selection. The goal is to find good samples in each pattern to correlate with collectibles on the track. This needs to work with any mod the player might provide.

The first piece I've chosen is pitch detection. We want to avoid repetitive drum/bass instruments and pick out the leads. Lead instruments will generally play at a higher pitch so this will form part of the "score" assigned to each instrument.

The dominant frequency in each sample is retrieved from its frequency spectrum, computed with a FFT on the sample data. This is combined with the playback pitches to calculate a per-pattern mean pitch.

To show how powerful this is by itself, the video below shows the game choosing instruments just by their pitch. This contrasts with the previous video where I picked a few instruments by hand. (The code isn't optimized yet so please gloss over the startup time. )

I plan to add further weighted components to the instrument scores. Per-pattern playback counts and mean volume are low-hanging fruit. I have some other ideas but to explore them fully I'm going to implement a debug overlay in the game to show the scores in real-time as the song plays.

[ Show youtube player ]

[DamienD]

Wow, looking good

[aszu]

looks very good!

[Hurrican]

Great! :-)