Berzerk 2600 in OpenGL

[Ringman]

Hey guys, my next OpenGL assignment for class involves remaking a classic atari 2600 game in OpenGL, we were limited to games of a certain type and I decided to go with Berzerk. I'm not asking about OpenGL code or anything like that, I got that. What I'd like to have is info about how Berzerk handles certain things. I read through the manual and played the game many times (a personal favorite), but I am still missing some basic info. I may have to play it a couple of more times and take notes to figure this out but if anybody already knows this stuff please tell me. Here's my questions:

 

How many room styles are there?

 

Do the color of the robots mean anything? (They don't seem to the basis behind robot activity simply seems to be how long you've been playing up to the 16th map and then it resets, though the speed of shooting stays the same once its hit max).

EDIT: Apparently color DOES affects the score and speed of the robots in the arcade, so it probably does the same in this version.

 

What are all the possible positions that he player appears at when entering a map? Does anything influence this?

 

EDIT: Apparently, the guy appears in the opposite spot from which he exited which then always puts him next o a wall. This obviously helps influence which map to use for the next room.

 

What are all the possible robot placements in each map? Does anything influence this?

 

What are all of Evil Otto's entry points? Does anything influence this?

 

EDIT: Evil Otto shows up after about 8 seconds into playing and comes from the direction that you began at.

 

Not specific to the Atari 2600, but what are all the voices used in the arcade version and when are they used? ( I may add sounds if I have time).

 

That's really it, the manual seemed to help sort out the rest.

 

Thanks, if you guys can help me I'd appreciate it, if not please don't tell me "Go play the game yourself and leave us alone." Obviously that's what I plan to do, but I was hoping someone could help speed up the process. Also if you guys think there may be a better place for this topic let me know.

 

EDIT: Robots fire are right handed when firing up or down.

 

If I get the chance I'll be posting my progress as I make it.

Edited September 25, 2008 by Ringman

[Nukey Shay]

How many room styles are there?

Four wall layouts. Two tall vertical walls, two tall vertical walls joined by a long horizontal wall, short vertical walls bordering the upper and lower exits, and short vertical walls bordering the upper exit with short horizontal walls below the side exits.

The left/right (combined), upper, or lower exits are blocked depending on where the player entered the room...so there are a total of 12 screens (4 with sides blocked, 4 with upper exit blocked, and 4 with lower exit blocked). The game uses reversed playfield pixels to block the exits...which is why the side exits are not blocked individually. A hack done by Supercat alters the game to use the ball sprite to accomplish this (interestingly, the collision-detection was already present for the ball sprite...suggesting that the original programmer may have had this in mind when writing the kernal).

 

 

Do the color of the robots mean anything? (They don't seem to the basis behind robot activity simply seems to be how long you've been playing up to the 16th map and then it resets, though the speed of shooting stays the same once its hit max).

EDIT: Apparently color DOES affects the score and speed of the robots in the arcade, so it probably does the same in this version.

Yes and no. The game uses a data table of 8 specific colors...which loop infinitely (although the robots themselves become increasingly more aggressive until the internal level counter is bumped past value 255 and rolls back to zero). The game level is divided by 2 (so that each color is used on 2 successive screens...except the first level - which is always yellow).

 

The 8 robot colors:

$1A (Yellow)

$36 (Red)

$0C (White)

$CA (Light Green)

$4C (Light Red)

$A8 (Greenish Blue)

$F0 (Brown)

$58 (Purple)

 

 

 

What are all the possible positions that he player appears at when entering a map?

Four. The game always starts with the player near the left exit spot (both side exits are blocked)...facing to the right. When exiting a screen, the current direction that the player sprite is facing is kept...and the screen position is updated to fall in the middle of the (blocked) door on the next screen. If a player is killed within a maze, it's screen position is flipped back to it's starting location...but the direction that the player faces is always kept regardless.

 

 

Does anything influence this?

There is no deviation. It's 100% dependant on where the given screen was entered and the current direction the player faced when doing so.

 

 

 

EDIT: Apparently, the guy appears in the opposite spot from which he exited which then always puts him next o a wall. This obviously helps influence which map to use for the next room.

The game uses no "map". One screen of the four is picked at random, and the starting position is checked when copying the screen data to the display to determine which of the exits to block.

 

 

 

What are all the possible robot placements in each map?

The vertical locations of the seven robots are set sequentially during the init routine. You can easily see this by pressing reset repeatedly while looking at the HMOVE lines on the left screen border (the HMOVE lines are always in the same locations). The horizontal position is picked at random. If this happens to fall where a wall exists, that robot is eliminated for the screen (leading to a pseudo-random number of robots for that level).

 

 

Does anything influence this?

Other than the random seed (which is an unknown value copied when the cartridge is powered-up), there are no outside influences.

 

 

 

What are all of Evil Otto's entry points? Does anything influence this?

EDIT: Evil Otto shows up after about 8 seconds into playing and comes from the direction that you began at.

Otto always appears precisely where the player entered. Those variables are simply reused to set it's initial location.

 

 

 

Not specific to the Atari 2600, but what are all the voices used in the arcade version and when are they used? ( I may add sounds if I have time).

Attract mode speech: "Coins detected in pocket"

During the level (robots still present): "Get the humanoid". The words are stored seperately, so "get" may be replaced with "kill" or "destroy". Likewise, "humanoid" may be replaced with "intruder".

When Otto appears: "Intruder alert! Intruder alert!"

Leaving a room without destroying every robot: "Chicken, fight like a robot!"

Leaving a room after destroying every robot: "The humanoid must not escape!"

Touching a wall, robot, robot missile, or Otto: "Got the humanoid!", and then immediately following in a different pitch, "Got the intruder!"

[Nukey Shay]

BTW the voice samples used in the arcade game can be downloaded here:

http://www.mameworld.net/samples/

 

Click on "older samples" for Berzerk.

[ComputerSpaceFan]

Since this hack never included the Voice Enhanced mode I would say that should be included in yours. I hope your Berzerk works out. Must have diagonal shots for both the player and the robots too. That's all I ask.

[Nukey Shay]

Since this hack never included the Voice Enhanced mode...

Huh? Berzerk VE has voice samples. The hack that you are linking to, Berzerk Arcade VE, is based off it.

[ComputerSpaceFan]

Since this hack never included the Voice Enhanced mode...

Huh? Berzerk VE has voice samples. The hack that you are linking to, Berzerk Arcade VE, is based off it.

 

Oops my mistake. Aplogies all round.

Still hoping for voice + diagonal shots though.

 

EDIT: this was the hack I meant.

Edited September 25, 2008 by ComputerSpaceFan

[Ringman]

Thanks immensely for the info nukeshay this will be extremely valuable.

 

I need to implement mouse picking in this game (required by the professor) so I will enhance it a bit anyway by giving the player a targeting system and the robots some small amounts of health. Basically, you click on the robot and from then on all your shots will aim for the robot's current position (unless he's dead at which point your shots will just shoot at their last position.) with some turbulence so that you miss from time to time. You'll need to click on the next robot for the next target.

 

Sorry if this seems to be changing the game alot, but this is a required part of the project, so I don't have much of a choice, and this was the easiest way to pull this off. Because of this, I will be giving the robots diagonal shooting to give them a better chance of nabbing you, since it will be easy to wipe them out with targeted shooting. You still only get 1 health, but the robots will get probably increasing amounts as the game gets harder. I'm Not sure by how much.

 

Sorry about the bolds, I'm just trying to make this post easier to read. Lol.

Edited September 26, 2008 by Ringman

[Rybags]

http://www.klov.com should also have some Berzerk info.

 

Another thing you must preserve: The "Bulletproof Necktie".

 

In the arcade and home versions, the head and body of the player have a blank pixel between them, and horizontal enemy shots can pass through it without harming the player.

 

 

Another thing: I think the 2600 version is the only one with flat bullets for diagonal shooting. A remake would probably work best with diagonal shaped shots as intended in the original arcade version.

Edited September 26, 2008 by Rybags

[Ringman]

Oh for the "auto aim" thing, I'll make it so it can be toggled on or off for those of you who'd prefer classic berzerk. The other thing is, I'll TRY to implement the bullet proof neck tie. This would require either, handling the head and player as separate polygons, or just reading the the pixels on the screen ahead of the shot as being, black or not, or figuring out where those pixels exist in on the cooridinates and specifying them as a "special case" for colision detection. Though, given the fickleness of openGL with concave polygons, it might just be easiest to make them separate images.

 

Right now, the only thing implemented at the moment is walking around the screen, double buffered animation, and mouse selection. I've set up the animation routine I just don't have any of the frames made yet as I'm doing this between other projects. But don't worry guys, because I have a deadline on this (and thankfully a 5 day break coming up) It WILL be done by Wednesday of next week. I don't have a choice in the matter, my grade depends on it!!!! I will release it as is, and release the source code (well commented of course because the teacher demands it.) for anyone who wants to play with it. Mind you, I am an ameteur openGL coder, so there may be things I do that could've been handled in an easier way. I'll try to compile a unix/linux version as well as a windows version if I can because its only a few changes of code and I can access our linux server from home to test it on.

 

Wish me luck.

 

EDIT: I do now have frames added in and full support for 8 way movement via the 4 arrow keys. Im right now handling the player sprite as a series of blocks, but it looks like it might be better to do it as a series of pixel wide vertices, then collision detection will be spot on and I can just input 2d bit arrays as my graphics and have it run them through a glVertex2d loop to render them.

 

One thing I need is all the frames of the characters, I realise I can get this via one of the atari graphics editors, which I probably will, but if anyone could do the job for me I'd appreciate it. This will makes things go faster since I won't have to worry about defining glPolygons for every sprite, and I won't need to use a tesselation function to process them.

Edited October 1, 2008 by Ringman

[Ringman]

UPDATE:

(First off if double posting for updates is not acceptable, please say something and I'll refrain from it, but I'm not sure if people will check this if it doesn't have new replies.)

 

Model Display

 

I've moved over to pixel wide vertices as opposed to gl defined blocks, this saves memory has less lines of code. I could do texture mapped planes, but this is much easier and will be able to be checked for pixel perfect interesections if I implement it right (so that way I can do the bullet proof necktie without modelling the head separately). This meant the vertice size had to be changed apon window resizes but that works fairly well. The only glitch some window sizes show black lines separating some of the pixels, I fixed this problem from occurring as often by setting it so that the vertices are a tiny fraction over 1 vertice per "unit", so the game looks normal at default and full screen and most sizes in between. The lines show up sometimes in sizes smaller then normal size.

 

Window Resizing

 

The normal viewport size is currently 800x400. This means some of the space is wasted in the viewport because the map takes up approx 700x400 but this was done for easier proportion calculations between resizes of the window, I might change it to 640x480 so there isn't a problem with screen resolutions, but since I'm using proportions you can resize it to whatever you need. The other reason for this is that 2:1 gets less hairy in decimals then 3:4 when it comes to weird resizes. Further more in that scenario there's more wasted vertical space as opposed to horizontal space, but at least default will fit most monitors. The original atari resolution was 190x160 which results in a really weird fraction (a discrete one, but weird nonetheless) and thus loses precision during resizes. This precision needed to maintain not only accurate vertice sizes, but collison bounding boxes as well.

 

Room Display

 

One room variation is up for testing purposes, and its only declared once then instanced twice and mirrored for the other side, the "door" is treated as a separate object so I can manipulate its size and position depending on the map set up.

 

Animation

 

I've added the dying and shooting frames, but currently only have running and dying implemented, I'll be implementing shooting last, I plan on doing robots next which if I've got everything set up right, will just be an instance of the same class as the player but handled differently because of the AI. Does anyone got any specifics on the robot AI that I should know about? I know that they wait for a certain period of time (determined randomly and I assume by how aggressive they are) they then check if they are within the players range at which point they shoot, or move into the player's xy range.

 

Collision Detection

 

I have enabled collision checking, right now since I was forced to use selection mode in opengl anyway, I decided to reuse my function for the collision checks. I'm not sure how much slowdown this will cause just yet, but we'll see when I have everything implemented.

 

Right now collision detection works simply like this, if the player collides with anything, he dies, if the robots collide with anything they die, and if the bullets collide with anything they die, and collisions are currently checked whether the objects are moving or not, but not during every cycle, just .15 clocks per cycle. This is just a number derived from observation, not one that I calculated, so does that mean it is 15 fps? I just know what "looked right".

 

It uses a bounding box to do the check but the objects it checks can have pixel perfect precision depending on how I perform the check. To do this for the player vs bullets (for the missing neck feature), I'd have to make it so the bullet checks if he hits the player not the other way around, but this requires a more specific check and naming system and definitely requires me to have robots be instances of the player struct or I'd need to make even more special cases.

 

I'll post a screeny this weekend, but I'll probably have it finished by then (It's due Wednesday so this weekend is vital).

 

UPDATE:

 

Well good news for me, bad news for guys waiting for this to be finished by Wednesday. Apparently this isn't due till NEXT Wednesday, which is good because I might have time to get sounds in before the deadline.

 

I just got the random map loading up and working, plus I changed the default resolution to 640x480 and added fullscreen mode toggle with alt+enter.

 

Next up - The robot loading!!!

 

UPDATE:

 

Robots load, and have walking and scanning AI (no shooting though). Right now the robot is persistent with maploading but that will be fixed.

Edited October 7, 2008 by Ringman

[Ringman]

Update:

 

Ok I'm getting near the end of the road here. I need to get this finished before Sunday, because I got another project assigned for another class to work on so some things may be cut.

 

I'm gonna implement diagonal robot shooting last, because Im short on time and I'm not sure I'll get to it, albeit it'll probably be easy I just need to move on with the robots.

 

Random robot loading is implemented, and their actions and timing have been randomized. Pretty much the robots are finished in terms of AI except for increasing speed, color changes, and increasing lazer speed but once again that stuff will be done last if possible.

 

Bullet proof necktie will not likely be implemented, the code wouldn't be hard to change to make it possible (just use 2 bounding boxes instead of one) but I don't have time to bug test it.

 

Still need to implement player shooting, but that's much easier then robot shooting was.

 

Evil Otto is next up on the list, then scoring and lives (which are in place but need to be implemented).

 

Definitely won't have time for voice or sound support, but I will post the code here when I'm done fully commented for you guys to play around with.

[Ringman]

UPDATE:

 

Evil Otto has been added, and tested. His movement algorithm seems a tad buggy because his speed varies alot, but he works and is very threatening. Since I'm coming to a close on this and still need to add menus, Im not going to be implementing robot difficulty changes or sounds or the bullet proof necktie. I'm not sure if I'll even have time for a score/lives system, but hopefully I will, depends on how much I need to do tomorrow night.

 

The one thing I have to add is simple menu system, and I have to comment/organise, since that in itself will probably take a few hours and I don't get home tomorrow night till 7:00 I'll be pressed to finish this thing. Anyway, wish me luck. I'll post the code and exe when done.

[Ringman]

Here it is:

 

http://www.savefile.com/files/1840465

 

It's got some bugs:

Evil Otto's speed isn't uniform (something wrong with my vector calculation) but he still functions,

the robots' sprites seem to jump every now and then (I tried figuring out why but I couldn't, something to do with my glTranslate I suppose.)

also the lazer bolts always show the horizontal bar sprite, (I meant to change that, but forgot, lol, it'd be an easy fix).

 

Features missing:

Lives, Score, Difficulty adjustment, sounds, bullet proof necktie.

 

Right click for a "debug" menu that allows you to turn off robot shooting and evil Otto.

 

Sorry if my code is sloppy, I never touched C or OpenGl befor this semsester. I did comment everything though, if you have any questions feel free to ask. I doubt I'll do any updates on this, at least not till the semester's over.

 

Code layout:

 

main.c - has the main loop obviously, and all the game running functions, plus the opengl ones. Has robot generation, collision detection, user control handling, handles the instructions in the game loop, player and map loading.

 

entity.c - just has one function, the drawFrame function which is a for loop that reads off arrays of 1's and 0's and creates Vertices out of them to be drawn to the screen.

 

player.c - handles player spawning, movment, shooting, dying and animation.

 

robot.c - handles all the robot ai,shooting, movement, dying, and animation

 

map.c - has the map generation, and door generation functions.

 

lazer.c - handles lazer spawning, movment, and dying.

 

* sprites.h - has all the sprites in them, obviously. They all use 2 dimensional arrays of 1's and 0's, but the robot sprites also have arrays of pointers to these arrays so he can iterate through them easily.

 

source.h - just a crapload of includes and defines used by all of the classes.

 

the other h files are self explanatory, robot and player do not have a header of their own they share the entity header.

 

 

Anyway have fun playing around with the code, if you have any advice on how to improve some of my algorithms, let me know. Thanks. And if you use this as a base for anything, please give me credit.

[Kurt_Woloch]

OK, some feedback here...

 

1. OK, some things are missing, most obviously the sound, the scoring and life counter. I won't comment further on that...

2. The game seems to run rather slowly, at least on my PC. If all robots are still there and shooting, it does only 4-5 frames per second, though it does speed up when most of them have been killed. And I don't have a slow PC... I've got an Intel Quadcore 4x2.4 GHz one.

3. You didn't tell us that we need a recent version of CYGWIN1.DLL and GLUT32.DLL for it to run. This also isn't mentioned in the documentation. Speaking of documentation, there's no README file either. But such things (dependencies that are needed which don't come with the download) should be mentioned, in my opinion, so that the user doesn't get confused.

4. There's a probability that you start the game or a new room and immediately get shot by a robot. Maybe the robots should be prevented from shooting for the first 1-2 seconds you're in a room so that the player has a chance to get out of danger.

[Ringman]

Thanks!

I appreciate the feedback.

 

1.Speed

The speed thing is an issue that I was not aware of, as I haven't had any speed problems. I am new to using opengl and C so I still need to learn more about ways to save speed.

 

However, I believe the speed problem is the cause of the selection function used for collision detection. Selection mode in opengl is a very powerful tool for determining placement of objects, but continuously using it to check for collision may be what's causing the slowdown. The one thing that doesn't make sense, however, is that the time() function used is supposed to keep the speed relatively constant. So it shouldn't go from massive slowdown to massive speed up. But, I'm not very familiar with how time() works just yet, so my "misuse" of it could be the speed problem as well. Or both. I need someone smarter then me to help me solve this one.

 

EDIT: I found something that may shed some light on the speed issue: http://www.it.usyd.edu.au/~tapted/slow_glselect.html Depending on your graphics driver, it may be that gl_select mode isn't very compatible with newer graphics drivers.

 

2. Fairness

 

I know about the robot shooting, instantaneously issue. This would be an easy fix, I just forgot about it because I was running out of time to finish this for class. The way to fix this is to make another value like "canShoot" and have it called "noShoot" and use it for robot lazer disabling in the menu and use "canShoot" as initially false, and make a counter that counts down to zero at the beginning before it allows the robots to shoot, unless of course noShoot is active, at which point it won't count down. I look into it.

 

3.Documentation

 

Yep, you're absolutely right. Let's call it laziness. This was never meant to be released to the public initially so I didn't worry about it, there is plenty of comments in the code itself explaining alot of stuff. I also didn't know about the cygwin issue, which I have to make sure I tell my teacher that because he has had some compiling issues and this may be related. Thanks for pointing that out. I had eclipse auto compile this so I didn't need to worry about a make file.

 

5. Final

 

If anyone has a mac and would like to give this thing a look at, let me know. Converting the code for Mac shouldn't be a problem, though I won't be able to compile it in a mac environment but I can make the code so that it "should compile" on a mac and the person can compile it themselves.

 

Thanks, If I have time I'll try to address these issues, but we already got our next opengl assignment and it doesn't look like any improvements on this will be made in the near future. I currently work 14 hours a week, and have 3 comp sci courses a 200, 300 and 400 level course, plus a course in Photoshop that's easy but requires a lot of projects.

 

Thanks again.

Edited October 16, 2008 by Ringman

[Ringman]

Yeah the speed issue seems to be ATI driver related.

Edited October 16, 2008 by Ringman

[Hornpipe2]

glSelect matrix should generally be reserved (I think) for very special circumstances like mouse-picking - it saves the developer some headache when you have an arbitrary scene and need to know "what was in that tiny box the user just clicked on?" and you only call it once per mouse click.

 

For something like this, where you are checking every shot on every frame for a collision... I would suggest instead looping through each shot and doing a point-in-box test within your code. It should be much much faster and I would think easier to write too.

Edited October 17, 2008 by Hornpipe2

[Ringman]

Agreed. But, in the situation I had, the professor required that we use GL_SELECT in some way anyway, so I just used it for collision detection. The only issue with doing collision detection the old fashion way, is dealing with the map walls as well as the robots, every shot they make, the player his shot, and evil otto all testing on whether or not any one of them hit any other one. Call me lazy. Funny thing, is, apparently the idea behind using GL_SELECT for collision detection was such an ass backwards way of doing things, the teacher actually thinks I should write a paper on it, because its still considered "clever." So I guess I'll give it a try, but I didn't think it was all that unique of an idea, I figured the relationship between the two were quite obvious. Doing a paper for it and giving a little demo of it for my school's conference, is still good for a resume.