So for fun, and .learning purposes I want to code a Text-based-java-rpg. I believe I have a strong enough knowledge of ting the java language to do this. My main problems areas are as followed
-Keeping my code neat, tiddy, understandable, maintainable, and in a logicical order.
for example id have a package called currency, that contains the currency.java which would contain all the infoirmation to convert and sort the gold the character has. Then I'd have a currencyDisplayer.java which would format the currency so something the player could easily understand. But would it go under the currency package or the display package?
- I also have problems nameing packages, classes, and data files to something relevant to the given situation.
- I have a terrible habbit of not commenting my which when i look back at it, it confuses the heck out of me.
- I am also terriable with pre planning a class, data file, package, interface ect.
- I sometimes dont know when to use an interface, or a constructor or why to use them.
- I have massively hard times understand multi-demnstion arrays.
Some of the the things I would like my game to have are very simple. Such as:
* and inventory system
* a turn based combat system
* a town/zone map type system
* a shoppe
* a inn
* save-states that hold most if not all character data via .sav files .
* configuration for the game via .PROPERTIES files
* quests which can be taken in and out, so they dont have to be hard coded in, maybe with regular .txt files or .dat files.
I know I can Do this, i just need some advice on where to start. Any help the ranch can give would be greatly apperciated!
Don't do everything from the start. Make a list of priorities, and make a completely working program every time you add a new feature to it.
For instance, you can start with: "I want to make a program that displays areas in a text user interface". Then you can start planning what you need in order to that. Your first complete program can display walls and doors and maybe other inanimate objects like trees. I suggest a top level package containing something like Area.java and a view.text package containing AreaView.java.
Then you can expand: "I want to make a program that displays creatures moving around in areas using a text user interface". Again, this is a clear goal for which you can write a fully functional program.
You see that a class that deals with currency is still very far away. You're already planning too far ahead. Add it when you need it.
Note that with each new version of your program, you should only consider it as finished if you've also documented all the code. Don't do everything at the very end.
Here's a snippet of code to help you on your way. Edit it as you see fit.
Here you see that Area encapsulates a 2-dimensional array of terrain types. Technically Java doesn't have multidimensional arrays, but for sake of clarity let's just call it that way. The different terrain types all have a character representation, that can help you with displaying the area later on, but they are still different terrain types, so you can later add different properties to them, if you need to.
This code demonstrates a very important concept that is essential to good programming: Defensive copying. The constructor takes an array, and stores a copy of it, so this array has no references to it outside of the Area object. Other classes can not edit it, so the Area is safe from unexpected problems.
Another important thing is argument checking. The constructor checks that the array is rectangular. Every column of the array must have the same height. Again, this prevents unexpected behavior later down the road. The getTerrainAt() method checks that the indices are not out of bounds. Normally it's good to let a method throw an exception if input is not valid, but in this case it might be easiest for the client to receive "empty" terrain instead.
You can learn a LOT about writing clean and readable code from JavaRanch's "CattleDrive" course. I recommend it. I've completed the first two sections (have two moose badges) and am working on the third.
Stephan has a lot of good advice, all of which I agree with.