This site requires JavaScript, please enable it in your browser!
Greenfoot back
Mortaz
Mortaz wrote ...

2014/12/21

On maPong by Mortaz

Mortaz Mortaz

2014/12/21

#
Feedback and improvement on my game maPong. The link to my game is http://www.greenfoot.org/scenarios/12851 with its source code, I have add comment on each line so its easy to understand what I did, I know my programming skill is very limited as this is my first game I created using Java however if there is something that needs changes please let me know that would be very helpful. Improve/Add: Main Menu Single Player Power Ups *(Still programming to add it to my game the red lines at the bottom corner will be used to paralyze the opponent for one sec. and can only be used once every ten sec. ) Better Physics when the Ball hits the Paddle Smooth Ball motion Remove Greenfeets at the beginning of the game I know the list is quite long but if there is anything you can help me with that would be awesome! The way I programmed is probably wrong too as there is an easier method of cloning items which I didn't know before. Oh well its too late for that...
danpost danpost

2014/12/21

#
If you take the first line in the act methods of your counter classes (the 'setImage' line) and put it in a separate method -- call it 'private void updateImage', then you can not only call it from the act method where the line currently is, but you can also call it from the constructor of the actor (which currently is not used in this class). For example:
public p1Counter()
{
    updateImage();
}
As an alternative, you can replace the method call in the constructor above with a copy of the 'setImage' line and leave the line also in the 'act' method without having to create the extra 'updateImage' method. There are several issues that need addressing. These are merely to help improve your programming skills. * class names should, by convention, begin with an uppercase letter and both field and method names should begin with lowercase letters; * you should avoid having processes performed that do not change the current state; for example, your counter classes set the image of the actor every single act cycle whether the score has changed or not; this is taking CPU time away from processes that do need attention; when ready, you can ask how to change your code to make it less CPU taxing; * the 'addObject' method has parameters for where an actor should be placed in the world; unless another class is causing the actor to be misplaced, there is no need to constantly set its specific location in the 'act' method (also, this goes along with the last issue); * you are missing out on the benefits of object-oriented programming by making multiple classes for the same type object (i.e. p1Counter vs. p2Counter; p1Power vs. p2Power; p1Won vs. p2Won; TopBorder vs. BottomBorder; LeftSide vs. RightSide; Paddle vs. CCPaddle); usually, all it takes is a field or two to differentiate between one object and another (the paddles would take a bit more); again, when ready, ask about this;
Mortaz Mortaz

2014/12/21

#
alright I will fix the scoreboard first, thank you for your help
Mortaz Mortaz

2014/12/21

#
Thank you Dan it worked. Could you please tell me why we used 'private void updateImage' instead of 'public void updateImage' and what makes it actually work?
danpost danpost

2014/12/21

#
We use 'private' when you do not want to allow any other class (including subclasses) to execute the method (or field, if you use it on one of them). I am not sure what you mean by 'what makes it actually work', or at least in what sense you mean it. When you call a method, the method executes its code and then return to the line after the statement that called it. If you mean how the image was no longer a green foot, then the code I provided, the constructor, is called when you use the 'new' keyword on the name of the class. So, the image is set before the actor is added into the world.
Mortaz Mortaz

2014/12/21

#
I see so If I use public I can execute a method from different actors too, which would be something like '(Actor name).(Method)();' so its like a static variable right? sorry I'm still new to programming, and yes I meant the second point. Thank you for helping!
danpost danpost

2014/12/21

#
Mortaz wrote...
I see so If I use public I can execute a method from different actors too, which would be something like '(Actor name).(Method)();'
yes; although, you should probably generalize is like this: ObjectName.MethodName(ParameterList) where ObjectName is referenced as a type of whatever class the method resides or a subclass of that type. All method calls conform to this line; however, the 'ObjectName' may be removed, or replaced with the 'this' keyword, for calls within the class.
// this will not work, say from an Actor subclass
World world = getWorld(); // world cast as World type object
Player player = world.getPlayer(); // cannot find method 'getPlayer'
// where this will work
MyWorld world = (MyWorld)getWorld(); // world cast as MyWorld type object
Player player = world.getPlayer(); // method found in MyWorld class
so its like a static variable right? sorry I'm still new to programming, and yes I meant the second point. Thank you for helping!
no; all 'static' means is that the member (the field or method) belongs to the class and not to the objects created from the class. That is another issue that should be dealt with -- as far as your static score fields in your counter classes. Anyway, when declaring fields and method, you can apply a modifier to show what kind of accessibility the member should have ('public', 'private', or 'protected' -- these are the ones mostly used). 'public' means you can access it from anywhere within the project; 'protected' means it can be accessed from the class it is in or any subclass of that class; and 'private' means it can not even be accessed by a subclass -- but, only from within the class itself. Getting back to 'static' (class) fields and 'non-static' (object or instance) fields. A set of all instance fields in a class are given to each object created from the class. Each object created can have different values set to its fields. These fields for an object are initialized when the object is created. The 'static' fields of a class are initialized during compilation of the project. Resetting the project does not even reset 'static' fields; so, care must be taken to ensure their proper initial values at start-up. Most of what I tried to explain above can be reviewed in the Java tutorials within the Classes and Objects trail..
Mortaz Mortaz

2014/12/21

#
very useful thank you, one more question in Greenfoot can you create complex objects under one Actor for example the top/ bottom border, red lines, and the middle screen all of them on a single Actor? if so how do you do it?
danpost danpost

2014/12/21

#
Mortaz wrote...
can you create complex objects under one Actor for example the top/ bottom border, red lines, and the middle screen all of them on a single Actor? if so how do you do it?
You could -- but, in your case, since none of them interact this any Actors or move, it might be just as well to draw them onto the background of the world.
You need to login to post a reply.