Game Idea: Fade Out

[salstadt]

Hey all,

 

Like I mentioned in my other post, I'm by trade a GBA artist, but I'd love to get into the Atari hobbydev scene now that I know it exists. So I'd like to go ahead and start designing/illustrating a game (I have a pretty original idea that would work well on the platform) but I could use some general advice on limitations (size, animation frames, sprite count, color count, etc).

 

I'd imagine Atari art (I'm aiming at 2600 specifically) and what can be done depends on the talent of the coder. But I'm looking for some limits that would be reasonable to stay in for my art, to ensure that it has a likely shot at working.

 

So, for very very broad reccomendations, what limits should I stay behind for:

 

- Sprite dimensions

- Sprite colors

- Number of sprites onscreen

- Background colors

- Animation frames

- Screen resolution

 

Or if 2600 code doesn't really work like that, any info anyone could provide on how I should be limiting myself would be greatly appreciated. Thanks in advance!

 

- Adam

[Room 34]

From what I know of 2600 program code I am scared to go near it, but I think overall you're thinking too much in modern terms. Granted, there are elements of what you're talking about in programming games for the 2600, but it's really a lot more low-level than that.

 

I've gathered that most 2600 programming is basically about figuring out how to draw the scanlines on the screen as the program code runs and then doing whatever processing you need to do in a small number of clock cycles to keep the picture from rolling.

[salstadt]

Ah, I can picture that. Well, how about screen resolution? Are there specific widths such as 'pixels' for 2600 titles, or is it all negotiable beyond the vertical numbers?

 

- Adam

[liquid_sky]

http://www.atariage.com/forums/viewforum.php?f=31

 

check out the information on the sprites

[Nukey Shay]

Decent general specs? I'd say at least three stars before age 40

[salstadt]

Okay, here's where I get ripped into. Going on the same res as Pitfall and the general idea of low-color, 8x16 sprites displayed at 2:1 and a background displayed at 8:1, I came up with this:

 

 

Basically, it's an action platformer where the two players (maybe we'll have more) try to take each other out. The twist is the background has patches of color the same color as the players, so it's very easy to hide from your enemy. Obviously this idea brings a lot of inherent flaws that need to be ironed out, but from what I've seen of 2600 titles it shouldn't be too hard to pull off.

 

And to answer the obvious question, 'How do you see yourself while playing?' You don't on those same-color backgrounds. But you do know where you're moving, if you're standing still, hopping downward or up so it should be managable to where you can at least be able to pop out of your square where you want, in order to surprise your foe.

 

Anywho, I could use some input and comments on blaring errors in the visual design, suggestions, questions, etc. I'm debating which would work better between guns and a close-attack weapon, and also maybe bumping up the sprite count (ie, four moving enemies, each with one of four colors). Or maybe needing to collect each weapon before limited use might be fun.

 

- Adam

[Cybergoth]

Hi there!

 

WOW!!

 

That is one cool idea for a game!

 

The graphics look almost doable. There's probably too much color changes per horizontal line here and there, but basically it's very close to the VCS specs.

 

Greetings,

Manuel

[salstadt]

Sweet! That kinda stuff can be easily cleared up when I design the real levels -- what's a managable color count (or is it color change count? This is all pretty foreign to me) per scanline?

 

Also, this game will eventually need a coder, too (hint hint, everyone).

 

- Adam

[Cybergoth]

Hi there!

 

Sweet! That kinda stuff can be easily cleared up when I design the real levels -- what's a managable color count (or is it color change count? This is all pretty foreign to me) per scanline?

 

Well, that's one of the main hurdles in VCS programming. Basically you can't tell until you sit down and programm the thing.

 

At present I can tell you for sure, that it's generally too complex.

 

You have 76 cycles per scannline to do anything. So with the current layout, you'd need 6 PF writes, which'd alone will cost 48 cycles. Add two sprites and we're at 64. Another 5 cycles for minal loop overhead and we're at 69.

 

And that is a complete monochrome screen only, not even displaying the bullets...

 

There's certain tricks to get better here & there, but Overall it's too complex.

 

As a programmer, the first two general compromise I'd do would be making this a 2-line kernel, thus losing half the vertical resolution.

 

The second compromise would be completely mirroring the screen. (Not that bad I assume, so both players have equal chances )

 

An alternative compromise without mirroring the screen would be disregarding PF0. You'd lose 16 pixels on both sides, but it might work.

 

Also, this game will eventually need a coder, too (hint hint, everyone).

 

I assume this'll in fact be the your major problem :wink:

But the concept sounds really cool. Maybe you should point Andrew Davie to this. (He's observing the "And for my next trick..." topic on the main page ) Or vice-versa, I thought he was looking for an artist doing the sprites for his Fu Kung! game...

 

Greetings,

Manuel

[salstadt]

Thanks for all the great info! Concerning the core gameplay, all the background NEEDS is a few platforms and blocks of color, so everything like hills, buildings, horizon, etc. is all gravy and thus removable if need be. If any coder thinks this might be worth taking a stab at and would like to chat with me about it, message me or catch me on MSN (salstadtx@hotmail.com) or AIM (adamctierney).

 

And yeah, if you can't tell, 1-color micosprites are a real passion for me. So even if no one has the time to code this title, if anyone needs me to whip up some quick art for any project, just give me a holler.

 

- Adam

[Thomas Jentzsch]

Nice idea!

 

Without going to much into details you have two options for the low resolution background (without constantly changing color values).

 

A) Two colors/row (background/foreground) independend from the player colors.

 

B) One independent background color and one foreground color for each side (identical with the player colors).

(Hi Manuel, forgot the SCORE mode again, didn't you? )

 

So maybe option B) may offer some new possibilities. And maybe you could even swap the left and right colors a few times.

 

And AFAIK this would be the first game that uses this mode for the game screen.

[Cybergoth]

Hi there!

 

B) One independent background color and one foreground color for each side (identical with the player colors).

(Hi Manuel, forgot the SCORE mode again, didn't you? )

 

As usual

 

Greetings,

Manuel

[salstadt]

Well ultimately I guess it would all be up to the coder. Basically however they wanted to handle the title, I'd just whip up art accordingly.

 

- Adam

[Chadivision]

Cybergoth suggested not using PF0. That is a great idea and, just to clarify, you would actually only lose 4 bits on each side of the screen because even though PF0 is 8 bits long, only 4 of the bits are used.

 

The idea of a reflected playfield was also suggested. That is another great idea. One other option is to use a repeated playfield, where instead of a mirror image (reversed) the right side is just copied. In order to make the levels more interesting you could also switch modes mid screen so that some scanlines are reflected and others are repeated. That would only cost you five cycles each time you switched modes.

LDA #$(some value) 2 cycles

STA ctrlpf 3 cycles

There may even be some optimazation tricks to cut down on this. One thing to keep in mind is that if you decide not to use PF0 and then use a repeated playfield, you are no longer losing 4 bits on the right side of the screen, it's just to the right of the middle of the screen. That's not necessarily a bad thing, but you would want to take it into account in your level design.

 

The main issue is how you are going to work with the programmer because a lot of the level design will be based on the programming restraints. I guess you have three options depending on how much time you want to put in and how much control you want over the project.

 

1. Give the programmer a general concept for the game and let them write the game themselves.

 

2. Design some levels and have the programmer modify them as necessary to make it work.

 

3. Learn VCS programming and write it yourself.

 

It looks like it will be a great game.

[salstadt]

As far as control over the project, I know that because of the nature of Atari programming I'll have to relinquish a lot of the design to the programmer, but that's fine with me because I'm better at plotting out games than getting in the little details. If a programmer wanted to design the levels and just have me whip up the sprites, that'd be fine. Conversely, if they wanted me to hand them finished everything, that would work, too.

 

The game definitely seems like it would work best as a 2-player title, but I'm wondering how well as 1-player mode could be done. Since the AI wouldn't be 'fooled' by the sprite and background matchling like we humans are, I guess it could only work if we were able to get the AI to lose detection ability once you enter a chamelion area, or fire blindly into the area you were last seen. But then again I don't know how able AI is on the system, so maybe it would be best to keep the title as a 2-player title only.

 

Also, what about multiple screens? I know screen scrolling out of of the question, but maybe we could have something similar to Keystone Kapers, where if either character moved off the screen, an arrow would pop up directing the other gamer to follow off-screen to the next area to continue the battle. Just me thinking out loud, but it might be cool to then have a couple of layouts that the players have the opportunity to bout on.

 

- Adam

[Chadivision]

The multiple screen thing is a good idea. I think it should be doable. One other option would be writing a level generating section of the program as opposed to designing each level individually. The downside is that you would lose a lot of control over level design (which would probably be one of the key elements of the game), but the upside is that is would save on ROM space and it would make the game less predictable.

 

One other idea that we haven't brought up yet would be to have sections of the screen that change color. For example you might be really well hidden, but then suddenly the color changes and you are visible again. You could even link the color changing to an object in the game (a switch or target of some kind) that the players could manipulate. You could also have a switch that makes it so that players will flash a different color every few seconds so that you can get an idea of where they are without making them completely visible (like the flame in Mountain King).

 

As far as the AI I'm not very experienced in that department. I don't think the problem would be keeping the computer from "seeing" a hidden player. I think the major problem would be the overall complexity of the AI. I'm not saying it couldn't be done, but it may involve some major tradeoffs. This game would take quite a bit of planning up front and I think that a major design choice would be to decide whether to make it a complex 2 player only game or a simpler 1 or 2 player game. On the one hand a 2 player only game would have a more limited audience and would be more difficult to play in an emulator, but it would be more fun to play with 2 people.

[salstadt]

Some nice ideas, Chad. What if there wasn't any screen scrolling, but a switch on each side of the level, so that at any point if your enemy is just hiding and doing nothing, you can run to the switch, hit it and BAM the level layout changes. The level could be changed an infinite amount of times, but switches can only work when alternated (meaning that once the left switch is hit, then the next change must be done via the right switch).

 

Also to avoid people being able to sit off to the side and keep firing infinitely, it might be cool to have each player only hold 5 or 10 bullets, which can be replenished by re-loading the levels via the switches, at which point a new ammo pickup will appear.

 

But again, all that will depend on the coder. I have experience at pixelling in general, workign with pallettes, etc. but the only 2600 experience I have is a few years of enjoyment.

 

- Adam

[Chadivision]

I have some experience as an Atari 2600 programmer. I have a pretty good understanding about how the hardware works, but I have only written one game so far (Backfire). Backfire is much simpler than this, but some of the same ideas apply. In Backfire I used an algorithmic level generator like I described. That may not be the best route to take with this game, but I wanted to throw the idea out there.

 

I might be interested in working on this, but I don't have a lot of time to spend on it. I still have to finish some last minute modifications to Backfire and write the instruction manual before it's released. I want to learn some more programming tricks and optimizations before I start another project. I also have a lot of business stuff going on right now. If I did program this it would take me quite a while and I wouldn't be able to commit to a definate timeframe. If that doesn't work for you, I hope someone else can dedicate more time to it because it is a really great idea.

[salstadt]

Time isn't a problem for me, just getting it finished. Would be nice to have it done and carted at least in time for Classic Gaming Expo 2004. For now I'm going to go ahead and whip out some animations for the characters. Beyond that though, it'll basically be me waiting for someone to come along and start coding it though (unless I want to get overzealous and start working on the label I was thinkig "Fade Out" would be a nice title.

 

Anywho, thanks for the offer Chad. Do your development, see how things go and if there's no coder pinned by the time you're freed up drop me a line. I tried to do an entry for your label design contest, but the other entries were so damned impressive I didn't get much farther than a decent logo before I gave up.

 

- Adam

[Chadivision]

There have been some awesome entries in the label contest.

 

I checked out some of the artwork on your site and it was really cool. I hope that you submit a label. You have a unique style and I think it would be interesting to see what you come up with.