Blob 2600

[MausGames]

I'll go ahead and make this my thread about my WIP 2600 game, Blob. It most likely won't be finished, but documenting gamedev can be useful to others.

 

You travel down a scrolling playfield, trying to stay on the screen, but you can also jump; there are enemies to avoid/kill; You must constantly collect pellets to keep from drying out. I'll keep posting bins as I add these things, and with a lot of luck this will end up being something you can actually play with the new Harmony/Melody tech.

 

So far (thanks to batari) I have a scrolling, customizable playfield. The res is 32x30, and each 5 lines of playfield requires four bytes. I'm limited to 8k of level data, but that is about 10,000 lines of playfield; plenty more than enough.

_____________________________________________________________________________

 

I'm trying to sync my pfcolors with the scrolling playfield, but it's off for a frame each transition. I've tried everything I could think of to get it to sync, it's driving me nuts. Anyone have an idea what I'm doing wrong?

 

I'd also appreciate it if anyone has any advice on how to speed up this code, it's using more cycles than I can spare.

 

scrollingbg1.bas.bin

scrollingbg1.bas

Edited October 28, 2009 by MausGames

[+batari]

Your color updates are lagging one frame behind the scrolling.

 

Tying it to playfieldpos will help.

 

As for cycles, reducing the number of inter-bank gotos or gosubs helps, but probably the best way to improve them is a custom scroll loop. When scrolling the playfield in Superchip, there is a lot of data to move.

 

Interestingly, bB code for an unrolled scroll-up loop is nearly as fast as asm (this only works in Superchip 32-high playfields.) If you are not wrapping the playfield but instead filling in the bottom row, there are two lines you can delete.

 playfieldpos=playfieldpos-1
 if !playfieldpos then playfieldpos=3 else goto noscrolling
 temp1=r000:temp2=r001:temp3=r002:temp4=r003:rem only necessary for wrapping playfields
 w000=r004:w001=r005:w002=r006:w003=r007
 w004=r008:w005=r009:w006=r010:w007=r011

 ... you fill in the 29 missing lines ... 

 w120=r124:w121=r125:w122=r126:w123=r127
 w124=temp1:w125=temp2:w126=temp3:w127=temp4:rem only necessary for wrapping playfields
noscrolling

scrollingbg1.bas

Edited October 25, 2009 by batari

[MausGames]

Thanks so much batari, that looks a lot better.

 

Here is the fixed bin:

 

scrollingbg1.bin

Edited October 27, 2009 by MausGames

[MausGames]

Here is an older demo of blob movement; it uses way too many cycles though, so I'm about to rewrite from scratch. Any suggestions appreciated.

blobmovement1.bin

[accousticguitar]

A dancing blob. I like it.

[MausGames]

Thanks! I still have a ton of player animations to add, hopefully I have room. I hate the limit on sprite data, it really makes things hard for me.

[smartkitten26]

Thats a nice game, Can't wait to see it when it's finished

Edited May 19, 2015 by smartkitten26

[nonner242]

Another cool idea!

[accousticguitar]

Thanks! I still have a ton of player animations to add, hopefully I have room. I hate the limit on sprite data, it really makes things hard for me.

I've made three games so far and all of them use a square as the player sprite.

[MausGames]

Nothing wrong with the missile/ball square; it can scale, rotate, change colors including fading in and out of sight, and any physics that can be applied to player sprites work exactly the same way with it. You should try using playfield pixels as individual sprites too; they have really course movement, but there is still a lot they can do.

Edited November 2, 2009 by MausGames

[jrok]

I really like the look and feel of the blob creature. It's a simple design, but it has a lot of personality (the eyes and the idle animation are nice touches.)

 

The scrolling platforms are an interesting mechanic. One suggestion I have is to incorporate fixed-point math into the jump function to simulate momentum and gravity. A debounce for the button might be nice, too. Perhaps holding down the fire button can build up momentum for a jump, then the jump is executed when the button is released. In other words, the player could tap the button for shorter jumps and hold and release for longer/higher ones.

 

A really nice start!

 

Jarod.

[yuppicide]

I like the look of the blob as well. Nice job. Game looks good. Platforms kind of remind me of "Roc N Rope" for some reason.