Newbie with a game idea

[Brian O]

About the title screen, if you decide to use a dedicated kernel instead of a standard one you could do a lot of little tricks and end up with something that looks much more like your original art. something like this:

 

 

The background is white, while the playfield is black. Jumpy's outline is the ball, and his eyes and bright spots are holes that let you see the background color. The platform also uses the players and the ball.

 

EDIT: Minor updates to the picture.

 

WOW! I didn't realize you could get that level of detail with the title screen. This one blows mine away. I love it.

 

Quick question -- Could the name of the game be positioned to the right of Jumpy? See my revision (attached)?

 

Thanks man, nice work!

 

-B

[tokumaru]

WOW! I didn't realize you could get that level of detail with the title screen. This one blows mine away. I love it.

Yeah, when you don't know about the hardware details there's no way to know how much you can "bend" the rules in your favor.

 

Quick question -- Could the name of the game be positioned to the right of Jumpy?

I don't think so... AFAIK, the "48 pixels per scanline" still applies.

 

Thanks man, nice work!

Thanks. It's still your art though, I just rearranged it to show you that you don't have to be as conservative as you thought with the title screen.

[Brian O]

WOW! I didn't realize you could get that level of detail with the title screen. This one blows mine away. I love it.

Yeah, when you don't know about the hardware details there's no way to know how much you can "bend" the rules in your favor.

 

Quick question -- Could the name of the game be positioned to the right of Jumpy?

I don't think so... AFAIK, the "48 pixels per scanline" still applies.

 

Thanks man, nice work!

Thanks. It's still your art though, I just rearranged it to show you that you don't have to be as conservative as you thought with the title screen.

 

Gotcha. I was thinking 48 pixels per sprite, not scanline.

 

I made a quick comp of an updated title screen that leverages your comp. However, I moved Jumpy out of the dark, and placed him below the title. This way, the title, character and "Press To Start" copy are to the right of the dark square.

 

Let me know your thoughts.

 

Thanks again!

-B

[Brian O]

Anyway, even if you flicker the playfield pixels to try to make it look like the scrolling is smoother, it won't stop the TIA from registering a collision if Jumpy touches the flickering playfield, so it will still *act* as though the dark had already moved forward a full 4 clocks.

Sure, but being such a simple kind of collision I guess it wouldn't be a problem to check for it in software instead of using the hardware collision flags. But like you said, the effect probably won't even look good, so there's no reason to worry about this.

 

The only way to make the playfield appear to scroll less than 4 clocks at a time is to use the ball. That could work in this game, but probably not if the ball is being used for the walls and door.

Yeah, that was my original idea for the ball too, until I remembered about the walls and doors. Missile 0 is still free, but the fact that it will share Jumpy's colors in the scanlines where both are displayed doesn't help... I just can't think of a way to have it all.

 

What if flicker wasn't used, and the playfield just moved 4 color clocks at a time? Would it look too choppy? If that were the case, would the platforms scroll smoothly, since they would be sprites, as opposed to the playfield? I think if the platforms moved smoothly, but the darkness moved 4 spaces at a time, it may not look terrible, but it's harder for me to visualize since I haven't had any exposure to how something like that would animate.

 

-B

[LS_Dracon]

It's a very optimistic screen. I'm afraid it can't to be possible.

Using 48 bit sprite require almost all of the scanline time, this title screen require also the black border around the character wich must to be done using ball, and also you need assimetrical playfield.

 

Perhaps, using hyper sprite, but it display a low resolution image.

 

My sugestion is to reduce the character size to 24 pixels wide, still a big sprite/image and this give to you more time for the others calculations.

And no black border also.

[Brian O]

Thanks everyone for their feedback, and for all of the concept work that you all submitted. I think at this time I'm going to put the FotD game idea to bed. I don't want to waste anyone's time, since I myself cannot code the game. Again, the game may need some minor modifications to be made to work properly -- perhaps the doors can be removed, etc. And I would be more than willing to work with anyone who wants to try and make this game happen.

 

I personally think this would be a fun game and I know I would love playing it if it were made.

 

It's just at this point in time I have received enough messages from people telling me that I'll need to code it myself or forget it, and I know that I am not capable of doing that.

 

I still intend to be an active member on the boards, however, and I will be more than willing to help anyone who needs it (even if it's just bug testing, etc.), especially after how great everyone has been to me.

 

Thanks again, everyone!

 

-B

[tokumaru]

Quick reply because I don't have much time: You can't move Jumpy out of the black, because it's not possible to completely outline him. The small piece that's outlined in my screen is a trick that uses the ball. It's a trick because since the rest of the sprite is on top of a black background your mind believes that Jumpy has an outline all around him, but we can't actually have that. When designing graphics for the Atari 2600 sometimes you have to rely on mind tricks to do what the hardware can't... =)

[tokumaru]

Got a little more time:

 

It's a very optimistic screen. I'm afraid it can't to be possible.

I agree that we can't have Jumpy fully outlined, but my original idea might still be doable.

 

Using 48 bit sprite require almost all of the scanline time, this title screen require also the black border around the character wich must to be done using ball, and also you need assimetrical playfield.

Updating the position and size of the ball is really quick, no problem there. I agree with you that the asymmetrical playfield might be a problem though... On the other hand, it's a very simple asymmetrical playfield, so we might move the dark a little to the left or a little to the right to make it easier to change, even if that requires changing the PF color to white (in a reflected playfield).

[tokumaru]

On the other hand, it's a very simple asymmetrical playfield, so we might move the dark a little to the left or a little to the right to make it easier to change, even if that requires changing the PF color to white (in a reflected playfield).

Sorry for the tripple post (!), but I'd like to ellaborate on this point. Here's an image to illustrate what I mean:

 

 

Look at the scanlines where Jumpy is displayed. At the right you can see how the black would be displayed if we didn't do anything to hide it, and the pink part is the time you have to do something about it. IMO, changing the PF color to white is the easiest way to do it, and that requires only 5 CPU cycles (the pink part is at least 8 cycles wide, so it's OK). The rest of the scanline plus the next HBlank can be used to update the ball's position and size, to prepare the next patterns for Jumpy, and to make the PF black again. I think there's enough time. Jumpy's white parts could be tricky, because we'd actually have to change PF1 and PF2.

 

As for the other sections of the image (the title, the platform and the text), the same trick can be used, you just have to find the best time to make the PF white, even if that requires moving things horizontally a bit. I see no problem if the title or the platform need to go a little to the left or to the right.

 

Thanks everyone for their feedback, and for all of the concept work that you all submitted. I think at this time I'm going to put the FotD game idea to bed. I don't want to waste anyone's time, since I myself cannot code the game. Again, the game may need some minor modifications to be made to work properly -- perhaps the doors can be removed, etc. And I would be more than willing to work with anyone who wants to try and make this game happen.

 

I personally think this would be a fun game and I know I would love playing it if it were made.

Unfortunately there's no way I can't commit to other people's projects right now, but I really liked your game idea and I think it would make a fun 2600 game. But I think that what we're doing here is nice, talking about the possibilities and imagining how things could be. At least it keps the ball rolling, and if we keep the idea alive eventually someone might even decide to code it.

[Brian O]

On the other hand, it's a very simple asymmetrical playfield, so we might move the dark a little to the left or a little to the right to make it easier to change, even if that requires changing the PF color to white (in a reflected playfield).

Sorry for the tripple post (!), but I'd like to ellaborate on this point. Here's an image to illustrate what I mean:

 

 

Look at the scanlines where Jumpy is displayed. At the right you can see how the black would be displayed if we didn't do anything to hide it, and the pink part is the time you have to do something about it. IMO, changing the PF color to white is the easiest way to do it, and that requires only 5 CPU cycles (the pink part is at least 8 cycles wide, so it's OK). The rest of the scanline plus the next HBlank can be used to update the ball's position and size, to prepare the next patterns for Jumpy, and to make the PF black again. I think there's enough time. Jumpy's white parts could be tricky, because we'd actually have to change PF1 and PF2.

 

As for the other sections of the image (the title, the platform and the text), the same trick can be used, you just have to find the best time to make the PF white, even if that requires moving things horizontally a bit. I see no problem if the title or the platform need to go a little to the left or to the right.

 

Thanks everyone for their feedback, and for all of the concept work that you all submitted. I think at this time I'm going to put the FotD game idea to bed. I don't want to waste anyone's time, since I myself cannot code the game. Again, the game may need some minor modifications to be made to work properly -- perhaps the doors can be removed, etc. And I would be more than willing to work with anyone who wants to try and make this game happen.

 

I personally think this would be a fun game and I know I would love playing it if it were made.

Unfortunately there's no way I can't commit to other people's projects right now, but I really liked your game idea and I think it would make a fun 2600 game. But I think that what we're doing here is nice, talking about the possibilities and imagining how things could be. At least it keps the ball rolling, and if we keep the idea alive eventually someone might even decide to code it.

 

Hey tokumaru,

 

I love that title screen. It amazes me what some folks are able to do with such stubborn hardware. Thanks for illustrating how the title screen is drawn. Like I said, I have learned a tremendous amount since joining the forum (and continue to learn more each day). I really appreciate folks like you taking the time to go through things.

 

I do still have a flicker of hope that someone may decide to code this, but I'm not holding my breath. I will most likely rethink some of the game play, and possibly remove the doors and/or the walls, since they seem to be problematic given the fixed number of graphic elements. I've thought about having the platforms disappear when you touch them, and maybe coupling that with some moving platforms, but again I'm not sure what the machine is truly capable of. I know must folks here can write custom kernels and increase K size to accommodate certain graphical/functional challenges.

 

Well, thanks again for your help! If the game ever gets made, your name will definitely be on the "thank you" page!

 

-B

[LS_Dracon]

There is the PF0 too but yeah with lot of work your title screen is possible.

 

Thanks everyone for their feedback, and for all of the concept work that you all submitted. I think at this time I'm going to put the FotD game idea to bed.

Ok.

Here's my last cent bout this game. Using hyper sprite and PF to the game logo I can draw a feasible title screen with a good color trick at most left.

Note the color uses Atari 2600 palete, sadly we haven't a 100% pure red.

Edited November 15, 2010 by LS_Dracon

[SeaGtGruff]

Missile 0 is still free, but the fact that it will share Jumpy's colors in the scanlines where both are displayed doesn't help... I just can't think of a way to have it all.

Programming for the 2600 is often about sacrificing one thing to get another, and about having to decide what you're willing to sacrifice versus what you want to keep. For example, if the walls and doors are red (i.e., Jumpy's color), then missile0 can be used to draw them:

 

background = white background

player0 = red Jumpy

missile0 = red walls and doors

player1 = various objects (different colors: green, blue, red, purple, etc.), as well as black platforms

missile1 = black platforms, as well as red key platform

playfield = the dark (black)

ball = the edge of the dark (dark)

 

That would let everything move and scroll at 1-clock intervals. The screen could be divided into vertical zones, with platforms being limited to certain y positions, and the various objects being limited to the areas between the platforms, so different COLUP1 colors could be used for the objects. Missile1 could be used for the narrowest platforms-- 8 clocks wide-- but player1 would have to be used for the wider platforms (16 clocks wide, 24 clocks wide, and 32 clocks wide, or whatever).

 

Michael

[Brian O]

There is the PF0 too but yeah with lot of work your title screen is possible.

 

Thanks everyone for their feedback, and for all of the concept work that you all submitted. I think at this time I'm going to put the FotD game idea to bed.

Ok.

Here's my last cent bout this game. Using hyper sprite and PF to the game logo I can draw a feasible title screen with a good color trick at most left.

Note the color uses Atari 2600 palete, sadly we haven't a 100% pure red.

 

LS -- This looks great too! Again, amazing what you guys do with such a limited pallete.

 

-B

[Brian O]

Missile 0 is still free, but the fact that it will share Jumpy's colors in the scanlines where both are displayed doesn't help... I just can't think of a way to have it all.

Programming for the 2600 is often about sacrificing one thing to get another, and about having to decide what you're willing to sacrifice versus what you want to keep. For example, if the walls and doors are red (i.e., Jumpy's color), then missile0 can be used to draw them:

 

background = white background

player0 = red Jumpy

missile0 = red walls and doors

player1 = various objects (different colors: green, blue, red, purple, etc.), as well as black platforms

missile1 = black platforms, as well as red key platform

playfield = the dark (black)

ball = the edge of the dark (dark)

 

That would let everything move and scroll at 1-clock intervals. The screen could be divided into vertical zones, with platforms being limited to certain y positions, and the various objects being limited to the areas between the platforms, so different COLUP1 colors could be used for the objects. Missile1 could be used for the narrowest platforms-- 8 clocks wide-- but player1 would have to be used for the wider platforms (16 clocks wide, 24 clocks wide, and 32 clocks wide, or whatever).

 

Michael

 

Michael --

 

I think the walls and doors being red would look good. And it would be a plus if it allowed the game to work as originally concepted

 

Finding it hard to let this game idea rest. I feel like Michael Corleone in the GFII -- every time I try to get out, you guys pull me back in again (with your great ideas).

 

Thanks again!

B

[abaudrand]

I like the idea of the game, I think it will be a very funny game to play with such a good idea.

Why not adding a second player? Let's say a blue player?

2nd player

Edited November 16, 2010 by abaudrand

[Brian O]

I like the idea of the game, I think it will be a very funny game to play with such a good idea.

Why not adding a second player? Let's say a blue player?

2nd player

 

LOL. Nice character art Thanks for the kind words.

[KevinMos3]

I normally don't even click on threads with "ideas from non-programmers," but I think this is an excellent proposal. I would love to see it made into a game someday. It's definitely something I could get excited about.

[Brian O]

I normally don't even click on threads with "ideas from non-programmers," but I think this is an excellent proposal. I would love to see it made into a game someday. It's definitely something I could get excited about.

 

Thanks, man!

 

(I'm hoping the same thing.)

[+Propane13]

Ditto, I don't usually read these types of threads either, but this is interesting.

 

Quick nitpicky question-- should it really say "press start"?

Perhaps "press reset" or "press fire" is more accurate?

 

-John

[Brian O]

Ditto, I don't usually read these types of threads either, but this is interesting.

 

Quick nitpicky question-- should it really say "press start"?

Perhaps "press reset" or "press fire" is more accurate?

 

-John

 

Hi John,

 

Good catch -- My Nintendo is showing.

 

-B

[tokumaru]

should it really say "press start"?

To be fair, I was the one who wrote "press start", knowing that the 2600 doesn't have a "start" button. The others have written "press to start", but... press what? So both sound a little weird to me... =)

 

Perhaps "press reset" or "press fire" is more accurate?

Yeah, that would probably be best.

[Brian O]

should it really say "press start"?

To be fair, I was the one who wrote "press start", knowing that the 2600 doesn't have a "start" button. The others have written "press to start", but... press what? So both sound a little weird to me... =)

 

Perhaps "press reset" or "press fire" is more accurate?

Yeah, that would probably be best.

 

Sup, tokumaru? I was going to make it say "Press fire to start", but it seemed too long. "Press to start" should work also. Since the only thing you can really press is the button on the joystick.

 

-B

[Brian O]

Missile 0 is still free, but the fact that it will share Jumpy's colors in the scanlines where both are displayed doesn't help... I just can't think of a way to have it all.

Programming for the 2600 is often about sacrificing one thing to get another, and about having to decide what you're willing to sacrifice versus what you want to keep. For example, if the walls and doors are red (i.e., Jumpy's color), then missile0 can be used to draw them:

 

background = white background

player0 = red Jumpy

missile0 = red walls and doors

player1 = various objects (different colors: green, blue, red, purple, etc.), as well as black platforms

missile1 = black platforms, as well as red key platform

playfield = the dark (black)

ball = the edge of the dark (dark)

 

That would let everything move and scroll at 1-clock intervals. The screen could be divided into vertical zones, with platforms being limited to certain y positions, and the various objects being limited to the areas between the platforms, so different COLUP1 colors could be used for the objects. Missile1 could be used for the narrowest platforms-- 8 clocks wide-- but player1 would have to be used for the wider platforms (16 clocks wide, 24 clocks wide, and 32 clocks wide, or whatever).

 

Michael

 

Thanks, Michael. Is the attached screenshot more in line with what you have laid out above?

 

-B

[raskar42]

holy cats, that's a good looking game.

[Brian O]

holy cats, that's a good looking game.

 

Thanks, man