80 replies to this topic

[DJT]

 DemonoidTentacle, on Sun Aug 14, 2011 8:47 AM, said:

 DJT, on Sun Aug 14, 2011 7:23 AM, said:

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.

[DemonoidTentacle]

Something tells me that a roguelike isn't something to tackle when learning how to program.

[GroovyBee]

 DJT, on Sun Aug 14, 2011 7:23 AM, said:

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

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.

[DJT]

 GroovyBee, on Sun Aug 14, 2011 9:10 AM, said:

 DJT, on Sun Aug 14, 2011 7:23 AM, said:

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

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!

[GroovyBee]

 DJT, on Sun Aug 14, 2011 9:29 AM, said:

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.

[DJT]

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!!

[GroovyBee]

 DJT, on Sun Aug 14, 2011 3:07 PM, said:

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.

[Nateo]

 DemonoidTentacle, on Sun Aug 14, 2011 8:47 AM, said:

 DJT, on Sun Aug 14, 2011 7:23 AM, said:

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.  

Pfft, learning's for looooosers  

[DJT]

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?

[DemonoidTentacle]

I've recently started with visual bB, and I'm reading ALOT of tutorials. Seems to be a good place to start.

[Nateo]

Batari Basic is a lot of fun. I have yet to come up with anything remotely of note myself, but there is good chunk you can do with it. I believe there's a major update in the works that will increase it's versatility.

[yllawwally]

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.

[DJT]

 DemonoidTentacle, on Tue Aug 16, 2011 6:11 AM, said:

I've recently started with visual bB, and I'm reading ALOT of tutorials. Seems to be a good place to start.

Any good tutorials you've found?

[PAC-MAN-RED]

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 )




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

Original:     Made for the Titlescreen Kernel:


The Amulet of Yendor(Rodney spelled backwards) awaits!

Illya

[DJT]

 PAC-MAN-RED, on Wed Aug 17, 2011 1:08 AM, said:

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 )

Rogue Comparison.PNG


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

Original: Eypx Rogue Original Titlescreen.gif    Made for the Titlescreen Kernel: Epyx Rogue Titlescreen.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:



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:

[DJT]

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.

[yllawwally]

Splitting the level into 2 screens, would make a half size map, because the sprites are 8 pixels wide.  160 across is 20 sprites wide, so you would need four screens, or have 4 pixel monsters and characters.

[DJT]

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?

[GroovyBee]

 DJT, on Wed Aug 17, 2011 5:47 PM, said:

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.

[DJT]

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?

[jrok]

 DJT, on Wed Aug 17, 2011 6:35 PM, said:

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.

 DJT, on Wed Aug 17, 2011 6:35 PM, said:

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

"Dungeon" springs to mind.  

[DJT]

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...

[jrok]

 DJT, on Wed Aug 17, 2011 7:00 PM, said:

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.

[DJT]

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

[SeaGtGruff]

 DJT, on Wed Aug 17, 2011 7:17 PM, said:

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