Java questions which don't deserve their own thread, yet.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.

fret logic: Mar 8, 2005; roffle

Hmm I was thinking about that program in the shower from what you posted in the other thread, and it looks a bit different from what I thought it would be. When I was thinking of the addition, I was implementing reducing to the lowest terms. This looks like it just multiplies the denominators and leaves it like that.

Just curious though, would a feature to keep people from entering fractions that would become complex use the modulus operator?

# ¿ Feb 26, 2008 06:58

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 22:47

fret logic: Mar 8, 2005; roffle

MEAT TREAT posted:

It says in the instructions that in the next project they will reduce the fraction to it's lowest terms. For now it's enough that they just keep multiplying the denominator.

Yeah, I was jus' sayin.

# ¿ Feb 26, 2008 08:55

fret logic: Mar 8, 2005; roffle

This is kind of an odd question because it's about my approach and not a bug in the code. I'm trying to do different projects to learn Java and C, and one of my Java projects was to build a very simple fighting RPG from the ground up as I learn. So tonight I was messing around with getting it to let the player choose which class to play and then shows them the stats when they pick.

My question is, how terrible did I go about this? I don't want to get in the habit of a bad approach to different problems.

code:

public class Player 
{
	private int hitpoints;
	private int strength;
	private int defense;
	private String playerclass;
	
	public Player(int choice)
	{
		switch (choice)
		{
		case 1: playerclass = "Fighter";
				strength = 20;
				defense = 18;
				hitpoints = 50;
				break;
		case 2: playerclass = "Archer";
				strength = 15;
				defense = 22;
				hitpoints = 30;
				break; 
		}
	}
	
	
	public void updateStats()
	{
		System.out.println("Player class: " + playerclass);
		System.out.println("Strength: " + strength);
		System.out.println("Defense: " + defense);
		System.out.println("Hitpoints: " + hitpoints);
	}
	
}

code:

import java.util.*;
public class GameLoop
{
	
	Scanner getinput;
	static Player newplayer;
	static GameLoop game;
	
	public static void main(String[] args)
	{
		game = new GameLoop();
		newplayer = new Player(game.choosePlayer());
		newplayer.updateStats();
	}
	
	public int choosePlayer()
	{
		
		int choose; 
		choose = 3; 
		
		getinput = new Scanner(System.in);
		
		while ((choose != 1) && (choose != 2)) {
			System.out.println("Choose a player class: ");
			System.out.println("1. Fighter");
			System.out.println("2. Archer");
			choose = getinput.nextInt();
			
			if ((choose != 1) && (choose != 2)) {
				System.out.println("That's not a correct choice");
			}
		}
		return choose;
		
		
	}
	
}

So how lovely is my approach to this simple program? Too complex? Improper use of O-O?

# ¿ Mar 11, 2008 03:22

fret logic: Mar 8, 2005; roffle

MEAT TREAT posted:

Well your approach isn't very OO yet. I'll try to critique your Player class first.

You are limiting yourself by defining the 2 playerclasses. A much more robust constructor would be this.
code:
public Player (int hitpoints, int strength, int defense, String playerclass){
    this.hitpoints = hitpoints;
    this.strength= strength
    this.defense, = defense, ;
    this.playerclass = playerclass;
}
Now in your main program you can create as many different characters classes as you wish or even variations of the same class. Imagine a Fighter with less hit points and higher defense. You could even allow the user to create their own class by giving them lets say 100 points to distribute between Strength, Defense, and HP. You can still use your approach and have some predefined classes that they can choose from. The choice is up to you but this constructor allows more flexibility later on.

Your method updateStats should be changed to override the toString method since you are not actually updating any of the stats.

I think the only method that is missing from the Player class is a combat method where he can do damage to another Player.

I'll let someone else comment on your GameLoop class because I have to run.

Thanks for the advice, the bit about making a more robust Player object is very helpful. I spent a long time thinking about how to set that up and this clears it up for me

This short program was a quick attempt at displaying some information based on user selection using a setup kind of like I would if I was making the actual game. I will be making the game at some point as a larger project, but at the moment I'm just making random pieces to have something to do.

# ¿ Mar 11, 2008 04:11

fret logic: Mar 8, 2005; roffle

MEAT TREAT posted:

There is Bruce Eckel's Thinking in Java which is available online for free. I've been reading his C++ book and I like it very much. I can't think of any Java tutorials, but frankly you should stay away from them. Tutorials rarely cover any subject in depth so there usefulness is limited.

That's the book I use and I'm really pleased with it for being free of charge and all.

# ¿ Mar 11, 2008 19:03

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 22:47

fret logic: Mar 8, 2005; roffle

ynef posted:

Depending on your game and what it will support in the future, I'd say that Player should be an abstract class and that you should subclass it with a Fighter and an Archer class. The reason (which may not be valid in your case) is that, for instance, you'll want to give all archers a bonus for ranged weapons or restrict so that fighters can't used crossbows (whatever). If you stick to using conditional statements (if, switch) then you will quickly get a headache trying to code all these rules that will be easily avoided if you just go with the subclassing. Also, the constructor for each class will be very simple and you can still keep the toString() method (which you should use) in the abstract Player class. Adding more types of Player will be ridiculously easy too.

If you go that route, keep in mind that you need to change all attributes in Player to "protected" for subclasses to access them.

That does make sense but I'm a little ashamed to say I had to look up how to create a subclass, since I haven't learned it yet. Thanks for the help!

# ¿ Mar 11, 2008 20:14

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.