@@ -6,6 +6,32 @@ import Signal.Keyboard.Raw
66import Signal.Window as Win
77
88
9+{-----------------------------------------------------------------------
10+
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
18+ entire GUI/game without any imperative code! No global mutable state,
19+ 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
21+ practices are a requirement, not just self-inforced suggestions.
22+
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
28+
29+ Let's get started!
30+
31+-----------------------------------------------------------------------}
32+
33+
34+
935------------------------------------------------------------------------
1036------ Extracting timesteps from JavaScript ------
1137------------------------------------------------------------------------
@@ -268,17 +294,4 @@ foreign export jsevent "finished"
268294
269295-- And finally, we display the view of the game to the user: Pong in Elm!
270296
271−main = view
272−
273−
274−-- Note that the structure of this game neatly divides Pong into three major
275−-- parts: modeling the game, updating the game, and viewing the game. It may
276−-- be helpful to think of it as a more functional (i.e. less imperative)
277−-- version of the Model-View-Controller paradigm.
278−
279−-- Hopefully this game also displays some of the strengths of Functional
280−-- Reactive Programming. We have written an entire GUI/game without any
281−-- imperative code! No global mutable state, no flipping pixels, no
282−-- destructive updates. In fact, Elm disallows all of these things at the
283−-- language level. Thus, good design is a requirement, not just a self-inforced
284−-- suggestion.
297+main = view