@@ -6,6 +6,32 @@ import Signal.Keyboard.Raw
6import Signal.Window as Win
6import Signal.Window as Win
9+{-----------------------------------------------------------------------
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
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.
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
31+-----------------------------------------------------------------------}
9------------------------------------------------------------------------
35------------------------------------------------------------------------
10------ Extracting timesteps from JavaScript ------
36------ Extracting timesteps from JavaScript ------
11------------------------------------------------------------------------
37------------------------------------------------------------------------
@@ -268,17 +294,4 @@ foreign export jsevent "finished"
269-- And finally, we display the view of the game to the user: Pong in Elm!
295-- And finally, we display the view of the game to the user: Pong in Elm!
271−main = view
297+main = view
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.
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