Messages

1

7DRLs / Re: Atarowg (Atari 2600) - 7DRL 2014 COMPLETE

« on: March 17, 2014, 06:13:10 PM »

The edit button on http://7drl.roguetemple.com/# is a little awkward.  There is no indication that new fields have been added to the bottom of the page.  It isn't obvious that something new has happened when there are many other 7DRL entries on the same page.

Maybe a solution would be to put the edit field for your entry on another page.

2

7DRLs / Re: Atarowg (Atari 2600) - 7DRL 2014 COMPLETE

« on: March 16, 2014, 08:20:27 AM »

Got this done using less than a weeks worth of time.  The Atari 2600 is a very basic system so only basic Rogue-like elements are in place.

* Dungeons floors are procedurally generated.
* Delve down 5 floors and retrieve and artifact.  Bring it back to first floor.

I did deviate from permadeath and instead opted to warp the player to a near pitch black dungeon floor.

3

7DRLs / Atarowg (Atari 2600) - 7DRL 2014 COMPLETE

« on: March 09, 2014, 04:20:39 AM »

Download at AtariAge:
http://atariage.com/forums/topic/223227-atarowg-atari-2600/

7DRL Entry:
http://7drl.org/2014/03/16/atarowg-atari-2600-7drl-complete/

4

Programming / Re: Gamemaker Goddamn

« on: February 21, 2014, 10:30:00 PM »

Yeah.  Game Maker has never been the same after Overmars gave up control.  I still use GM 5 because it plays nice with WINE.  I have a friend who uses Studio and even HIS recent projects get broken by updates.  The final nail for me was the hack-ey iOS support and weak support for Ouya.

5

Programming / Re: Is this Rogue-like?

« on: March 13, 2013, 07:58:52 PM »

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.

6

Programming / Re: Is this Rogue-like?

« on: March 13, 2013, 05:46:50 PM »

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!

7

Programming / Re: Is this Rogue-like?

« on: March 13, 2013, 01:28:44 PM »

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.

8

Programming / Re: Is this Rogue-like?

« on: March 13, 2013, 12:07:46 PM »

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!

9

Programming / Is this Rogue-like?

« on: March 13, 2013, 04:33:34 AM »

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!

10

Programming / Re: Importance of persistence

« on: August 31, 2012, 12:28:44 PM »

Not many people think a Rogue-like on an Atari 2600 is a good idea.  Not many people are up to the challenge either.  It's OKAY if others think it's a bad idea.  It's OKAY if it seems impossible to some.  What's not okay is to limit yourself because others think it's a "stupid question."  Krice can have his opinions.

I think what I'm feeling here is that SOME persistence is a good idea at least on the floor the player is exploring.

11

Programming / Re: Importance of persistence

« on: August 30, 2012, 09:35:20 PM »

Thanks guys for the advice so far.  I'm going to be reading and re-reading the responses and links to fully understand things.

I wondered how strong Rogue fans felt about items staying in place once you've dropped them.  I think using a pseudo random seed for item and monster location is the key.  It allows un-picked up objects to stay in place no matter what x/y/z location the player wanders.  I may use up some variables for a kind of weak persistence within a dungeon level.  Maybe the last and second to last monster spawn will stay empty.  Maybe the last and second to last item will have their locations recorded for that level.

I really appreciate the feedback!  Thanks for taking the time to mull things over with me

12

Programming / Re: Importance of persistence

« on: August 30, 2012, 09:19:39 PM »

On the Atari 2600 I have 26 8-bit variables to use for the ENTIRE game.  I just don't see how to store item location information like on a PC.

I remember the time with 8-bit computers that had serious resource limitations and personally I can't think any good reason to return to that by selecting a platform from that time. If it's some kind of challenge then it's ok, but then you should not ask stupid questions, you should already know what you are doing.

So, you are stating:
* You wouldn't try to program a Rogue for a constrained system
* I shouldn't ask questions because I should know already?

Thanks, thanks for that.

13

Programming / Importance of persistence

« on: August 21, 2012, 04:27:16 PM »

I have an Atari 2600 Rogue-like project.  I'm heavily using procedural and or pseudo random techniques for my dungeons.  Right now I have each item persistent all through the dungeon and levels until the player picks it up.  Then EVERY other instance of that item in every level of the dungeon changes location.

Most PC Rogue-likes probably expect things can be moved around and remain stationary.  On the Atari 2600 I have 26 8-bit variables to use for the ENTIRE game.  I just don't see how to store item location information like on a PC.

Is my compromise above enough?  How strong is persistence for a Rogue-like?

14

Programming / Re: Roguelike graphics project

« on: July 01, 2012, 05:28:28 PM »

What are your tiles licensed under?

I recently chose Creative Commons Attribution 3.0 Unported (CC BY 3.0) for some work of mine:
http://creativecommons.org/licenses/by/3.0/

15

Programming / Re: Colors in the Mono Console

« on: June 23, 2012, 03:25:31 PM »

If you really need cross-platform uniformity then you might consider making your own "console" using graphical characters.  There are plenty of sprite sheets of ASCII characters out there.  You solve palette issues and font issues in one fell stroke.