Jump to content
LS_Dracon

Spider Game [Atari 2600]

Recommended Posts

Here I am with my third project for the Atari2600.

It's an original game, actually my first game concept (My previous project is an unfinished Pong clone and Bee•Ball, original concept created by one friend, not by me).

 

Spider game (prototype name) is a platform game, you play as spider and must walk around and climb platforms to collect goodies, while dodge all cast of dangerous enemies such scoprions, bats and others.

 

You can climb on upper platform, fix on it and walk in upside-down view, this is the novelty.

Another good think, this game will have tons of different stages with different themes and each stage with own selection of enemies.

 

At first, my idea was not another insect themed game (spider is an arachnid, thoug), but one game that have a option to play in inverse way, walking in upsidedown view.

This make sence if the player is an insect. The original idea was playing with an ant, but ant doesn't jump so I figure one jumping spider. The interesting from spider is the hability to make web, so instead jump, do the web.

 

Probably you think about vcs spiderman, there's nothing from spiderman in this game, exept the web, but unlike spiderman, the web is not the real gameplay, here its fast to do and you don't need a high precision. The web is a complement.

 

To create a huge numbers of levels, this must to be an 8kb game. I gonna use the first 4kb bank for main code, and the extra 4kb for store level data.

In theory my code need about 28 bytes per level, so in a 4kb I can store about 142 levels.

Too much, my goal is around 60-70 levels, enought and no doubt I gonna find a good usage for the rest of the rom.

This demo is 4kb and probably keep this until the final adjusts.

 

My biggest task was create a flexible code enought, for easily build new stages and send new enemies information. I'm still working on it and soon as possible everyone here can create levels for this game. :)

 

Don't worry about sprites, I'm patiently drawing them, the current sprites is a placeholder.

I wont show the real sprites for keep them as surprise, I'm trying to do something new for the vcs.

 

The game is almost done in my mind, now I have the hard job to convert idea into binary.

Feedbacks are welcome, and let me know your first considerations :)

 

How to play : move the spider to left or right, and hold fire button to make web.

If web touches the upper platform, keep holding the button and push up to get up (or down, if needed)

Touching any platform you fix and can walk on it. If you walk tru an hole, you will fall.

Relase button to cancel web at anytime.

The objective is collect the "fliyng dots" (not added yet) and avoid enemies (there's no collisions detection for now).

Alot of things do not work for now or work with bugs, soon as possible I will fix them all.

The real game history and objective I'll post soon.

 

Edit : Every new version, I'll delete the previous one, the latest version is atached on my late posts.

post-10940-1228394506_thumb.jpg

Edited by LS_Dracon

Share this post


Link to post
Share on other sites

Neat concept! Would it be feasible to have the web stay put when you let go of the fire button? then have it disappear if you tap the button again? Also, it'd be neat if you could swing on a web so that momentum can get you over obstacles. This may affect the gameplay you had in mind but I thought I'd just throw it out there :) Looking forward to your progress!

Share this post


Link to post
Share on other sites
Neat concept! Would it be feasible to have the web stay put when you let go of the fire button? then have it disappear if you tap the button again? Also, it'd be neat if you could swing on a web so that momentum can get you over obstacles. This may affect the gameplay you had in mind but I thought I'd just throw it out there Looking forward to your progress!

Tnx Emehr.

I did some test creating one vetorial line, necessary for this effect, it's on hold.

i like the idea...keep us updated on your progress

Tnx Paulie, glad to see you liked Bee•Ball, or at least, the label :)

ice concept. Looking forward to its progress...

Tnx TrekMD.

 

Edit : I have one question for veterans programmers:

How safe is use 200 scanlines of picture, reguarding 262 lines of ntsc resolution?

And shoud I reduce vertical blank or overscan lines?

Edited by LS_Dracon

Share this post


Link to post
Share on other sites

I still need to order Bee-Ball from Atariage store one day..i like the game from what

I saw on my emulator... I like the label..hence why i used it as my Avatar

 

keep up the good work...

 

Paulie

Share this post


Link to post
Share on other sites

Finally, finished the kernal, I don't need to care about how the atari will display the game graphics. It's done :)

 

Here's what the kernal support :

 

10 Independent enemies, 2 per floor. Independent position, speed, direction, sprite and color.

 

5 Flying dot (item to be collected) 1 per floor, with independent position, direction and speed. They are ball object, so I can't draw one sprite for them and they share playfield color. This object is one Fly (insect)

Probably I'll use Frog Pond's fly like.

 

1 Floating sprite, the spider, with missile (web) support.

 

4 Platforms, assimetrical, with possibility to set holes at any desired position (PF1-PF2-PF3-PF4) for now, holes with 3 and 4 pf-pixels size are possible.

 

5 Columns, simetrical, one per floor. Using PF2 only.

As it is simetrical, changing PF2 the same information goes to PF3. For create a sort of maze.

 

About the rom information necessary for one level :

 

10 Bytes, one per enemy. Using left nibble to select the enemy, up to 15, plus blank (no enemy)

And right nibble to select NUMSIZ1 (sprite wide, 2 or 3 copies etc...) Not added yet.

 

8 Bytes for the platform, 2 bytes per row, one nibble for each PF, I can add up to 16 possible combinations for the holes, including blank PF and full (no hole). 9 combinations already used, Blank, Full, 4 positions of holes with 3 PF-pixels wide and 3 positions with 4 pixels wide.

They can be set at any position of the platform, one hole per PF, maximum of 4 holes per row.

I still have 7 free combinations for future expansion (such 2 holes per PF).

It's added and working.

 

5 Bytes for columns. 1 byte/column per floor, I can directly draw the wall. Using 1 pixel for example, I have two columns/walls, as it's simetrical. And I'm using PF2 only, it's enough.

Added and working.

 

10+8+5 = 23.

 

I can create about 90 unique levels (type of enemies, holes and walls places) using only 2 kb of rom data :)

 

And about the game itself (I don't start to code it yet. It's a to do list)

 

15 possible enemies types (Scorpion, bat etc...), maximun of 10 per screen, I can choose any of them in order of appearance.

Each enemy had own movement pattern. Scorpions just walk foward, turn and walk again. It's most basic.

They don't know where the spider is, and they are slow. Good for the first enemy of the game.

Bats fly fast crossing the screen, such bats from pitfall 2, mountain king etc... :P

There will be enemies that know where the spider is and attack.

 

About Fly, I don't know if shoud be good display all five or only one per time... Anyway it's possible display all 5 at same time.

 

The spider can fix and walk on the upper platform, also reach new floor using the web and crossing the platform's holes.

But the spider can't thru the walls, and not climb on it.

The enemies such scorpions can't too, so I have plans to create enemies able to through the walls.

 

Hiting the fly you collect it and earn points. Touching enemies, you loose one life.

 

I Don't know the rules to go for next level, maybe collecting % of Fly, or by time, and if you not collect one amount of fly, you loose one life. I don't care about this for now.

 

Around 10 levels per stage, each stage with own enemies and tricks, my objetive is about 6 or 7 stages (~70 levels).

 

It's the game I have on mind. Things can be changed, removed or added.

 

Edit : Column :P

post-10940-1229474865_thumb.jpg

Edited by LS_Dracon

Share this post


Link to post
Share on other sites

Looking good so far! I like the fact that the spider can walk on either the top or bottom of the platforms. That's going to add a lot of possibilities to the gameplay.

Share this post


Link to post
Share on other sites
Looking good so far! I like the fact that the spider can walk on either the top or bottom of the platforms. That's going to add a lot of possibilities to the gameplay.

Tnx.

My next target is a working gameplay, with a definitive code for the spider.

This version show full using of the kernal, in early levels I don't need to set all 10 enemies, walls or platforms.

Edited by LS_Dracon

Share this post


Link to post
Share on other sites

Tnx Impaler.

Here is a example of how the levels can be.

There's nothing new, just changed the codes to display one level.

 

...

 

I'll be out by one or two weeks, in january probably I'm return to the works :)

Edited by LS_Dracon

Share this post


Link to post
Share on other sites
Edit : I have one question for veterans programmers:

How safe is use 200 scanlines of picture, reguarding 262 lines of ntsc resolution?

And shoud I reduce vertical blank or overscan lines?

200 active scanlines should be perfectly safe for an NTSC picture. If I remember correctly, the Commodore computers had 200 active scanlines.

 

For NTSC, we can say there are three types of active area for the television screen display:

 

-- There's the whole picture, meaning the entire active area (i.e., the part that isn't blanked). As I understand it, very few older TV sets were able to display the whole picture, because they were deliberately designed to overscan the picture, or draw it too big for the screen, such that the outer edges of the picture ended up being "cropped." This is 100%.

 

-- There's the "action safe zone," which is a slightly reduced area that is expected to be visible on most TV sets, although the outermost edges might not be visible on all TV sets. Broadcasters and TV producers try to keep all "significant" action in this zone, so it will be visible on most TVs. This is 90% of the picture in the horizontal and vertical directions-- i.e., there is a 5% "border" on all four sides of the picture (although "border" isn't really an accurate term, since it does contain picture information-- just not any "significant" parts of the picture).

 

-- Finally, there's the "title safe zone," which is an even more reduced area that is expected to be visible on all TV sets (but possibly not on some TV sets). Broadcasters and TV producers try to keep all titles, credits, and other textual information in this zone. This is 80% of the picture in the horizontal and vertical directions-- i.e., there is a 10% "border" on all four sides of the picture.

 

Most modern TV sets can display more of the picture than older TV sets could-- but not everyone has a modern TV set!

 

I'm not certain what 100% of the horizontal dimension is in terms of color clocks, because the exact numbers can vary a bit depending on the standard used. The original RS-170 standard gives the numbers as 63.5 µs for the entire scanline, with 10.9 µs for the horizontal blanking interval and 52.6 µs for the active portion. These are approximate values, and are for the original monochrome video standard rather than the revised color video standard, but we'll use them as given. There are 227.5 color clocks on a scanline, so that's about 188.45 color clocks for the active portion (227.5 * 52.6 / 63.5). That's 100%, so 90% is about 169.6 color clocks, and 80% is about 150.76 color clocks. The Atari 2600's active portion of the scanline is 160 color clocks, which is about 85% of the whole picture in the horizontal direction. Thus, all of the Atari's 160 color clocks fall within the "action safe zone," but some of the pixels on the leftmost and rightmost edges of the screen might not be visible on some older TV sets.

 

For the vertical direction, the whole picture (or 100%) has 483 active lines-- but that's for an interlaced picture, and the Atari 2600 doesn't usually display an interlaced picture, so we'll call it 241.5 lines. That means 90% is 217.35 lines, and 80% is 193.2 lines. Thus, if we display 192 lines (about 79.5%), we can safely assume that all of the lines will be visible on just about any TV set, since all of the lines will be within the "title safe zone." If we increase our game screen to 200 active lines (about 82.8%), we're still well within the "action safe zone," and only slightly beyond the "title safe zone," so we can assume that all of the lines will still be visible on most older TV sets, and almost certainly on just about any newer TV set.

 

As for whether you should reduce the number of "vertical blank" lines or the number of "overscan" lines, you should reduce both to try to keep the active lines vertically centered on the screen. The "Stella Programmer's Guide" gives the following numbers:

 

3 "vertical sync" lines

37 "vertical blank" lines

192 "picture" lines

30 "overscan" lines

 

But that's actually a little bit off from being vertically centered, because the NTSC standard gives the following numbers:

 

3 "pre-equalizing pulse" lines

3 "vertical sync" lines

3 "post-equalizing pulse" lines

11 "vertical flyback" lines

1 "closed-captioning" line

241.5 "active" lines

 

If we reorganize that to better correspond with the Atari, it would be more or less as follows:

 

3 "vertical sync" lines

15 "vertical blank" lines

241 "picture" lines

3 "overscan" lines

 

To keep the active picture vertically centered as we increase or decrease the number of "picture" lines, we would want to increase or decrease the "vertical blank" and "overscan" lines in equal amounts. Since 192 is 49 less than 241, and half of 49 is 24.5, we would therefore add about 24 or 25 lines to the "vertical blank" and "overscan," which would be as follows:

 

3 "vertical sync" lines

39 "vertical blank" lines (remember, the "Stella Programmer's Guide" said 37)

192 "picture" lines

28 "overscan" lines (the "SPG" said 30)

 

Likewise, the ideal numbers for a 200-line picture should be more or less as follows:

 

3 "vertical sync" lines

35 "vertical blank" lines

200 "picture" lines

24 "overscan" lines

 

Michael

Share this post


Link to post
Share on other sites

Thanks Michael, for your explanation. :)

 

I'm using the standard picture size, reducing some lines from kernal. But is good to know more about it.

 

Do you know something about screen standard used by Activision in their games?

Vblank (?), picture (192) and overscan (?).

 

I don't know if is my Atari2600, but Activision games works with perfect screen...

Some others games, the screen get a little distortion, nothing annoiyng, but probalby is problem on synchronisation...

Share this post


Link to post
Share on other sites
Thanks Michael, for your explanation. :)

 

I'm using the standard picture size, reducing some lines from kernal. But is good to know more about it.

 

Do you know something about screen standard used by Activision in their games?

Vblank (?), picture (192) and overscan (?).

 

I don't know if is my Atari2600, but Activision games works with perfect screen...

Some others games, the screen get a little distortion, nothing annoiyng, but probalby is problem on synchronisation...

I don't know if Activision had a "company standard" about that, but we can either disassemble their games and see what the code says, or run them in Stella and watch the line numbers in the debug mode as the screen is being drawn. I'll chevk out a game or two and let you know what I found out, but the minor difference between the numbers given in the "Stella Programmer's Guide" versus the "more or less ideal" numbers that I posted shouldn't be enough to matter one most TV sets, unless you want to pull out a ruler and measure the top and bottom borders of the screen to see whether they're equal. On the other hand, if you're going to start adding more active lines to the screen (thereby decreasing the sizes of the top and bottom borders), then you'll probably want to get closer to the most "ideal" numbers as far as keeping things as vertically-centered as possible. And the bad news is, you still can't control whether the picture will be vertically-centered on all sets, or whether all of the active lines will be visible!

 

Michael

Share this post


Link to post
Share on other sites
Sorry to be such a killjoy.

Hehe no problem, I mean original because is not a port from existent game.

Impossible to not be influencied by others games. ;)

 

I'll look for information about Spider: The Video Game.

 

But my game will not be called spider game, it's a proto name, I need find one name. Accept suggestions :)

Share this post


Link to post
Share on other sites

Spider for PS1 was a great game. I wish they made a newer one. It would make me buy a PS3!!! Only for that!

Share this post


Link to post
Share on other sites

Looks great. Perhaps the Spider can be after an aphid ... which does look like a little dot.

 

Aphids are also eaten by lady bugs, hoverflys and wasps. Perhaps these can be your enemies.

Share this post


Link to post
Share on other sites

I not work much on this game in these days.

This new beta shows the gravity system, a very small update. The spider can't be damaged if fall, I never liked this on the old games.

The cutscene is more interesting, I want to use "hiper sprite" (composition of sprites and playfield pixels to draw one image)

as cutscenes between the levels. I think is a good usage of the graphic vcs hardware and don't waste much rom ( I can store 9 images like that in 1kb).

 

My next step is a bit hard, I need to add the playfield colision code, this must be done by software because both, platforms and columns, are playfield and the spider must be free to walk horizontally on the platform but not to cross one column, or fall even touching one column but stop hitting a platform.

 

Timdu, one AtariAge user, give-me some suggestions for the game name, and ArachnaMania sonds cool for me, what you think?

 

Looks great. Perhaps the Spider can be after an aphid ... which does look like a little dot.

 

Aphids are also eaten by lady bugs, hoverflys and wasps. Perhaps these can be your enemies.

Tnx Devin, I'm using one Fly becouse it can be moved fast and turn the hunting more challenging.

I like the idea to use one wasp, some wasps are natural spider's predator.

 

The enemy list for now:

Scorpion, Bat, Centipede, Explosion beatle, Wasp, Mole.

And not living thinks like fire and others.

Also

and sand beatle, but these are fixed on the floor and don't think if coud be usefull.

 

People, look this funny video about jumping spiders : http://www.youtube.com/watch?v=D92AUXhYZ0M :D

spider_v0.4c_Feb08.bin

cutscene.bin

post-10940-1233701930_thumb.jpg

Edited by LS_Dracon

Share this post


Link to post
Share on other sites

Just for report, this project is not dead.

 

I was working in a new kernel and it's almost done.

Now the game support enemies with size and copy number variation.

My problem now is the RAM, even removing one floor, now with 8 enemies on the screen, still heavy to handle all of these sprites.

I'm using 76 of the 128 bytes avaliable. Don't want to jump to 256 bytes of RAM, not yet.

 

Since there's not much changes from the previous beta, follow an image only :

post-10940-127432275125_thumb.jpg

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   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...