Bri's House

While I applaud your enthusiasm, many a great game idea has been smashed by the limitations of TIA graphics.

 

Looking at your "screenshot", I think your biggest challenge is going to be making the platforms, particularly if they have to change color.

 

The TIA has the following graphics capabilities:

background color

20 quad pixel playfield graphics, which may be mirrored or duplicated for the right & left sides (for a total of 40 quad pixels. Different playfield graphics may be shown on the left & right, but requires the registers to be updated mid-line

ball sprite, same color as playfield, may be 1, 2, 4 or 8 pixels wide

two 8 pixel player sprites, may be duplicated and double or quad pixels

two missile sprites, same color as player, may be 1, 2, 4 or 8 pixels wide

 

The sprites can be repositioned, but that takes a line of CPU time when little else can be changed.

 

Okay, so let's think about your "screenshot" and break it down into TIA objects.

 

1. dark - probably easiest to use the playfield, although it will require mid-line updates

2. dashed bar - use the ball sprite, but it will be the same color as the dark

3. platforms - use the missile sprites, just remember the player sprites will be the same color on the same line and only two per line; repositioning required. Note: two color platforms (dark transition) would require both sprites to be used.

4. player and other objects - use the player sprites. Repositioning required if there is more than one non-player object on screen. Only two objects may be on the same line unless flicker is used.

 

So put away your doodle pad and start coding the kernel to create your vision.

While I applaud your enthusiasm, many a great game idea has been smashed by the limitations of TIA graphics.

 

Looking at your "screenshot", I think your biggest challenge is going to be making the platforms, particularly if they have to change color.

 

The TIA has the following graphics capabilities:

background color

20 quad pixel playfield graphics, which may be mirrored or duplicated for the right & left sides (for a total of 40 quad pixels. Different playfield graphics may be shown on the left & right, but requires the registers to be updated mid-line

ball sprite, same color as playfield, may be 1, 2, 4 or 8 pixels wide

two 8 pixel player sprites, may be duplicated and double or quad pixels

two missile sprites, same color as player, may be 1, 2, 4 or 8 pixels wide

 

The sprites can be repositioned, but that takes a line of CPU time when little else can be changed.

 

Okay, so let's think about your "screenshot" and break it down into TIA objects.

 

1. dark - probably easiest to use the playfield, although it will require mid-line updates

2. dashed bar - use the ball sprite, but it will be the same color as the dark

3. platforms - use the missile sprites, just remember the player sprites will be the same color on the same line and only two per line; repositioning required. Note: two color platforms (dark transition) would require both sprites to be used.

4. player and other objects - use the player sprites. Repositioning required if there is more than one non-player object on screen. Only two objects may be on the same line unless flicker is used.

 

So put away your doodle pad and start coding the kernel to create your vision.

 

 

Hi Eric,

 

Thanks for all of the feedback. I'm basically a designer, not a developer/programmer. As much as I love the 2600 and how much I'd love to create an Atari 2600 game, I'm afraid I just don't have the know-how to do so. I have tried to go through the tutorials on the site, but since I have never programmed anything in my life, I get lost very quickly reading through some of that information.

 

When I posted my concept for Fear of the Dark, the response seemed to be very favorable and people seemed interested in the game. I assumed that if the game seemed interesting and entertaining enough that someone would offer to work with me on developing it. A few folks on the board were honest enough to tell me that it was unlikely someone would take on the development of the game. I completely understand that, believe me. But I figured I would continue comping up some screens, just for fun and see what happens.

 

So, while I appreciate the information you have provided, I am not sure what I'd be able to do with it other than modify my screenshots and some of the game play to fit what the TIA could handle (my other screenshots also had walls and power ups), but not sure it would do anything but invite more messages telling me to just code the damn thing myself. I may just modify the screenshots based on more recent feedback and keep them to myself. We'll see. I don't want to waste anyone's time.

 

I think, at this point, I am going to put this game idea to bed. I gave it my best shot, and I still think it could be a great game if developed, but taking it to the next level is beyond my capabilities.

 

Thanks again for the feedback.

 

-B

Sorry to rain on your parade, but ideas and artwork are only 1% of the final product. And no-one, except yourself, has the passion to see the project to completion.

 

Sure, there are many who will cheer you from the sidelines. But I doubt you will get anyone to put in the time and effort to provide you with code on a platter. Coders have their own ideas and passions.

 

Yes, coding is hard. (Although batari Basic is easier.) It requires lots of time, knowledge and patience. But all of the information you need is on this site. Plus there are lots of coders who are willing to share their tricks. You just need to take the initiative.

 

That being said, coders often do need help with artwork. Sometimes there are label contests. Or see if there are projects looking for assistance with sprites. (8 pixels wide, one color per line).

Eric --

 

I understand what you're saying, but I have been trying to do my due diligence with this game. Instead of just blurting out "Hey, I have an idea in my head -- make me a game!", I have done my best to try and think through different scenarios and gameplay, even w/ my limited 2600 knowledge. While concept and art may be 1% to you, I think that number is a bit low. I'm not trying to take anything away from the developers/programmers, but I think a good game concept and good artwork is essential to a good game.

 

Also, this has nothing to do with me not taking initiative. I have never programmed a thing in my life, and it would be extremely difficult (if not impossible) for me to start now, and learn assembly language. In my mind, I have taken the initiative by posting my fleshed out concept, screenshots, label art, box art, and manual art. As well as concepts for title screens (as bad as mine were!).

 

Maybe the game is never picked up by anyone. Maybe no one ever develops it. That, of course, would be disappointing, but what can you do? All I know is that I've done all I can do, and I've learned a lot in the process. A lot of people on the forum have contributed their ideas to how the game can be developed. I think if the game wasn't interesting and didn't have the chance to be fun, no one would even bother to continue providing feedback and insights.

 

But thanks for not pulling any punches and being honest about the game's development chances. I'd rather hear that than "don't worry, you'll have 20 guys who want to make your game". I will definitely be on the lookout for label contests, sprite artwork, etc.

 

-B

I have never programmed a thing in my life, and it would be extremely difficult (if not impossible) for me to start now, and learn assembly language.

I think you're selling yourself short. Learning something new takes time and dedication, but one of the joys of homebrew is you can take as much time as you need and you are doing something you want to do. So don't start with ASM. Many people have done some amazing games with batari Basic. Work through the tutorials and documentation. Read through other people's code, make changes and see what happens. You don't even need a VCS, just use one of the emulators. Put the same amount of passion and enthusiasm you put into your artwork into learning something new.

I have never programmed a thing in my life, and it would be extremely difficult (if not impossible) for me to start now, and learn assembly language.

I think you're selling yourself short. Learning something new takes time and dedication, but one of the joys of homebrew is you can take as much time as you need and you are doing something you want to do. So don't start with ASM. Many people have done some amazing games with batari Basic. Work through the tutorials and documentation. Read through other people's code, make changes and see what happens. You don't even need a VCS, just use one of the emulators. Put the same amount of passion and enthusiasm you put into your artwork into learning something new.

Hi Eric,I may download the VbB editor and see what happens. I've started looking through some of the introductory code and it's all pretty confusing. I'm honestly not sure I'll ever understand it. We'll see what happens...Thanks for the encouragement -B