Starting my project (again)...
Author
Ok, this time, I'm REALLY going to work hard on my Turn-based RPG in Java. I started earlier, but it was VERY poorly coded, and largely procedural. I wasn't taking advantage of Java, so I got frustrated and just gave up. I'm starting a clean slate this time. I've only read the basics of C/C++ so I don't think that's enough to start this RPG game. This will be a small project I'll work on with my free time...
First, I'm doing this in a simple GUI interface, with JFrames, JLabels, and all that. Just a simple interface- I don't want to delve too deep in 3D yet, but I don't think a text-based game would interest anyone, including me much. My plan is to create a universal JFrame, and within it, three JPanels. One JPanel for the main display (maps, villages, battle screen), the second for the stats, and the third for the movement compass JButtons. It worked pretty well last time, so I think I'll take this route again. Whenever I switch to a battle, I'll just call a method to remake the main JPanel from the map to a battle screen. Is this a good plan or is there a more efficient way to do this?
Second, I really need to start using more OOP. I'm thinking to create a player object, and have all his stats as attributes. I previously called those attributes with "player.strength", but I saw that this method kind of defeated the purpose of OOP. Would I have to create a method to return the value for EACH stat? (We call them accessor methods at my high school) Also, is there an easy way to do this with enemy stats as well?
Third, I keep the player's stats in a ".dat" file. Whenever I launch the game, I call a method that reads from the file (with Scanner) and stores the values into the application. I was thinking I could do the opposite- taking the variables and overwriting it to the .dat file, to save the game. This makes sense, but I just feel this is a poor way to code this...
Note- I don't have much experience in programming yet. I've just finished my first year of Computer Science in high school, so I only know the basics. I don't want to learn something too advanced yet, because chances are I'll just be using examples, and NOT knowing what I'm actually coding. This is a project that I'm coding to show MY knowledge in programming, and it will grow as I learn more. Right now, it will be pretty basic before I add more stuff to it. I'm waiting for a few tips before I start coding this...
Quote:Original post by XG08Zero
Second, I really need to start using more OOP. I'm thinking to create a player object, and have all his stats as attributes. I previously called those attributes with "player.strength", but I saw that this method kind of defeated the purpose of OOP. Would I have to create a method to return the value for EACH stat? (We call them accessor methods at my high school) Also, is there an easy way to do this with enemy stats as well?
What's the difference between the player and an enemy? If they have the same attributes, you just create two instances of the object, naming one 'player' and one 'enemy'. If they are slightly different, create an object with the same attributes and inherit your player and enemy class from this super-class. That's what OOP is for.
Regarding the accessor-methods: yes, you should encapsulate those fields you like to access from outside of the object. If you are using an IDE (like Eclipse, Netbeans, or something similar) you can let those accessor-methods create automatically.
Quote:Original post by XG08Zero
Third, I keep the player's stats in a ".dat" file. Whenever I launch the game, I call a method that reads from the file (with Scanner) and stores the values into the application. I was thinking I could do the opposite- taking the variables and overwriting it to the .dat file, to save the game. This makes sense, but I just feel this is a poor way to code this...
Why should this be a poor way to code? Saving a game works like this... Maybe you should not overwrite the same .dat file everytime. Instead give the player the opportunity to have more than one save-game.
Good luck.
You really should read a book about Java to get you started thinking about object-oriented programming or you will be confused nevertheless (leaving aside issues of the merits and demerits of OOP since Java is object oriented). I recommend this one, which is also what I used to learn Java. The prose is engaging so you will not fall asleep reading it.
Acessor methods in Java - you should create them, but only for those that need to be exposed. A setHealth() method may be ok, but (a simplistic example) what about a takeDamage() method that modifies health in some way instead? The good news is that it's easy to create these getters and setters - in Eclipse, for instance, you can right click on a variable and select (source->generate getters and setters)
Acessor methods in Java - you should create them, but only for those that need to be exposed. A setHealth() method may be ok, but (a simplistic example) what about a takeDamage() method that modifies health in some way instead? The good news is that it's easy to create these getters and setters - in Eclipse, for instance, you can right click on a variable and select (source->generate getters and setters)
Author
Quote:Original post by Jockel
What's the difference between the player and an enemy? If they have the same attributes, you just create two instances of the object, naming one 'player' and one 'enemy'. If they are slightly different, create an object with the same attributes and inherit your player and enemy class from this super-class. That's what OOP is for.
Regarding the accessor-methods: yes, you should encapsulate those fields you like to access from outside of the object. If you are using an IDE (like Eclipse, Netbeans, or something similar) you can let those accessor-methods create automatically.
See- I NEVER thought of that! XD You are right. I still have alot to learn...
So when I need to start a battle, should I create the enemy object then? I was originally thinking that I would create a LARGE .dat file that would keep the stats of all kinds of monsters. I would then read from the file and create a monster based on that. So, what I'm saying is that I'm thinking of having a large .dat file, or many small ones, to store the monster's stats. Man, I have alot to learn...
Quote:Original post by Jockel
Why should this be a poor way to code? Saving a game works like this... Maybe you should not overwrite the same .dat file everytime. Instead give the player the opportunity to have more than one save-game.
Good luck.
Ok, that makes sense. I just felt it was poor because I was overwriting it, which could lead to problems. I'm excited about this now. Thanks a ton. I'll post back when I need more help! :D
As lighbringer mentioned it, maybe it would be best for you to get a book and go through the examples. Even though it might be pretty boring but it's just frustrating if you have an idea in mind and you cannot realize it because you wanted to skip the basic stuff.
So take a book, work through it and then things will be much clearer (and easier).
So take a book, work through it and then things will be much clearer (and easier).
Quote:Original post by XG08Zero
I don't want to delve too deep in 3D yet, but I don't think a text-based game would interest anyone, including me much.
Just as a quick side note - Theres a pretty large community of text based gamers out there, actually
A general principle of OOP: methods should *do something*.
// BadMonster x, y;y.hp -= x.strength;// Much worse!Monster x, y;y.setHp(y.getHp() - x.getStrength());// Don't write those functions. In the real world, they basically never end up// doing anything beyond "raw" access or mutation of the variable, unless you// specifically designed for it from the beginning.// Properclass Monster { // other stuff public void injure(Monster other) { other.takeDamage(strength); } public void takeDamage(int amount) { hp -= amount; }}Monster x, y;x.injure(y);
Author
Ok, I know that the first example is bad- bc that's what I did before...
I was planning to code my game like the second example. I never knew that was a bad way. Now that I think about it, I understand why. So THIS is OOP. My teachers taught me to code like the second example, and said that was the majority of OOP. Now that I think about it, it kind of is the same thing as the first example, just one more step. I understand this now. So the player/monster object should have it's OWN functions for calculating damage and such. I only used the object's attributes, and used global functions. I understand this now. Thanks a ton!
I was planning to code my game like the second example. I never knew that was a bad way. Now that I think about it, I understand why. So THIS is OOP. My teachers taught me to code like the second example, and said that was the majority of OOP. Now that I think about it, it kind of is the same thing as the first example, just one more step. I understand this now. So the player/monster object should have it's OWN functions for calculating damage and such. I only used the object's attributes, and used global functions. I understand this now. Thanks a ton!
Though the second example *is* appropriate - in some cases. Such as a physics engine might need to let you change about the friction of an object. The advantage of the second example over the first is that if the object needs to change something when a value is changed, it can. So, when the friction is changed, the object may also need to recalculate a couple other values based off of that.
The trick is to pick what is appropriate to use and when.
The trick is to pick what is appropriate to use and when.
Yeah, I agree with most of what has been said. You DEFINATELY want to do the monster.injure method, and definately want to have the player and the monster be made or inherited from the same class. Make sure you do everything very professionally, if you catch yourself starting to say "bah, I don't want to have to do all of that! I'll just stick this code in the main method here..." Stop yourself right away, and remind youself of what happened last time.. You don't want to scrap this and start over agian, do you?
I'm currently making an RTS in java, lots of the same concepts apply. Its easy to do surprisingly complicated things with your objects once you've set up a good class system to make things less complicated. If you have x.injure(y), you don't even have to think about it, you just know it will work, since you thought about how it will work once, and wrote the injure function.
I suppose I'll give one tiny example. I made a unit class, with soldiers, clerics, archers, workers derived from it. I had a move function for each unit - call it once, and on each update of the unit, it would automatically move towards the destination. Because I had such a nice function & it was very easy to use, I was able to move battalions of soldiers at a time, all into a formation, without much difficulty. This would have been impossible for me without OOP.
Good luck with your project, don't get discouraged, and definately don't fall into sloppy coding habits!
Good luck,
Adam
[Edited by - Adams555 on July 4, 2006 8:51:58 PM]
I'm currently making an RTS in java, lots of the same concepts apply. Its easy to do surprisingly complicated things with your objects once you've set up a good class system to make things less complicated. If you have x.injure(y), you don't even have to think about it, you just know it will work, since you thought about how it will work once, and wrote the injure function.
I suppose I'll give one tiny example. I made a unit class, with soldiers, clerics, archers, workers derived from it. I had a move function for each unit - call it once, and on each update of the unit, it would automatically move towards the destination. Because I had such a nice function & it was very easy to use, I was able to move battalions of soldiers at a time, all into a formation, without much difficulty. This would have been impossible for me without OOP.
Good luck with your project, don't get discouraged, and definately don't fall into sloppy coding habits!
Good luck,
Adam
[Edited by - Adams555 on July 4, 2006 8:51:58 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
