DJT Posted August 14, 2011 Author Share Posted August 14, 2011 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. Quote Link to comment Share on other sites More sharing options...
DemonoidTentacle Posted August 14, 2011 Share Posted August 14, 2011 Something tells me that a roguelike isn't something to tackle when learning how to program. 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted August 14, 2011 Share Posted August 14, 2011 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. Quote Link to comment Share on other sites More sharing options...
DJT Posted August 14, 2011 Author Share Posted August 14, 2011 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! Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted August 14, 2011 Share Posted August 14, 2011 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. Quote Link to comment Share on other sites More sharing options...
DJT Posted August 14, 2011 Author Share Posted August 14, 2011 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!! Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted August 14, 2011 Share Posted August 14, 2011 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. Quote Link to comment Share on other sites More sharing options...
Nateo Posted August 14, 2011 Share Posted August 14, 2011 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 Quote Link to comment Share on other sites More sharing options...
DJT Posted August 16, 2011 Author Share Posted August 16, 2011 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? Quote Link to comment Share on other sites More sharing options...
DemonoidTentacle Posted August 16, 2011 Share Posted August 16, 2011 I've recently started with visual bB, and I'm reading ALOT of tutorials. Seems to be a good place to start. Quote Link to comment Share on other sites More sharing options...
Nateo Posted August 16, 2011 Share Posted August 16, 2011 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. Quote Link to comment Share on other sites More sharing options...
yllawwally Posted August 16, 2011 Share Posted August 16, 2011 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. Quote Link to comment Share on other sites More sharing options...
DJT Posted August 17, 2011 Author Share Posted August 17, 2011 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? Quote Link to comment Share on other sites More sharing options...
PAC-MAN-RED Posted August 17, 2011 Share Posted August 17, 2011 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 Quote Link to comment Share on other sites More sharing options...
DJT Posted August 17, 2011 Author Share Posted August 17, 2011 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 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: Quote Link to comment Share on other sites More sharing options...
DJT Posted August 17, 2011 Author Share Posted August 17, 2011 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. Quote Link to comment Share on other sites More sharing options...
yllawwally Posted August 17, 2011 Share Posted August 17, 2011 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. Quote Link to comment Share on other sites More sharing options...
DJT Posted August 17, 2011 Author Share Posted August 17, 2011 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? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted August 17, 2011 Share Posted August 17, 2011 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. Quote Link to comment Share on other sites More sharing options...
DJT Posted August 18, 2011 Author Share Posted August 18, 2011 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? Quote Link to comment Share on other sites More sharing options...
jrok Posted August 18, 2011 Share Posted August 18, 2011 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. Quote Link to comment Share on other sites More sharing options...
DJT Posted August 18, 2011 Author Share Posted August 18, 2011 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... Quote Link to comment Share on other sites More sharing options...
jrok Posted August 18, 2011 Share Posted August 18, 2011 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. Quote Link to comment Share on other sites More sharing options...
DJT Posted August 18, 2011 Author Share Posted August 18, 2011 When you speak of kernels what does that mean? Like bits of code? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 18, 2011 Share Posted August 18, 2011 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.