I openend a new “Showcase” - Thread for the game here:
oh yeah dont forget to try implement custom engine for random number generation.
You mean instead of using the java-pseudorandom number generator I should use a true random number generator?
I already changed the “dice”-code from
die = (int) (sidesOfDie*Math.random() + 1);
to use the java.util.Random API instead yesterday, if you meant that :).
P.S.: I would really appreciate if any suggestions regarding the game would be made in the other thread but I would still like to keep this thread for asking general questions :).
java.util.Random is lrand48 which as modern PRNG’s go is pretty crummy, but it’s way more than enough for rolling dice in a game like this. Do not use anything but a PRNG (you may want to save a seed at some time), and do not write your own PRNG (they are devilishly hard to get right). Write the game first before you start bikeshedding details like this.
Yes I also don’t see why I should write a custom engine for a simple game like that 
I have two new questions:
I still don’t understand Objects 100%. For example what if I have my “player object” and the “enemy object” and want them to communicate. The way I do it now only the “enemy object” can get information about the “player” via Getters and Setters (but not vice versa). I created them in the main game file like this:
private Player player;
private Mob mob;
public Main()
{
player = new Player();
mob = new Mob(player);
}
Is there a way I can get them to share information??
and No. 2:
When i have an class e.g. one that handles the player’s input is it also good to make an instance in the main class or is it also okay to just create it in the class you really need it (since all the other objects don’t need to see it) instead of passing it into a constructor.
Greetings, EatenByAGrue
Two objects communicate with each other by one having a reference to the other. Let’s move away from Player and Enemy, which is actually kind of a complicated situation, and on to objects more directly related. Let’s go with the worn out car analogy, because hey, I can’t be original. This is java-flavored pseudocode below, I’m leaving out the definition of getters/setters.
class Car {
Engine engine;
public void stepOnTheGas() {
Engine.rev(5000);
}
}
class Engine {
DriveTrain drive;
void rev(int rpms) {
int force = reallyComplexEquationOfTorqueAndWhatever(rpms);
drive.applyForce(force);
}
}
class DriveTrain {
// We're leaving out all that complex transmission and differential stuff
List<Wheel> wheels;
void applyForce(force) {
for (Wheel w: wheels) { w.spin(force / wheels.size()) }
}
}
Aside from being the world’s worst mechanical simulation, what this demonstrates is how you build a system out of references from one part of it to another. Notice how the Car doesn’t even know about its wheels. It talks to the engine, the engine talks to the drivetrain, then the drivetrain spins the wheels. If you decided to break up the drivetrain later into a transmission and a differential, Car and Engine don’t have to know about it – it’s not Car’s responsibility to know.
Bureaucracy is the name of the game when it comes to good Object Oriented Design: every object has a job description that outlines its responsibilities, and those objects only ever talk to their immediate peers. Car never talks to Drivetrain without going through Engine. The technical name for this in software engineering is the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter). The wikipedia page on the subject goes off on a lot of tangents, but the three bullet points at the top are worth taking to heart.
Now, how does this relate to getting mobs and players to interact with each other? Simple: they don’t. What you need is at least one middleman, a GameState of sorts, that knows about both, and is able to hook them up. Chances are there will be all sorts of rules involved, like whether the player is aware of the mob being there (e.g. can they see it?) so that access will involve some more interesting methods than a mere getter and setter. I’ll see if I can dig up some of the interesting MUD designs I had from years back and share some with you.
What information are you wanting to share between the player and enemy?
In doing the battle, I would recommend that the player will call the enemy.attack(). And the enemy can call player.attack(). These methods would take what information they need to know when being attack. (The attack roll; How many points of damage) and then respond with a “I’m still alive” or “I’m dead, you killed me”.
To get the player and the enemy together, like suggeted, the GameState (or maybe the BattleGround object), will get the enemy and call player.setOpponent(enemy) and enemy.setOpponent(player), to get the two to interact with each other.
Is that what you were thinking?
I guess Player and Enemy was a bad example … I just picked them because I was in a hurry yesterday. But your posts made it pretty clear to me in general.
I ran into this problem while creating Items (like Armor, Potion, etc.) but solved that now by creating a “middleman” who can get information from both the player and the item class via accessors - why I didn’t find that solution myself earlier… I don’t know :clue: Sorry for that !
Considering my second question maybe a good example is my UserInput class which I use to get (who could’ve guessed it) all the user’s input throughout the game and return it as a value (int or String). Besides that it doesn’t have any fields nor accessor methods to communicate with other objects. What I want to know is, if it’s still reasonable to create only one instance of that object at a higher level (e.g. in the main class similar to how I do it now with my player class) and pass it into the constructors of those classes who use it OR would it also be okay to create it in each class seperatly because (the way I see it) for those objects it isn’t important to have access to one specific object … I hope you understand what I mean - it’s really hard for me to explain it in english (so please forgive me if I use the wrong expressions occasionally :/).
There’s certainly nothing wrong with singleton classes that are passed on to other objects. A true singleton doesn’t actually need to be passed though – if you follow the classic singleton pattern , you can get at it via UserInput.getInstance().
If your objects have fancier wiring needs, where you have a whole web of classes that need references to each other, you can use a DI container like Spring or Guice, but that tends to be seen as overkill for most games (and for Spring at least, I’d certainly agree).