Jump to content
  • entry
    1
  • comments
    4
  • views
    4,452

Prototypical Game Idea Thread


R. Jones

722 views

Since Adam Tierney's posts are full of dead images, there aren't many examples of good "game idea" threads. So I was thinking about trying to make sort of a prototypical game proposal thread.

 

The idea is based off of a project I was considering doing, but realized that I don't enjoy the source material enough to go through with the entire game.

 

So here's my rough draft. I thought I'd post this in a blog first, to get feedback on it.

 

The thread will start with one post explaining what the thread is:

This thread is intended to provide a template that shows what a good game proposal for the Atari VCS/2600 is.

 

Things to keep in mind when starting threads about game you don't intend to program:

1. The Atari's graphics chip (the TIA) is limited but flexible. If you design a very complex game that ignores the Atari's limitations, then it will be impossible to do on a real VCS and pretty much worthless to a programmer. If you just dumb your idea down, you will have a game that is lacking in many areas for no reason. To create a good proposal you should try to get at least a basic knowledge of how the machine works. This post by supercat gives an easy to understand explanation for the layman.

 

2. For the same reasons as above, include a lot of mock-ups. It's much easier to look at a picture of how something's laid out and think, "That's clever," than to read through many paragraphs and try to imagine it. Also, if you're musically inclined, you can try Paul Slocum's Music Kit to prototype music for your idea.

 

3. Don't limit your ideas for no reason. Don't try and come up with "simple" ideas because the atari is a "simple" system. Keep you proposals within the limits you know of, but don't expect Stella to be weak without cause. If your idea is impossible people will tell you, and some of them will even tell you why. You can learn from that.

 

Then I will post this second message into the thread, right behind the first:

 

Pac-Man

 

One problem with the Pac-Man games for the VCS is that they have to flicker a lot. If you could create Pac-Man using the ball, then the ghost could be flickered at 30 hz. I think this would look really good on a black background.

 

Here are the horizontal frames of animation for Pacman:

 

 

Here are the vertical frames of animation for Pacman (top) and the sprites for the ghosts moving in different directions:

pesco.zip

 

In the maze, the bonuses would be made out of the ghosts' missiles, and at the bottom of the screen they would be displayed using multicolor sprites, :

post-571-1072135354_thumb.jpg

 

The playfield would also flicker at 30 hz. It would alternate between blue and yellow. The dots would be displayed on both the blue and yellow frames. They would bleed together and have a light grey appearance. The walls would be shown only on blue. And the protagonist only on yellow. Any text would be done in either grey or yellow. Bright white text, would make the "white" dots look dull. Here's a mockup of the screen layout using Ms. Pacman as a base:

 

 

And another from scratch:

post-574-1072753844_thumb.jpg

 

I'd love for this to be able to fit into 4K, but if it can't, then might not be too hard to add several other Pac-Man games to the cart:

post-574-1072754277_thumb.jpg

post-574-1072754276_thumb.jpg

 

EDIT: I've added a demo that I made in bB, that demonstrates the idea.

4 Comments


Recommended Comments

It is complimentary? I'll add a demo to the original post. I can't attach it to this.

 

Two colors whose hue differs by 7 or 8 will blend to show something close to gray, but it will often be slightly tinted. Various factors will affect the tint that's produced, and games should not require the user to distinguish among various grays since some of them may be identical with certain monitors and machines.

 

To understand the reason for the tinting, imagine that a particular monitor renders colors as (assume hue is scaled from 0 to 2*pi)

 

blue=luma-saturation*cos(hue)

green=luma-saturation*cos(hue + 2*pi/3)

red=luma-saturation*cos(hue - 2*pi/3)

 

If luma and saturation are both 0.5, then a hue of zero would represent rgb=(0.75,0.75,0) while a hue of pi would represent RGB=(0.25,0.25,1). Although either set of colors should balance out to (0.5,0.5,0.5), in practice there will be a visual difference between blending 0.25 with 0.75, versus blending 0 and 1.

 

In any case, I would suggest that flicker-blending colors to produce gray (as opposed to stripe-blending or flicker-stripe blending) may produce an annoying level of flicker. Using two colors whose hues are closer to each other will greatly reduce flicker or stripiness.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...