8.3.1 Mouse event ¶

Mouse cursor enters game play ¶

We want to catch events when the mouse cursor moves over our SpaceWar morph.

Once we make explicit we want the game play to receive mouse move-over events, we need to set the behavior accordingly with dedicated methods.

Each time the mouse cursor enters the game play, we want to:

• Get keyboard focus. It follows the mouse cursor: the keyboard input goes to the morph under the mouse cursor. In Cuis-Smalltalk, the mouse cursor is modeled as a HandMorph instance, an event object (see event classes hierarchy at the beginning of this chapter). An event object is interrogated about its hand with the #hand message. All in all, we want the keyboard focus to be targeted toward our game play when the mouse enters:

  event hand newKeyboardFocus: self
  

• Resume the game. The continuous update of the game is done through a dedicated process stepping mechanism, which will be discussed in the next chapter. The game play just asks itself to resume stepping:

  self startStepping
  

Mouse cursor leaves game play ¶

We also want to be informed when the mouse cursor leaves our SpaceWar morph. Thanks to the work done in Exercise 8.1, we already informed Cuis-Smalltalk we want to be notified of mouse movement over the game play. However we need to code the behavior when the mouse cursor leaves the game play:

• Release keyboard focus. We tell Cuis-Smalltalk the game play does not want keyboard focus:

  event hand releaseKeyboardFocus: self
  

• Pause the game. We stop the continuous stepping update of the game:

  self stopStepping
  

In graphic user interface, a visual effect is often used to inform the user the keyboard focus changed. In Spacewar! we change the game play background depending on the state of the keyboard focus.

In Figure 8.1, at the left keyboard focus is on the game; at the right keyboard focus is not on the game, it is paused and we can see underneath.

Figure 8.1: Spacewar! effect depending on the keyboard focus

In the Morph framework, the #keyboardFocusChange: message is sent to the morph losing or gaining the keyboard focus, its parameter is a Boolean. Therefore we implement the Figure 8.1 behavior in the matching SpaceWar’s method keyboardFocusChange:

SpaceWar>>keyboardFocusChange: gotFocus
   gotFocus 
      ifTrue: [color := self defaultColor]
      ifFalse: [color := self defaultColor alpha: 0.5].
   self redrawNeeded

8.3.2 Keyboard event ¶

To control the space ships, we use the keyboard. Therefore we want the game play to be notified of keyboard events.

We can decide to be notified of the key down or key up event and also key down then up event (key stroke). As long as our SpaceWar morph responds true to the #handlesKeyboard message, it receives the messages #keyUp:, #keyDown: and #keyStroke:. By default, the matching methods in the Morph class do nothing.

The argument of these messages is a KeyboardEvent object to which, among other things, you can ask the #keyCharacter of the pressed key or test about some special keys as the keyboard arrows. The first player ship – the green one – is controlled with the keyboard arrows when there are stroked:

SpaceWar>>keyStroke: event
   event isArrowUp ifTrue: [^ ships first push].
   event isArrowRight ifTrue: [^ ships first right].
   event isArrowLeft ifTrue: [^ ships first left].
   event isArrowDown ifTrue: [^ ships first fireTorpedo].
   ...

To control the second player ship, we use another classic arrangement in QWERTY keyboard controlled game: WASD²⁷.