HopeDagger wrote:
Buying a good, solid, up-to-date book is where my recommendation goes. With most of the top results for "Java tutorials" on Google as a secondary backup.

And of course the Java APIs documentation.
Regarding the first point, it's very important to make sure you purchase a recently-printed Java book, because API changes and deprecation brought a lot of change between the < 1.1 and > 1.1 eras. I've got an ancient copy of Java Programming for Dummies, and a large portion of its contents is totally covered by new APIs in 1.4-1.5.
If you're familiar with Perl, than it should be a bit of an interesting 'jump' to Java, but still hopefully won't be that bad. As with all programming, sticking to it and practising often are the keys to getting good with it.

Good luck!
Yeah, I'm probably going to end up buying a book... but I might not. I learned perl using books, however the book only was really needed so I could get basic programming concepts off the ground... After that I learned stuff like the SDL module for perl and unrealscript on my own. Though It shouldn't be that big of a jump, I understand that Java was one of the major inspirations for UnrealScript, and from what I've seen of Java code here and there, it's pretty similar.
Sion wrote:
Here is an important lesson in using encapsulation. Suppose you just directly modified the damage variable to reflect the double-damage effect when picked up. When what if the level designer decides to place two double damage modifier powerups next to each other in a level?
Scenario:
- Player picks up double damage modifier.
Damage = Damage * 2 = 100 * 2 = 200.
- Player picks up double damage modifier.
Damage = Damage * 2 = 200 * 2 = 400.
- Double damage modifier wears off.
Damage = Damge * 0.5 = 400 * 0.5 = 200.
Not very desirable.
If the double damage powerup were instead created as DamageModifier-classes, then the player could have an array of damage modifier objects. When the player picks one up, an object is added to the array and when the getDamage() method is called, the comultative damage is calculated. When a DamageModifier class expires, it automatically removes itself from the list and things are back to normal. It's dynamic and it's flexible.
Ahh, that's where the right way to do it (as done in Unreal Tournament 1) comes in. There you can check if someone already has UDamage.
Here's the classes involved in UT2003/2004:
--Pawn (handles some of the timer stuff, the damage multiplication, and the overlay effect on the weapons)
--UDamageCharger (respawns/spawns the pickup)
--UDamagePickup (the item you pickup)
--UDamageInfo (handles the other part of the timer (this does the actually counting down and setting Pawn.bHasUDamage to false, Pawn just holds the variable that contains the time))
Whereas in UT it was a single class, UDamage. UDamage handled all of these functions. While separating out those classes might have made sense in the case of UDamageCharger and UDamagePickup, splitting UDamage between Pawn and UDamageInfo wasn't such a great idea. A better implementation would've removed the UDamageInfo and the double damage code from Pawn and created a UDamageInventory class, which would count down, modify the relevant DamageAtten values, and using the CheckPickup function (IIRC, that's the name of, UnrealWiki's google-based search is temporarily broken), to simply add to the timer whenever you pick up more UDamage, and also to do the purple glowy overlay effect over your weapons. Though you have a partially better idea, the Inventory abstract base class should have a function like (this is unrealscript (without any of that crazy network replication stuff the Unreal Engine uses for multiplayer games):
Code:
function float GetDamage(float Damage) {
// Do stuff to damage here in subclasses.
return NextInventory.GetDamage(Damage); // Every Pawn instance has an Inventory linked list like this
}
So therefore UDamage would do this:
Code:
function float GetDamage(float Damage) {
Damage *= 2;
return NextInventory.GetDamage(Damage); // Every Pawn instance has an Inventory linked list like this
}
The Unreal Engine seems to have been made by a brilliant guy (Tim Sweeney, I believe) with the help of an army of morons.