Atari 2600 RPG mockup

[HughSpectrum]

Inspired by BladeJunker's thread, I decided I wanted to try and make a mockup within Atari 2600 restrictions.  If this isn't considered true pixel art (and I can see why it wouldn't be) go ahead and move it to Low-spec or something.

The mockup is inspired by Strategic Simulations' AD&D games where map navigation is on a first person view, and baddies walk up to you before you go into combat (which is a separate screen which I haven't tried to draw yet).

I'm hoping to make sure the restrictions work out so hopefully BladeJunker will comment here.

Designed this so that the sky color can change and still look alright on daytime sky colors (also I just realized that I didn't adjust the colors on my desktop computer so the colors will most likely change).


This was fun to do.  I'll probably have to make improvements in readability for the armor.


Not sure what I want to do about the HUD at the bottom.  Not even sure what I want to put there to begin with since imitating the full statistical gameplay is out of the question.

EDIT:

[BladeJunker]

Inspired by BladeJunker's thread, I decided I wanted to try and make a mockup within Atari 2600 restrictions.  If this isn't considered true pixel art (and I can see why it wouldn't be) go ahead and move it to Low-spec or something.

You and me both on where to put 2600 stuff, hard to say where to file it?

The mockup is inspired by Strategic Simulations' AD&D games where map navigation is on a first person view, and baddies walk up to you before you go into combat (which is a separate screen which I haven't tried to draw yet).

I'm not familiar with the inspiration so I'll have to look into that. I will say that separation of activities into different screens or modes is something I can recommend for any 2600 game since the lack of drawing units is not unlike a polygon limit in that isolation and concentration of rendering power to one focused subject matter will reap rewards.

I'm hoping to make sure the restrictions work out so hopefully BladeJunker will comment here.

The restrictions look to me that they will work, 2 line kernel Playfield render with per scanline color changes. You're a lot more conservative than I was when first started trying this stuff out, I went overboard so many times.

Not a bad choice clipping the background for the sake of changing the monsters color scheme as its a good method to get familiar with. However you're already so trim with your rendering use you could probably use a mid-line color change within the middle 16 pixels of the Playfield and preserve most of background on the sides and use any of the movable object sprites to fill in the remainder of your background clipping losses.

Another option is to render the monster using both Player objects as an overlay stretched to maximum width, if you don't need any Missile bits within that vertical zone this would completely avoid any background clipping issues. Since your backgrounds are mirrored using Player objects for the monster would avoid the extra costs of drawing an asymmetrical Playfield to insert the monster tile made of Playfield pixels.

Designed this so that the sky color can change and still look alright on daytime sky colors (also I just realized that I didn't adjust the colors on my desktop computer so the colors will most likely change).

Sounds good, plenty of color shifting routines on the 2600. As far as the colors being off its the same old story of NTSC or Never The Same Color, most posts on AtariAge tend to vary between emulator results and changes needed when running on actual hardware plus NTSC and PAL differences. Manual tweaking at actual run time isn't so bad since we're not using that many colors to begin with.

This was fun to do.  I'll probably have to make improvements in readability for the armor.

I think I'd recommend trying for more iconic readability as large chunky pixels turn into noise very easily, might want to try one color first for composition and then consider color zones afterwards with some tweaking. I saw some good examples by Pac-Man-Red over at AtariAge on utilizing per scanline color changes, he's quite good at drawing sprites in general and he often draws within a 2 line kernel resolution. Here take a look.http://www.atariage.com/forums/topic/169238-free-sprites-for-the-taking/

Not sure what I want to do about the HUD at the bottom.  Not even sure what I want to put there to begin with since imitating the full statistical gameplay is out of the question.

EDIT:

I'm looking into HUD/stat related limitations soon so I'll post that under my discussion asap. You're right to be doubtful about full statistical tracking as the 6502 CPU is limited in speed but any kind of turn based gameplay should help so it only has to do 1 or few things at a time.

Anyway looking good in my opinion.

[HughSpectrum]

Good timing, I've already been working on the readability of the lizardman some more.

However you're already so trim with your rendering use you could probably use a mid-line color change within the middle 16 pixels of the Playfield and preserve most of background on the sides and use any of the movable object sprites to fill in the remainder of your background clipping losses.

Preparing in advance for if I need to use sprites and whatnot to convey information needed elsewhere.  Plus I'm not that concerned about the background.

How are high scores rendered anyway?

As far as the colors being off its the same old story of NTSC or Never The Same Color, most posts on AtariAge tend to vary between emulator results and changes needed when running on actual hardware plus NTSC and PAL differences. Manual tweaking at actual run time isn't so bad since we're not using that many colors to begin with.

It's actually more of an issue of my laptop's colors being off compared to other displays, which causes me to require changing the colors later after working with it (such as brightening a couple of colors on the lizard).

[BladeJunker]

Good timing, I've already been working on the readability of the lizardman some more.

Looking good, I can make out the face, loin cloth, and boots quite well. I don't quite understand the armor visually, I see gaps from the color changes, are you thinking of filling those gaps in the the lizardman with Missile pixels?

Preparing in advance for if I need to use sprites and whatnot to convey information needed elsewhere.  Plus I'm not that concerned about the background.

How are high scores rendered anyway?

I looked up your inspiration a bit, are you thinking of using the clipped background for HUD space and create a couple icon stacks on the left & right of the screen since that would work well?

2 common high score rendering setups include Playfield based numerals but they are kind of big that not much else will fit next to them, the other is often called the SCORE method which uses a multiplexing of Player0 and Player1 each making 3 digits but it can't do much more than 6 digits total and nothing else can occupy its scanlines since the kernel is quite demanding by itself.

It's actually more of an issue of my laptop's colors being off compared to other displays, which causes me to require changing the colors later after working with it (such as brightening a couple of colors on the lizard).

Idk maybe a conversion table, I'm not sure how to resolve differences between the displays of 2 work stations but I'm sure somebody must know something about it.

[Helm]

I'm afaid I don't have much critique at this point because I can't wrap my head around the restrictions from the other thread, yet. But I do consider this to be pixel art (to an even greater degree than working on 8-bit spec systems, even) and I see no need for this to be moved to low-spec at all. I doubt I'll be able to understand what's going on here, but I wanted to say that 1. I am trying and 2. the information and dialogue between you two is a benefit to all Pixelation users to come that will be interested in the 2600. Very glad to see the knowledge drop.

[HughSpectrum]

Looking good, I can make out the face, loin cloth, and boots quite well. I don't quite understand the armor visually, I see gaps from the color changes, are you thinking of filling those gaps in the the lizardman with Missile pixels?

Nope.  They're meant to be "reflective" of the background based on how I tend to shade metal.  It makes more sense on a dark background (at night), but I felt I needed to make it look reasonable at daytime too.

I looked up your inspiration a bit, are you thinking of using the clipped background for HUD space and create a couple icon stacks on the left & right of the screen since that would work well?

Maybe, but only for actions specific to how one would deal with monsters before battle (attack, flee, parlay, etc), and considering this is the Atari 2600 that kind of gameplay is likely out of the question anyway.

In fact, I've decided another reason it'd be best not to care about the sides of the screen is because then I can represent different sizes of monsters by making them wider or thinner.

The actual HUD elements I've decided is a N-E-S-W compass and map coordinates because besides a mini-map, those are the most immediately useful for that type of screen.  Pressing the fire button will bring up a different screen for if you need to see other information.

Later today I'll post some "camp" and battle screenshots that I'm working on, but here's the compass display I made similar to how you described a score display.



@Helm: I'm glad I'm not the only one taking interest.

[HughSpectrum]

Camp screen.  Heart = HP, S = Strength, I = Intelligence, D = Dexterity.  Made the stat scale so that only one digit would need to be kept track of for each stat.


Combat screen.  I originally envisioned a lineup of Player 1 sprites and the enemies being Player 2 sprites on the right, but I figured this setup would make it so that the 2600 wouldn't have to keep track of as many enemies and their stats

Missile sprite for showing whose turn it is, and I envision damage done for physical attacks being a simple animation and a missile sprite being flung towards a target, and "DAMAGE #" on top of the screen.  Magic would be larger missiles, and the background flashing colors while it's flung.

The icons are for the Cleric, and they're Attack, Turn Undead, Magic, and Inventory.

I altered the Lizard image a bit and moved his right leg to our left a bit.

EDIT: Fixed an unintended error on the lizard image.

[BladeJunker]

I'm afaid I don't have much critique at this point because I can't wrap my head around the restrictions from the other thread, yet. But I do consider this to be pixel art (to an even greater degree than working on 8-bit spec systems, even) and I see no need for this to be moved to low-spec at all. I doubt I'll be able to understand what's going on here, but I wanted to say that 1. I am trying and 2. the information and dialogue between you two is a benefit to all Pixelation users to come that will be interested in the 2600. Very glad to see the knowledge drop.

First I'd like to say thanks for your endorsement as I am a big fan of your work and I'm glad you approve of its status as pixel art. Yes the 2600 is quite foreign to every other platform on this forum that people have drawn mockups for. Sorry I probably skipped over too many basics on 2600 pixel rendering than I should have but I think I was just anxious to get to the meat of the subject or the application of the sprite objects towards common pixel art tasks.

I would say most of time 2600 pixel art critiquing lies in the basics of implied form or the iconic shape, the best possible arrangement of pixels from abstract to the clear intentions of the form within imho. Although I am trying to find ways to inject 2600 graphics with more shading depth and traditional pixeling techniques that more typical CCs can be made.

[BladeJunker]

In fact, I've decided another reason it'd be best not to care about the sides of the screen is because then I can represent different sizes of monsters by making them wider or thinner.

Ah I see, that is a good reason to ignore the background clipping.

The actual HUD elements I've decided is a N-E-S-W compass and map coordinates because besides a mini-map, those are the most immediately useful for that type of screen.  Pressing the fire button will bring up a different screen for if you need to see other information.

Sounds logical to have compass and mini-maps have been done in quite a few 2600 games even in ones that didn't really need them.

[BladeJunker]

Camp screen.  Heart = HP, S = Strength, I = Intelligence, D = Dexterity.  Made the stat scale so that only one digit would need to be kept track of for each stat.


Combat screen.  I originally envisioned a lineup of Player 1 sprites and the enemies being Player 2 sprites on the right, but I figured this setup would make it so that the 2600 wouldn't have to keep track of as many enemies and their stats.

Wow looking good, you're like a duck to water with this 2600 work. So much of what I do is exploring the inside of the box that is the 2600 but only a small percentage of my posts have ever been said to be plausible. I can't say for sure you'd get a programmer collaboration at AtariAge but based on your approach I don't think it would be rejected as an impossibility to actually make.

Missile sprite for showing whose turn it is, and I envision damage done for physical attacks being a simple animation and a missile sprite being flung towards a target, and "DAMAGE #" on top of the screen.  Magic would be larger missiles, and the background flashing colors while it's flung.

The icons are for the Cleric, and they're Attack, Turn Undead, Magic, and Inventory.

I altered the Lizard image a bit and moved his right leg to our left a bit.

EDIT: Fixed an unintended error on the lizard image.

Well that all sounds great, you're really grasping the limitations and object alignments very well towards leveraging your sprite objects.