A class, whether World, Actor or any other, is a blueprint (or part of one) for a type of object. Its fields maintain the different states that its objects can have and its methods provide the behavior for its objects (things these type objects can do). For each object, its states can be change and its behaviors can be utilized throughout the object's life (or its existence -- until all references to that object are lost). I should mention that the constructor(s) of a class only initialize the objects created from the class (setting initial states). That being said, your World object is basically your game controller. For example, a time limit can be placed on your game which would involve an int timer field and a method to run the timer. By the way, if you look in the World class API documentation, you will see that you can add an act method to your World subclass that greenfoot will automatically call on your World object once each act step (or frame). An act method would be added to call the method that runs the timer. If it the behavior that the player's interaction causes the new object to be added (or removed), then, yes, that should be coded in that Actor subclass.