Contra !

[AndrewT]

Hey I am the one working on the project that Bryan spoke of me needing help on. It is gonna be Contra like the one some of you may be familiar with on the NES. I am doing my best to give the game the same feel as the original while I know it will be tough to compare it graphic wise but that doesn't really matter since the graphics will be astounding for a game written in BASIC. As far as moving the character goes, that's basically finished aside from the fact that the gravity/pxl-text routine needs a little work. The level designs are pretty much already thought up. You control a little sprite dude that actually appears to run and it is fast without much flickering. The levels will be in frames, when you reach the end of the right side of the screen a new frame in the level will appear and the character you control will come out of the left side of the screen.

Here's what he looks like:



Not much to him but hey I wanted it to be fast, and that it is.


As far as drawing the levels go, I figured using lists to store line coordinates into would work just fine but I never stored so many numbers into a list before so I didn't realize how much memory it would take up. And I want the levels to be pretty detailed so it really is gonna require a lot of lines. Each level is drawn fit over a 5 x 8 grid so that the guy you control doesn't clear over any part of the level so that the level only needs to be drawn once.

As far as the enemys go, they will probably be moving impaired so i guess if you get near them that will be the only way they could shoot you. Both you and the enemys machine gun has only about a 10 pixel radius. I've already made the gun firing routine for the guy you control, how the enemy's will work... I'll worry about that as soon as I figure out how to make the levels.

The routine I made up to draw the level out of a list looks like this...

1->Z
For(Y,1,dim(LLV1)/4 ;4 coordinates to a line
Line(LLV1(Z),LLV1(Z+1),LLV1(Z+2),LLV1(Z+3)
Z+4->Z
End

This didn't prove to be as 'instant' as I had hoped the level to be drawn. Maybe it would be possible to draw the first level frame in this manner and then somehow store the next level frame as a temporary pic so that when you reached then end of the screen the next one would load up instantly and then draw the next frame in the level and store in into the same temporary pic and so on. But then that would require a pic slot and I don't like having to do that.

But Apparently this isn't going to work considering that the first test list I made contained 100 numbers and it isn't even as detailed as what I had planned for the level to be. That list of 100 numbers turned out to be 911 bytes in size and that's only one frame of the level. I plan to have at least 10 frames to a level. So if I went along with this, 911 bytes x 10 =9110 bytes per level! WHEW! And if I keep going I plan to have at LEAST 10 levels.... 91100 bytes... plus the actual program... and again that list of 50 coordinates, 100 numbers isn't even that much of a detailed level.

... HELP!!

[JacobdeHaan]

Well, two things you can do that will speed it up are to use lists like Jbirk said, and also, for( loops are actually slower than a while loop with you increasing the variable. Those two should give you a little bit of a speed increase...

edit: Lists are a lot bigger because they are always made up entirely of 9 byte floating point numbers

[Bryan Thomas]

Yeah Ive seen it obviously since IM helping him out on it. Its pretty fast. Hes gonna spend the night ove rmy house soon and we will get alot done, we will post updates as they come...

[Adm.Wiggin]

ok, sweet... sounds good... looks awesome

[Arcane Wizard]

Use one list for all frame, but only load the current frame into it.

//character moves to next screen
If L=1:Then //level 1
If F=1:{1,1,1,1,1,2,2,2,2,2->LLVL //frame 1
If F=2:{1,1,3,3,1,2,2,3,3,2->LLVL //frame 2
End
If L=2:Then //level 2
If F=1:{4,4,1,1,1,2,2,4,4,2->LLVL //frame 1
If F=2:{1,1,5,5,1,2,5,2,2,2->LLVL //frame 2
End
//your load screen routine here
//resume game

Something like that?

[AndrewT]

Hmmmm.... that is great, great, great idea. Perfect. But now I wonder how I will make a level editor since the level information will be stored into the actual program and not in there own special list... Where would the level editor store the coordinates without taking up mass amounts of memory. I could just say forget the level editor but we'll see. Thanks Arcane Wizard, that simple idea will probably solve the level problem but now I just need to figure out how to draw the enemys. Maybe in the same manner? But each enemy will need its own x,y coordinate for collision dection to work so I would imagine this would be the best way to draw the enemys...

//character moves to next screen
If L=1:Then //level 1
If F=1:Then
1->A
2->B
3->C
4->D
{1,1,1,1,1,2,2,2,2,2->LLVL //frame 1
{A,B,A,B,C,D,C,D->LNME //frame 1
End
If F=2:Then
5->A
6->B
7->C
8->D
{1,1,3,3,1,2,2,3,3,2->LLVL //frame 2
{A,B,A,B,C,D,C,D->LNME //frame 2
End
End
If L=2:Then //level 2
If F=1:Then
1->A
2->B
3->C
4->D
{4,4,1,1,1,2,2,4,4,2->LLVL //frame 1
{A,B,A,B,C,D,C,D->LNME //frame 1
End
If F=2:Then
5->A
6->B
7->C
8->D
{1,1,5,5,1,2,5,2,2,2->LLVL //frame 2
{A,B,A,B,C,D,C,D->LNME //frame 2
End
End
//your load screen routine here
//resume game

Think that will work?

[Arcane Wizard]

That would work but why save everything to some variables first?

[AndrewT]

I don't want to use up every variable on the calc. If I were to store the coordinates into there variables at the beginning of the program it would require there to be a lot of variables. Much more then exists. The way I did it solves that problem just as your level recalling rountine did. If lets say there were two enemys a screen, that would only be 4 variables. Is that what you were asking?

[Arcane Wizard]

No, I was asking why you used the variables to store the coordinates to at all, you can just use the list.

{A,B,A,B,C,D,C,D->LNME
Doesn't work because of the variables.
This would work:
A->LNME(1)
B->LNME(2)
etc.

/////////////////////

If L=1:Then //level 1
If F=1:Then
{1,1,1,1,1,2,2,2,2,2->LLVL //frame 1
{1,2,1,2,3,4,3,4->LNME //frame 1
End
End

[AndrewT]

Your right but

1->A
2->B
3->C
4->D
{A,B,A,B,C,D,C,D->LNME

technically does work, LNME will = {1,2,1,2,3,4,3,4}

But you are right I should just store the coordinates straight to list like
{1,2,1,2,3,4,3,4->LNME I don't know why I came up with using the variables. Whatever I was thinking, it seemed good at the time but I realized that point as soon as I begin programming my previous version of the code into the actual calc.

And is there any quick and easy AI rountines already made up that will go with what I'm doing? That will be the most important aspect to the game so I got to come up with something good.

[Tyler]

I know this isn't exactly AI, but it would have difficutly levels!

randInt(1,x)->z
If Z=1:

Follow Your X Coords

randInt(1,y)->z
If Z=1:

Attack

The difficutily could be made harder by decreasing x and y, and it may not be very good, because I spent 10 whole seconds thinking about it!

[tr1p1ea]

Do you guys only program in basic?

I realise that this is the BASIC section...but asm offers soo much more flexability... :P

(Dont hit me)

*tr1p1ea runs........

[Arcane Wizard]

[KD5YTX]

If there are simply going to be stationary gunners, I assume the only thing that would be changing would be the angle at which they are aimed (from their "home" position) and the frequency of bullets that they fire. If you keep the frequency of bullets constant, you could just change the angle at which their are aimed by a certain amount (say, 5-10 degrees) to be closer to hitting the player each cycle. They would then "follow" your character (as far as aiming goes), yet the tracking would not be imedeate, giving the player a chance.


Ninja programmers can go 314 hours without sleep or caffeine.

[Tyler]

<OffTopic>

Humans can go 512! (I think I remember that from the guiness book of world records) The grandmother died after because a lack of sleep :

</OffTopic>

[AndrewT]

Well I'll try to describe the ideal AI that I'm looking for. It will need to be what makes it a good game that's challenging yet possible. The enemy's machine gun and yours will have a distance limit and the enemy will only be able to fire at you if your at the same Y level as the enemy. And I also have to come up with something that will cause an enemy to turn around if you jump over him or go under him on a lower platform. I wouldn't want them to be stuck only being able to fire in one direction. But maybe if you go under him on a lower platform it could be so he won't see you so you can jump up to his platform while he is turned the other way and kill him so that could be one of the strategies. lol there goes the game speed down the drain. Ummm about him only being able to fire at you if you are near him... I wouldn't want it so right when you get into a range where you can hit him he kills you instantly haha, but I still wouldn't want to much of a delay before he fires at you. Remember, Contra was a difficult game on NES. But you could dodge bullets there too and I planned for the enemys gun to be kinda instant 5 bullets then clear so the game speed won't be shot. It really is hard making this type of a game in BASIC that is fast. I just don't want this last aspect of the game to ruin it all. I really don't want to write any AI code because it usually takes me a while to come up with something good to me but you would probably laugh at it Arcane Wizard. Whatever you think would work and is fast is all I need.

[Arcane Wizard]

A = player X
B = player Y
C = bot X
D = bot Y
E = direction the bot is looking, -1=left, 1=right
F = range of bullets

If (A+3>C-F)(A<C+F)(B+5>D-F)(B<D+F)
//(A+3>C-F) = player isn't too far to the left
//(A<C+F) = player isn't too far to the right
//(B+5>D-F) = player isn't too high
//(B<D+F) = player isn't too low
//all should be true so multiplying them all will only be true if they all are
Then //player is in range
(A>C)-(A<C)->E //look at player, remember that this is only done if the player is in range, if he's too far away the bot can't see or hear the player and can easily be shot in the back
//fire at player routine, see below
Else //in case you want the bots to run around if you're not near them
//let's say 'place to go' X = H and 'place to go' Y = I
If (C+3>H-3)(C<H+3)(D+5>I-5)(D<I+5) //I take it the bot is 3*5
Then //'place to go' has been reached
C+randInt(-20,20)->H //generate new random 'place to go'
D+randInt(-20,20)->I //bot would just walk through walls and float in the air and stuff, or do you have collission detection and gravity working?
C-(H<C)+(H>C)->C//move towards 'place to go'
D-(I<D)+(I>D)->D
//you might not need the bot to move vertically at all, just remove some stuff
End

I left out the fire routine because I do not know wether you want the bots to only fire straight ahead, if so just fire in the direction E.

[AndrewT]

Thanks a whole lot for the routine. I can't look it over right now... or untill tomorrow but thank you a lot. I'll be sure to stick you in the credits.

[KD5YTX]

In contra, the enemies could all fire in at least 8 directions, up right down left upper-right lower-right upper-left lower-left. You should at least give the enemies the ability to fire up, upper right, upper left, and left + right. Then, just keep their aim following you and firing contuously, so that the bullets can jump out a good 15 pixels in but a couple cycles and the game would still be possible (you could get a feel for the on-off rythym of their shooting - shoot, pause, shoot, pause, shoot, RUN FOR IT...). The platform idea is really nifty...


Ninjas love Contra!

[AndrewT]

Yeah, that's a perfect description of what made Contra a good game. It almost needs to have the aspect of the "shoot, pause, shoot, pause, shoot, RUN FOR IT" for it to really be considered true Contra. And having the enemy fire in all of those directions may be necessary to accomplish just that. I will see what I can do.