Nikki Johnson wrote:We decided we wanted to be able to have the enemies (Ugly Ogres) be stored in a 2d array so that they can "defend" each other against attacks.
Liutauras Vilda wrote:Welcome to the Ranch
Delete '2d' and 'Java' combination before Campbell wakes up and comes here.
Why do you represent Enemies as chars? Something is very wrong with design seems. Will need to look deeper to give you some insights.
Nikki Johnson wrote:Uh oh, is there a way to edit my post that I'm not seeing?
Nikki Johnson wrote:So the point of an array of array is that when each UglyOgre is created, it is put in either [1][0], [1][1] or [1][2]. Then when the player attacks, the ogre has a chance to move in front of another one to prevent it from getting attacked. Say the ogre in [1][0] is attacked, then the ogre from [1][1] can move to [0][0] and take damage instead of the [1][0] ogre.
loc 1 | loc 2 | loc 3 |
loc 4 | loc 5 | loc 6 |
loc 7 | loc 8 | loc 9 |
Nikki Johnson wrote:I've managed to confuse myself on how I'm supposed to create a new UglyOgre, and then store it in the 2d array, because it each ogre also needs a "type", which is defined in the UglyOgre class.
Liutauras Vilda wrote:. . . Don't worry about that, he might forgive you . . .
Stephan van Hulst wrote:This separation will make it much easier for you to reason about your code and ...
Nikki Johnson wrote:The Enemies represented as chars was part of the design other group member came up with
Stephan wrote:
Liutauras Vilda wrote:
Nikki Johnson wrote:The Enemies represented as chars was part of the design other group member came up with
Probably as a first thing you need to do is to inform your colleagues so they would stop doing whatever they are doing based on that design you have been given.
Most likelyThey will need to amend their tasks based on the new design you are going to propose them. How much of work going to be to re-do don't know. Could be everything.
Liutauras Vilda wrote:What Stephan suggested, I'd go even a bit further (since you are doing OOP assignment), changing x and y coordinates to Location object.
This reveals your intention. So you need player and enemy classes (in your case UglyOgre.. or something), both classes could implement Fighters interface, so you could have something similar to
Bottom line: Choose names that will make your code reveal intent and hide implementation. This is what Abstraction is about and it's a very important concept to keep in mind when you're trying to come up with any kind of design.
Junilu Lacar wrote:
This is what's called reification - you turn two separate data points (x and y) into a real object.
Nikki Johnson wrote:
and got ahold of one of my group partners to fix the char parameter problem, which is making everything *compile* swimmingly, but I won't know if anything actually works until we all get together and put our classes together.
Aaaaaaaaaaaaaaaaaah!Nikki Johnson wrote:. . . whether each ogre created is either i=Ice, f=Fire, or n=Normal, hence why we were using chars to show which kind was created.
Lots of people make that mistake; it shouldn't be too difficult to correct. You will have problems if you leave your Character class lying around; when October comes and you can't get methods in java.lang.Character to work and can't understand why, it is probably because you have another class with the same simple name.[We] didn't realize . . . that Character was already a class in the java.lang.package.
In which case you won't know how to use a circular list or a circular array.. . . me and my fellow classmates working on this project are very new to java
That's a pleasureThank you!
Whew!!! OK, so I took Liutauras Vilda advice and did something more like this to fix my problems
I particularly liked what he said about ¾ of the way along:-Junilu Lacar wrote:. . . Invest five minutes and listen to Ward Cunningham explain the Debt Metaphor. . . .
That worries me; we hear people say that sort of thing on this forum often enough.. . . the idea that you could write code poorly with the intention of doing a good job later . . .
You need to know whether it works before you put things together. You need to decide a design, and for each class a specification. That can be simplified to its public interface and documentation. Remember the documentation is the contract of each class and method; Liutauras has shown you how to write it in the documentation comments. Then you need to test each class and each method in it, with “normal” and “abnormal” inputs, which is probably the simplest version of unit testing. Note what Junilu told you about test driven development.Nikki Johnson wrote:. . . I won't know if anything actually works until we all get together and put our classes together. . . .
Nikki Johnson wrote:this class being the first one for most of us, and it seems we might have gotten over enthusiastic about what we can accomplish.
Junilu Lacar wrote:realize you have failed and your project along with you.
Campbell Ritchie wrote:
I particularly liked what he said about ¾ of the way along:-Junilu Lacar wrote:. . . Invest five minutes and listen to Ward Cunningham explain the Debt Metaphor. . . .
That worries me; we hear people say that sort of thing on this forum often enough.. . . the idea that you could write code poorly with the intention of doing a good job later . . .
Another facet of the debt metaphor is that the sooner you pay it off, the less interest you pay; the sooner you correct the structure of your code the less hard work you will have. And any hard work will be fruitful rather than fruitless.