@@ -1,36 +1,64 @@
4−import Foreign.JavaScript
5−import Signal.Keyboard.Raw
6−import Signal.Window as Win
9{-----------------------------------------------------------------------
2{-----------------------------------------------------------------------
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.
16− Hopefully this game also displays some of the strengths of Functional
4+ This game displays some of the strengths of Functional Reactive
17− Reactive Programming. By the end of this file we will have written an
5+ Programming (FRP). By the end of this file we will have written an
18 entire GUI/game without any imperative code! No global mutable state,
6 entire GUI/game without any imperative code! No global mutable state,
19 no flipping pixels, no destructive updates. In fact, Elm disallows all
7 no flipping pixels, no destructive updates. In fact, Elm disallows all
20 of these things at the language level. So good design and safe coding
8 of these things at the language level. So good design and safe coding
21 practices are a requirement, not just self-inforced suggestions.
9 practices are a requirement, not just self-inforced suggestions.
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
23− The following code is structured as follows:
16+ The code for Pong is structured as follows:
24− 1. Models of game inputs (clock-ticks and keyboard input) and the
17+
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.
25− game itself (paddles, ball, score, etc.)
23+ - A model of the game itself: paddles, ball, score, etc.
26− 2. A step function that updates the game based on the inputs
24+ Without a model of the game we would have nothing to update
26+ These models are the basis for the next two sections, holding
27+ all of the information about Pong that we will need.
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.
27− 3. A display function that defines the user's view of the game
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
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.
29 Let's get started!
51 Let's get started!
31-----------------------------------------------------------------------}
53-----------------------------------------------------------------------}
58+import Foreign.JavaScript
59+import Signal.Keyboard.Raw
60+import Signal.Window as Win
35------------------------------------------------------------------------
63------------------------------------------------------------------------
36------ Extracting timesteps from JavaScript ------
64------ Extracting timesteps from JavaScript ------