204 replies to this topic

[tokumaru]

Hey everyone!

I guess most of you don't know this but I'm a huge Sonic The Hedgehog fan (I'm talking about the classic games here, I don't care for anything since Adventure). And every time I learn to code for a new platform I start considering the possibility of coding a Sonic game for it (I have a NES engine in the works, but not really playable yet). With the 2600 I quickly gave up on that idea though, given how difficult it would be to scroll the screen and the fact that a screen-by-screen sonic game probably wouldn't be much fun.

But the other day I started thinking about the possibility of making a platformer with 8-way scrolling, and suddenly the idea didn't seem so technically impossible. I know that there are a couple of 8-way scrolling games for the 2600, but they don't seem to use the technique I thought of. Since I wanted smooth scrolling (not the 4-pixels-at-a-time that are possible with the playfield) I decided that it should be possible to have the level map constructed mainly by sprites. So, while player 0 would be used for the main character, player 1 (and its copies) would be used for both enemies and level blocks, and those two wouldn't be allowed to share the same scanlines.

Since a level made only of a few sparse floating blocks would be too dull, I decided that it should be possible to use the playfield to represent longer sections of ground, as well as longer platforms. I would only use solid colors for the playfield, and would use player 1 and/or the ball to smooth out the transitions from ground to empty space and empty space to ground to keep the scrolling smooth. There will of course be several limitations regarding the way in which objects and the terrain can be arranged in the level map, but I think it's still possible to come up with interesting results without making the limitations obvious to the average player.

So, just for the heck of it, I went ahead and made a few sprites:



And here are a few animations based on the sprites above:



Forgive me if I made any mistakes regarding resolution or color count, it's just that I use MS Paint to draw my sprites instead of a 2600-specific tool. Also, these sprites obviously need a black (or at least considerably dark) background to look good.

Anyway, you may have noticed that Sonic has half of the vertical resolution, this is so that he can "play nice" with all the mini-kernels, since he can be anywhere in the level. Player 1 is full resolution though. Sonic uses its missile to have 9 pixels across instead of 8. Both players can be stretched in case they need to represent wider pictures, but they can't mix different widths (except for the bosses, which would probably have their own kernel to accommodate that).

I did some math and it looks perfectly possible to come up with a combination of mini-kernels to accomplish what I want. The main bottleneck in a project like this would be storage, RAM and ROM.

Well, this is it I guess. I'm not sure I'll go through with this project, but I'm playing with the idea, and thought some of you would find it interesting. Any thoughts?

Edited by tokumaru, Wed Sep 29, 2010 8:47 AM.

[BDW]

That's some nice looking sprites you got there..

[psquare75]

WOW. A+ IMO!

[Chris Leach]

I know the nintendo sonic has been made and the copy I have is terrible...THe sprites you show here already look good

[cd-w]

Those are some nice looking sprites.

8-way scrolling on the 2600 is a tall order. I'd suggest revisiting the idea of a single screen Sonic, or restricting to vertical scrolling only.

If you look at Halo 2600, you will see that it captures the essence of the game, without trying to replicate all of the details. A similar approach may work nicely for Sonic.

Chris

[Chris Leach]

I think someone should make a Strawberry Shortcake Musical Matchup o and remake it using all sorts of cool people from current popular games, like sonic or mario or halo or anyone of the sort. The sky would be the limit...

[roland p]

I wonder what the levels would look like. Loopings are probably a big no no.

[tokumaru]

I wonder what the levels would look like. Loopings are probably a big no no.

I'll try to post a mockup of what I have in mind soon. You are probably right about the loops though. Hum... maybe they could be done if they had their own kernel...

[tokumaru]

Here's a very simple screen showing the multiple functions of player 1:



As you can see, only the central portion of the screen is used, meaning that only 2 playfield registers are used. Also, the blanked area at the sides will conveniently hide portions of the sprites so that they can smoothly scroll in and out of view. This scene has no slopes (something a Sonic game can't lack!), but player 1 can also be used to make those. I'll post a screen with slopes later.

EDIT: Of course the game would have decent physics, with acceleration, inertia, and so on... otherwise it wouldn't be Sonic!

Edited by tokumaru, Wed Sep 29, 2010 11:22 AM.

[TrekMD]

All I can say is WOW! I'm still picking up my jaw.

[yuppicide]

EDIT: Of course the game would have those insanely hard bonus ring levels or whatever that if you don't beat them you can't win the game.

[Ed Fries]

8-way scrolling on the 2600 is a tall order. I'd suggest revisiting the idea of a single screen Sonic, or restricting to vertical scrolling only.

I've got a little demo with 8-way scrolling working using just the technique he mentions (p0 is the player and it remains relatively stationary in the center of the screen - only moves up and down), P1 and the missiles are used for everything else. Probably won't use the playfield at all for the same reasons he mentions: I want smooth scrolling left and right. It's still early but it certainly seems to be possible.

-EdF

[roland p]

Here's a very simple screen showing the multiple functions of player 1:



As you can see, only the central portion of the screen is used, meaning that only 2 playfield registers are used. Also, the blanked area at the sides will conveniently hide portions of the sprites so that they can smoothly scroll in and out of view. This scene has no slopes (something a Sonic game can't lack!), but player 1 can also be used to make those. I'll post a screen with slopes later.

This looks so nice... If this screens can be done AND you can create some nice gameplay this will be a winner.

[tokumaru]

p0 is the player and it remains relatively stationary in the center of the screen - only moves up and down

That's actually a pretty good idea! By keeping player 0 always centered (or nearly centered) you can be more flexible with the times you set its graphics and colors. I wonder how I'd prevent the player from moving to the sides when it reaches the horizontal edges of the level though... Invisible wall? =)

Probably won't use the playfield at all for the same reasons he mentions: I want smooth scrolling left and right.

I plan on using player 1 + its missile and/or the ball to smooth out playfield scrolling. So even though the playfield can only scroll 4 color clocks at a time, the sprites layered on top of it will make it seem like it con move 1 pixel at a time. I won't be able to add any detail to the playfield though, because I'll only be able to smooth out the edges, not the middle.

It's still early but it certainly seems to be possible.

I agree. It's a technique that hasn't been explored much, probably because it is "unconventional", but it definitely seems possible.

[e1will]

Very impressive artwork there.

--Will

[Nesbroslash]

I.......I thought this was impossible.

[roland p]

I plan on using player 1 + its missile and/or the ball to smooth out playfield scrolling. So even though the playfield can only scroll 4 color clocks at a time, the sprites layered on top of it will make it seem like it con move 1 pixel at a time. I won't be able to add any detail to the playfield though, because I'll only be able to smooth out the edges, not the middle.

You could also use player 1 to make the hole in the floor. So you only need to change the background color each line.

Edit: I don't know if this still works the right way with sprite priorities...

[Ed Fries]

p0 is the player and it remains relatively stationary in the center of the screen - only moves up and down

That's actually a pretty good idea! By keeping player 0 always centered (or nearly centered) you can be more flexible with the times you set its graphics and colors. I wonder how I'd prevent the player from moving to the sides when it reaches the horizontal edges of the level though... Invisible wall? =)

I guess I am suggesting that you keep Sonic in the middle of the screen (horizontally, he can jump up and down vertically) and just scroll the terrain past him. You have some awesome sprites. My advice is to get something simple working now and then build from it.

-EdF

[LS_Dracon]

Hi Tokumaru.

Nice sprites you did.

Check out this project, may hep you with the concept of player based backgrounds.

http://www.atariage....twins-2600-wip/

Edited by LS_Dracon, Thu Sep 30, 2010 4:23 PM.

[tokumaru]

Thanks, LS_Dracon! Coming from a person who makes such great Atari 2600 sprites that means a lot! =)

Check out this project, may hep you with the concept of player based backgrounds.

http://www.atariage....twins-2600-wip/

Yeah, I remember that. In fact that might be where I got the idea from! I want to do something similar, but without the flickering (I'm very annoyed by it on the 2600) and with vertical scrolling as well.

You could also use player 1 to make the hole in the floor. So you only need to change the background color each line.

That's a good idea, but I don't want the floor to go all the way to the end of the level, I want to be able to make larger gaps, wider than player 1 and its missiles would allow me to (larger than a screen).

Edit: I don't know if this still works the right way with sprite priorities...

Yeah, I guess that if the background has high priority it will be in front of the sprite that is trying to cover it, so it wouldn't work. For now I don't plan to mess with the background priority though.

What I would like to do is dynamically switch player 0 and player 1 in order to control whether the player is in front or behind of other objects, but that would complicate the kernels too much... I'm having enough trouble fitting it all as it is! =)

My advice is to get something simple working now and then build from it.

Yeah, I'm awfully tempted to try this. I'm sketching some kernels on paper, let's see how this goes...

One problem I can foresee is that all these graphics will take a lot of space, and I'll probably have to use different banks for different levels, replicating the sprites that are used through the whole game (Sonic, rings, monitors, etc). The level maps will probably take a lot of space too, so I'm afraid even 32KB won't be enough for a complete game (which means I won't be able to test it on my Harmony cart). Oh well, I guess it's too soon to worry about that, so I'll try not to! =)

Edited by tokumaru, Thu Sep 30, 2010 5:05 PM.

[TooSlowGamer]

So this isn't a port, this will have original levels?

If you don't want items to share the same scanline you'll have to be really clever with your level design. Like anything within one screen apart cannot be on the same level.

[tokumaru]

So this isn't a port, this will have original levels?

Well, apart from the mandatory green level, anything is game I suppose. =)

I thing making a port would be kinda pointless, considering that most of the existing maps and gimmicks wouldn't be possible, so I feel like it's better to design new content with the limitations in mind.

If you don't want items to share the same scanline you'll have to be really clever with your level design. Like anything within one screen apart cannot be on the same level.

Yup, that's right. I don't think this is a problem though, since it's still possible to have lots of things vertically/diagonally.

[bomberpunk]

i think if tokumaru and ed fries teamed up, this could possibly be the most ridiculously giddy sweet giggle-like-a-little-girl game for the VCS. ever.

just sayin..

[tokumaru]

Hey everyone! Unfortunately I don't have anything significant programmed yet, but I have a few updates on the sprites I'd like to show you:




The lower resolution/color rings are the ones Sonic loses when he gets hit (they'll flicker so much I don't think it makes a difference).

About programming, I'm having some trouble efficiently repositioning P1. I'm sure it can be done though. And I might have to go with roland p's idea of using P1 to make holes on the ground, and not use the playfield at all (BTW roland, I mistakenly read "playfield" when you said "background", so I don't think there would be any priority issues with your idea), because of the time it would take to draw the asymmetrical playfield and the RAM necessary to maintain its state. I don't think this decision compromises the level layout much though.

[Animan]

Hey everyone! Unfortunately I don't have anything significant programmed yet, but I have a few updates on the sprites I'd like to show you:




The lower resolution/color rings are the ones Sonic loses when he gets hit (they'll flicker so much I don't think it makes a difference).

About programming, I'm having some trouble efficiently repositioning P1. I'm sure it can be done though. And I might have to go with roland p's idea of using P1 to make holes on the ground, and not use the playfield at all (BTW roland, I mistakenly read "playfield" when you said "background", so I don't think there would be any priority issues with your idea), because of the time it would take to draw the asymmetrical playfield and the RAM necessary to maintain its state. I don't think this decision compromises the level layout much though.

One idea, if you are having trouble with the rings that Sonic loses (the way they are animated), it never hurts to do what the GG games did (showed a single ring fly away, and you couldn't get it back). I know it was kind of dumb, but it will be easier to program.

This is a very promising project. If I get around to it, I might draw up some enemy sprites that you can use if you want.