@@ -1,36 +1,64 @@
11
2−module Pong where
3−
4−import Foreign.JavaScript
5−import Signal.Keyboard.Raw
6−import Signal.Window as Win
7−
8−
92{-----------------------------------------------------------------------
103
11− This code neatly divides Pong into three major parts: modeling the
12− game, updating the game, and viewing the game. It may be helpful to
13− think of it as a more functional (i.e. less imperative) version of
14− the Model-View-Controller paradigm.
15−
16− Hopefully this game also displays some of the strengths of Functional
17− Reactive Programming. By the end of this file we will have written an
4+ This game displays some of the strengths of Functional Reactive
5+ Programming (FRP). By the end of this file we will have written an
186 entire GUI/game without any imperative code! No global mutable state,
197 no flipping pixels, no destructive updates. In fact, Elm disallows all
208 of these things at the language level. So good design and safe coding
219 practices are a requirement, not just self-inforced suggestions.
2210
23− The following code is structured as follows:
24− 1. Models of game inputs (clock-ticks and keyboard input) and the
25− game itself (paddles, ball, score, etc.)
26− 2. A step function that updates the game based on the inputs
27− 3. A display function that defines the user's view of the game
11+ This code neatly divides Pong into three major parts: modeling the
12+ game, updating the game, and viewing the game. It may be helpful to
13+ think of it as a functional variation on the Model-View-Controller
14+ paradigm.
15+
16+ The code for Pong is structured as follows:
17+
18+ 1. MODEL:
19+ First we need to define Pong. We do this by modelling Pong with
20+ simple data structures. We need two categories of model:
21+ - Inputs to the game. For Pong, this is keyboard input from
22+ users and clock-ticks from the frame rate manager.
23+ - A model of the game itself: paddles, ball, score, etc.
24+ Without a model of the game we would have nothing to update
25+ or display!
26+ These models are the basis for the next two sections, holding
27+ all of the information about Pong that we will need.
28+
29+ 2. UPDATE:
30+ When new inputs come in, we need to update the current state
31+ of the game. Without updates, this version of Pong would be very
32+ very boring! This section defines a number of 'step functions'
33+ that step the game forward based on our inputs. By separating
34+ this from the model and display code, we can change how the game
35+ works (how it steps forward) without changing anything else: the
36+ underlying model and the display code need not be touched.
37+
38+ 3. VIEW:
39+ Finally, we need a display function that defines the user's view
40+ of the game. This code is separate from the game logic, so like
41+ the update logic, it can be modified without affecting any other
42+ part of the program. We can also define many different views
43+ of the same underlying model. In Pong there's not much need for
44+ this, but as your model becomes more complex this may be very
45+ useful!
46+
47+ If you would like to make a game or larger application in Elm, use
48+ this structure! Maybe even use this file as a starting point for
49+ playing around with your own ideas.
2850
2951 Let's get started!
3052
3153-----------------------------------------------------------------------}
3254
3355
56+module Pong where
57+
58+import Foreign.JavaScript
59+import Signal.Keyboard.Raw
60+import Signal.Window as Win
61+
3462
3563------------------------------------------------------------------------
3664------ Extracting timesteps from JavaScript ------