Is this Rogue-like?

[theloon]

I need a sanity check.  Not sure if I'll be able to fit it into the 7DRL.  I'd like to know if enthusiasts would consider this a "Rogue-like".  The platform would be Atari 2600.

The player starts in the middle of a field.  Somewhere hidden within a 256x256 sector grid resides Moloch which you must defeat in order to attain the Amulet of Yendor.  Movement between sectors reduces health.  The player may encounter territorial monsters in certain sectors.  Gold can be found by spelunking in dungeons found in certain sectors.  Gold can be brought to sectors with markets to purchase healing, weapon and defense upgrades.  After the player has found Molochs lair and properly augmented himself he has a chance of defeating said boss and winning the game.

Any thoughts?  Thanks in advance!

[Holsety]

7DRLs are very lenient in general, but what you posted sounds like it would fit in.
If it's turn based, great, but even if it's realtime or a platformer it fits the theme.
Having procedurally generated content certainly won't hurt you in the public opinion 

[Krice]

I'd like to know if enthusiasts would consider this a "Rogue-like".

It's difficult to say, because your description doesn't tell anything about roguelike properties, other than it has some sort of grid.

[theloon]

I'd like to know if enthusiasts would consider this a "Rogue-like".

It's difficult to say, because your description doesn't tell anything about roguelike properties, other than it has some sort of grid.

What are these roguelike properties you speak of?

Thanks for the feedback so far, guys!

[Darren Grey]

Procedural content and permadeath are the two biggies from most people's perspectives.  Anything playing with those two is likely going to be a little bit roguelike at least.

[theloon]

Procedural content and permadeath are the two biggies from most people's perspectives.  Anything playing with those two is likely going to be a little bit roguelike at least.

Hmmn.  Then it appears I've at least got a bit Rogue-like nailed.  The Atari 2600 has no save game memory.  Instant permadeath!  Also, the location of the boss, markets and enemy hoards are dictated by a pseudo random number generator at the games start.

[joeclark77]

So you're going to have an overworld with 256x256 = 65,536 grid cells, each of which contains a separate town/dungeon/lair and only one of which contains Moloch?  That world is way too big to search it in one lifetime.  Unless you have a system of "clues" or "maps" or something that's going to help the player find his target.  I agree that it sounds roguelike -- there's no way you're going to store 65,536 separate dungeons in a reasonably sized savegame, so they'll have to be procedurally generated (and you just store the seed on disk).  Also cool that it's for the Atari 2600 (although I seem to have misplaced mine... 25 years ago).  You might want a smaller world, though.

[mughinn]

It sounds like a roguelike, procedural content, permadeath. I have to agree with joeclark though, how does that 256x256 grid work?
Is it an overworld grid that you can pass one by one and then, if you want, can get inside? or is it a full blown map, gigantic and enormous?

Good luck with it, hope you make it

[theloon]

The player can move within 256x256 pixel sectors.  Each sector can be populated by a boss, market, dungeon, random encounter or nothing.  Sectors would be populated enough to make it hard for the player to starve to death.  The boss moves closer to the player over time.  Eventually finding HIM if he grinds too much.

Progress has been much slower than I anticipated.  Last weekend I went to the Louisville Arcade Expo to help promote another game I made.  That "wasted" 2 valuable days.  Ack!

[joeclark77]

Boss hunting the player seems to be a solution that works.
So, you're going to use pixels rather than tiles?  I take it the Atari 2600 has big, clunky pixels: does it have 256x256 of them?

I just did a search and found that the screen res depended on the type of TV, but a typical value is 192 (vertical) x 160 (horizontal).  You might want to use that for your overworld map.  If you used 4x4 pixel tiles, you could have a little graphic detail and still squeeze 48x40 of them on screen, which oughta be enough.

Now you've really piqued my curiosity as to how you're going to really do this.  Do you have the capability of actually writing data to an atari game cartridge and playing it on the console?  Or is this all being done in an emulator?  What language(s) can you program in?  I'm very curious about the process and the constraints you'll be working with.

[theloon]

Boss hunting the player seems to be a solution that works.
So, you're going to use pixels rather than tiles?  I take it the Atari 2600 has big, clunky pixels: does it have 256x256 of them?

I just did a search and found that the screen res depended on the type of TV, but a typical value is 192 (vertical) x 160 (horizontal).  You might want to use that for your overworld map.  If you used 4x4 pixel tiles, you could have a little graphic detail and still squeeze 48x40 of them on screen, which oughta be enough.

Now you've really piqued my curiosity as to how you're going to really do this.  Do you have the capability of actually writing data to an atari game cartridge and playing it on the console?  Or is this all being done in an emulator?  What language(s) can you program in?  I'm very curious about the process and the constraints you'll be working with.

The compiler is called batari BASIC http://bataribasic.com/

No can do on tiles.  You get 2 hardware sprites, 2 missiles and a ball.  No save RAM as well.  There is a device called a SaveKey but very few people have it.  Each section will be 256x256 x/y coordinates big.  There is no hardware scrolling so movement will be simulated through objects.  The end result will indeed be a real Atari 2600 cart.  Probably 16k in size (separated into 4k banks).  You get 26 8-bit variables to work with - some of which are eaten up by kernel related features.