Idea...?

[Giltygear]

So i'm screwing around with tutorials and examples in VbB and such, and i came up with an idea for a game. This might prove to be a bit too much for the 2600 to handle and quite an undertaking considering how little programming i actually KNOW, but i figured id run it by you guys before i started anything.

 

On the PS1 there was a game called "Sanvein," which was a grid-based race-against-the-clock-type shooter. Its actually very good, so if you have a means to play it, then enlighten yourself and do so.

 

Anyway, the "levels" are actually a honeycomb-style grid, with the cells themselves being the actual "stages." Yu only have a short amount of time to pick a stage, or the game automatically chooses whatever cell your cursor is on. when you pick a stage, your ship faces off against 3-5 enemies. when you defeat the enemies, you go back to the grid and pick another one.

 

Boss stages are placed in certain spots on the grid, which brings a certain amount of strategy to the game, as you can only pick stages that are "connected" to the previously cleared cell (hence the honeycomb design). The more cells you clear around a single cell (be it a boss stage or not) the more powerful your ship becomes, which gives you more firepower to defeat the enemies in that particular cell.

 

All through the stage there is a counter that is constantly counting down, which adds to the urgency of picking the fastest path to clear the "Boss" cells to clear the grid and move onto the next one. when cells are cleared, you gain a small amount of time back, as well as a score boost. When you're ship is hit, you LOSE time, so it become crucial in the latter parts of the game to try to clear the stages as fast as possible with as minimal damage as possible.

 

I have a very preliminary layout for this game:

 

-The first screen would be the grid.

-when you pick a stage, the next screen would be the enemies (obviously it would start out very simple and progress from there)

-when the stage is cleared, you return to the grid to pick another stage, with the one you just finished being "greyed out" so you couldnt pick it again, and so you can plot your next move

-3 sprites: player, enemy, and boss (im aware that they would not be very detailed, but i would like their strength to increase as you get deeper in the game). i would like to just change the color of the enemy and boss sprites to go along with their strength/HP level

 

Now im not very technical with bB or programming in general, and im not too sure about the limitations of the system. Would something like be even REMOTELY possible to pull off?

 

a video to demonstrate what im talking about

 

Any input would be appreciated. IMO i think this type of game would be perfect for this system

[ScumSoft]

You'd really have to dumb down the games action a bit for the 2600. It would most likely resemble Disc's of Tron with a honeycomb grid doing things the normal way.

[+grafixbmp]

I found your idea inspiring and drew up some quickies in 5 min thought I would drop them in. Have fun!

 

[Giltygear]

I found your idea inspiring and drew up some quickies in 5 min thought I would drop them in. Have fun!

 

 

Thats awesome! Thank you. really gives me some much-needed inspiration

[+grafixbmp]

Never noticed this before and it may be because I wear glasses but the red hexes appear to float in 3d above the blue ones. Man I love optical illusions.

[Giltygear]

Never noticed this before and it may be because I wear glasses but the red hexes appear to float in 3d above the blue ones. Man I love optical illusions.

 

How did you make that picture? im using vbB, and cant get anything close to resembling what you made...

[+grafixbmp]

Never noticed this before and it may be because I wear glasses but the red hexes appear to float in 3d above the blue ones. Man I love optical illusions.

 

How did you make that picture? im using vbB, and cant get anything close to resembling what you made...

 

Well, with vbB you dont get the full range of the playfield and you have several limitations with the standard kernel sprites. You 'can' get something similar by brute forcing it. Activate your multiple copies and set the positions so that you have alternating layout with one player set to 3 close and the other to 2 close then setup your sprite as a tall one for both having many of the hex images in a row vertically then just have the player set to 3 draw them and the player set to 2 "being in between the 3" display the same thing but offset by have tall hex space. This way you only get either one color if both are set to the same thing or alternating pattern of 3 blue and 2 red. There are limitations which limit what you can produce but you 'can' create some intresting patterns. As far as the plafield, it gets chunky but it can work. Here is an example of what vbB version could look like.

[Giltygear]

OK, so just so im straight, youre talking about 2 different "player" sprites?

 

I really do apologize, but that explanation went right over my head lol

[+grafixbmp]

OK, so just so im straight, youre talking about 2 different "player" sprites?

 

I really do apologize, but that explanation went right over my head lol

 

Ok the 2600 graphics chip "the TIA" has only a few graphical properties. For general bB use there are player0 and player1 each being 8 bits wide. there are 2 missles only one bit wide. and a single bit ball for a total of 5 objects. Thoes objects can be modified with control registers listed on Random Terrain's bB guide website. You can duplicate both of the 8 bit wide player graphics to make copies of themselves you can even stretch a single sprite too. These copies position themselves to the right of your actual sprite location and do so as 2 or 3 repeating what you have set as that particular graphic. The spacing of the copies is predefined in the hardware but the are several options. If you position player0 somewhere on the screen and position player1 8 spaces to the right of it and activate the repeat settings, they automaticaly create the copies for you. Then you need to use the ball or missiles as a cursor and then check the cursor's position to know which hex block it is over. There are several examples in the batari Basic section of the forum. They are code snipets which preform some of the basic things in programing a game. The one thing to remember is when you set up what you want to be shown and run conditions and such then you must "drawscreen" and the changes will be made. you can have more than one drawscreen in a program but you must always make your program loop. For every pass through your loop, you begin to change minor things about what is being shown. But remember that there must be 60 drawscreens a second which means that your game code shouldn't take too long between "drawscreen"s

 

As a quick example, if you change the location of a graphic every other drawscreen then change it back the others, you effectively add another graphic to your screen but this produces flicker which is one of the classic 2600 staples among many other consoles.