1/3/2024 0 Comments Greenfoot worldAlso, it allows use of multiple scenarios in a single course, since the overhead of installing and learning to interact with a new framework is avoided. This enables use of more user- targeted scenarios, since scenario writing is at a level of complexity that puts it within reach of many teachers. In greenfoot, a goal is to allow widely differing scenarios to be developed by knowledgeable users (such as teachers) within a single framework (Figure 2). The overhead of learning to use a different micro world system in order to use a different scenario is usually forbidding. It also means that courses typically use only a single scenario. If, for example, some students have no interest in robots, they still cannot escape them if Karel is used. The scenario cannot easily be adapted for different user groups. While this restriction has the advantage to simplify start-up, it has disadvantages as well. Many existing micro worlds achieve simplicity by restricting use to a single scenario: The Marine Biology Case Study deals with fish and nothing else, Karel has robots and "beepers", turtle graphics has a turtle and a pen. One of the important characteristics of greenfoot is the de- coupling of the user level scenario from the animation and interaction framework. They can have behaviour that is exhibited when the simulation is run using the Run button, and they can be used for direct interaction through associated popup menus when the simulation is paused. All objects in a greenfoot world are automatically animated and interactive. The appearance can span one or more cells. Greenfoot objects have a location in the world and a rotation that is applied to the icon. Each greenfoot object can specify its own individual appearance using an icon or a drawing method. The world provides a grid of cells, which can hold greenfoot objects. The environment also provides a predefined class GreenfootWorld, which implements the world itself. All classes whose instances should be visible in the greenfoot world extend the predefined superclass GreenfootObject. The lower part of the window holds execution controls to run, stop or single-step the simulation and a slider to control the execution speed. These actions can be accessed from a popup menu of the class. The classes can be edited, compiled and instantiated. The classes are divided into Greenfoot-World Classes, representing worlds, and Greenfoot-Object Classes, representing visible objects within the world. Here, all classes involved in the current application are shown. To the right of the world is a class display. It holds the greenfoot objects (ant hills, ants and food in this example). The largest part of greenfoot’s user interface is reserved for the display of the world, shown in the centre of the screen ( Figure 1). The greenfoot system also provides a full IDE, including integrated editing, compilation, creation of new classes, object inspection and a source level debugger. Scenarios are completely decoupled from the visualisation and interaction framework, so that greenfoot can be used for a wide variety of graphical applications. In addition to this, greenfoot allows direct interactive method calls on simulation objects, similar to the interaction facilities in the BlueJ environment. One aspect of greenfoot is that it allows visualisation of appearance and location of simulation objects in a two- dimensional grid, similar to micro world systems, such as Karel J. It provides a framework and environment to create interactive, simulation-like applications in a two-dimensional plane. The greenfoot system is an interactive object world. We describe the motivation and environment mechanism for supporting this below. The goal of supporting an interaction mechanism for running applications – for the purpose of developing game-like applications – has recently been added and was not included in earlier discussions of design goals. Some of these design goals have been discussed in more detail in. to allow for easy development of interactive scenarios, for example interactive games, by students to support migration to other environments.to provide a clean illustration of object-oriented concepts.to support highly flexible scenarios, while freeing scenario writers from dealing with GUI programming.to allow active interaction and experimentation with object instances and to explore behaviour interactively.to provide visual feedback of object state and behaviour.in detail, we give a brief summary of the main design goals, which will help to put into perspective those decisions we discuss later in more detail.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |