text:
While our framework borrows from some design patterns, we feel that games are a very expressive medium. We want you, the reader of this book, to think outside that proverbial, over-used box. While design pattern ideas lend them selves to all manner of application development, we don't want you to feel hemmed in to using any one set of ideas for creating their games. Our framework gives structure to the overall flow of a game but does not dictate how to code the actual game logic.
Exploring the Framework
The game framework is housed in a reusable package structure. A package structure at its very basic is an organized set of folders that will contain reusable classes. All of the standard class files for using the framwork will be in this package structure. We will update and extend this structure as we proceed through this book. Let's start by giving you an idea of what classes we will be creating for the framework.
The GameFrameWork.as class
The GameFrameWork.as class is the foundation of the framework. It contains a simple state machine and a basic game loop timer. Our state machine is a simple construct containing a set of state constants to switch the framework between states. States are handled by state functions inside the GameFrameWork.as file. We will employ a variable to reference the current state function. The game timer will use this refernce to call the current state function on each frame tick. We will create states for such things as the title screen, instructions screen, game play, game over, and more. When we create a new game our document class will be an instance of GameFrameWork called Main.as. This Main.as will have an init (short for "initialization") function that will set up the framework for use. This Main.as class will also act as a sort of message gateway between the game and the framework classes. If you are confused, don't worry; we'll be explaining this in greater detail soon.
The FrameWorkStates.as class
This FrameWorkStates.as class will simply contain a set of constant integer values representing the state machine states. When we first create the framework we will have 10 different state constants. All will begin with the STATE_SYSTEM designation. For example, we will have a state that displays the title screen. The state constant for this will be STATE_SYSTEM_TITLE. More states will be added as we progress through the chapters in this book.
The BasicScreen class and SimpleBlitButton helper class
The BasicScreen class will be used to display very simple game state screens. These screens can have a basic background color with transparency (if needed), as well as some text centered on the screen. Each screen can also have a button that needs to be clicked to move to a new state in the state machine. This class is so simple that it will probably never be used without major modification in your own commercial games. We present it here, in its very simple form, for utility purposes. The SimpleBlitButton helper class is used to create a clickable button with rollover and off states. The button is created completely in code with a simple color background for the over and off states to be sed in the BasicScreen class. We do this for simplicity and to demonstrate some Sprite blitting techniques (much more on these later in the book) using a set of BitmapData instances for the background color change of the button on rollover.
The ScoreBoard class and SideBySideScoreElement helper class
The ScoreBoard class displays information for the user during game play. Data such as the current game score, time remaining, and other useful information can be displayed to the user with a very basic look and feel by using this class. It can be used as is, but when you start to make your own commercial games, you might find it useful to extend this class with more functionality. This very basic class is used inside the framework to demonstrate how to use events from a Game instance to update a game score board. The SideBySideScoreElement helper class is used to display a text label and corresponding dynamic text field as a pair side by side on the screen. For example, it can be implemented by the ScoreBoard class to display the word Score followed by the user's current score.
The Game class
The Game class is a stub style class that all games in the framework will inherit from. It contains the basic variables and functions needed to work with the GameFrameWork class.
The Custom event classes
The framework makes use of events to communicate between classes. The instances of the Game class will use events to communicate with the ScoreBoard and the Main classes. We will create a custom Main.as class for each game. This Main class will be a sub-class (or child) of the GameFrameWork class. Some of the events we will use will be simple events. These are instances of the standard Flash Event class used for basic communication. By this, we mean events that don't need to send any data along with them. For example, instances of the Game.as framework class will have a constant variable called GAME_OVER. This constant will be used as the name of a simple Event instance that is fired off with the standard dispatchEvent function call. This example GAME_OVER event wil be used to tell the Main.as to move to the game over (STATE_SYSTEM_GAME_OVER) state in the main state loop when the current game has completed. We will also be creating three distinct custom event classes as part of the framework. These will be used to send specific data from the Game class instance to the Main.as (GameFrameWork.as instance) class. The Main.as will act on the data sent and if needed, pass the data to other framework classes. By doing this, we are using Main.as as a sort of message gateway.
The CustomEventButtonId.as class
This custom event will have the ability to pass an identification integer value to the listening function. It is used for cases where multiple buttons share the same listener function. It will be used in the framework (specifically in the GameFrameWork instance, Main.as) to allow BasicScreen instances to each share the same listener functions if they employ a SimpleBlitButton. You will see this when we examine the GameFrameWork class file. It can also be used for any game or application that needs to send a basic integer id along with an Event instance.
The CustomEventLevelScreenUpdate.as class
This custom event will be used by the Game.as class instance to send data to a BasicScreen instance we will create called levelInScreen. The levelInScreen will have the ability to display custom text between each level. The event listnener for this event will change this text with a value passed when the event is fired off. The Main.as (GameFrameWork.as sub-class) will listen for this event and pass the data to the levelInScreen.
The CustomEventScoreBoardUpdate.as class
This custom event will be used by the the Game.as class instance to update the values on the ScoreBoard class instance. The Main.as class will listen to for this event and pass the data on to the ScoreBoard.as class instance.
The framework package structure
We will be organizing all of the code we will create into a package structure. The reusable framework classes will be in one package, and the games we will create will be in a separate package. Let's to create these two package structures now.
The source folder
Choose a spot on your disk drive of choice, and create a folder called source. This will be the root or base level for all of the code and games we will create in this book.
The classes package
The reusable framework classes will be in a package called classes. Create a folder called classes inside the source folder from the previous step. You should now have a folder structure that looks a little like this: [source] [classes] Next, we will create the actual package that will contain all of the source code for the reusable framework classes. We will name this package com.efg.framework. To create this, you must first create a folder inside the classes folder called com, then a folder called efg inside the com folder, and finally a framework folder inside the efg folder. By the way, the "efg" is an abbreviation for the book title, Essential Flash Games. You should now have a folder structure that looks like this: [source] [classes] [com] [efg] [framework] When we start to create all of the class files necessary for the framework, they will all go into the framework folder. You will see that when we create these classes, the package name will look like this: package com.efg.framework {
The projects package
The second package we will create is called the projects package. You can start this right away by creating a folder inside the root source folder called projects. The projects folder is not going to be a straight package structure like the classes folder. It is organized in a manner to allow individual custom game development using the framework. Inside this projects folder, we are going to create a unique folder for each game in the book. The first game we are going to create is called stubgame. A stub is usually a function or class that contains very little (if any) usable code but is instead a simple placeholder. Our game will be slightly more than a placeholder but not much more. It will be used to demonstrate the basic functionality of the framework. Go ahead and create a folder called stubgame in the projects folder. You should have a projects set of folders that look like this:
[source] [classes] ... [projects] [stubgame] Next, we are going to create two folders, each to hold a different version of our game. Why are we going to do this? This book is meant to support Flash game development with a variety of tools. There are many popular methods to create Flash games with an assortment of tools and code integrated development environments (IDEs). We are going to focus on two such tools in this book: the Flash IDE (the one with the library, timelines, drawing tools, and so on all combined into a single tool) and Flash Develop (a very popular, free IDE made specifically for ActionScript development). You can use any tool with this book, but you will need to follow the documentation specific to your own tool when setting up projects. You will need to pay careful attention to linking the reusable code package structure to your games, because linking may vary depending on the Flash code editor environment you are using. Linking the package to a game is actually a very simple process, but it differs between the various code IDE versions. Jeff does most of his Flash game development Flash Develop using the free Flex SDK that Adobe provides. Steve, on the other-hand, uses the Flash IDE almost exclusively. We have combined our efforts on all of the chapter games to bring you code that will work with both a Flex SDK project and a Flash IDE project.
On that note, the next two folders you will create inside the stubgame folder are called flashIDE and flexSDK. You don't have to create both for any project. You just need to create the one that works with the tools you are going to use to create Flash games. Each is set up differently, so pay attention to the specifics of the one you will be using the most.
You should now have a projects folder that looks like this:
[projects] [stubgame] [flashIDE] [flexSDK]
The Flash IDE package structure
The Flash IDE package structure begins right inside the flashIDE folder. The package name is very similar to the classes package you saw in the last section. The package structure will be com.efg.games.[game name]. For instance, with the stub game we are going to create in this chapter, the package name will be com.efg.games.stubgame. Go ahead and create those folders now. You should have this package structure when you are complete: [projects] [stubgame] [flashIDE] [com] [efg] [games] [stubgame] [flexSDK]
The Flex SDK package structure
The Flex SDK package structure is very similar to the Flash IDE package structure with one small difference. Flash Develop and other Flex tools use a specific set of folders for organizing their own project structures. To accommodate these and still have a common package structure for our games, we must add the Flash Develop created src folder to the flexSDK folder. You will not have to create the src folder or the package structure by hand, as Flash Develop will create it automatically for you when you start a new project. In the section called "Setting up the game in Flash Develop," we will go into the details. For now, here is the way the structure will be laid out (including the Flash Develop specific folders such as bin, obj, and lib. If you have used Flash Develop to create a Flex SDK project, you will recognize the following structure: [projects] [stubgame] [flexSDK] [bin] [obj] [lib] [src] [com] [efg] [games] [stubgame] Notice that we have created the exact same package structure inside the src folder as we will use with the Flash IDE. The package name for our game will be com.efg.games.stubgame. The package name in the code for classes in both the Flash IDE and Flex SDK will be the same:
package com.efg.games.stubgame {
The Main.as and StubGame.as files
When we start to add files to the subgame package we will be creating two subclasses (or children) of framework classes that will be unique to our game. The Main.as will be created as a subclass (or child) of GameFrameWork.as framework class. The StubGame.as class will be a subclass (or child) of the Game.as framework class.
Starting a project using the framework packages
You have just seen the basic package structure for both the framework reusable classes and the projects we are going to create. Let's make use of this right away by creating a project for the stub game. The stub game will be very similar to the Chapter 1 game where the player is tasked with clicking the mouse ten times.
Creating the stub game project in the Flash IDE
Follow these steps to set up stub game using the Flash IDE:
- Start up your version of Flash. I am using CS3, but this will work exactly the same in CS4 and CS5.
- Create a .fla file in the /source/projects/stubgame/flashIDE/ folder called stubgame.
- In the /source/projects/stubgame/flashIDE/ folder, create the following package structure for your game: /com/efg/games/stubgame/
- Set the frame rate of the Flash movie to 30 FPS. Set the width and height both to 400.
- Set the document class to com.efg.games.stubgame.Main
- We have not yet created the Main.as class so you will see a warning. We are going to create this later in this chapter.
- Add the framework reusable class package to the class path for the .fla file
- In the publish settings, select [Flash] -> [ActionScript 3 Setting].
- Click the Browse to Path button and find the /source folder we created earlier for the package structure. Select the classes folder, and click the choose button. Now the com.efg.framework package will be available for use when we begin to create our game. We have not created the framework class files yet, but we will be doing this very shortly.
Creating the stub game project in Flash Develop
And these are the steps to create the same project using Flash Develop:
- Create a folder inside the [source][projects][stubgame] folder called [flexSDK] (if you have not already done so).
- Start Flash Develop, and create a new project:
- Select Flex 3 Project.
- Give the project the name stubgame.
- The location should be the /source/projects/stubgame/flexSDK folder.
- The package should be com.efg.games.stubgame.
- Do not have Flash Develop create a project folder automatically. Make sure the Create Folder For Project box is unchecked.
- Click the OK button to create the project.
- Go to the [project] -> [properties] -> [classpaths] menu item.
- Click the add class path button.
- Find the /source folder we created earlier, and select the classes subfolder.
- Click the ok button and then the apply button. You now have the basic structure to start creating projects inside the framework. We are now going to discuss a few topics concerning the structure of the framework classes and then move into building the reusable framework code. Here are a couple of things to note: For Flex Builder, Flash Builder, or other IDEs, please refer to the documentation provided for that product to create a new project and set the default compile class.
A common method of Flash development is to use the Flash IDE for assets and organization and Flash Develop for code editing. If this is your workflow of choice, you will want to follow the Flash IDE folder and package structure rather than the Flex SDK folder structure.
Creating game timers
There are two basic methods that most Flash developers implement when creating a frame-based game timer. By "frame-based," we mean a timer that uses the idea of a segment of time broken up into logical slices (or frames) to manage game logic. There are other types of methods for timing game updates, but we will make extensive use of time-slice or frame-based timers in this book. The basic game timer we will use most of the games will attempt to squeeze all processing and screen updates into each segment or frame. We will also explore a time-step timer and a sleep-based timer in chapter 11. The first timer method is the Event.ENTER_FRAME event timer. The standard Event.ENTER_FRAME event handler will attempt to run the game loop at the .swf file's set frame rate. This very handy game loop timer has been in use for a number of years. The second standard game loop timer method makes use of the Timer class. The Timer class is used to call the game loop at millisecond intervals specified by a delay interval. For example, if the millisecond delay interval is set to 100, the Timer instance would run ten times a second (there are 1,000 milliseconds in a single second). Our framework will begin by using this Timer instance game loop timer. We will do this so we can make use of the TimerEvent.TIMER updateAfterEvent function. As you will see, this function will help smooth out screen updates.
Defining "frame timer tick"
You will see the phrases "frame timer tick," "timer tick," and "frame tick" used in this book. When we refer to a "tick" or a "frame tick," we simply mean one frame's worth of processing. When we run a game at 30 frames per second, we have 30 ticks or 30 frame ticks. This also means that we only have 33.33 milliseconds (or 1,000/30) inside each tick to do all of our processing.
State Machines
A traditional state machine at its very basic is a mechanism that controls the state, or current actions a system can perform. Sometimes this is called a finite state machine. Finite state machines have traditionally been used to model complex mathematical computations and more recently artificial intelligence. The "finite" in the name refers to the fact that the system can only be in a single state at any one time. Our game framework is built on a simple state machine pattern that employs a separate code function or method for each state. There are many other styles of state machines; some use entire classes for each individual state (sometimes called an object-oriented state machine) and some use a simple switch:case statement block called on each frame tick to control state. We will use a third type that borrows from these two. We call our state machine pattern a function reference pattern. Unlike the object-oriented state machine, our machine will contain a separate method or function for each state inside a single framework class. Each of these state functions will control elements in the framework such as instances of the BasicScreen and Game classes. We will use a switch:case statement to move between states. Unlike the afore mentioned very simple switch/case state machine structures that call this switch/state control structure on each frame tick, we only need to call it when we are switching states. The switch:case we call will simply change the function reference we call on each frame tick. The GameFrameWork.as will contain the state machine that controls overall game flow. This will move our game system between states defined in the FrameWorkStates.as file.
Each individual game package we create will contain a Main.as (in the game's own package structure) that will extend GameFrameWork.as. We will also create a unique Game.as child class for each game. The Game class children that we create can also employ their own internal state machines based on the function reference pattern when needed.
Richard (Squize) Myles of www.gamingyourway.com was one of the first to offer the idea of a function reference state machine for ActionScript 3 on his well-respected blog.
The FrameWorkStates.as class file
This class file is a simple collection of constants that will define the states for the game framework. They will be consumed by the GameFrameWork.as class file. The following code listing shows the entire code for this file; you will want to create this file according to the package structure in the previous section: package com.efg.framework { /** * ... * @author Jeff and Steve Fulton * */ public class FrameWorkStates { public static const STATE_SYSTEM_WAIT_FOR_CLOSE:int = 0; public static const STATE_SYSTEM_TITLE:int = 1; public static const STATE_SYSTEM_INSTRUCTIONS:int = 2; public static const STATE_SYSTEM_NEW_GAME:int = 3; public static const STATE_SYSTEM_GAME_OVER:int = 4; public static const STATE_SYSTEM_NEW_LEVEL:int = 5; public static const STATE_SYSTEM_LEVEL_IN:int = 6; public static const STATE_SYSTEM_GAME_PLAY:int = 7; public static const STATE_SYSTEM_LEVEL_OUT:int = 8; public static const STATE_SYSTEM_WAIT:int = 9; } } The first thing you should notice about this class is the package name in the first line. It conforms to the file system structure we created earlier. No matter if you are using a version of Flash, Flex Builder, Flash Builder, Flash Develop, TextMate, or even plain old Notepad, this package name will be the same. The package name is not depended on the code development environment but the chosen file structure for organizing the code. Save this file in the location we created previously. /source/classes/com/efg/framework/FrameWorkStates.as
The state variables
The state variables are constants that the game loop state machine will use to move between game states. We have set up the most common basic states in this sample file, but you will be able to create as many as you need. As we progress through the chapters, more will be added as necessary.
- STATE_SYSTEM_TITLE: This state is used to display a basic title screen with an OK button for the user to click to move on. Once the instructions are on the screen, the state will change to the next state.
- STATE_SYSTEM_WAIT_FOR_CLOSE: This one waits until the OK button is clicked for any instance of the BasicScreen class.
- STATE_SYSTEM_INSTRUCTIONS: This state is used to display basic instructions with the same OK button as in the SYSTEM_TITLE state. It also changes to the STATE_SYSTEM_WAIT_FOR_CLOSE state until the OK button is clicked.
- STATE_SYSTEM_NEW_GAME: This state will call the game logic class and fire off its game.newGame() function. It does not wait but moves on to the NEW_LEVEL state right away.
- STATE_SYSTEM_NEW_LEVEL: With this state, we can call the game.newLevel() function to set up a new level for the given game.
- STATE_SYSTEM_LEVEL_IN: This state is used to display some basic information, if needed, for the beginning of a level. In this basic game, we simply display the level screen and wait a few seconds before moving on. The wait is accomplished by changing state to the STATE_SYSTEM_WAIT state for the specified number of frame ticks.
- STATE_SYSTEM_GAME_PLAY: This one simply calls the game logic class's runGame function repeatedly and lets the game take care of its own logic and states.
- STATE_SYSTEM_GAME_OVER: The game over state displays the basic game over screen and waits for the OK button to be clicked before moving back to the instructions screen. It quickly changes state to the STATE_SYSTEM_WAIT_FOR_CLOSE until the OK button is clicked.
- STATE_SYSTEM_WAIT: This state waits for a specified number of frames and then fires off a simple custom event constant called WAIT_COMPLETE.
The GameFrameWork.as class file
The GameFrameWork.as will be that parent of our game's document class. Main.as (the game's document class) for our games will extend this class and call functions to modify the framework for each unique game. The entire code listing is provided at the end of this section. We will explore it in detail once your have had a chance to type in the code. The location for this file in the package structure is /source/classes/com/efg/framework/GameFrameWork.as
The GameFrameWork.as will be the parent class to the Main.as class we will use for our games, and it's shown in the following listing. In later chapters, we will add some functions to this file and even create one that uses a completely different timer. The Main.as will subclass this class with the extends syntax and override the blank stub init function we are about to create. This class will also contain all of the state functions that coincide with the state variables in the FrameWorkStates class. All of the functions in the GameFrameWork.as are public so all can be overridden by the Main.as if needed. In this way, we can customize the behavior of the state functions if we need to.
For example, in later chapters, we will want to play music on the title screen. The function call to play the music will need to be added to the systemTitle state function. Not all games will need this though, so we will not add it to the GameFrameWork.as file's systemTitleFunction. Instead, we will create a new version of the function in Main.as to override the one in GameFrameWork.as. The new one will play the sound needed and then call the systemTitle function inside GameFrameWork.as with the super.systemTitle() function call.
Source Listing 1
The class imports
The class import section contains the necessary Flash core classes needed for the Main class. Notice the package name coincides with the package structure we created earlier in the chapter for the framework: package com.efg.framework {
We also must import all of the classes needed for the framework to run. You will see this put to use shortly.
The variable definitions
The variable definition section defines all of the global scope variables for the class. These include all of the variables needed for the state machine, screens, and the game timer. We will make use of constants to define the current state and a set of variables to hold the state information. These have been be defined on the FrameWorkStates.as file we created in the last section. More states can be added to the basic ones, but these will be sufficient for many games that we will create in this book. There are two special states that are used for the system and wait for button clicks or things like animations to complete. These are the STATE_SYSTEM_WAIT_FOR_CLOSE and STATE_SYSTEM_WAIT respectively. We will also make use of a generic function called systemFunction that will hold the current state function to call in our game loop. Combined with this, we use a set of integer variables to hold the value of the current state (currentSystemState), the last state (lastSystemState) and the next state (nextSystemState) for processing purposes. These states should not be confused with an actual game pause function. This will be handled in a different manner and added to the framework in Chapter 11.
If you are using the Flash IDE and have any assets in the library that need to be exported in the first frame, you must extend MovieClip and not Sprite even if you don't plan to use the main time line for anything else. We have extended MovieClip for the GameFrameWork so it will work with both Flex SDK and Flash IDE projects.
The state control variables
The control variables keep the system functioning within the context of the current state. The main control variable is an instance of the Function class called systemFunction. This function holds a reference to the current function that will be repeatedly called on each frame tick. This saves us from having to evaluate a switch:case statement on each frame to decide which function to call. The function is changed to a new reference by called the switchSystemState() function and passing a new constant that represents the new state. Optimization! switchSystemState() is the first of many optimizations we will make to the game framework. All of these optimizations will make the Flash games run much more efficiently. These efficiencies in the game framework will allow the actual game code to perform more complex operations and still run with a reasonable frame rate. The currentSystemState integer variable holds a number representing the constant of the current state the system is running. The nextSystemState contains the constant integer value for the state to transition to after this state is complete. The lastSystemState variable holds the integer constant of the previous system state. This is used in the rare occurrence that the game loop needs to return to the previous system state. The lastSystemState variable will become useful when we use a shared state such as STATE_SYSTEM_WAIT. The STATE_SYSTEM_LEVEL_IN state will implement a 30-millisecond delay before moving on to the STATE_SYSTEM_GAME_PLAY state. The nextSystemState will be STATE_SYSTEM_WAIT and the lastSystemState will be STATE_SYSTEM_LEVEL_IN. When the 30-millisecond wait time has expired, the waitCompleteListener function will be called. It will use the lastSystemState to determine where the processing was before the wait was started. You'll see this in detail later in this chapter when we examine the waitCompleteListener function.
The background fill variables
All Flash applications have a background color of some type. No matter what game we are going to be creating, the framework can control this background color. You should never rely on the background color setting in HTML for your Flash application's background color. This leaves the HTML embed code with control over major aspect of your application. If you are creating a viral game to be placed on game portals, you will lose control of your game's background color, and it will default to what ever the game portal operators have selected as the standard background color in their embed code. The framework allows you to override the HTML settings here by placing a simple colored Bitmap behind the entire application. We will simply define a BitmapData object called appBackBitmapData and a Bitmap object called appBackBitmap that will be used to place the BitmapData onto the displayList. We will not define the background in the GameFrameWork.as file, but rather the Main.as subclass of the GameFrameWork will set the background if needed in its init function override.
The timer variables
The timer will control the frame rate of the game and help smooth out the display by employing the TimerEvent.updateAfterEvent method. The frameRate variable will be defined in Main.as as the number of frame ticks per second we want our game timer to run. The most important thing to note is that we are making use of the built-in Timer class (gameTimer). We are not using the standard EnterFrame event. This allows us to create our own frame rate for the game and specify it in the frameRate variable. By doing this, we can control game timer tick rate independent of the .swf file's frame rate (FPS). The .swf file can have a frame rate setting of 25 (for example), but the game can run at a 30 frame ticks a second. To do this, we first set the frameRate to the desired number of frame update ticks we want per second (30). When Main.as calls the startTimer function (described in detail when we get to the section on the init function), the gameTimer is put into action. First, we will calculate the timerPeriod value as 1000 / frameRate. With the updateAfterEvent function call (in the runGame function), we help to smooth out the render of the screen by asking the Flash display engine to update at the rate of the Timer, not the frame rate set in the .swf. So, going back to our example, if the game SWF is set to run at 25 FPS, and the frameRate is set to 30 ticks, the updateAfterEvent will help to smooth out the rendering of the screen by asking the Flash display engine to update at the timer tick rate (30), not the .swf file's FPS setting (25).
The timerPeriod will be passed into the Timer instance and the game will attempt to run at this rate. We say "attempt" because if the game includes too many on screen moving objects or more logic than can be computed inside the timerPeriod number of milliseconds (or a combination of both), then there will be a noticable slowdown in the game screen updates. In later chapters, we will add functionality to the runGame function to mitigate some of these issues.
The screen definition variables
The screen definition variables create instances of our BasicScreen class. This is a rather simple class that allows a single positional text box and an OK button on the screen. We will use this simple screen for the title, instructions, level, and game over screens. We will customize each screen when we create the init function override in our game's Main.as class. Note that the levelInText is a special variable. Setting this string to a default value will allow the leveInScreen to display some default text along on each new level. This text can be combined with dynamic text to create a screen that says something like Level 1 with the word "Level" being the default text and the number "1" being the dynamic text. public var titleScreen:BasicScreen; public var gameOverScreen:BasicScreen; public var instructionsScreen:BasicScreen; public var levelInScreen:BasicScreen; public var levelInText:String; public var screenTextFormat:TextFormat; public var screenButtonFormat:TextFormat; We also create two TextFormat objects that will be used for defining the format of the text on the screens and the format of the button text.
The ScoreBoard variables
The scoreBoard instance of the ScoreBoard class will handle a simple heads up display (HUD) for the user with information such as the current score. It is a simple framework class that will be customized in the init function override in each game's Main.as class. The changes will depend on the game that is to be created. We also define a TextFormatObject for the basic look of the text for our scoreboard text: scoreBoardTextFormat.
The Game object variable
The Game object, represented by the variable simply named game, is an instance of the Game class. The Main.as class's init function override will inistantiate this. For example, the StubGame.as we will create for the game in this chapter will be a child of the Game.as base class. It will override some of the Game.as base classes and hold the custom logic for the game. //Game is our custom class to hold all logic for the game. private var game:Game;
The wait variables
These variables are used for the simple wait period in the STATE_SYSTEM_WAIT state. waitTime can be set to a different value each time it is used. 30 is the default. We have set the frame rate for our application framework to 30 frames per second, so this would be a one second wait time. 30 frame ticks equals 1 second of time in our game timer if the frame rate is set to 30. waitCount is incremented each frame when a wait is occurring. When waitCount==waitTime, the control moves to the next state. //waitTime is used in conjunction with the STATE_SYSTEM_WAIT state // it suspends the game and allows animation or other processing to //finish private var waitTime:int = 30; private var waitCount:int=0;
The constructor function definition
The constructor for GameFrameWork.as does not contain any code. It is simply a placeholder. We will subclass GameFrameWork.as to create the unique Main.as for each game. The Main.as constructor will contain code to call the init function override. public function GameFrameWork() {}
The init function definition
The init() function is simply a stub to be overridden by the Main.as subclass of GameFrameWork.as.
The setApplicationBackGround function definition
This function accepts in parameters to create a basic back ground for the game. The width, height, transparency Boolean, and color values for the back ground are passed and used to instantiate the appBackBitmapData and place it on to the display list.
The startTimer function definition
This function will be called by the Main.as subclass inside its init function. It will use the frameRate variable to create the timerPeriod. Since the timerPeriod must be expressed in milliseconds (1,000/1 of a second equals a timerPeriod of 1000 or a single second), we simply divide the frameRate into 1,000 to get the number of times per second that the timer must run. In the case of a frameRate that is set to 30 ticks for example, the timerPeriod would be 33.33.
The runGame function definition
The runGame function is the core of the state machine. Once the systemFunction has been set with the switchSystemState (discussed next) function call, the runGame function will call it repeatedly at the set timerPeriod rate every 33 milliseconds (or so) for or frame rate of 30. public function runGame(e:TimerEvent):void { systemFunction(); e.updateAfterEvent(); } The e.updateAfterEvent() function call tells the Flash player to make an extra screen update after the frame tick is over, rather than waiting for the next system frame update to occur. System frame update events happen based on the SWF's stage frame rate. If we don't call e.updateAfterEvent here, the screen would not be updated until an actual system frame update event occurs. By using this, we smooth out the look of the screen updates to coincide with out selected gameTimer delay value.
The switchSystemState function definition
While the runGame function is the core of the timer, the switchSystemState() function is the core of the simplified state machine. It is passed a constant value for the state. Using that value, it switches the systemFunction reference accordingly. The switchSystemState function is used to change the current systemFunction of the timer for the next frame timer tick. A reference to one of the state constants is passed into the function, and it acts on it to change the systemState variable. It also changes the lastSystemState and nextSystemState variables. As a refresher, here are the constants from the variable definition section of this FrameWorkStates.as class:
public static const STATE_SYSTEM_WAIT_FOR_CLOSE:int = 0; public static const STATE_SYSTEM_TITLE:int = 1; public static const STATE_SYSTEM_INSTRUCTIONS:int = 2; public static const STATE_SYSTEM_NEW_GAME:int = 3; public static const STATE_SYSTEM_GAME_OVER:int = 4; public static const STATE_SYSTEM_NEW_LEVEL:int = 5; public static const STATE_SYSTEM_LEVEL_IN:int = 6; public static const STATE_SYSTEM_GAME_PLAY:int = 7; public static const STATE_SYSTEM_LEVEL_OUT:int = 8; public static const STATE_SYSTEM_WAIT:int = 9; We first set lastSystemState = currentSystemState, so we can have a reference if needed to switch back to previous state. This might occur in circumstances where we need to jump to the STATE_SYSTEM_WAIT state for a period of time and then jump back to the state we were in before the wait. The systemLevelIn function is a good example of this. Once we get to the systemLevelIn function, we want to wait a specified number of milliseconds before removing the levelInScreen from the display. Once the wait is over, the WAIT_COMPLETE event is fired off. The waitCompleteListener function will need to know what the previous systemState was before the wait so it can determine what to do next. We then set currentSystemState = stateval. The stateval was passed when we called the switchSytemState function. This forces the switch/case statement to set the current systemFunction to the function we want to repeatedly call in our loop. We will now start with the first function state the loop calls, the systemTitle function.
The systemTitle function definition
The systemTitle function sets up the display of the title screen and then jumps to a common state used for all button clicks that close the BasicScreen windows STATE_SYSTEM_WAIT_FOR_CLOSE We have not looked at the set of functions that control the STATE_SYSTEM_TITLE, STATE_SYSTEM_INSTRUCTIONS, SYSTEM_LEVEL_IN, and STATE_SYSTEM_GAME_OVER states in detail yet, so let's do that now. There are two basic screen types represented:
- Those that wait for a click of the OK button: titleScreen, instructionsScreen, and gameOverScreen
- Those that wait a predefined time to display the screen before moving on: levenInScreen First, we add an event listener to listen for the OK button clicked event to call the okButtonClickListener function that is shared among all of the screens. After that, we switch the systemState to the constant STATE_SYSTEM_WAIT_FOR_CLOSE. We then set the nextSystemState to be called after okButtonClickListener is fired off. This the first use for one of the three custom event classes we will create:
titleScreen.addEventListener(CustomEventButtonId.BUTTON_ID, okButtonClickListener,false, 0, true);
All of the BasicScreen instances share the same okButtonClickListener function. The custom event passes the id value of the BasicScreen instance to this listening function. The id value is used to determine which screen the button was on and then moves the state machine to a new state based on this evaluation.
The systemTitle, systemInstructions, and systemGameOver functions all look very similar. We'll take a look at those in a bit. First, let's examine the waitForclose and okButtonClickListener functions.
The systemWaitForClose function definition
The systemWaitForClose() function is associated with the STATE_SYSTEM_WAIT_FOR_CLOSE state. It simply does nothing until the OK button on a screen is clicked. This is the simplest function that you will encounter in this book. It does absolutely nothing! It is just a placeholder that the game loop can call while waiting for the OK button to be clicked.
The okButtonClickListener function definition
The okButtonClickListener function is used to determine what to do when an OK button on one of the various BasicScreen instances is clicked. It switches to the nextSystemState when complete. This "listener" function is only fired off when it receives a CustomEventButtonId.BUTTON_ID event.
No matter which OK button was clicked (on any of the three screens that we will define with them), we remove the event listener before we change state. Even though the same listener is used for both the title and the instructions screens (for example), and we remove it from the title screen before adding it again in the systemInstructions function. We do this to be sure we never have extra listeners hanging around. Unused listeners waste memory and can slow down processing. This function shows how we can share a single listener for the OK button click on three different screens (title, instructions, and game over). We switch on the id value passed from CUSTOMEVENT_OK_CLICKED.
No matter which screen we were on, the last line of the function calls the switchSystemState function and passes in the nextSystemState variable.
The systemInstructions function definition
The systemInstructions function is used to display the instructions screen to the user. It is associated with the STATE_SYSTEM_INSTRUCTIONS state. It is called a single time and then processing is passed to the STATE_SYSYEM_WAIT_FOR_CLOSE state. The systemInstructions function is very similar to the systemTitle function. In fact, they are almost identical with a few minor changes. We first add the systemInstructionsScreen to the displayList with an addChild call.
We also setup a listener for the same CustomEvent that the titleScreen used and we switch to the STATE_SYSTEM_WAIT_FOR_CLOSE state. Again, this state does nothing but let the system wait for the CustomEventButtonId.BUTTON_ID on an instance of the BasicScreen class. Finally, we switch to the STATE_SYSYEM_WAIT_FOR_CLOSE on to wait for the OK button to be clicked. We also set the nextSystemState to be evaluated and used once the OK button is clicked.
The systemGameOver function definition
The systemGameOver function displays the gameOverScreen. It is associated with the STATE_SYSTEM_GAMEOVER state and waits for the OK button click shared with the other BasicScreen instances. We take a look at the systemGameover function now, because it uses the BasicScreen instance gameOverScreen in a similar manner as the titleScreen and instructionsScreen instances. The systemGameOver state is set in Main when the Game class instance sends out the simple custom event called GAME_OVER. In the next section, we will see the Main class set up to listen for this event from the Game class.
The sytemGameOver function follows the exact same format as the systemTitle and systemInstructions functions. There is one difference though: it takes care of removing the Game class instance, game, from the display list with a call to the removeChild function.
The systemNewGame function definition
The systemNewGame function is associated with the STATE_SYSTEM_NEW_GAME state. It is called one time and then moves on to the STATE_SYSTEM_NEW_LEVEL state. Its purpose is to add all of the event listeners for communication between the Game class and some other framework classes (such as the ScoreBoard class). It also calls the game.newGame function to allow the Game instance to do its own internal new game related processing. When setting up a new game, we first add our Game class instance (game) to the display list with the addChild function call. This will display the Game.as Sprite (or MovieClip) on the screen. Next, we set up some basic communication between the Game.as and the Main.as classes. We do this by creating four event lsteners. The first two we set up are custom event class instances (classes we will discuss in detail later in the chapter).
The CustomeEventLevelScreenUpdate class allows the passing of a text String instance with the event. The String is used in the Game class to pass the level number (or any text) back to the Main.as class. The Main.as class updates the levelInString variable with the passed in text. We will see this listener function shortly.
The CustomEventScoreBoardUpdate class is used to update the ScoreBoard (another class we will discuss later in this chapter). This event passes data back to the scoreBoadUpdateListener indicating which field on the ScoreBoard to update and what the new value will be. For example: If we wanted to update the player's score, we would pass back the name of the score field (probably "score") and the value of the player's score (example, 5000).
We also create two simple event constants called GAME_OVER and NEW_LEVEL. These will not pass any data back to the listening functions so they will be fired by passing the GAME_OVER or NEW_LEVEL constant into the dispatchEvent function. We do not need custom classes for these types of events.
The systemNewLevel function definition
The systemNewLevel function is associated with the STATE_SYSTEM_NEW_LEVEL state. Its purpose is to call the game.newLevel function and allow the game to start its own internal new level processing. The systemNewLevel function doesn't do much inside Main. It is merely there to call the Game classes' newLevel function. This function will be demonstrated when we get to the simple stub game example. It is used to initialize variables and difficulty for the new level. When it is complete, it switches the system state to STATE_SYSTEM_LEVEL_IN.
The systemLevelIn function definition
The systemLevelIn() function is associated with the STATE_SYSTEM_LEVEL_IN state. It displays a new level message for 30 frame ticks and then moves processing on to the STATE_SYSTEM_GAME_PLAY state. Using systemLevelIn is by no means the only method of forcing the state machine to wait. There are a number of third party custom classes and tools such as TweenMax that can be used for the synchronization of clips and tweens between screens and states. We have added this simple wait state to the state machine for it to be complete framework. The state machine is designed to be easily updated with new states and system functions. Feel free to implement any custom or third-party library or tools that will make your job easier.
The systemLevelIn function is used to allow the developer to display some sort of special text or animation as a precursor to each game level. It employs the use of the STATE_SYSTEM_WAIT state. It is set right after the levelInScreen is added to the display list. The levelInScreen is a BasicScreen instance that does not use the OK button. Instead, it simply waits for the specified waitTime (30 frame ticks in this example) and then fires off the WAIT_COMPLETE simple custom event. The Main class listens for this event and calls the associated listener function. The text on this screen is a combination of the levelInText variable we created in the variable definition section and text passed through the CustomeEventLevelScreenUpdate event. The levelIntext can be set in the init function override of the Main.as (GameFrameWork.as child class). It will be combined with the text passed from the event to create the text on the levelInScreen. We will examine the listener function that does this shortly.
The systemWait function definition
The levelInscreen is very similar to the instructionsScreen, but instead of using the STATE_SYSTEM_WAIT_FOR_CLOSE state, it uses the STATE_SYSTEM_WAIT state. What's the difference? The STATE_SYSTEM_WAIT state calls a function that counts for a specified number of frame ticks before moving on to the nextSystemFunction rather than waiting for the click of the OK button. When the systemState is switched to the STATE_SYSTEM_WAIT state, it calls the systemWait function repeatedly (on each frame tick) until the waitCount is greater than the waitTime set in the systemLevelIn function. When the waitCount is reached, we dispatch a WAIT_COMPLETE event that calls the waitCompleteListener (see the next section). Currently, there is only one systemState that uses the systemWait function, so there is only one item in the case statement. We could add many states that use this systemWait function though, so we have it set up for later expansion. The waitCompleteListener function definition The waitCompleteListener function is triggered when the WAIT_COMPLETE event is fired off from the levelInScreen. It can be used for more screens by updating the switch:case statement.
Once the waitCompleteListener fires off, it switches on the lastSystemState because the currentSystemState is now the STATE_SYSTEM_WAIT. This allows us to share a single listener function for all uses of the WAIT_COMPLETE event. It then switches state to the nextSystemState when it calls switchSystemState(nextSystemState). In this example, the nextSystemState is systemGameplay.
The systemGameplay() function definition
The systemGameplay function is the heart of the gameTimer. It is associated with the STATE_SYSTEM_GAME_PLAY state. The game.runGame function is called on each frame tick when systemGamePlay is the systemFunction reference. The Game class instance (game) will handle all of the game's processing within the game.runGame function. private function systemGameplay():void { game.runGame(); }
The custom event listener functions
The last four functions inside GameFrameWork.as are listener functions for simple and complex custom events that are needed by the Game instance class to communicate with Main class, as well as the levelInScreen and scoreBoard class instances. We'll briefly explain each here so you have a complete version of all the Main.as code in one place. Their use inside those classes will be examined later as we go through the Game->ScoreBoard, and CustomEvent classes.
The scoreBoardUpdateListener function definition for Main.as
The scoreBoardUpdateListener receives updates from the Game class instance that are passed to the ScoreBoard through a CustomEventScoreBoardUpdate instance. The scoreBoardUpdateListener passes data, represented by a simple key/value pair of String object class instances to the ScoreBoard class instance. The element variable will contain a string value representing a constant that we will define in the Main.as (GameFrameWork.as child class). The constant will be the id string name of the element on the scoreBoard to update. The value variable passed will be a string representing the value to show on the scoreBoard for the corresponding TextField. It's constructed to allow the Game class instance and its associated classes to update the ScoreBoard class instance without having to maintain a reference to it. This allows the Game and its associated classes to remain decoupled from the Main.as and the basic framework classes. We will see the same thing with the levelInScreen a little later. Why is the ScoreBoard part of the framework and not part of the Game class? We wanted to have the ScoreBoard be part of the Main class game framework because the Game class instance is not the only object that might interact with the ScoreBoard. We do not implement it in this simple example, but the Main might have other data such as a system-held high score, links out, or even a frame counter in the ScoreBoard.
Why decouple the scoreboard from the game class instance? It is true that we could make calls directly to the ScoreBoard from Game by using the root or parent attribute of the Game class. While this is certainly possible, if we decouple the Game class from the ScoreBoard class, then the Game class will be reusable across multiple frameworks (even your own) with no need to use our framework. The new framework would just need its own ScoreBoard or the Game would need to implement its own.
The levelScreenUpdateListener function definition for Main.as
The levelScreenUpdateListener allows the Game class to update the text on the levelInScreen. Like the scoreBoardUpdateListener, the levelScreenUpdateListener function is used to pass data from the Game class instance to the levelInScreen. When the Game class updates the level value using its own newLevel function, the levelInScreen must also update its text so the correct level number will be shown on the screen during the systemLevelIn function. The predefined default String variable, levelIntext will be combined with the passed in value:
levelInScreen.setDisplayText(levelInText + e.text);
The gameOverListener function definition for Main.as
The gameOverListener listens for the Game.GAME_OVER simple custom event and then changes the framework state accordingly. When the Game class instance fires off the GAME_OVER simple custom event, the Main listens for it and runs this function. It cleans up all of the game-related listeners by removing them and then changes state to the STATE_SYSTEM_GAME_OVER state which was discussed earlier
The newLevelListener function definition for Main.as
The newLevelListener listens for the Game.NEW_LEVEL simple custom event and changes the state accordingly. The newLevelListener listens for the Game class instance to fire off the simple custom event, NEW_LEVEL. It then changes the systemState to the STATE_SYSTEM_NEW_LEVEL state.
Framework classes beyond Main
The framework does not rely on FrameWorkStates and the GameFrameWork classes alone. We are now going to define and explain the classes that make up the BasicScreen (and its helper classes), ScoreBoard, and the custom event classes. We have discussed all each of these briefly in the GameFrameWork.as class description. Now, we take a look at each in greater detail.
The BasicScreen class
All of the simple screens in this basic game framework are created using a very simplified BasicScreen class. The BasicScreen class can become a parent class for more elaborate screens, but in the basic framework, it is very simple. Each screen contains some text positioned on the screen, an OK button if needed and a background color. That is all. If the OK button is needed, there is an event inside the BasicScreen class that is fired off, and it, in turn, fires off its own event to tell GameFrameWork class that it has been clicked. This makes use of a custom event class instance (okButtonClickListener) that we will create in the next section. You should save this class file in the folder structure we created earlier in the chapter to correspond to the framework package.
Here is entire code listing for this class.
Class import and variable definition section for BasicScreen
The class import section imports the necessary core Flash classes we will see in action shortly. The one custom class the BasicScreen class makes use of is the CustomEventButtonId class. We will dissect this class in detail later in the chapter, but for now, know that we dispatch an instance of it if the OK button is clicked on any of the instances of this BasicScreen.
The variable definition section of the BasicScreen class creates variables to hold data for the three optional pieces of the BasicScreen:
- The background color BackGroundBitmapData, which is associated BackGroundBimap
- The text to display on the screen, displayText
- The button that will fire off the CustomEventButtonId when clicked, which is an instance of another framework custom class we will create called SimpleBlitButton All three of these optional items are set with public functions inside the BasicScreen class. The Main.as class we create for each unique game will customize the BasicScreen instances by passing values to these public functions inside its init function override of the GameFrameWork's init function. One of the most interesting things about this BasicScreen class is the way we are creating this background for the OK button. We decided not to import or embed any external assets for this first game, because it would necessitate explaining how to do it in both the Flash IDE and Flash Develop (with the open source Flex SDK), and it's too early in this book for that discussion. Instead, we have created a very simple custom button class called SimpleBlitButton. The instance name for this button is okButton. We will discuss this class in detail in the SimpleBlitButton class deinition.
The final variable we need is the id integer. This is passed into the BasicScreen instance from Main. It is used in the switch:case inside the GameFrameWork classes' okButtonClickListener function to change state based on the screen whose OK button was clicked.
Class constructor function definition
The constructor for the BasicScreen class accepts in the basic information needed to set up a screen for display. A screen needs an id value passed in as an integer, as well as the information needed to create the background color for the screen. This is done by passing values needed to customize the backGroundBitmapData variable that was created in the variable definition section. A BitmapData instance needs these four pieces of data passed:
- A width
- A height
- A Boolean (true/false) value to indicate whether or not the BitmapData will use transparency
- A color represented as an unsigned integer (uint). A completely transparent background can be set for a screen by passing in true for the isTransparent parameter and a 32-bit color value with an alpha channel set to 00. Colors are represented as AARRBBGG where the alpha (AA) values ranging from 0x00 (0) (completely transparent) to 0xFF (255) (completely opaque) can be passed in. The init function is used to set up the field for the display text (displayText) and the OK button (okButtonSprite). The OK button is added only if the passed in okNeeded is set to true.
The first actual line of code might be a little cryptic:
textformat1.align = flash.text.textFormayAlign.CENTER
When we set up the textFormat1 variable, we didn't set the alignment to center because not all uses of it will be centered. We can change the alignment on the fly, and we do so here before we apply it to the displayText field as its defaultTextFormat. Then, we simply add the text to the screen. In the first init call, there is no text to actually add to the screen. It is added with the setDisplytext function described next. The setDisplayText function is public and is called by the Main class when the BasicScreen instances (title, instruction, game over, and so on) are placed on the display list. This allows the text for the screen to be customized for each showing.
The createDisplayText function definition
By calling the createDisplayText function on a BasicScreen instance, we can turn on a


text:
Summaries of EU Legislation
Summaries of EU legislation: direct access to the main summaries page.
- Archived: true
Debate on the eco-labelling of fisheries products
At the end of June 2005 the Commission launched a debate on a Community approach towards eco-labelling schemes for fisheries products. It evaluates the current situation as regards eco-labelling and puts forward objectives, accompanied by available options for the level of regulation by the public authorities.
Commission Communication to the Council, the European Parliament and the European Economic and Social Committee - "Launching a debate on a Community approach towards eco-labelling schemes for fisheries products" [COM(2005) 275 final - Not published in the Official Journal].
The need to discuss eco-labelling * schemes was first addressed in a Commission Communication on the Future for the Market on Fisheries Products in the EU in December 1997. However, no progress was made on the issue due to differing views on how a common approach should be implemented. The importance of ensuring more sustainable exploitation of the marine environment has since increased considerably with the introduction in 2002 of the reformed Common Fisheries Policy. As consumers are demonstrating a growing interest in these labels and as significant progress has already been made, eco-labelling seems to be one way of further integrating the environmental aspects of the Common Fisheries Policy. The progress made as part of this policy opens up the issue of eco-labelling schemes.
The recent increase in the number of eco-labelled products creates difficulties in terms of competition, trade and consumer protection policies and has put the issue back on the agenda.
International momentum has also been created with the adoption of the United Nations Food and Agriculture Organisation (FAO) guidelines on "eco-labelling for fish and fisheries products from marine fisheries" and attention should be given to the work in the FAO and the World Trade Organisation (WTO) on this issue.
Existing eco-labelling schemes
Existing schemes use different certification criteria, and in some cases are liable to cause market access problems. There prove to be reserves on the part of developing countries which fear their products may be excluded from the markets of developed countries. Furthermore, it is not always easy to ascertain the credibility of environmental claims displayed on the labels and the criteria used for issuing the label.
Work on eco-labelling in international fora
Despite the commitment under the Doha Development Agenda, the debate within the WTO has still not resulted in a better synergy between trade, development and environment policies. However, the FAO Committee on Fisheries adopted guidelines for eco-labelling at its 26th meeting in March 2005. The Commission was involved in drawing up these guidelines and fully supports them.
Objectives of a Community approach
The Commission considers that eco-labelling must stimulate consumer awareness of the environmental dimension of fishing and thereby give managers in the sector the financial incentive to go above and beyond the requirements of existing ecology rules. The Community policy should ensure:
- sustainable fisheries and an adequate level of protection of the ecosystem;
- a harmonised approach throughout the Community;
- transparent and objective information for consumers. Information must be clear and verifiable in accordance with the consumer protection policy;
- fair competition;
- labelling schemes are not prohibitive for small and medium enterprises or developing countries.
Possible levels of regulation
The Commission feels there are three options. The public authorities therefore have the choice between:
- non-action;
- creating a single Community eco-labelling scheme;
- establishing minimum requirements for voluntary private and/or public eco-labelling schemes.
Having assessed the advantages and disadvantages of each option, the Commission is in favour of the third one as it would offer enough flexibility and would be proportionate in terms of costs. It would also offer an appropriate level of consumer protection.
The key points of the assessment carried out by the Commission include:
- The cost in terms of the administrative resources needed for action by the public authorities, and the expertise needed within the public authorities to take this action.
- Ease of access to the schemes for small and medium sized enterprises and developing countries.
- The transparency, credibility and reliability of the assessments carried out by eco-labelling schemes.
- Integration into a certification procedure carried out by a third party.
- The risk of market distortion, or even fragmentation, and restrictions on the free circulation of goods and on market access.
- A division between private sector initiatives and public sector regulatory activities.
- The flexibility of the schemes and therefore their ability to adapt their requirements to any developments without being discriminatory.
- The coherence between various schemes which apply different criteria for awarding their eco-label, such as ecological stock management, protecting the ecosystem or the fishing technique used.
The debate
Before arriving at a real Community approach to eco-labelling a debate must be held on some key questions, such as:
- What should an eco-labelling scheme certify?
- How to ensure a non-contradictory approach whilst simultaneously offering a high degree of voluntary participation and feasibility?
- How to use fully the potential of schemes to promote sustainable fisheries, while yielding real benefits for fishermen, processors and consumers?
- Should the approach be more result oriented or means oriented?
This Communication invites the Council, the European Parliament, the Economic and Social Committee, the members of the European Economic Area and all interested parties to participate in the debate on a Community eco-labelling policy.
As a result of to the debate the Commission may be able to put forward appropriate legislative proposals.
Key terms used in the act
- Eco-labelling: an eco-labelling scheme under which a product can bear a distinctive logo or statement by which consumers are assured that the product in question has been produced according to a given set of environmental standards.
Communication from the Commission to the Council and the European Parliament of 16 December 1997 - The future for the market in fisheries products in the European Union: responsibility, partnership and competitiveness [COM(1997) 719 final - Not published in the Official Journal].
Communication from the Commission of 28 May 2002 setting out a Community Action Plan to integrate environmental protection requirements into the Common Fisheries Policy [COM(2002) 186 final - Not published in the Official Journal].
Last updated: 20.10.2006

subset: commoncrawl


text:
Nats' taxed bullpen gets break in series finale
Williams had considered pitching Roark had Strasburg endured short start
By Andrew Simon / MLB.com
WASHINGTON -- When Nationals right-hander Jordan Zimmermann lasted only 1 2/3 innings in his start on Wednesday night against the Marlins, it put the club's bullpen in a tough spot. If Washington's relievers had needed to soak up significant innings again on Thursday, it would have forced manager Matt Williams into some difficult decisions.
Fortunately for the Nats, that didn't become an issue, as Stephen Strasburg was efficient in shutting down the Marlins over 6 2/3 strong innings of a 7-1 win. Jerry Blevins and Aaron Barrett -- the only two Nats relievers not to pitch on Wednesday -- followed Strasburg, and Rafael Soriano closed it out.
Long man Craig Stammen, who tossed 3 1/3 innings the night before, likely was unavailable for the game, according to Williams. Setup men Drew Storen and Tyler Clippard already had pitched two days in a row, and Williams also preferred not to use lefty Ross Detwiler for a second straight day.
In the event of a short start by Strasburg or a long extra-inning game, Williams would have considered turning to righty Tanner Roark as a long reliever, even though Roark is scheduled to start on Friday in Atlanta.
"We have the ability to go to Tanner, if we have to," Williams said before the game. "We hope that's not the case. If we do, he would be available potentially for us long if it gets to that. The best-laid plans are that that doesn't happen. [Soriano's] good. The back end of the bullpen is good. They're taxed, but they're good. But if it gets to a situation like we had yesterday, then our long guy today, we'd look to Tanner, potentially."
Had that become necessary, the Nats would have considered bringing an extra pitcher to Atlanta for Friday's series opener there. However, Williams said after Thursday's win that no roster move was in the works.
"We're good," the manager said. "We made it through today, and I think we'll be OK."
After remaining in the bullpen on Thursday, Detwiler still has not pitched in back-to-back games in his career. Before the game, Williams had sounded reluctant to use the converted starter in that way.
"We'd like to stay away from him if we could," Williams said. "But you don't know what's going to happen in the course of a game. So we'll evaluate that at the time. In a perfect world, I wouldn't want to get him in a game today, but you never know."
Detwiler, who has pitched five scoreless innings across three appearances this season, said that he would be ready to go on consecutive days, as long as he felt good after playing catch before the game.
"You just have to communicate," Detwiler said. "It's never, 'Oh, I'm good to go today.' You're always up until you tell them you can't go."
Back at third, Zimmerman works on sidearm motion
WASHINGTON -- Ryan Zimmerman was in the Nationals' lineup at third base for a second consecutive game on Thursday after sitting out on Tuesday with right shoulder soreness.
Manager Matt Williams was pleased with how Zimmerman looked in the field in his return, and he had no qualms about putting the third baseman back out there again in the series finale against the Marlins. For the second straight day, Zimmerman completed some early work at third base, utilizing a more sidearm motion designed to alleviate any pain in his surgically repaired shoulder.
"I thought he was good. Got challenged right away," Williams said. "No ill effects. He reported today that he felt good. We went through another session today out there and he's got no issues, which is good. So hopefully that little adjustment will take some pressure off the shoulder."
In the fifth inning of Wednesday's game, Zimmerman was faced with the type of play that his given him trouble, as Casey McGehee hit a grounder that forced him to back up, field the ball backhanded and make a long throw across the diamond. It appeared that Zimmerman was caught somewhere in between an overhand and sidearm release, and the result was an awkward throw that one-hopped first baseman Adam LaRoche, but it still was in time to get the runner.
Earlier in the game, Zimmerman looked smooth in moving to his left to cut off a slow grounder from Adeiny Hechavarria, spinning and whipping a strong sidearm throw to first.
"Pace of game, runner, all of that stuff will dictate what he wants to do," Williams said. "We're working on the routine. It's a function of his work, so going out taking ground balls, doing all the things he does every day, we just don't want to inflame [the shoulder] again, so we change a little bit of an angle. It's not that big of a change, but it just takes a little pressure off, so he can go ahead and get his work done, do all the things he wants to do without having any pain. And then instinct will take over in the game anyway."
Span gets to rest, McLouth hits leadoff
WASHINGTON -- Nate McLouth, still looking for his first hit as a member of the Nationals, got his second start of the season -- and first in the leadoff spot -- as manager Matt Williams continued to shake up his lineup on Thursday.
Williams said that there is nothing wrong with usual center fielder and leadoff man Denard Span, but with the Nats in an early stretch of 20 games in 20 days, the manager wanted to give Span a rest.
"We've got a stretch of games here with no off-day, so it's just a day [off]," Williams said. "Certainly have to get Nate in there and get him some ABs, too. No issues though. [Span's] good."
McLouth signed a two-year, $10.75 million deal this winter to serve as the Nats' fourth outfielder after logging nearly 600 plate appearances last season with the Orioles. He came into Thursday 0-for-5 with two walks, having made his first start on Sunday in the No. 7 spot in the lineup.
Meanwhile, Williams moved Bryce Harper from seventh in the order back to sixth after Harper broke out of a slump by going 2-for-4 with a home run and three RBIs on Wednesday.
So far this season, Williams has used eight different batting orders in nine games. He's yet to use the same one in back-to-back games.
Worth noting
• Nats right-hander Doug Fister, rehabbing a right lat strain, threw off flat ground on Thursday. According to Williams, he "came through it well," and the righty could throw a bullpen session on Friday.
Andrew Simon is a reporter for MLB.com. Follow him on Twitter @AndrewSimonMLB. This story was not subject to the approval of Major League Baseball or its clubs.


text:
Asche moved up as Sandberg changes lineup
By Todd Zolecki and Austin Laymance / MLB.com
PHILADELPHIA -- Manager Ryne Sandberg tinkered once more with the Phillies lineup on Saturday at Citizens Bank Park. And the changes paid off, as the Phils had 13 hits in a 12-1 victory over the Reds.
Sandberg kept Jimmy Rollins and Carlos Ruiz in the top two spots for the second consecutive game with Ben Revere sidelined with a stomach virus and carrying a .289 on-base percentage in the leadoff spot, which is 24th out of 26 hitters with 100 or more plate appearances in the top spot this season. Sandberg also moved up Cody Asche to sixth after hitting eighth in his previous 27 starts this season.
"I was impressed with [Asche's] at-bats last night," Sandberg said before the game. "Driving the ball, quality at-bats, nice aggressive swings. I want to try him in the sixth spot. I like the way he's going about things, working on things and applying it. Kind of a grind-it-out attitude."
After going 2-for-4 with three RBIs on Saturday, Asche is now hitting .318 (14-for-44) with five doubles, two home runs and nine RBIs in 13 games this month. He also has a .752 OPS for the season, which is higher than Ryan Howard (.750), Domonic Brown (.596) and Revere (.581).
Brown had hit sixth in 34 of his 36 starts this season, but he dropped to seventh. He responded on Saturday with just his second homer since last August and drove in a career-high five runs.
"A lineup creates scoring opportunities, then it comes down to execution and a big at-bat and a swing to drive in one run or maybe two or three," Sandberg said. "That's the one punch that we want to see. That's what we need to get us over the hump and get us going. There are multiple guys in the lineup that could be that guy. I don't think it's one person."
Hamels strikes out side in third on nine pitches
PHILADELPHIA -- Phillies left-hander Cole Hamels has had his way with the Reds over his career.
Hamels improved to 9-0 with a 1.49 ERA in 12 career starts against Cincinnati, including a shutout in Game 3 of the 2010 National League Division Series. He allowed three hits, one run, two walks and struck out 10 in seven innings Saturday in a 12-1 victory over the Reds at Citizens Bank Park, the 100th win of his career.
Hamels struck out the side on nine pitches in the third inning: Zack Cosart, Brandon Phillips and Todd Frazier. Five of the strikes were swinging, including all three third strikes.
"I didn't know until someone told me," Hamels said. "You're just trying to plug away, throw strikes and get through the inning. I know A.J. [Burnett] and I have done it [this season], so we might have to push so Cliff [Lee] might be able to do it someday."
"I know he's not off to a great start this year and he started on the DL, but he's back," Reds manager Bryan Price said. "That's what our scouting report said. He looks like the regular guy -- good velocity, both sides of the plate, all the accoutrements. He's got the cutter and the change and the curveball and the good fastball command. And he pitched a good game."
Hernandez to rejoin rotation as fifth starter
PHILADELPHIA -- Roberto Hernandez is proving to be a valuable piece in the bullpen for the Phillies, but he'll be back in the rotation next week. Such is the life of a fifth starter with experience as a reliever.
With the Phillies using a four-man rotation in the short-term, Hernandez has made two relief appearances since making 99 pitches in a start against the Nationals on May 4. Manager Ryne Sandberg seems to trust the right-hander out of the bullpen, as both of Hernandez's appearances have come in the ninth inning.
Hernandez tossed a scoreless ninth against the Reds on Friday with the Phillies trailing, 3-0. Clinging to a lead last Sunday in New York, Sandberg asked Hernandez to get out of a jam left behind by Antonio Bastardo.
"He's got his stuff right from the get go," Sandberg said of Hernandez, who is 2-1 with a 4.19 ERA in seven starts. "He gets to let it all hang out there for one inning and he's got a lot to offer. He gets some tough swings, but he's got good movement on his stuff all around the zone. So as far as coming out and throwing strikes, he's been very good at that."
Phillies management still prefers Hernandez to be in the rotation, and he's scheduled to start Friday against the Dodgers. The organization doesn't have many options to replace Hernandez as a starter. Jonathan Pettibone is on the disabled list in Triple-A due to a shoulder issue.
General manager Ruben Amaro Jr. said Pettibone was examined by team physician Michael G. Ciccotti and given a couple of options -- likely including surgery -- but is seeking a second opinion on Wednesday from Dr. James Andrews in Pensacola, Fla.
Pettibone has a history of shoulder problems. He was on the disabled list for the final two months of last season and had a setback during Spring Training this year.
Worth noting
• Phillies shortstop Jimmy Rollins singled in the first inning for the 2,212th hit of his career. It moved him past Hall of Fame outfielder Ed Delahanty into sole possession of third place on the Phillies' all-time hits list. He is five shy of Richie Ashburn (2,217) for second place.
• Right-hander Ethan Martin, the Phillies No. 8 prospect according to MLB.com, was reinstated from the 15-day disabled list on Thursday and optioned to Triple-A Lehigh Valley. Martin began the season on the DL after experiencing shoulder inflammation during Spring Training.
Todd Zolecki is a reporter for MLB.com. Austin Laymance is a reporter for MLB.com. This story was not subject to the approval of Major League Baseball or its clubs.


text:
Spring training: Giants 10, A's 6
The Giants' offensive struggles at home the previous two nights may very well have been related adjusting to night baseball. Because on Saturday afternoon in Oakland, the Giants broke out for 10 runs and 12 hits in a 10-6 win over the A's.
John Bowker, Eugenio Velez and Pablo Sandoval each belted two-run home runs and Nate Schierholtz went 3 for 5 with two doubles.
Jonathan Sanchez threw four innings of one-hit ball. Jeremy Affeldt, Brandon Medders and Dan Runzler followed with scoreless innings, giving up just one hit between them.
The A's tallied five runs in the ninth. Alex Hinshaw, who will open the season at Triple-A, gave up four runs on no hits, believe it or not. He walked three hit and hit one. Felix Romero came in with the bases loaded and allowed all three runs to score.
The Giants will complete their exhibition schedule with 12:05 p.m. game Sunday at home against the Mariners. Todd Wellemeyer will start for the Giants.


text: My left arm (I'm right handed) looks absolutely dead when I hit. Watching some vids of myself, I notice that my left arm goes down and in on forehands instead up up and away. On backhands (one handed) I forget to spread my left arm back. I know I need to remember to do this but when I'm focused on the ball I fail to do so. Any tips on how to ingrain proper left arm motion? Thanks.


text:
IMPORTANT NOTICE: The SE 7.2.x release is expected to take LONGER; please click for more info… (more)
Skip to content
Are you sure you want to delete all cookies set by this board?
Need Forum Help? Check out our Product Knowledgebase. eMail your questions to: Forum Administrator
Online Repair Information: ProDemand | ShopKeyPro
Powered by phpBB® Forum Software © phpBB Group
Cerulean Style by Daniel St. Jules of Gamexe.net


text:
Like us on Facebook
SUPzero Forums
- sup master instructor course from the Italian Federation for Amateur Paddling: October2016-June2017 » You should check out the ACA SUP program, as it sounds kinda similar...
- Waterblading - Send your Pics » bounce...
- Show us your SUP fish pics! » Extra Wide SUP for Fishing WideSUPfor2-2-3... (SUP Fishing)
[please login to make this ad block disappear]
Nov 23
Himalayan River Fest
The NEW Himalayan River Fest will be held in Nepal on the 23rd – 25th 2012 November To enter...
The NEW Himalayan River Fest will be held in Nepal on the 23rd – 25th 2012 November To enter...
- 1 attendee
- Hosted by kayakmaila
- More
- Liked 0
- The NEW Himalayan River Fest will be held in Nepal on the 23rd – 25th 2012 November
To enter please email [email protected]Organizer: Himalayan River Fest
Mail: click here
Phone: +977 9841447561Contact: Himalayan River Fest
Mail: click here
Phone: +977 9841447561
Mail: click hereExtra Info:
Series: International
Date & TimeNov 23 2012 at 00:00 - Nov 23 2012 at 23:59 UTC
Location & full addressNepal, Fishling, Trisuli River
Event Adminskayakmaila
See the AUP for our Acceptable Use Policy and a Privacy Statement. Verein Playak is responsible for all editorial content on this site (including all graphics). No part of this site may be duplicated in any way without explicit permission from Verein Playak. Verein Playak takes great care to only publish original content, but since part of the content is user generated, we cannot always guarantee this 100%. If you notice any copyright violations, please let the editors know through the contact form and they will take appropriate action immediately. As a news and information platform, we republish small text snippets and thumbnail images, but always link to original content on other sites, and thus aim to adhere to a 'Fair Use' policy. If you believe we violate this policy in any particular case, please contact us directly and we'll take appropriate action immediately.


text:
Wind River Range > Mitchell Peak > Climber's Log
Mitchell Peak Climber's Log
[ Sign the Climber's Log ]
|Up I Go
|07/23/14 Climbed North Face Center 5.9 with Nick Gaddy
|Posted Jul 25, 2014 11:34 am
Date Climbed: Jul 11, 2013
|Great hike and breath taking views. The hubs and I researched Finis Mitchell before we went. Made the experience even more special. :)
|Posted Jul 14, 2013 5:33 pm
|Ryan Borzea
|Awesome Area!
Date Climbed: Jul 11, 2013
|Great peak! Set up base camp at Big Sandy Lake, summited Mitchell the next morning. Amazing view of the Cirque of the Towers!!!
|Posted Jul 14, 2013 5:28 pm
Date Climbed: Aug 6, 2008
|Awesome scramble with my bud Boone.
|Posted Oct 14, 2012 1:14 am
|Scramble up west slopes. If west slopes is used for descent, make sure to mark the couloir that was ascended before you navigate the flat top to the summit. Seen from Texas pass, this is one of the most impressive mountains I have seen anywhere in the world.
|Posted Feb 23, 2011 8:12 pm
|Bitchell Peak?
Date Climbed: Jul 14, 2010
|We hiked to the Cirque in the morning and decided to attempt Mitchell along our route back to our campsite. Rather than lose elevation and hit the standard path, we went up...and up...and up, along the rocks and grass facing the Cirque. Not sure if this route actually saved our legs or killed them. Finally reached the last pitch and raced up the last 200 ft or so. Coming down, we again chose a "shortcut" to our campsite...followed by the 6 mile hike back to Big Sandy trailhead. Long day, and lots of battle scars and blisters. Well worth it for the views!!
|Posted Jul 20, 2010 3:39 pm
|Scrambled Legs
Date Climbed: Jul 14, 2010
|Up from Jackass Pass and down to North Lake from the west side. Breathstealing views of the Cirque. Camped at North Lake... Beware of mosquitoes in July!
|Posted Jul 20, 2010 2:26 pm
|North Face, Left (5.7)
Date Climbed: Jul 25, 2009
|Climbed the North Face, Left (III, 5.7), with Levi, Matt J., Glenn and Matt L. This was our second day in the Cirque. After Pingora's S. Buttress, this route was a lot more adventurous, complete with loose rock, mud-filled cracks, moss and confusing routefinding. The last pitch chimney nearly ate us alive.
We didn't continue to the true summit a LONG ways away, but managed to get down to Jackass Pass a few minutes before a massive thunderstorm rolled in.
|Posted Feb 5, 2010 3:54 am
|Back in the day
Date Climbed: Aug 3, 1980
|I'm pretty sure this is the peak I hiked up with two friends from High School. We camped at the base of the Cirque and then Hiked up. I remember the stunning views of the Cirque from the summit.
|Posted Jul 11, 2009 8:16 pm
|South Slopes
Date Climbed: Aug 13, 2008
|Climbed from south slopes... Was a beautiful day and the views from the summit are phenomenal in all directions!
|Posted Aug 15, 2008 3:47 pm
|South Side
Date Climbed: Sep 4, 1988
|Great view of the Cirque. Climbed East Temple the next day.
|Posted May 9, 2008 7:36 pm
|West Couloir
Date Climbed: Jul 31, 2007
|Sketchy couloir coming out of Jackass pass. Beautiful!!!
B&W video taken near the summit...
|Posted Oct 14, 2007 6:28 am
|mtn runr
|From the South
Date Climbed: Aug 14, 1981
|Climbed this peak with my wife. We were vaguely aware of distant thunder but paid it scant attention until, coming around an exposed section, my wife's long hair went shooting up above her head in a flow of static energy. I reached my arm out over the edge and I swear I could hear my arm hairs crackling. We hunkered down and sat on our packs for half an hour before proceeding to the summit. (Lightning never did go off near us.)
|Posted Apr 10, 2006 9:44 pm
|Route Climbed: South Slopes Date Climbed: July 2, 1989
|Climbed with my father and the Wasatch Mountain Club. Summitters from the Club were my father, Steve Neggler, and myself. There was lots of snow and MOSQUITOES, but still a nice climb.
|Posted Apr 21, 2005 10:35 pm
|Route Climbed: North Face, Center - Ecclesiastes, IV 5.9 Date Climbed: August 22nd 1996
|Long, fun climb on a big, big wall.
|Posted Apr 9, 2005 2:05 pm
|Dave Dinnell
|Route Climbed: South Slopes Date Climbed: July 1991
|Climbed up from Jackass Pass with my wife. Great views of the Cirque!
|Posted Feb 10, 2005 10:53 pm


text:
Does anyone know of a good book for quilting as you go with lots of pictures and step by step instructions. I have watched some youtube video but computer in the kitchen and sewing room to far to run back and forth. I need all that youtube stuff in a book. Been making string quilts and think that would be a good quilt as you go project since the blocks are all uniform size. I will pay just about anything for a book that will help me.
Evelyn in Sequim WA


text:
Posts Tagged ahtletics
Tufts in the Quidditch World Cup
Posted by Georgy Cohen in Uncategorized on November 11, 2010
The 4th annual Quidditch World Cup will take place on November 13 and 14, 2010 in New York City's DeWitt Clinton Park. The World Cup is an international event including 46 teams — including Tufts — from the United States and Canada.
Quidditch is an actively growing intramural sport that has spread to Tufts University through the Harry Potter Society in 2009.
Here's a first person look at Quidditch through the eyes of a seeker.
Seeker Cam – Tufts Quidditch vs. Brandeis from Arlin Ladue on Vimeo.
Follow the Tufts team via Twitter or their Facebook group. You can also view some past coverage of the team on Jumble.


text:
Skip to page content
In an area of many square miles here in western Cyprus, there seems to be just one particular small outcrop of soft chalky rock where some creatures have obviously had their colony for many years.
The first three photos show how the rock is riddled with their holes (the middle photo has a wrist watch for scale).
It looks like they excavate the holes then build cells within them, the cell walls being made of the same material (presumably chewed-up and mixed with fluid by the creatures).
For two years I have wondered what creature might have made the holes and cells. Today, I finally spotted them. They are mid-sized brown bees.
I was able to get only bad photos of the bees, sorry.
I would be very pleased if somebody could ID this bee species - thanks in advance.
I guess there is a possibility that these are mason bees. As I understand it, mason bees use existing holes rather than make new ones.
If these are mason bees, and they did not create the holes, what did?
Well, if nobody else is going to help me!...
I'm fairly sure this is a plasterer bee, Colletes sp.
That is one genus in the Colletidae, commonly called plasterer bees or polyester bees because they build cells in underground nests that are lined with a polyester secretion, giving an almost pearly lustre. That is visible in my photos.
Just two of the 54 genera occur in Europe - Colletes and Hylaeus. The latter looks different and normally nests above ground, hence I consider the genus of 'my' species to be Colletes. Also, the whitish banding on the abdomen is fairly characteristic of Colletes.
This photo of C. daviesanus shows the nesting holes, including the pearly lining - very similar to my photos -
I am not trying to identify to species level because my photos are inadequate and 'there are numerous species ... difficult to determine without dissection' (http://www.eakringbirds.com/eakringbirds3/insectinfocuscolletesdaviesanus.htm).
However, I note the following species are recorded from Cyprus:
- C. cyprius (http://www.nhm.ac.uk/resources-rx/files/checklist--bibliography-palaearctic-and-oriental-colletes-27444.pdf)
- C. brevigena (http://www.discoverlife.org/mp/20l?id=AMNH_BEES33942)
- C. carinatus (recorded from Turkey, Israel and Egypt, but I have no actual records from Cyprus itself)
- C. hylaeiformis (http://www.discoverlife.org/mp/20q?search=Colletes+hylaeiformis&guide=1&cl=AJ&flags=HAS:)
- C. maidli (http://www.discoverlife.org/mp/20l?id=AMNH_BEES34577)
- C. similis (http://www.discoverlife.org/mp/20l?id=GBIF209294712)
- C. squamulosus (http://www.discoverlife.org/mp/20l?id=GBIF209294864)
- It is not Colletes hederae (known from Cyprus) because that flies later in the year (when ivy is in flower) (http://en.wikipedia.org/wiki/Colletes_hederae).
- Colletidae - http://en.wikipedia.org/wiki/Colletidae
- Colletes - http://en.wikipedia.org/wiki/Colletes
- Discover Life - database search for Apoidea - http://www.discoverlife.org/mp/20q?guide=Apoidea_species&flags=HAS:&cl=AJ


text:
These days, as Palo Alto basks in its status as a global leader on climate change and technological innovation, officials have different priorities. Under a new model for partnerships that the City Council discussed Monday, the city's new international partners will function less like siblings and more like business partners. Bonds will revolve around "mutually established metrics" relating to entrepreneurship, information technology, online public services and "smart mobility." Coordination would come from the city manager's office rather than Neighbors Abroad, the nonprofit organization that has been managing the city's cultural-exchange program. And unlike the sister relationships, these new partnerships wouldn't last forever. Economic Development Manager Thomas Fehrenbach described the relationships as "more nimble and less permanent" than existing ones.
Not coincidentally, Palo Alto's new partners tend to have more in common with the city than its sisters. In November, the city entered into its first "Smart City" partnership with Yangpu District of Shanghai, China, an area that is transforming from a garment district to a technological hub and that counts VMWare among its major employers. Since then, staff and several council members have traveled to Yangpu to tour business campuses and meet with government officials. More recently, six Palo Alto High School students took a trip to Yangpu as part of an exchange program.
Vice Mayor Nancy Shepherd, who traveled to Yangpu and who is on a steering committee that is organizing the "Smart City" conference in China, praised the student program. The youth, she said, got to learn Mandarin and received a "global introduction to economics," which she called "very useful."
"I see nothing but other good experiences that we'll have as we pursue this further," Shepherd said Monday, moments after she made a motion to enter into a "Smart City" partnership with Heidelberg, Germany. Like Palo Alto, the German city brands itself as a global leader in sustainability and climate protection.
"I think we have a natural synergy with Heidelberg, Germany, because of our interests in green technology," Shepherd said.
The council approved on Monday a partnership with Heidelberg and agreed to explore a student fellowship program that would involve Stanford University as well as the city of Espoo, Finland, and the University of Aalto in Espoo. The idea is for the two cities to simultaneously create graduate-student programs with their respective universities focusing on "government innovations and entrepreneurship," according to a staff report.
The council praised both ideas, though members were less enthusiastic about two other staff proposals, one that would have sent a council member to represent the Bay Area Council at the U.S.-China Collaboration Symposium in October and another one that would direct staff to explore adding "Smart City" components to existing relationships with sister cities.
The council voted 7-2, with Shepherd and Liz Kniss dissenting, to approve the Heidelberg partnership and exploration of the Espoo fellowship program. Shepherd and Kniss backed the entire package of staff recommendations, including working with Neighbors Abroad to modify existing Sister City partnerships.
Councilmembers Karen Holman and Larry Klein both warned against trying to do too much at once. Holman said it would be "prudent for us to do this in a phased manner." Klein said that before the city goes further it needs to answer two questions: What are we trying to accomplish? What would success look like?
"Yangpu and Heidelberg are two big pieces," Klein said. "Until we see what they do, I don't see why we should start thinking even bigger."
He was also skeptical about introducing "Smart City" concepts to existing sister cities, many of which are not in a position to exchange information about best practices with Palo Alto.
"With Heidelberg, we're dealing with a peer city, for example," Klein said. "Palo and Oaxaca are certainly not peer cities economically. So if we wanted to do something with them and we can't be a peer, are we just trying to help them out? To sort of be a donor? Those are questions to be answered before we start spending lots of staff time or any other resources of the city on this."
The goal of Palo Alto's non-binding agreement with Heidelberg is to "exchange ideas and value, especially in areas of environmental sustainability and innovation-driven economic development," according to the agreement. Once the two cities build a "strong foundation, we will seek to create mutual programs with measurable results."
"These programs will target the areas of sustainable practices and community engagement, as well as the development, market introduction, and application of new technologies," the agreement states.
This story contains 840 words.
Stories older than 90 days are available only to subscribing members. Please help sustain quality local journalism by becoming a subscribing member today.
If you are already a subscriber, please log in so you can continue to enjoy unlimited access to stories and archives. Subscriptions start at $5 per month and may be cancelled at any time.


text: Here's the difference for me. At the end of "Basics, Part II," the crew got their ship back, the bad guys had to limp away, Seska was killed, the ship didn't have an unusal amount of damage and they move on. The only thing that remains is Chakotay's baby may have survived, and perhaps that will come up in a future episode, or perhaps not. We shall see. But based on the ending, I have no expectations for immediate continuity into the next episode. At the end of "Deadlock" however, the ship is in shambles, the deck 15 breach had widened to encompass a part of deck 14, 632 micro-fractures are all over the hull, all primary systems are offline, the antimatter levels are at 18 percent and continuing to fall, the warp coils in both nacelles are fused and inoperative, and it's going to take them 3 days just to be able to return to the bridge. Sure repairs were "underway," but there is no way they could warp away immediately, they're very close to Vidiian space and the ship is effectively disabled. Again, they're very close to Vidiian space! So my expectations were that the next episode would deal with the dilemma of still trying to make a dent in the excessive repair list they're facing while trying to avoid the Vidiians, or perhaps encountering the Vidiians and running into some danger there, being forced to negotiate for some parts they need to make repairs, or something to pick up where they left off. There was potential for that at least. Instead, in the next episode they've conveniently gone beyond Vidiian space and the ship is already 100% tip top. So that's not a "reset" based on your definition (and that's fine, just forget the word "reset"), but it was just disappointing to me based on what the writers could have done based on where they were at the end of "Deadlock." There was so much potential for a really good continuation there. That's the difference for me. And as I have acknowledged, this happens in every Trek. I'm just expressing the simple disappointment I felt based on the potential in this case that was wasted in my view. I hope that at least clears up what was going through my head when I made my original post.