Jump to content
IGNORED

Atari Roguelikes


DJT

Recommended Posts

Okay, so are we all going to pool some money together to hire a freelancer to do this or what ;)

 

Or, now here's an idea... We could learn. :)

 

What's funny is that RIGHT NOW I am looking at enrolling in some Continuing Ed classes to learn how to program. The problem is that none of it is about assembly. It seems pretty daunting to just jump in it. I think I've read Session 1 like 4 times on here and all I can do is sigh.

Link to comment
Share on other sites

Okay, so are we all going to pool some money together to hire a freelancer to do this or what ;)

 

:lol: The money pool wouldn't cover a real freelancer's hourly rate for very long because most good quality homebrew projects take 100s of hours to develop. Your best bet is to try and get a programmer on board who is interested in your project or start learning to program yourself.

Link to comment
Share on other sites

Okay, so are we all going to pool some money together to hire a freelancer to do this or what ;)

 

:lol: The money pool wouldn't cover a real freelancer's hourly rate for very long because most good quality homebrew projects take 100s of hours to develop. Your best bet is to try and get a programmer on board who is interested in your project or start learning to program yourself.

 

These are all very very valid points. I think on a personal level, I'm really not going to be satisfied until I really learn how to do this stuff. I'm pretty sure it's going to be a loooooong process, but I guess we'll see where the rabbit hole takes me!

Link to comment
Share on other sites

These are all very very valid points. I think on a personal level, I'm really not going to be satisfied until I really learn how to do this stuff. I'm pretty sure it's going to be a loooooong process, but I guess we'll see where the rabbit hole takes me!

 

If you've never programmed anything then the 2600 probably isn't the place to start in my opinion. You might find it more fun to develop using PC high level languages so you get a good grasp of variables, decisions (if/then/else), loops and general program structure to get your ideas going (with much easier debugging facilities) and then translate it to the 2600 later. If you still want a retro feel to your development process then using BASIC on the A8s (or any other computer you had as a kid) would be a good start too. When you have built up your confidence have a go at the 2600 using assembler or batari Basic.

Link to comment
Share on other sites

Great advice.. I think I'm going to really hone up my proficiency in BASIC.. Play around on my apple ii with it a little, then see how brave (and competent) I am to make the jump to assembly. As I said before, I learned basic BASIC when I was in high school, but it's been years since I really used it.... Time to get back in it!!

Link to comment
Share on other sites

Great advice.. I think I'm going to really hone up my proficiency in BASIC.. Play around on my apple ii with it a little, then see how brave (and competent) I am to make the jump to assembly. As I said before, I learned basic BASIC when I was in high school, but it's been years since I really used it.... Time to get back in it!!

 

If you get stuck with anything just ask. There are plenty of programmers covering a multitude of platforms on the forums.

Link to comment
Share on other sites

After a little research, I noticed that there is a visual bB program out there. I found all the links thru this forum. Does anyone have any experience with batari and making games? I'm thinking of going down this road to start before I think about assembly.

 

Any thoughts?

Link to comment
Share on other sites

The original rogue was pretty simple. Player stats, only had HP, Dex and Str. The original rogue is pretty doable. Rooms were random, but in a limited way. There was 6 to 9 rooms, with passages between them. They were always arranged, in a tic-tac-toe type pattern. There were few monsters on a level, about 4 to start, more joined in the longer you sat on the level. The light only showing close up is a bonus, because it limits the max number of monsters that need to be shown at any one time. So light should be implemented. Traps are pretty easy to do, and add alot to the game. I think hunger could be skipped, unless making a Moria clone. If stores were available on level 1, that would add alot. But rogue had no stores. There were 26 monsters, but no animation is expected so that would mean only 200 bytes of graphics. This game is probably doable on a standard 4k cartridge. I've always been surprised it never got made. No character classes, very simple leveling scheme.

Link to comment
Share on other sites

Just a mock up comparison I did with the original at the Top and the 2600 at the bottom. The overall height of the dungeon playfields are the same, but I've stretched and trimmed the Atari one to cover two screens - indicated by the 2 different colors.(don't worry, your monitor isn't fading on one side :D)

 

post-26314-0-86273600-1313563848_thumb.png

 

 

Now this is the Rogue I remember. :D Works great in DOSBox too, where I "play test" all of my old school games.

 

Original: post-26314-0-70884400-1313563869_thumb.gif Made for the Titlescreen Kernel: post-26314-0-53458400-1313563893_thumb.png

 

 

The Amulet of Yendor(Rodney spelled backwards) awaits!

 

Illya

Link to comment
Share on other sites

Just a mock up comparison I did with the original at the Top and the 2600 at the bottom. The overall height of the dungeon playfields are the same, but I've stretched and trimmed the Atari one to cover two screens - indicated by the 2 different colors.(don't worry, your monitor isn't fading on one side :D)

 

post-26314-0-86273600-1313563848_thumb.png

 

 

Now this is the Rogue I remember. :D Works great in DOSBox too, where I "play test" all of my old school games.

 

Original: post-26314-0-70884400-1313563869_thumb.gif Made for the Titlescreen Kernel: post-26314-0-53458400-1313563893_thumb.png

 

 

The Amulet of Yendor(Rodney spelled backwards) awaits!

 

Illya

 

awesome! You know, even a half sized map would still be fun. Just make more floors! You still give yourself like 5 random rooms. I was thinking like a half sized playfield/map with your inventory always shown up on the scrren either above or below the map/playfield. so you have basically:

 

post-29832-0-86179100-1313586514_thumb.jpg

 

It's probably too much for one screen...it just seems so easy in my head. But i know we're dealing with hardware limitations.

 

 

Your inventory would correspond to some of the buttons on the keypad controller (star raiders) save the top 3 buttons for direct commands. USE/DROP/THROW like this:

 

post-29832-0-01586700-1313587167_thumb.jpg

 

 

 

Link to comment
Share on other sites

correction. I was playing around with the play field in visual bB...I don't think there's any way to fit all that on the screen. You'd have to have two screens.

 

One for your map/random dungeon and score

 

then hit the joystick button to call up your inventory/equipment/stats. This screen would then be manipulated with keypad controller.

 

 

 

Link to comment
Share on other sites

within bB i don't see where you can code key pad controllers. Looks like only joysticks and paddles. I noticed something about a sega genesis controller but nothing else....

 

I guess i'm just trying to figure out the limitations of the programming language to then design a "roguelike" game out of it. What I'm considering is that I make a series of playfields that would act as "floors" I'd design like 20 or so floor. At. the beginning of each adventure, the program would randomly pick like 10 floors you can explore or whatever. But can you program it to remember the floors it picked so you can go between them so they aren't randomized?

Link to comment
Share on other sites

within bB i don't see where you can code key pad controllers. Looks like only joysticks and paddles. I noticed something about a sega genesis controller but nothing else....

 

You can always drop into assembly language to to do anything that isn't supported by a standard bB keyword.

Link to comment
Share on other sites

yikes.. i'm trying to crawl before i walk ;)

 

okay. so here's what I *think* I might be able to tackle within the confines of the limitations within visual bB:

 

Simple dungeon crawler-esque adventure with a simple premise:

 

 

NPC wants you to explore the cave for him to fetch an item for him (chosen at random)

 

Enter the caves in search for the item.

in the caves you encounter random monsters, random loot

explore till you found the dude's item, travel back thru the maps to get back to first screen to give the NPC his item, he'll reward you with a random item or treasure.

 

at this point, i just don't see a way within bB to be able to generate an inventory. it's like everything is going to have to be activated the instant you pick it up.

 

Has anyone seen a completed project in bB that wasn't just a simple shooter?

Link to comment
Share on other sites

at this point, i just don't see a way within bB to be able to generate an inventory. it's like everything is going to have to be activated the instant you pick it up.

 

There are plenty of way to generate an inventory with bB, simple or otherwise. Not that it's the only way, but here's one that demonstrates an on-screen inventory using the score sprites. Of course, that's only if you need the inventory to be on the same screen as the map. With multiple game screen to toggle between, you have many more options of displaying an inventory.

 

Has anyone seen a completed project in bB that wasn't just a simple shooter?

 

"Dungeon" springs to mind. :)

Link to comment
Share on other sites

Omg... That's really good stuff. I'm usually not a pessimist, but I don't know if I'm going to be able to figure all this stuff out. It just looks so advanced...

 

I think there's a misconception out there that the batari kernel is somehow hobbled, but it's really not. There are three kernels in release now (standard, multiplayer and DPC+), lots of minikernel contributions, RevEng's titlescreen kernel, etc. Also, programmers can use assembly language inline with their BASIC scripts. I think that a lot of folks overstate what can be done with the language.

Link to comment
Share on other sites

When you speak of kernels what does that mean? Like bits of code?

In general, "kernel" is the inner seed or inner core or essential heart of something.

 

In computers, "kernel" typically refers to the core of the operating system, or the basic and essential routines that enable the computer to work-- the input/output routines, math routines, graphics routines, etc.

 

In the Atari 2600 video game console, there's no operating system per se (although in a sense the audio-visual functions provided by the TIA chip sort of constitute the closest thing the 2600 has to an "operating system"), so each plug-in game ROM cartridge needs to provide its own "kernel," or the basic routines that determine how the game will manage the RAM, draw the screen, generate sounds, process "collisions," process the input from the console switches and game controllers, update the score, etc.

 

But in Atari 2600 games (especially in batari Basic), the "kernel" is often thought of as the display routine in particular-- the main loop that performs the vertical blank, vertical sync, and draws the screen by updating the graphics registers and positioning the sprites. So in batari Basic the "kernel" is the pre-packaged (or "canned") code that gets performed when you use the "drawscreen" command, and the rest of the program code-- the stuff you write using batari Basic instructions or inline assembly code-- isn't usually considered to be part of the "kernel" per se.

 

It would probably be more proper to call it the "display kernel" rather than just the "kernel," because the "kernel" would really include the code you write, too, and not just the code that gets performed when you use the "drawscreen" command. In other words, the "display kernel" is a subset or portion of the entire "game kernel"-- the "display kernel" being the part that's provided for you by the "drawscreen" command, and the "game kernel" being the core loop of your game (which you write) that sets everything up so the "drawscreen" command can draw the screen the way you've specified, as well as the code you write for reading the input, changing sprite positions or graphics based on that input, checking the "collisions" and acting upon them, updating the score, etc.

 

Michael

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...