2D Zombie Shooter - New Pandora Game Announcement


emil10001

Active Member
Joined
May 19, 2008
Messages
669
Reign of Brains is a simple 2D Zombie shooter. It's style is similar to the TMNT arcade games. Thus far, there is one complete level, where the player can enter various doors to collect items. Items help the player survive the level and include sandwiches, health packs and ammunition.

This game currently runs on Windows, Mac and Linux. But, the target platform for is the Pandora. Once the device ships, I plan on spending some time optimizing the code to run really smoothly on this platform. Then, once it's up and running, I plan on making more levels for it.

This is my first attempt at game development. I wrote most of the code myself. I also did all of the character graphics/animations myself. I had some help with the music and some of the backgrounds, but those too are 100% original.

If any of you are inclined, please feel free to download it and try it out for yourselves. I would appreciate any feedback.

zombie.png
 

Attachments

  • zombie.png
    zombie.png
    120.1 KB · Views: 148
emil10001 said:
Reign of Brains is a simple 2D Zombie shooter. It's style is similar to the TMNT arcade games. Thus far, there is one complete level, where the player can enter various doors to collect items. Items help the player survive the level and include sandwiches, health packs and ammunition.

This game currently runs on Windows, Mac and Linux. But, the target platform for is the Pandora. Once the device ships, I plan on spending some time optimizing the code to run really smoothly on this platform. Then, once it's up and running, I plan on making more levels for it.

This is my first attempt at game development. I wrote most of the code myself. I also did all of the character graphics/animations myself. I had some help with the music and some of the backgrounds, but those too are 100% original.

If any of you are inclined, please feel free to download it and try it out for yourselves. I would appreciate any feedback.

zombie.png

Awesome. I saw this on Reddit and thought that it would be perfect for Pandora. Can't wait to try your work.
 

Attachments

  • zombie.png
    zombie.png
    120.1 KB · Views: 146
Last edited by a moderator:
Alerino said:
keep up the good work, dude... put it in the appstore.

As soon as it's running on the pandora I'll put it in the appstore. I also plan on wrapping it in a pnd archive.
 
Last edited by a moderator:
emil10001 said:
Alerino said:
keep up the good work, dude... put it in the appstore.

As soon as it's running on the pandora I'll put it in the appstore. I also plan on wrapping it in a pnd archive.

Do you mean after a compatible java is ported? Or are you planning to port to another base like QT or GTK or something?

I do hope java does come to pandora.

Edit: Sorry reread post and I guess 'As soon as its running onthe Pandora.' would have answered my question.
 
Last edited by a moderator:
dsleaf67 said:
emil10001 said:
Alerino said:
keep up the good work, dude... put it in the appstore.

As soon as it's running on the pandora I'll put it in the appstore. I also plan on wrapping it in a pnd archive.

Do you mean after a compatible java is ported? Or are you planning to port to another base like QT or GTK or something?

I do hope java does come to pandora.

Edit: Sorry reread post and I guess 'As soon as its running onthe Pandora.' would have answered my question.

lwjgl is the library that needs to be ported. Also, currently gamepad support under linux is spotty, so that might need to be fixed as well (because of lwjgl).
 
Last edited by a moderator:
Mithrildor said:
You walk really slow :(

The ribbon moves slowly, but there is a 'run' button.

I *might* be able to speed up the ribbon, but it was a lot of effort to make sure that the doors move at the same rate as the background. Which is pretty important.
 
Last edited by a moderator:
I'm sorry, but I think the game still needs a lot of polishing.

First off, the mouse. It's impossible to tell in advance when the game will register a click and when it won't. This makes the game artificially difficult since you can click a zombie five times without firing a single shot - and it creates an image of poor workmanship. The game can be as hard as it wants but unresponsive controls are a big no-no.
The flaky mouse support is especially problematic since a single zombie can drain 100% off your health in about two or three seconds so when you enter the hospital you either have about thirty health packs left or you die within the five seconds it takes the game to register you want to attack the zombies currently eating you. Again, tough spots are okay but they should be tough due to the level design, not due to technical issues.

Secondly, the loading times. This kind of game shouldn't have any, yet there are noticeable freezes when leaving a house.

Thirdly, the music. Yes, it does remind one of the old home computers of yore but it is a bit too monotonous and loops too quickly. A longer tune or a randomly played selection of tunes might benefit the game. Also, you should try to include more than one sound effect for zombie moans; hearing the same sound effect over and over is bad for immersion.

Fourthly, you should at least explain what the icons at the top are. What's that oil barrel for? And that yellow toast-like thing? Is there even a way to use them in the game?

Oh, and also the screen should scroll earlier (that is, the protagonist should be closer towards the center of the screen when it scrolls). The way it is now, you need to constantly aim near the window border in order to hit zombies before they can attack you, which can lead to the player occasionally clicking outside the window by accident.


All testing was done on OS X.
 
j6cubic said:
I'm sorry, but I think the game still needs a lot of polishing.

First off, the mouse. It's impossible to tell in advance when the game will register a click and when it won't. This makes the game artificially difficult since you can click a zombie five times without firing a single shot - and it creates an image of poor workmanship. The game can be as hard as it wants but unresponsive controls are a big no-no.
The flaky mouse support is especially problematic since a single zombie can drain 100% off your health in about two or three seconds so when you enter the hospital you either have about thirty health packs left or you die within the five seconds it takes the game to register you want to attack the zombies currently eating you. Again, tough spots are okay but they should be tough due to the level design, not due to technical issues.

Secondly, the loading times. This kind of game shouldn't have any, yet there are noticeable freezes when leaving a house.

Thirdly, the music. Yes, it does remind one of the old home computers of yore but it is a bit too monotonous and loops too quickly. A longer tune or a randomly played selection of tunes might benefit the game. Also, you should try to include more than one sound effect for zombie moans; hearing the same sound effect over and over is bad for immersion.

Fourthly, you should at least explain what the icons at the top are. What's that oil barrel for? And that yellow toast-like thing? Is there even a way to use them in the game?

Oh, and also the screen should scroll earlier (that is, the protagonist should be closer towards the center of the screen when it scrolls). The way it is now, you need to constantly aim near the window border in order to hit zombies before they can attack you, which can lead to the player occasionally clicking outside the window by accident.


All testing was done on OS X.

Thank you for the feedback, it is very helpful. Those are a lot of good points.

First off, the input support. The biggest reason that I can point to as to why this behaves the way that it does is that I had done a re-write of the game with a focus on using a gamepad as input. When I did that, whenever you fired it would spray a stream of bullets or would constantly be using the axe. So, i added a delay. I agree it's not the best way to do it, and this is something that I will try to fix for the pandora version. (Should be easier to deal with on the pandora since there will only be one input method.)

Load times are a bit more difficult. It has to do with how everything is drawn, spawning enimies and memory management. To accomplish a long ribbon background, I wrote a tile manager, a few brick sprites and a text file to describe the level. Since I don't want all that stuff in memory whenever you leave the main street, I nulled out that area, and rebuilt it when you go back to the street. The indoor areas are all single background images, so the load times are a lot shorter. Graphics is not really my area, and since I don't really have any help on this project, for now, I am not going to make any promises of improvement here. We'll see what happens. The biggest issue here is that the text file is how I know where to put the doors. If it's just a flat image, I'd have to figure that out by hand. I am hoping that some optimization will cut down on load times.

Music is something that I want to update. However, longer songs mean larger files, which mean more memory usage. I am loading wav files right now, the main wav that is being used is 13MB. I *might* be able to rewrite this to use midi's, and maybe get my brother to re-do the music. I totally agree about the zombie moans, after a month and a half of testing, I drove my fiancee a bit nuts with the audio.

As for the other items, well, there are several features that I wrote into the game, but which aren't used in the first level. There are some things that I am pretty excited about adding to future levels, such as a radio and survivors. The oil barrel thing is a battery (yes, I know it looks terrible, and I'm going to re-draw it). The 'toast' thing is a sandwich. I also have code written to have survivors that will appear in different levels for you to rescue. The radio will be for giving the player goals and hints, if he has enough batteries. I'd like to add some menu options to the start screen to bring you to screens that would explain this better, but that requires more time and effort than I have right now, and is a bit lower on the priority list.

The screen-scrolling issue is something that I was thinking about the other day. Yes, it's something that I want to fix, but it would require re-writing certain things and possibly breaking some stuff. So, that will be something to do for when I move it over to the Pandora.

Finally, there is a general storyline that I have in mind for this game, and a couple more features to be added. I also plan on drawing two more types of zombies, and a survivor or two. The starting point will be changed a lot, as that has to do with a critical plot-point.

Again, thank you for your critisisms. I really want to be able to deliver a nice, fun, enjoyable game for the pandora, so I will do my best to fix all of these issues.
 
Last edited by a moderator:
emil10001 said:
First off, the input support. The biggest reason that I can point to as to why this behaves the way that it does is that I had done a re-write of the game with a focus on using a gamepad as input. When I did that, whenever you fired it would spray a stream of bullets or would constantly be using the axe. So, i added a delay. I agree it's not the best way to do it, and this is something that I will try to fix for the pandora version. (Should be easier to deal with on the pandora since there will only be one input method.)
Hmm. If you can somehow distinguish mouse clicks from button presses, that would be the obvious way to do it. Otherwise you could put the delay in the shooting code instead of the interface (that is, the game would immediately trigger a shooting event but the event would simply do nothing if too little time has elapsed since the last shot).

Load times are a bit more difficult. It has to do with how everything is drawn, spawning enimies and memory management. To accomplish a long ribbon background, I wrote a tile manager, a few brick sprites and a text file to describe the level. Since I don't want all that stuff in memory whenever you leave the main street, I nulled out that area, and rebuilt it when you go back to the street. The indoor areas are all single background images, so the load times are a lot shorter. Graphics is not really my area, and since I don't really have any help on this project, for now, I am not going to make any promises of improvement here. We'll see what happens. The biggest issue here is that the text file is how I know where to put the doors. If it's just a flat image, I'd have to figure that out by hand. I am hoping that some optimization will cut down on load times.
Hmm. Depending on what takes the most time you could perhaps work with an indermediate format. So if parsing the text file into the level layout takes the most time you could parse the text file when first loading the level and then keep the layout (sans tiles) in memory. Of course that only helps if the parsing is the slow part.

Music is something that I want to update. However, longer songs mean larger files, which mean more memory usage. I am loading wav files right now, the main wav that is being used is 13MB. I *might* be able to rewrite this to use midi's, and maybe get my brother to re-do the music. I totally agree about the zombie moans, after a month and a half of testing, I drove my fiancee a bit nuts with the audio.
Have you thought about Vorbis (more commonly called "Ogg", even though that's just the container)? It's used by many games, gives a better compression than MP3 and there's a BSD-licensed reference library called libvorbis you can use with your game (might also require libogg). Both libraries should also be available in every decent package manager.

I'm not going to answer to the rest of your post because, well, I don't have anything useful to add there. Go do your thing.
 
Last edited by a moderator:
j6cubic said:
Hmm. If you can somehow distinguish mouse clicks from button presses, that would be the obvious way to do it. Otherwise you could put the delay in the shooting code instead of the interface (that is, the game would immediately trigger a shooting event but the event would simply do nothing if too little time has elapsed since the last shot).

I've already taken care of the mouse-click issue. I need to test it on the gamepad to see if it's better there too. :D

Hmm. Depending on what takes the most time you could perhaps work with an indermediate format. So if parsing the text file into the level layout takes the most time you could parse the text file when first loading the level and then keep the layout (sans tiles) in memory. Of course that only helps if the parsing is the slow part.

I've already looked into this and figured out that the load time probably has more to do with generating the zombies than it does with generating the background image. But, this is something that would require a fair amount of re-writing and testing, so I'm going to put it off for a bit. Regardless, I should have it fixed for the pandora version.

Have you thought about Vorbis (more commonly called "Ogg", even though that's just the container)? It's used by many games, gives a better compression than MP3 and there's a BSD-licensed reference library called libvorbis you can use with your game (might also require libogg). Both libraries should also be available in every decent package manager.

Eh, we'll see about the sound. If I get everything else taken care of, I might come back to this. I would really rather cut it out altogether and maybe encourage the player to have their own music going in the background. The other thing is that I'd like to keep the number of dependencies down to as small a number as possible. External libs makes it harder to build, run and test, especially if I want to release future versions on other platforms besides the pandora. I will keep vorbis in mind if I get fed up with dealing with wavs.
 
Last edited by a moderator:
emil10001 said:
So, i added a delay. I agree it's not the best way to do it, and this is something that I will try to fix for the pandora version. (Should be easier to deal with on the pandora since there will only be one input method.)

Your delay should be when firing - not when detecting the input.

Mouse1 pressed -> RequestShoot

Gameloop -> ShootCooldownOkay && RequestShoot -> Shoot

That way if someone clicks, it fires once at the next possible opportunity, even if they couldn't fire at that moment.


emil10001 said:
Load times are a bit more difficult. It has to do with how everything is drawn, spawning enimies and memory management. To accomplish a long ribbon background, I wrote a tile manager, a few brick sprites and a text file to describe the level. Since I don't want all that stuff in memory whenever you leave the main street, I nulled out that area, and rebuilt it when you go back to the street.

It's fairly easy to do level streaming speedily with binary formats.

But that's a bit beyond the scope of this post.

My suggestion: Load everything into memory. You've got a guaranteed 100MB on the Pandora. Use it, if it enhances the player's experience, and optimize later. ;)


emil10001 said:
Music is something that I want to update. However, longer songs mean larger files, which mean more memory usage. I am loading wav files right now, the main wav that is being used is 13MB. I *might* be able to rewrite this to use midi's, and maybe get my brother to re-do the music. I totally agree about the zombie moans, after a month and a half of testing, I drove my fiancee a bit nuts with the audio.

Look into ogg and mp3. If you need your sounds converted to either, I'll do it for you. You just have to figure out how to play them.

emil10001 said:
I've already taken care of the mouse-click issue. I need to test it on the gamepad to see if it's better there too. :D
Good to hear. :D
 
Last edited by a moderator:
New version posted. Much faster load times between areas. (I took Krammy's advice on loading almost everything at the beginning, helped a lot.) Much better mouse response. Lower RAM usage. Touched up the ribbon movement, it moves earlier, but when you reach the end, you can walk all the way to the side.

There are still some issues, like the sound and probably the gamepad isn't 100% yet. But, as I said, I plan on working those issues out for the pandora release. I also plan on trying to do a fair amount of optimization to make it run well on the pandora.

http://sites.google.com/site/reignofbrains
 
Not entirely related, but this weekend was the Reddit GameJam, and I participated. Wrote a game from scratch over the weekend, source provided. Please vote me up:
http://www.reddit.com/r/RedditGameJam/comments/c493l/first_reddit_game_jam_has_started_theme_space/c0q4hyg

This game will probably work on the Pandora. (Even though it's crappy and rushed.)
 
Back
Top