Targeting/Attacking - Survivors will automatically attack zombies once they get within the gun's target range. To do this, I have every survivor get the distance (using distance formula) to every zombie and find the closest one to attack. I check for this constantly

Targeting/Attacking - Survivors will automatically attack zombies once they get within the gun's target range. To do this, I have every survivor get the distance (using distance formula) to every zombie and find the closest one to attack. I check for this constantly so if a faster zombie gets closer, the survivor will change targets. For zombies, they acquire a target and stick to it (for now). The zombies constantly check if they are within the attack range (around 50 pixels) using the distance formula. If they are within range, stop and attack, otherwise, move towards the target.[/quote]
There are a few things that aren't quite correct, but I suppose this would work. Firstly, don't set hard pixel values like a 50px range - you want your game to be able to be played on any resolution whatsoever, and for this to happen you need the game logic to be r esolution-independent. This means you want to convert your coordinates to floating-point numbers between, say, 0 and 1, and say that the attack range of a zombie is for instance 0.05 (e.g. 5% of the screen width, for instance). This also helps for logic overall.

2D Camera - So a camera in a 2D environment moves the world around instead of you. My current method is have my zombies/survivors/any entities on the map stored in array lists. First the background is adjusted, then all the lists are cycled through and every entity's x and y values are modified. This seems to work alright but some stuff you can really notice sliding around on the background. Not really sure how to avoid this.[/quote]
I guess it depends how you look at it. You could imagine the 2D world scrolling under a viewport, or a camera scrolling over the world, both are equivalent (in fact, with no external reference point you can't tell which is which - relativity). I'm not sure this is the right way to approach it. You should keep track of the camera offset, and translate your entities' positions accordingly, but without modifying them permanently. You only keep a "translated copy" for rendering purposes. Unless I misunderstood.

User Interface - I really have no clue how to work with UI. What I've been doing so far is simply using a background and then generating button objects and manually lining them up. Then, I check if the mouse is over any of the button's areas and if there is a click while moused over the button. I have three different backgrounds and buttons that I switch out with booleans. I'm going to recode that area though, using objects with the background and buttons. Is this the correct way to do UI?[/quote]
GUI's are tricky to do in Java. Ultimately it boils down to this at the lowest level (detecting where the mouse is and providing visual feedback based on user cursory input), but you could certainly use a library to make your life much easier. Perhaps Slick2D has some sort of addon/plugin to make GUI management less of a pain (I don't know, I've never used it), so you wouldn't need to deal with all that stuff and just provide the locations of the different UI objects and attach events to them.

Path Finding - I have no path finding system yet. Do I have to stick to a grid system? I really rather my entities move freely along the terrain and not in a weird square to square motion.[/quote]
In general, the optimal shortest path to a destination doesn't look natural anyway as it's usually just a bunch of lines pieced together (connecting each node of the grid solution). However if you use a velocity-based approach for moving your entities, it will smooth out the movement of your zombies, making them move in a more realistic curvy way as they slowly change their direction instead of instantly snapping from one heading to another.

Selecting - I have it so you can select survivors, upgrade them, and other random stuff. My current method for selecting is constantly check where the mouse X and Y is. I get the distance from the mouse to every survivor and check if it is within 30 pixels. Then, I check if there is a click, if so, select the survivor and unselect all others. I'm still trying to figure out how to unselect all survivors if I click on open space. Is there a better way to go about doing this?[/quote]
You should probably check if there is a click before doing any position analysis, since nothing will happen anyway if the mouse isn't clicked (more efficient). This can't really be answered because it's unclear how you manage your survivor entities, but you could just make it that if no survivor is near the mouse when it is clicked (= open space), then you loop over all survivors and "unselect" them. But it depends on how "selection" is defined inside your game, it could be a flag in each survivor entity or it could be a "selection list" attached to the player (if that makes sense).

Picking stuff up - Same way as said before. I check the distance from the player to every item that can be picked up. If the item is within 30 pixels of the player, it picks it up. It seems to work fine for the moment I suppose. Maybe there really is no other way to do this.[/quote]
Well, yes, it seems logical to do it like this. There are more complicated and efficient ways to do this (which involve subdividing the world into a grid with smaller and smaller cells and quickly finding which object is the closest one to the player faster than just iterating through all of them) but if you only have a handful of objects on the screen at any given time the overhead is usually not worth it. What you are doing is good enough.

Animations - I understand the how to animate with sprites, but I just want to make sure. So if I have 7 different guns to be shot, do I need to manually make functions that have precise timing on each sprite. Say if I have a shotgun, it needs a recoil, pump forward, brief pause, pump back, and ready again. For a pistol I need just the recoil really. So I'd have to make unique functions for each of these animations?[/quote]
No, you certainly don't need to make multiple functions. You need to manage your animations so that they include:
- the number of frames in the animation
- each frame, as a texture (or whatever image system you have)
- optionally, the speed at which each frame should be displayed
Then you can easily handle different animations with only one function which will take the animation as a parameter and display it properly taking into account the details above. Does that make sense?

So I'm making a 2d Java game with the slick2d and MarteEngine libraries. This is the biggest project since I made checkers for my Java class. I am still pretty new to programming concepts and using optimal ways to get stuff done.[/quote]
Don't get obsessed over "optimal ways". Most of the time you'll get people saying "quicksort is faster than bubblesort", "octrees are faster than naive intersection", etc.. but the truth is, this is only correct in an asymptotic sense, e.g. it's only true if you have enough objects for the more efficient method to even make a difference (and in fact, the "faster" method may be slower if you have very little objects because of overhead of getting the efficient method into gear). Remember: if it's fast enough, don't optimize it (unless it's an easy and guaranteed optimization). And yes, as jbadams says, the best way is the way that works for you!