iceburg333 wrote:ShipSave extends SavedGameState
Oh, I've missed that bit. It's totally fine then.
iceburg333 wrote:Also, things like the ship's image, button reference, etc, you're saying that it'd be better to move that within the save file, but I think that the only time it's read is when we're refreshing the panel (and we want stuff to be re-read to make sure we're accurate). Am I making sense/ missing something?
Thing is, once you read the information, you have to store the data somewhere. What better place to do this than a class to which this data is directly related to?
I perused the code; the imageCache is good as it is, but the JButton[] could be changed to be a field of the ShipSave class:
Code: Select all
public class ShipSave extends SavedGameState {
public File shipFilePath;
public JButton boardButton;
public String imageInnerPath; // to retrieve the image from imageCache
...
And this entire loop in SpaceDockUI.init():
Code: Select all
for (int i = 0; i < myShips.length; i++) {
...
Could instead be converted into ShipSave's constructor, so that each time you create a new instance of ShipSave, the button, label, and other related UI elements are also created.
It
is nitpicky, because the code will work either way; however, thinking of code in an object-oriented way makes it much easier to organise, scale, work with and be understood by others.
Not sure if you've stumbled upon any OOP related resources or articles, but a good mental exercise is to break down a car into components:
On the highest level of abstraction, you have the Car class - what can you tell about a car when you first look at it? Color, brand, model, its plate number... But you can't really tell much about its other components without having a closer look. So, you come closer and examine the Engine - and take note of its own, specific properties (its own brand, model, type, efficiency, number of cylinders...), you look at the Tire(s) (brand, rubber, adhesion)...
Then you back away again, look at the car and remember that all those components are just parts that the Car references and makes use of.
Of course, you could store all of this information (or parts of it, depending on what you need for the project) in the Car class, but you'd end up with a lot of variables, arrays, maps, methods, and it'd all be a big mess to work with and keep track of. And then say you want to describe a three-wheeled car...
It's just a change in the mindset, but once you "get it", the code starts to organise itself in an eerily intuitive way, without you ever paying attention to it.
Also:
Arrays are good for some super-simple, one-time local stuff, or array-specific stuff, but they are clumsy to use. For storing references to objects that are used across the entire application, an ArrayList<ShipSave> would be much easier to use. It'd also allow you to get rid of the 50 saves limit, since ArrayList expands automatically as you add more entries to it.
Then, in conjunction with OO approach I talked about earlier you could get rid of the BoardListener and implement the button-press functionality in a neat way ("there must be a better way to do this!"):
Code: Select all
public class ShipSave extends SavedGameState {
...
// constructor
public ShipSave() {
...
button = new JButton(...);
// add it to the loopPanel, which now would have to be a public field in SpaceDockUI
button.addListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
if (SpaceDockUI.currentShip != this) {
SpaceDockUI.currentShip.dock();
board(); // changes currentShip = this and button text to "Dock", etc...
} else {
dock(); // changes button text to "Board", etc...
}
}
});
...
}
...
iceburg333 wrote:I started to do this, but I think my code relies too heavily on the Editor. I'd have to copy 60% of their code over
Huh, that's a bit of a dependency indeed. I don't know, personally I'd probably copy it over anyway, simply treating it as a library the program uses (I used this approach with Superluminal, copying the entire datLib class from KuroSaru's DatManager). I'm not sure if it's a good practice, however.
*shrug*iceburg333 wrote:Ps. I didn't really think about your program's name until the other day while reading an article on IRL FTL drives, and then it hit me: "super" meaning higher/beyond and "luminal" meaning light. That's a sick name! =D
I still think it's cheesy as hell
it was the working name I had for it, hoping I'd eventually come up with something better. Fast forward to the "release day", I went "fuck it, that's what it's going to be called", and just rolled with it.