Is a game like Ghosts 'n Goblins possible on the 2600?

[LatchKeyKid]

I've been playing around with sprites for a potential fantasy genre homebrew game or hack and I was curious if a game like Ghosts 'n Goblins would be possible on the 2600.  Gameplay-wise, I'm referring to a player character than can generally jump, climb, and attack (both ranged and melee) generally on one or max two planes of activity.  Obviously, this would be restricted by the particular color and sprite capabilities of the 2600 so if there was a tombstone to jump over then there wouldn't be a zombie on the same plane with it and the player (though there might be a flying enemy sweeping down from above instead).   If it is something that's possible, are there any examples either officially released or homebrew?

 

The closest game that comes to mind for me is strangely enough Moon Patrol.  While you can't jump the moon car up to a second level platform, you have "enemies" at ground level (pits and mounds) that must be overcome (jumped over and destroyed) as well as "enemies" attacking from above at the same time.  In the homebrew scene, the unofficial port of SMB comes to mind as accomplishing something even closer to what I'm imagining.   Genearlly speaking (assuming such a thing is correct in this circumstance), is it more demanding in terms of coding/cpu cycles to do side scrolling like Moon Patrol/SMB or single advancing screens like the original Pitfall? 

[+splendidnut]

Huh, it seems you've already kind of half answered your own questions.  I'm guessing you're really looking for more examples (Moon Patrol and the Princess Rescue being the ones you've provided)?

 

Gameplay-wise... that's all on the programmer.  I essentially have all those basic player movement elements in the Bruce Lee POC I've done (granted, no projectiles, but that's relatively easy to add).

 

Your technical question basically asks which path to take:  Side-Scrolling or Screen-by-Screen.  Screen-by-screen would be an interesting approach with the challenge being mainly focused on capturing the essence of the game.  Side-scrolling would be the more complicated path to take, but would be more inline with other ports of the game.  The side-scrolling approach would potentially steer the project in the ARM-based direction (DPC+, CDFJ), but that's not a necessity.

 

Graphically, regardless of which path is taken, I would probably do the gravestones as Playfield (and not worry about drawing the fence).  This leaves the both player objects available for the player and enemies.  You could probably do some sprite spawning trickery to be able to use the sprite duplication (spawn two zombies simultaneously, spaced properly, and they move in-sync) to help reduce flicker.

 

 

 

 

[Cris1997XX]

Uhh...wait, are these screenshots from the Game Boy Color version??

[Cris1997XX]

42 minutes ago, splendidnut said:

Huh, it seems you've already kind of half answered your own questions.  I'm guessing you're really looking for more examples (Moon Patrol and the Princess Rescue being the ones you've provided)?

 

Gameplay-wise... that's all on the programmer.  I essentially have all those basic player movement elements in the Bruce Lee POC I've done (granted, no projectiles, but that's relatively easy to add).

 

Your technical question basically asks which path to take:  Side-Scrolling or Screen-by-Screen.  Screen-by-screen would be an interesting approach with the challenge being mainly focused on capturing the essence of the game.  Side-scrolling would be the more complicated path to take, but would be more inline with other ports of the game.  The side-scrolling approach would potentially steer the project in the ARM-based direction (DPC+, CDFJ), but that's not a necessity.

 

Graphically, regardless of which path is taken, I would probably do the gravestones as Playfield (and not worry about drawing the fence).  This leaves the both player objects available for the player and enemies.  You could probably do some sprite spawning trickery to be able to use the sprite duplication (spawn two zombies simultaneously, spaced properly, and they move in-sync) to help reduce flicker.

 

 

 

 

DPC+/CDJF would really help on the audio side of things, the TIA is kinda limited and I'm pretty sure it would churn out terrible renditions of the game's soundtrack

[LatchKeyKid]

3 hours ago, Cris1997XX said:

Uhh...wait, are these screenshots from the Game Boy Color version??

Yup.  I figured that was the best comparison pic I could show as it's less graphically advanced (at least in terms of color and resolution) than the NES or obviously arcade versions.

 

2 hours ago, Cris1997XX said:

DPC+/CDJF would really help on the audio side of things, the TIA is kinda limited and I'm pretty sure it would churn out terrible renditions of the game's soundtrack

I definitely agree with you on both those points though my use of Ghosts 'n Goblins was more of a descriptor of the style of game I'm proposing/asking about rather than wanting to do a direct port.  I'd be fine with normal TIA music given my own (almost complete lack of) programming skill. 

Edited March 18, 2023 by LatchKeyKid

[LatchKeyKid]

4 hours ago, splendidnut said:

Huh, it seems you've already kind of half answered your own questions.  I'm guessing you're really looking for more examples (Moon Patrol and the Princess Rescue being the ones you've provided)?

 

Gameplay-wise... that's all on the programmer.  I essentially have all those basic player movement elements in the Bruce Lee POC I've done (granted, no projectiles, but that's relatively easy to add).

 

Your technical question basically asks which path to take:  Side-Scrolling or Screen-by-Screen.  Screen-by-screen would be an interesting approach with the challenge being mainly focused on capturing the essence of the game.  Side-scrolling would be the more complicated path to take, but would be more inline with other ports of the game.  The side-scrolling approach would potentially steer the project in the ARM-based direction (DPC+, CDFJ), but that's not a necessity.

 

Graphically, regardless of which path is taken, I would probably do the gravestones as Playfield (and not worry about drawing the fence).  This leaves the both player objects available for the player and enemies.  You could probably do some sprite spawning trickery to be able to use the sprite duplication (spawn two zombies simultaneously, spaced properly, and they move in-sync) to help reduce flicker.

Yeah, I was just brainstorming and trying to see if something like it already existed.  Those two games (Moon Patrol and the obviously much more recent Princess Rescue) came to mind in terms of mechanics (side scrolling, shooting, jumping, etc).   I have no idea what it takes to actually code almost anything on the 2600 from scratch (my only experience being a hack of a fully annotated game) let alone a side scroller.   I'm not an OG hardware purist by any means and am constantly impressed with what folks do with hardware upgrades to the 2600 like ARM (just like companies did with NES enhancement chips) but I'd probably want to stick with just extra RAM and larger cartridge size/bank switching as the only upgrades potentially.

 

I agree about not drawing fences (and the mountains and trees for example).  The reason I was mentioning segmenting gameplay into planes (though in hindsight "vertical zones" might have been a better term) was to increase variety using the sprites.  If done in an original Pitfall style advancing screen style, screens with tombstone sprites duplicated at ground level could have diving demons/gargoyles above using the same sprite.  If there are zombies at ground level using the sprites then there may be graves (holes in the playfield augmented by sprites lower down?) but not tombstones.  I don't know how many scanlines you need to have inbetween uses of the same sprite to avoid potential issues as I don't plan on using flicker. 

 

I fully admit the idea is currently about as disjointed as you can get as I've just got the equivalent of general gameplay in my head and some sprites actually designed... which I'm not sure will fit in the CPU cycle constraints in a 2 line kernal as I hope to use the ball to add color to otherwise monochrome player sprites like my avatar pic (previously discussed in a thread a while back where you were a big help in explaining the process) along with playfield changes and missiles.  I've been looking through the various threads (that I think you also posted in years ago!) about techniques to draw sprites along with their various upsides and downsides (like dodraw and masking).  I'd be lying though if I said I actually understood it beyond the superficial though.

 

I suppose I'm trying to find out if what I want is possible in full on the 2600 or only as a NES "de-make" to Atari style instead.   The latter would definitely be both possible and likely easier relatively speaking but I'd prefer the former by a wide margin.

Edited March 18, 2023 by LatchKeyKid

[+Yurkie]

This would be a good question for @Andrew Davie

 

I guessing he could draw the screen like Wen Hop and make a very decent looking version of the game.

[+Andrew Davie]

9 hours ago, Yurkie said:

This would be a good question for @Andrew Davie

 

I guessing he could draw the screen like Wen Hop and make a very decent looking version of the game.

 

I've had a look at a YouTube video of the arcade version.  The Wen-Hop type system could display the backgrounds reasonably, I think, but only 1/4 of the visible screen.  Each of my "characters" is 5 pixels wide x 30 scanlines deep, and visible on the screen is thus 8 wide x about 7 deep.  The arcade appears to have about 16 x 14.  So, pretty much 1/4 exactly. This means you see less of the playing area.  The major issue though is that I do not have a multi-sprite system, catering for only the one player. It would be possible to do this, but with the typical '2600 sprite limitations so there would be flicker and lack of colours.  There are only 7 colours + black available in each character, too, so getting good looking screens using my system is a black art.  I'd say it might be do-able but difficult. I'm not sure this would be the right way to go for this game.