I’ve started committing solutions to those 99 problems in the Objective Caml language to GitHub ; the repository is:

https://github.com/VictorNicollet/99-Problems-OCaml

If you’re interested in starting OCaml programming, have read the manual, and are looking for exercises to get up to speed, consider spending a little time trying to come up with the solutions on your own, using my solutions as a reference. And if you’re an OCaml expert, feel free to propose corrections and improvements : this is what GitHub is for.

Other solutions for OCaml do exist, for instance from Christian Kissig, which is currently more complete than mine. Note that we don’t share the same philosophy as far as writing the code goes, so you can probably look at both sides of the issues. For example, on the “find the last element of a list” problem, Christian throws an exception if no last element exists, while I return None, because I hate exceptions.

Enjoy.

Here’s the question: what is the amount, smaller than 500€, which causes the highest number of notes and coins to be exchanged?

While this could be solved mathematically, I am going to go for a brute-force algorithm because it’s easier on the mind. The approach consists in exploring all possible transactions of size one (only one note or coin is exchanged) and remember what amounts were available, then construct all transactions of size two (by adding a coin or note to a transaction of size one), and so on until all new transactions end up being for amounts that have already been explored (there are 50001 possible amounts, so the algorithm will inevitably terminate, even if it takes a while).

First, I need a representation of all available coins and notes (in both positive and negative form, because in a transaction they can go either way). I will save some typing by writing some code that generates them:

let values =
  List.concat
    (List.map
       (fun v -> [ 5*v ; 2*v ; v ; -v ; -2*v ; -5*v ])
       [ 100_00 ; 10_00 ; 1_00 ; 10 ; 1 ])

This code turns every power of 10 between 10000 (100€) and 1 (0.01€) into a six-item list (for instance, 10 becomes 50, 20, 10, -10, -20, -50), then concatenates all these lists together. The resulting 30-element list contains all 15 notes and coins twice: once positive and once negative.

To represent a transaction (a node in my exploration algorithm) I will define a brand new type that contains the current total in the transaction, the change (a list of notes and coins), and the transaction size (this is actually equal to the length of the change list, but storing it is faster than having to compute it from scratch). The type looks like this:

type t = { total : int ; change : int list ; count : int }

Before I continue, a quick word about complexity: in my algorithm, I expect to do a lot of “has this node already been explored” queries, because this is what determines whether I need to stop processing. I also expect the list of explored nodes to grow to a size of 50001, and if I have to run such a query for every single node, I am looking at a minimum of one billion comparisons. This is starting to get a bit too large for my tastes (probably several minutes worth of computations), so I will look into an alternative storage method: sets.

Sets are optimized for quick “add this element to the set” and “is this element in the set?” operations, running in logarithmic time rather than linear time. This makes the above queries several orders of magnitude faster (expect a 50000-element set to behave about as fast as a 50-element list). In Objective Caml, sets are available as part of the standard library, and can be used by defining a module containing the type you wish to store in the set, then call Set.Make to create a specialized set module dedicated to your type:

module Node = struct
  type t = { total : int ; change : int list ; count : int }
  let compare node_1 node_2 = compare node_1.total node_2.total
end

module NodeSet = Set.Make(Node)

Nothing very complex here: my module defines a type named t (as expected by the set module) and a compare function that relies on the built-in compare function to compare the totals (because my actual query is “was a node with this total explored?”) so that nodes with equal totals but different transactions are still considered the same.

While I’m doing this, I will also add two other functions to my node module: a function which adds a coin to a node (this changes the total, prepends the coin to the transaction list, and increments the count), and a function which returns whether the node is valid (its total is between 0€ and 500€). I will also add an empty node from which the exploration will start:

module Node = struct

  type t = { total : int ; change : int list ; count : int }

  let compare node_1 node_2 = compare node_1.total node_2.total

  let add node coin = {
    total  = node.total + coin ;
    change = coin :: node.change ;
    count  = node.count + 1
  }

  let is_valid node = node.total >= 0 && node.total <= 500_00

  let empty = { total = 0 ; change = [] ; count = 0 }

end

Next, I use the set module to define a “node is not explored yet” function:

let is_unknown known node = not (NodeSet.mem node known)

Here NodeSet.mem element set is a function which returns true if the element is inside the set (“mem” means “member”). Based on this function, I can write the “explore one node” routine, which consists in adding all possible coin and note values to the node, eliminating any nodes that end up outside the 0€ – 500€ range and any nodes that have already been explored, and then returning those nodes. Elimination will use the built-in List.filter predicate list function, which keeps only the elements in the list for which the predicate function returns true. My predicates are “is not explored” and “is valid”:

let explore known node =
  let reached    = List.map (Node.add node) values in
  let valid      = List.filter Node.is_valid reached in
  let unexplored = List.filter (is_unknown known) valid in
  unexplored

The exploration process is fairly similar to what happened in the previous installment. An unexplored list is kept, and one item is taken from it and explored, which creates new unexplored items. Any items added to the list of unexplored items is also added to the set of known items to avoid duplicates. When the unexplored list runs out (everything has been explored), the set of known items is returned, because it contains all reachable nodes including the largest transaction. In order to make sure the smallest transaction is kept for every amount, the algorithm processes shorter transactions before longer transactions (so that the first transaction for any given total is always the shortest transaction for that total). This is done by appending newly found unexplored elements at the end of the unexplored list. The complete code is:

let rec process known unexplored =
  match unexplored with
    | [] -> explored
    | next :: rest ->
      let found = explore known next in
      let known = List.fold_left (fun known node -> NodeSet.add node known) known found in
      process known (rest @ found)

This is the hardest function of the bunch, and the most complex line is the one that uses List.fold_left to add several new nodes to the set of known nodes. As an interesting side note, the order of the parameters to NodeSet.add is not adapted to the List.fold_left function, which forces me to write an anonymous function that swaps the two arguments it receives.

Once this is written, it’s a simple matter of calling the function:

let explored = process NodeSet.empty [Node.empty]

And extracting the maximum using NodeSet.fold, the set equivalent of List.fold_left:

let maximum =
  NodeSet.fold
    (fun node best -> if node.Node.count > best.Node.count then node else best)
    explored Node.empty

Since the set is sorted in ascending order of node totals, I know that if several transactions have the maximum size, the one with the smallest total amount will be found first and kept as the best. And the result is 333.33€, for which the optimal transaction consists in giving 500€ and receiving 100€, 50€, 10€, 5€, 1€, 0.5€, 0.1€, 0.05€ and 0.02€ back (a total of ten coins and banknotes). The computation, when compiled as an optimized executable, takes 58 seconds on a computer that was average by early 2008 standards.

How can one solve this? There’s no simple formula for determining what number comes next, so it boils down to computing enough numbers to be certain that the 1000 smallest values have all been computed, and then sort the result to extract the first 1000.

Finding these numbers looks a lot like exploring a map or maze. From every number, there are four paths one can follow, which consist in adding one of the four initial integers to the current number. So, the paths from 225 lead to 450, 543, 754 and 938. Exploring a number means to write down all four destinations on the map, to be explored later. By definition, all paths lead to higher numbers, which provides a helpful property: if the 1000 smallest integers on the map are all explored, then no path from an unexplored integer can lead to a number smaller than one of those already explored (because that unexplored integer is greater than those 1000 explored ones, and so the path would lead to an even greater integer).

So, the algorithm consists in keeping a list of unexplored numbers and then repeating the following process a thousand times: pick the smallest integer, explore it (adding new numbers to the list of unexplored numbers) and add it to the list of explored items. In the end, the explored list contains 1000 items, sorted from least to greatest, with the guarantee that no unexplored integers can lead to smaller ones.

You might recognize this as a variation on Dijkstra’s Algorithm.

Writing this down in Objective Caml requires a preliminary decision: how are we going to extract the smallest number from the unexplored list? One way is to keep the list sorted at all times—this makes extraction easy (pick the first element) but insertion hard (you have to keep the list sorted). Conversely, one may keep the list in random order—this makes insertion easy (just prepend) but extraction hard (you have to find and remove the minimum). Since the latter is marginally harder than the former, I’ll go with the first option. Inserting an element into a sorted list is a textbook example of recursive function:

let rec insert sorted element =
  match sorted with
    | [] -> [element]
    | head :: tail -> if element < head then element :: sorted
                      else if element = head then sorted
                      else head :: insert tail element

The algorithm is fairly straightforward: if the list is empty, return a one-element list containing only the element ; if the first item in the list is greater than the element, then the element goes in first and the rest of the list follows ; if the element is equal to the first item in the list, then return the list as-is to avoid duplicated ; if the element is greater than the first item in the list, then insert recursively that element in the remainder of the list and prepend the original first element to the result.

Then, there’s the exploration function, which is recursive as well, and expects two arguments: the number of items left to explore, and the list of unexplored elements. The list of explored elements is returned. It is written as:

let values = [ 225; 318; 529; 713 ]

let rec explore n = function
  | [] -> []
  | current :: unexplored ->
    if n = 0 then [] else
      let new_values = List.map ((+) current) values in
      current :: explore (n-1) (List.fold_left insert unexplored new_values)

The exploration function extracts the first element of the unexplored list (if that is empty for some reason, it returns no elements, because there’s nothing to explore) and computes new_values by adding all the original values to the explored element. This uses the built-in List.map func list which calls func on every item of the list and places it in a new list that is then returned. Here, the function is (+) current, which is a function that adds “current” to its argument. So, if the explored element was 225, the returned list would contain 450, 543, 754 and 938.

The code then inserts those four values into the unexplored list by using List.fold_left (which I have already covered yesterday), and recursively calls explore (asking for one less element). It then prepends the current element to the returned list (because it’s smaller than all the elements to be explored next) and returns everything.

That’s all! To find the 20 smallest values, one writes:

let smallest_20 = explore 20 values

These are:

[225; 318; 450; 529; 543; 636; 675; 713; 754; 768; 847; 861; 900; 938; 954;
 979; 993; 1031; 1058; 1072]

Any questions? Ask away in the comments section!

The font used for the headings is Tusj, and there’s a link to a downloadable and printable PDF file here. And don’t forget to support the Switzerland.

]]> http://www.nicollet.net/2010/12/gifts/feed/ 0 http://www.nicollet.net/2009/05/hadopi/ http://www.nicollet.net/2009/05/hadopi/#comments Wed, 20 May 2009 18:20:35 +0000 Victor Nicollet http://www.nicollet.net/?p=965 The HADOPI law was recently adopted by the French parliament. I have an issue with this law: it deals with technical things that few people are knowledgeable in (including most members of parliament) such as the Internet Protocol and the use of IP addresses.

So, I have made a small effort on this website to explain the basic technical principles underlying the HADOPI law [fr].

The project is called JITBrain. In itself, it’s nothing quite groundbreaking, merely an issue tracking platform that services two categories of users:

• Individuals that have a lot to do but never seem to manage it. These are helped by features such as extremely simple todo-list manipulation, a search engine for looking at previous tasks and retrieving important information, and helpful statistics.
• Teams that must collaborate on projects. These are helped by features such as issue tracking, simple workflows, attached links and files, planning poker, reporting charts, and motivational gizmos.

The unusual thing about the project is the development method: it builds upon my earlier ramblings on snippet-oriented development (developing quality software by actively thinking of the people who will read and reuse the code) to actually become an advanced tutorial in itself. This brings yet another benefit, since the code is not only designed in short bursts of concisely explained functionality, but a complete documentation and log is being written along with it.

As such, it has the additional purpose of serving as a simple reference for “classic mistakes” both in technical and functional areas in the development of a website.

The tutorial advances along with the development of the system, which means you can see the tutorial or look at the website.

I intended this article as a short introductory meta-note about learning C++. It should give you some elements that can be helpful in understanding C++ books and tutorials. If you’re really keen on doing this, I suggest Thinking in C++ and the C++ FAQ Lite, both of which are freely available online and are quality resources.

And stay away from any tutorials that #include <iostream.h> !

The benefits

Why would someone use C++?

As a project manager: you probably have existing code written in C++ that you can leverage for your project (or C code that you could interface with), costly tools related to C++ that you don’t want to buy again for another language, and you might already have a team of C++ programmers that can work on it—so why choose another language?

As an individual programmer: you might want to be hired by an industry that uses C++ a lot (such as the games industry or front-office investment banking), or it might be the only language you have managed to learn—or the only one you like.

In both cases, you might be constrained to a platform that has no support for other languages you might prefer, or be shoehorned into using a specific language by the project requirements.

The downsides

Why would someone not use C++?

It’s dangerous. C++ leaves a huge amount of things undefined, meaning that virtually every large project written in C++ will rely on some specific behavior that is not guaranteed by the language. This leads to unpredictable errors that happen only on certain computers and are extremely difficult to track.

Also, when a part of a C++ program fails, the entire program fails—therefore, if you wish to isolate your program from a subprogram written by someone else, you have to separate them and therefore spend a lot of time on working on communication between the two.

Last but not least, C++ relies on a “the programmer is always right” philosophy. If you cannot be up to the task of always being right, you might want to avoid using C++ on a large scale.

It might be awkward for specific situations. C++ is a general-purpose compiled language, so it certainly does not excel at all tasks. This can be an issue for the programmer himself (text manipulation in C++ lacks all the amenities of PHP and Perl text manipulation), for the organization (the C++ compilation model does not lend itself to short modify-and-test cycles like Lua or Python would) or for the user (no user will install a C++ application to visit a website, but nearly all of them can run JavaScript or ActionScript in their browsers).

How C++ code turns into executables

As a programmer, you write source code. Source code is stored in plain text files—usually with the .cpp extension, to indicate that it’s C++ code. Text editors (including notepad) can open source code files, but people usually have dedicated source code editors that add many features (such as highlighting relevant parts of programs or smart search-and-replace tool). I use emacs on Linux and Visual C++ Express Edition on Windows—both are free and available online for download.

So, I would write this code (don’t try to understand the details just yet) :

void print(int x)
{
  ... explain how to show the integer x to the user ...
}

print(2 + 3);

Then, I use a compiler to create the executable.

The C++ compiler is a program that reads a C++ source file and turns it into a program.

Well, that’s not entirely true. The problem is that the average program contains hundreds of thousands of lines of code, and many people work on such programs, which makes it necessary to separate the program into separate source files. What if, for instance, I wanted to let a co-worker use the ‘print’ function I’ve defined above?

Besides, for performance purposes, it would be wise to avoid processing a file that has not changed since the last time it was processed. This has led to the creation of object files.

The C++ compiler is a program that reads a C++ source file and turns it into an object file.

The C++ linker is a program that reads several object files and connects them together to form a program.

The linking process mostly just sticks the object files together in an executable file. It sometimes performs two additional operations:

• If an object file uses something provided by another object file (that is, your code uses some code written by another programmer), it connects the two together. This leads to linker errors if a thing is defined  by two object files (which one should be used?) or if it’s defined by none (it’s required, but not provided).Here, it finds out that my object file needs ‘print’, and that an object file provided by someone else defines ‘print’, so it connects them.
• If an object file provides something that nobody uses, it is often stripped from the resulting executable file to avoid wasting space.

We’re getting close, but we’re not there yet. There is still one problem: how does the linker know what an object file uses? Using a piece of code usually involves the name of that piece, but a program may involve a lot of pieces with the same name, and therefore needs more information to select one. Therefore, C++ requires the programmer to declare in his code that he’s using a certain piece of code, along with all appropriate information about that piece.

In the ‘print’ example above, you would have to specify a few more details in order to differentiate ‘print’ that displays an integer from ‘print’ that displays some text. The declaration of my ‘print’ would look like this:

void print(int);

print(2 + 3);

This also has a useful side-effect: since you’ve given a lot of information about that piece of code, the compiler can determine whether you’re using correctly or not based on that information. This means that you don’t have to wait until link-time to find out if you have errors, and the compiler can even give you the lines where the errors happen (the linker often does not have access to line numbers).

As a consequence, the C++ language requires you to always declare objects before you use them (and, of course, defining an object counts as declaring it).

However, all users of my code will have to declare the things that I provide. Wouldn’t it be easier if I provided them with a list of declarations that they can just copy-paste into their own code? In fact, wouldn’t it be even easier if the language provided a way of inserting a list of declarations in your source code?

This is precisely what the preprocessor does: it inserts lists of declarations (called header files, which use the .h or .hpp extension) into source files. For instance, I would write:

-- myfile.cpp --

void print(int x)
{
  ... explain how to print x ...
}

-- myfile.hpp --

void print(int);

-- yourfile.cpp -- 

#include "myfile.hpp"
print(2 + 3);

The ‘#include’ tells the preprocessor that it should copy-paste the contents of the ‘myfile.hpp’ file right there. This operation happens before the compiler manipulates the file, so that the compiler always sees the transformed file.

The preprocessor reads each source file (.cpp) and inserts any header files (.hpp) that the source file includes. The result of preprocessing a source file is called a translation unit.

The compiler reads each translation unit and turns it into a lightweight, optimized representation that is quite close to machine language, and stores it in an object file (.o or .obj) for later reuse.

The linker reads all object files, connects them together to resolve pieces of code references between objects, and eliminates unused pieces. This results in an executable program.

There are many variations on the above layout (such as precompiled headers, or libraries), but you don’t need to know about these yet. Besides, while knowledge of the above is useful to understand error messages and code layout, you don’t need to do that manually: most compilers actually the entire preprocess-compile-link sequence for you without needing human intervention in the simple cases.

Undefined Behavior

Before you advance any further, you need to understand undefined behavior. The C++ language is defined by a standard: a complex document that describes in excruciating detail every single feature of the language and how it should behave. The philosophy of the C++ language is that compilers should have as much latitude as possible in order to generate high-performance executables.

This has led to three levels of description:

• Standard-defined details must be supported by every C++ compiler in the world. If you rely on these details, your program will work across all platforms that have a standard C++ compiler. For instance, that every opening brace “(” should be matched by a closing brace “)” is part of the standard.
• Implementation-defined details are not specified by the standard, they are left for the compiler writers to determine. The only constraint is that compiler writers must make a decision and document that decision. So, you can rely on these details being defined and safe on every platform, although they will not be the same between platforms. For instance, an integer may require two, four or eight bytes depending on the platform being 16-bit, 32-bit or 64-bits.
• Undefined behavior is just undefined. This lets the compiler writers do anything without telling the programmer what they are doing. This can be a compiler warning or error, doing “what the programmer expects”, crashing the program, randomly altering values in other parts of the program, and in some cases outright crashing the computer. The blue screen of death and Windows access violations are typical examples of what undefined behavior can lead to.

The problem with undefined behavior is that it can indeed do “what the programmer expects” while you’re developing, and then suddenly stop working when you give the program to a friend, reboot your own computer, or are trying to do a demo in front of your investors.

This means that you should never write code unless you are absolutely certain that the standard or your implementation allows it. The natural consequence is that although C++ is an extremely complex and varied language, most expert C++ programmers will only ever use a small subset of C++ that they are intimately familiar with, because straying from these subsets in a safe fashion requires you to spend a lot of time reading the standard and the compiler documentation just to check that what you are doing can be done.

This is also the reason why C++ is not advised as a first language: it’s easy to write a C++ program that compiles and works on the first run but crashes and burns when you least expect it—writing reliable programs require the programmer maturity to always check with the standard whether the code is safe, and beginners seldom have the will or the ability to check the standard.

Modern C++

There are different styles of writing C++. By styles, I do not mean how many spaces each tab contains, where you place your curly braces, how you name your variables or whether you prefix members with “m_”. Many people, including experienced programmers (and me, too), tend to make a fuss about these typographical details, but what ultimately matters is that you should be able to write in whatever style your team needs you to write, to read whatever code your team needs you to read, and that you should choose for your own programs the style which requires the least brainpower on your part to read and write (this tends to be, for me, the default style enforced by my editor).

The style in which most experienced C++ users write is called Modern C++. It relies on a technique known as RAII to avoid forgetting “always do B after A” constraints such as “always release memory after you use it”, “always close files after you write them” and “always display a frame after rendering it”. In particular, Modern C++ code never uses the delete operator explicitly, and instead gives memory ownership to scoped objects that will delete it themselves when they go out of scope. By tying a necessary operation (delete memory) to an inevitable event (leave a certain scope), you ensure that the operation always happens.

By contrast, many inexperienced C++ programmers (whether they come from a C background or followed a C tutorial with some C++ details) write in a style known as “C with classes”. They take advantage of a small number of C++ features that do not exist in C, but otherwise use C approaches to problems. While this is not, in itself, a problem, it is essential to note that C with classes does not play well with several C++ features, such as exceptions or polymorphism.

Modern C++ adepts tend to find C-with-classes to be counter-productive. This is a subjective statement—someone who writes C-with-classes code can seldom be more productive, because this would require Modern C++ techniques, and learning these takes time. However, someone who masters Modern C++ has access to techniques that can shorten code by an order of magnitude while also keeping it safe and correct (and delegating such boring verification tasks to the computer), making them intrinsically more productive that C-with-classes authors.

Do not expect to “guess” Modern C++ on your own—beginners are inevitably drawn to C-with-classes. As you learn, you will inevitably meet Modern C++ programmers who will comment on your code and explain to you that some part is too long and could be shortened by correct application of modern techniques, or that another part is not exception-safe and should be rewritten using safe idioms that Modern C++ provides. Do not contradict them without giving their proposal some attention, for even if you do not ultimately listen to their advice, the mere act of trying out what they suggest makes you a better C++ programmer. Over the course of a few years, you will move from a C-with-classes programmer to a Modern C++ programmer, if you have enough Modern C++ programmers around to teach you (in my case, I spent 5 years as a C-with-classes programmer).

Related Posts

• An Introduction to C++ Pointers : one of the trickiest tricks in the C++ bag (see also Array iterators)
• Can references be null? : the classic example of undefined behavior
• Member and Non-Member Functions : thorny first-class functions in C++

Do you know of other benefits or downsides to C++? Do you think everyone should learn, if only for the learning experience? Do you have horror stories of undefined behavior rampaging through code bases? Please leave a comment below!

But how does one start creating a video game? How does the initial idea of a video game translate to an actual program you can run? This step isn’t the hardest of all steps in game development (far from it) but it deters a lot of otherwise well-motivated wannabes.

As a former game developer (I was the lead programmer for Darklaga : Cannonball Symphony) I will try to answer a few of these questions on the technical side. To this end, I have written a short video game which you can find here, which happens to be a reimplementation of Pong (one of the earliest video games). In this article, I will discuss video game development using that game as an illustration.

How Game Development Works

So, how does a video game get created? It usually follows the same set of steps:

• A team of designers has a basic idea for a game. it designs most of the high-level details of the game: the look and feel, the various elements and their behavior, win and loss conditions, player controls, and so on.
• A team of artists creates the graphics and sounds for the game, using their favorite editors and tools and recording studios, according to the designer’s vision.
• A team of programmers writes the program itself, describing how, where and when the graphics should appear and the sounds should be played, and how the player’s input affects this, according to the designer’s vision.
• Testers play the game, provide input to the designers, who alter the design to please the testers. The cycle repeats until the testers are happy or money runs out.
• A publisher takes the game, packages it, sends it to retail stores and advertises it.

Of course, all of this could be done by a single person (Pong), or it could be done by an independent team of five (Darklaga), or it could be done by a professional experienced studio backed by a strong publisher (Red Alert 3).

In an ideal world, you would be able to pitch in an idea, and people would take that idea, create a game from it, publish it and give you a share of the money. This rarely happens in the real world, because games take time to be developed, there’s limited manpower to go around, and so those few idea-pitcher positions are already taken by people with vast amounts of experience and connections in the business. Tom Sloper has a few quite interesting articles about getting your game done, which you can read here.

So, if you have a great game idea, but neither connections nor experience in the business, you’re basically stuck with either giving up or doing it yourself. This will involve either convincing a programmer to work for you, or doing the programming yourself. If you want to try programming, read on.

Programming Games

Video games are computer programs: contraptions designed and written by programmers to make the computer behave in a certain way. Since programmers tend not to be happy with available tools, they often invent new ways of programming computers, which means there are many ways of creating a video game. For instance, the Pong game I wrote for this article is written using a programming language called Javascript (or ECMAScript, depending on whom you ask). The part of the program responsible for making the ball bounce on the screen edges looks like this:

if (this.ball.y + ball.h > field.h)
  { this.ball.vy = - ball.s } 

if (this.ball.y - ball.h < - field.h)
  { this.ball.vy = ball.s }

Different programming languages look different. Sometimes, differences are small, so an equivalent program in the C++ programming language would look like:

if (this -> ball.y + ball::h > field::h)
  { this -> ball.vy = - ball::s } 

if (this -> ball.y - ball::h < - field::h)
  { this -> ball.vy = ball::s }

These two are fairly similar, because both C++ and Javascript belong to the same family of languages (called the C family) and therefore share a lot of features and constructs. By contrast, Objective Caml is a programming language of the ML family, and has a quite different take on things:

method verticalBounce =
  if y -. Const.ball_h < -. Const.field_h then
    {< vy = Const.ball_s >}
  else if y + Const.ball_h > Const.field_h then
    {< vy = -. Const.ball_s >}
  else
    self

Different languages have different capabilities. I chose Javascript because it allows running the game in a browser with no downloading or applets. One could choose the ActionScript language to run a video game in a Flash or Flex applet, or the Java language for running a video game in a Java applet, both within a browser. Developing for Windows or the XBox could involve using the C#, F# or VisualBasic.Net languages. Developing for the PC and most consoles can also happen in the C++ and C languages, as well as one of the many BASIC language variants and many others as well. Writing the central server program for multiplayer games could involve the ErLang or Stackless Python programming languages for performance reasons. Writing a video game for a pocket calculator would involve using the assembly language for that calculator. Every programmer know several languages, and chooses whichever best fits the problem he is solving.

All languages have a thing in common: they’re human-readable text which the computer does not understand, and as such they necessitate a translation phase where the program, written in a programming language, is transformed into a sequence of machine instructions that the computer can execute. This translation sometimes happens before running the program (done by another program called a compiler), and sometimes it happens while running the program (done by another program called an interpreter). Some languages, such as C++, tend to be always compiled, while other languages, such as JavaScript, tend to be always interpreted, and many programs are half-compiled and half-interpreted.

Almost everyone has a Javascript interpreter on their computer: Internet Explorer, Firefox and Safari all bundle one, because web pages tend to use Javascript to make their content dynamic and interact with the user. Because of this, all you need to start programming is a text editor (such as Notepad) to edit javascript files and a web browser (such as Internet Explorer) to view the result. I prefer to use improved tools (the Crimson Editor, Firefox and the Firebug plug-in) because they help me write programs faster.

A very important aspect of programming (and computer usage in general) is the use of existing tools for accomplishing common tasks. Programmers who regularly solve the same problems eventually write down code to solve these problems, once and for all, and then store that code in code libraries. Sometimes, a library is useful enough that it deserves to be published and used by many other programmers worldwide. For instance, my Pong game needs to move green things around on the screen, which is a fairly common task that is already done by the jQuery Javascript library. In general, when a programmer has a difficult task to solve, he usually searches for an existing solution on the web before rolling out his own.

A Programming Primer

This article is not going to teach you how to program. That would require more space and time than I have here. What it can do, however, is teach a few basic elements of programming in Javascript, which you may also find useful in other languages.

The simplest way of executing Javascript is to write it as part of a web page. For instance:

<html>
  <head>
    <title></title>
    <script type="text/javascript">
<![CDATA[
   { write your javascript code here }
]]>
    </script>
  </head>
  <body></body>
</html>

Save this text with the “html” file extension, and start writing Javascript. Open the file in a browser to test it (depending on your security settings, you might have to enable scripts for this to work). Again, I strongly advise you to use the CrimsonEditor/Firefox/Firebug triad for working with Javascript.

Statements, Variables, Values

Javascript is an imperative language: it describes sequences of operations to be performed by the computer. Individual operations are called statements. For instance, the sentence $(document).text(“Hello”) is an operation which replaces the content of the document with the text “Hello”. You can chain several statements together by separating them with semicolons: the statements are then executed in order, left-to-right and top-to-bottom. One very useful statement is the “alert” statement, which creates a message box containing some text:

alert("This is my message")

If you’re using Firebug, you have access to the superior “console.debug” option, which is not as nasty as a message box and allows you to output things more complex than text:

console.debug("This is my message")

Programs manipulate values: these can be numbers, lists of other values, pieces of text, parts of a web page, or even parts of a program. The most elementary operation to be performed with a value is to store it in a variable: this is useful so that values are kept around when you’re not using them. A variable is just a name which is associated with a value: you can retrieve that value at any time by writing the variable’s name, and you can change the value of a variably any time you wish.

Creating a variable uses the “var” keyword, which is reserved for that purpose:

var zero = 0

This statement creates a variable, called zero, and associates it with the number 0. You can use a variable anywhere you would use its value:

var message = "This is my message" ;
alert(message)

This displays “This is my message” in a message box. You can also change the value of a variable after you’ve created it. That operation is called an assignment:

var message = "This is my message" ;
alert(message) ;
message = "On second thought, it isn't" ;
alert(message)

This displays “This is my message” followed by “On second thought, it isn’t”. The first value assigned to the variable is lost, replaced by the second value assigned to the variable.

You can manipulate values in many fashions. For instance, you can have arithmetic operations (+a, -a, a + b, a – b, a / b are fairly obvious, a * b is multiplication, and a % b is the remainder of dividing a by b), comparisons (a == b for equality, a != b for inequality, a < b, a > b, a <= b and a >= b), and logical connectors (a && b : and, a || b: or, !a : not).

Blocks, Functions

I have mentioned earlier that you can manipulate parts of a program. The easiest way of doing so (although somewhat limited) is to use blocks and control structures. A block is zero, one or more statements between curly braces, for instance { a ; b }. A control structure is a special statement which is followed by a block, and executes that block under special circumstances. For example, a conditional statement only executes its associated block if a certain condition is true:

if (age < 13)
{ alert("You are not allowed to view this website")  }

Control statements give you control over which statements are executed in certain situations. They are invaluable for expressing complex behavior in your programs. A typical extension of the conditional statement is to also specify something to be done when the condition is not verified:

if (name == "John") { alert("Hello, John!") }
else                { alert("Who are you?") }

By now, you have probably noticed that I position my blocks and statements around randomly. This is indeed the case: Javascript doesn’t care about the position of your statements and blocks. Just like in English, you can write your sentences every way you wish as long as you don’t split or swap your words.

Another typical control statement is the loop. It executes its associated block repeatedly as long as its condition is true. So, displaying a countdown from 10 to 0 would look like this:

var i = 10 ;
while (i != 0)
{ alert(i) ; i = i - 1 }

The loop displays the number, then substracts one from it, until the number is no longer different from zero.

The improved version of a block is a function: a function is, for all purposes, a block that can be manipulated as a value. This means that you can assign it to variables, keep it around, and execute it when you want it to. You create a function from a block by using the “function()” keyword in front of that block. You then call functions (which executes the corresponding block) by appending two parentheses after the variable name:

var scare = function() { alert("Boo!") }; 

if (surprise)
{ scare() ; alert("Sorry for scaring you!") }
else
{ alert("I'm going to scare you!") ; scare() }

Functions serve several purposed in a program. Their primary purpose is to eliminate repeated code: if you have code which is repeated in several places, turn that code into a function and call the function wherever you need without having to rewrite the code. This even works if you have code that is not identical, but still similar enough:

var i = 1 ;
var total = 0 ;
while (i <= 10) { total = total + i }
alert(total) ; 

i = 1 ;
total = 0;
while (i <= 20) { total = total + i }
alert(total)

These two pieces of code compute the sum of numbers between 1 and 10, and between 1 and 20. The only difference here is the number 10 (or 20). It is then possible to make this number a parameter of a function: when a function has a parameter, a value for that parameter has to be provided when the function is called. The parameter then becomes a variable associated to that value. In this case:

var sum = function(max)
{ var i = 1 ;
  var total = 0 ;
  while (i <= max) { total = total + i }
  alert(total) }; 

sum(10) ;
sum(20)

A function may have several parameters. If that is the case, then the parameter values must be provided in the same order. Parameters enhance the ability of functions to eliminate repetitive code.

The secondary use of functions is to serve in special situations where one needs to represent a block. For instance, the setTimeout() operation registers a function to be executed after a specified duration. So, for instance:

alert("First message") ;
setTimeout(function(){ alert("Third message") }, 3000) ;
alert("Second message")

This displays “First message”. When that message box is closed, it registers “Third message” to be displayed after 3 seconds (3000 milliseconds) and immediately displays “Second message”. Another example is jQuery’s “when document is loaded” operation, $():

$(function(){ alert("Document has finished loading") });

Note that you can define functions and assign them to a new variable in a single action using an alternative simplified syntax:

function sum(max)
{ var i = 1 ;
  var total = 0 ;
  while (i <= max) { total = total + i }
  alert(total) }

Objects, Classes

One other feature of Javascript is the ability to combine several values into one. For example, it’s interesting to store together in a single variable the horizontal and vertical positions of the ball in a Pong game, yet still be able to access them independently. In Javascript, an object is an aggregation of several values: these values are members of the object, and they are given names which allows the program to access them:

var obj = { x : 10, y : 20 } ;
alert (obj.x) ;
alert (obj.y) ;
obj.x = 30 ;
alert (obj.x)

This code creates an object with members x (equals 10) and y (equals 20). It then displays the value of member x, then the value of member y. Then, it changes the value of member x, and displays it again. The result is 10, 20, 30.

When it becomes useful to create many objects along the same pattern, as well as define functions which can operate on these objects, Javascript allows you to define classes of objects. A class is a template which allows the creation of objects which have function members that operate on the object. A class is a template used for the creation of objects. For instance:

function number(x)
{ this.x = x } 

number.prototype.increase = function() { this.x = this.x + 1 } ; 

number.prototype.show = function() { alert(this.x) } ; 

var n = new number(10) ;
n.show() ;
n.increase() ;
n.show()

This example introduces several new concepts, which are all necessary to understand classes:

• The ‘prototype’ keyword indicates that the ‘number’ function is in fact a class, and defines two functions, ‘increase’ and ‘show’, as being members of all objects of class ‘number’.
• The ‘new’ keyword creates a new object of the ‘number’ class. That is, it creates an empty object, then adds every function inside the class prototype to that object. Then, it calls the function ‘number’ itself, with the provided parameter values.
• The ‘this’ keyword acts as a variable. Whenever a member of an object is called,’this’ becomes equal to that object, so that any operations applied to ‘this’ will be applied to the object. When the ‘number’ function is called because of the ‘new’ keyword, ‘this’ becomes equal to the newly created object.

In detail, what the example above does is:

• Define a function called ‘number’.
• Decide that ‘number’ is in fact a class, and define member functions ‘increase’ and ‘show’.
• Create a new instance of ‘number’ : this creates an object, adds the ‘increase’ and ‘show’ functions to it, sets ‘this’ to that object, and calls ‘number’.
• When ‘number’ is called, it creates a new member ‘x’ and sets it to 10. So, the new object has a member ‘x’ equal to 10.
• The program calls the ‘show’ function. This sets ‘this’ to the object, and the function reads the ‘x’ member of that object (which equals 10) and displays it.
• The program calls the ‘increase’ function. This sets ‘this’ to the object, and the function adds one to the ‘x’ member of that object (so it now equals 11).
• The program calls the ‘show’ function. This sets ‘this’ to the object, and the function reads the ‘x’ member of that object (which is now 11) and displays it.

Note that the value of ‘this’ is restored after a member function returns.

But I Can’t Remember All This!

Of course, you can’t. This kind of stuff takes time and patience to remember. So, take your time and read it a few times. If you don’t understand something, try it out to see for yourself what happens. If you really don’t get it, ask around. I’m willing to answer questions if you ask them in comments to this entry, and you can always ask questions around the good folks at gamedev.net anytime. After a few weeks of practice, you’ll be able to do most of this on your own.

Game Design

Before you jump right into coding (and drawing your assets, if applicable) you need to have a fairly complete and detailed description of the game you intend to develop. Otherwise, like a mason without a plan, the house you build is unlikely to ever be finished, and will crash to the ground in strong wind if it is.

The basic requirements for a pong game are as follows:

• The Pong game contains a square ball and two rectangular paddles.

• The ball moves at a certain speed along both horizontal and vertical axis.
• When it hits the top or bottom of the screen, the vertical velocity is reversed.
• When it hits the left or right edges of the screen, the horizontal velocity is reversed and the ball is moved to the center (horizontally). The player on the other side gains a point.
• When it hits a paddle, the horizontal velocity is reversed.

• Paddles are vertical, and there is one on each side of the screen.
• They move up and down at a fixed speed.
• When they hit the top or bottom edges of the screen, they stop moving.
• They move slightly slower than the ball (so that “follow the ball” is not a winning strategy).
• The player controls the left paddle, an AI controls the right paddle.

Writing the program

The game is a large piece of functionality. However, programming only allows us to express small bits of functionality. So, we will have to split up the program in smaller pieces before we can create it.

One common way of splitting things is the MVC architecture. MVC stands for Model/View/Controller, which can be explained like this:

• The Model describes everything that happens behind the scenes. It doesn’t care about how the game will be displayed on the screen, or how the input from the player will be received. What it cares about is where the ball is, where the paddles are, how the ball should bounce when it hits something, and when scores should increase. This will be an entire object containing all the data required to describe the game, along with functions that compute the movement of the paddles and ball over time.
• The View describes how the game should be displayed. It doesn’t really care why the ball and paddles move a certain way: all it cares about is where the ball and paddles are, and which way they are moving. It gets this information from the model, and displays it in one way or another.
• The Controller is what makes the game interactive: it reads user input in one way or another, generates AI strategies, and enters all that data into the model. Once the model has computed the new positions and scores, it asks the view to draw it, then starts again.

Applying MVC splits the program in three parts that are much cleaner and, therefore, potentially easier to create. It’s usually considered a good first step when designing a program.

The Model

Since the view depends on the model, and the controller depends on both the view and the model, the first thing to be implemented is usually the model: it’s independent of anything else, and so it can be written on its own.

First, there is data to be stored that will change a lot over time:

• The position of the ball, as the ball’s velocity.
• The vertical position of each paddle, and its vertical velocity.
• The score of each player.

Then, there’s also data that will not change:

• The default horizontal and vertical speed of the ball.
• The horizontal position and default vertical speed of the paddles.
• The dimensions of the field, ball and paddles.

We can store these constants in objects that will never be changed:

var field    = { w: 320, h: 240 };
var paddle   = { x: 300, w:   2, h:  30, s: 76 };
var ball     = { w:   5, h:   5, s: 120 };

The changing data itself should be stored in a model object, which should store the different categories of model data in sub-objects:

function model()
{ var s = ball.s;
  this.left   = {  pos: 0,   vel: 0 };
  this.right  = {  pos: 0,   vel: 0 };
  this.ball   = {    x: 0,     y: 0,
                    vx: s,    vy: s };
  this.scores = { left: 0, right: 0 }
}

Before going on, let’s discuss a bit all these definitions. Obviously, this code creates a model class with data for left and right paddles, a ball, and scores. Constants are also defined to describe the dimensions of the field, paddles and ball, as well as the default speeds of the ball and paddles. This can be inferred fairly easily from the code if you know JavaScript. The unanswered question is, what do those numbers represent?

• Since the play field is symmetric, I have chosen coordinates (0,0) to represent the center of the field. This way, the top and bottom edges are at -field.h and field.h respectively (which means the total height of the field is, in fact, 480 pixels and not 240 pixels), the left and right edges are at -field.w and field.w (total width of 640 pixels). In general, the width and height are actually half-widths and half-heights, and the position of an object is in fact the position of its center.
• Speeds are expressed in pixels per second. This means that the ball traverses the field vertically in 2 seconds and horizontally in 2.6 seconds, and the paddles traverse the field vertically in a bit more than 3 seconds (all of this is computed without taking the dimensions of the elements into account).
• The scores are points. You add one point to the winner’s score on each round.

Initially, everything is centered, and the ball moves to the bottom-right (and since it moves faster than the AI’s paddle, the AI always loses the first round, but that’s not really a problem because it lets the player get his bearings for nearly two seconds).

The most elementary thing that can happen to the model is be controlled: this makes the paddles move by changing their velocity. So, when a player presses a key, the velocity changes, and when the key is released the velocity resets to zero. The model doesn’t care about keys (that is the job of the controller), only about directions, so the movement functions have a direction parameter:

model.prototype.moveLeft = function(d)
{ this.left.vel  = d * paddle.s }; 

model.prototype.moveRight = function(d)
{ this.right.vel = d * paddle.s };

These functions are added to the model class and move the left and right paddle, at the appropriate speed, depending on the direction. Here, we assume that the direction parameter d will equal -1 for “up”, 0 for “don’t move” and 1 for “down”, and we’ll have to take care in the controller in order to guarantee that.

The other thing that the model does is make things move. In the computer world, movement is a quick succession of different images which give the illusion of movement (as with flipbooks). So, instead of working in a continuous motion, the model should skip ahead of time by a certain duration (known as the time step). Here, I’m going to choose a reasonable timestep: 10 milliseconds (that’s 100 steps per second):

var timestep = 0.01;

The update function is pretty heavy: it has to move the objects around (to match those 10 milliseconds) then determine if the ball should bounce, if the paddles should stop moving, and if the scores should increase. The entire function is:

model.prototype.update = function()
{
  var t = timestep; 

  this.left.pos  += t * this.left.vel;
  this.right.pos += t * this.right.vel;
  this.ball.x    += t * this.ball.vx;
  this.ball.y    += t * this.ball.vy; 

  var clip = function(pad)
  { var pos = pad.pos;
    pos = Math.min(pos,field.h - paddle.h);
    pos = Math.max(pos,paddle.h - field.h);
    if (pos != pad.pos) pad.vel = 0;
    pad.pos = pos;
  }; 

  clip(this.left);
  clip(this.right); 

  if (this.ball.y + ball.h > field.h)
  { this.ball.vy = - ball.s } 

  if (this.ball.y - ball.h < - field.h)
  { this.ball.vy = ball.s } 

  if (this.ball.x - ball.h < - paddle.x + paddle.w &&
      this.ball.x + ball.h > - paddle.x - paddle.w &&
      this.ball.y + ball.h > this.left.pos - paddle.h &&
      this.ball.y - ball.h < this.left.pos + paddle.h )
  { this.ball.vx = ball.s } 

  if (this.ball.x - ball.h < paddle.x + paddle.w &&
      this.ball.x + ball.h > paddle.x - paddle.w &&
      this.ball.y + ball.h > this.right.pos - paddle.h &&
      this.ball.y - ball.h < this.right.pos + paddle.h)
  { this.ball.vx = - ball.s }  

  if (this.ball.x - ball.h < -field.w)
  { this.scores.right++;
    this.ball.x = 0;
    this.ball.vx = ball.s } 

  if (this.ball.x + ball.h > field.w)
  { this.scores.left++;
    this.ball.x = 0;
    this.ball.vx = - ball.s } 

};

Let’s go through it step-by-step:

• First, it moves objects around. This is done by adding (+=) the moved distance (t * speed) to the position of objects. This computes the final position of objects after that step. The next steps then handle collisions.
• The first collision test is handled by the “clip” function, which prevents the paddles from leaving the screen (it’s a function because there are two paddles, so I created it once and used it for both paddles). The basic rule is: clip the paddle to the screen and, if it went outside, set its speed to zero. Since the position of the paddle is the position of its center, I have to take the height of the paddle into account in order to avoid leaving the field.
• The next two collision tests happen between the ball and the top and bottom edges of the field: if the ball went beyond these, the vertical speed is set so that the ball moves back into the field.
• The next two collision tests happen between the ball and the paddles. It tests whether the ball-rectangle hits the paddle-rectangle by checking whether any of them intersect (collision detection is a topic in itself) and if they do, sets the horizontal speed to move back into the field.
• The last two collision tests check if the ball leaves the field on either side. When this happens, the score of the corresponding player is increased (++), the ball is moved to the center (x=0) and its speed is reversed.

So, if we call the “update” function, it computes the state of the game after 10 milliseconds. If we do it often enough, we can get the game state in real time. Now, we have to display it.

The View

The view is the part of the program responsible for displaying things to the player. It reads data from the model, and somehow maps it to whatever display techniques the program has.

In this example, I’m using the jQuery library. It allows the program to resize and move around DIV elements of a web page (by default, a DIV element is a rectangle with a set position). So, the first step I will take is create the HTML page which will be manipulated by the view:

<html>
  <head><title>Pong</title>
  <script type="text/javascript" src="jquery.js"></script>
  <script type="text/javascript" src="pong.js"></script>
  <style>
#playfield {
  color           : black;
  background-color: black;
  border          : 0px none black;
  margin          : 0px;
  padding         : 0px;
  position        : absolute;
  top             : 0px;
  left            : 0px }
div {
  font-size       : 1px;
  color           : white;
  background-color: #33FF33;
  margin          : 0px;
  padding         : 0px;
  position        : absolute;
  top             : 0px;
  left            : 0px }
div.score {
  color           : #33FF33;
  background-color: transparent;
  width           : 640px;
  font-size       : 20px;
  font-family     : courier new }
  </style>
  </head>
  <body>
    <input id="playfield"/>
    <div><div id="paddle_left"/></div>
    <div><div id="paddle_right"/></div>
    <div><div class="score" style="text-align:left" id="score_left">0</div></div>
    <div><div class="score" style="text-align:right" id="score_right">0</div></div>
    <div><div id="ball"/></div>
  </body>
</html>

This creates several rectangles, with identifiers, and also determines their color and margin. Note that the playfield is an “input” (because we need to receive input from the player, so we use this object as a trick). Also, all “div” elements are within “div” elements, to prevent their relative positions from influencing each other (because several elements with an absolute position are within the same body).

Most of the above should be fairly obvious to you (if it isn’t you can peek at a few online courses: html and css).

A point of interest here is the fact that the HTML file includes our script (pong.js) as well as the jQuery script (jquery.js). You can download jQuery here.

what is interesting about jQuery is that it allows selecting the objects quite easily, and then telling them to do things such as moving. An extremely important function in the view is this:

var move = function(avatar,pos,spd,size)
{ var x = pos.x - size.w + field.w;
  var y = pos.y - size.h + field.h;
  avatar.stop()
    .css({left:x,top:y})
    .animate({left:x+10*spd.vx, top:y+10*spd.vy},10000,"linear");
};

This function has four parameters: the ‘avatar’ is a jQuery object representing one of the “div” elements above (the ball, a paddle etc), the ‘pos’ is the position (with x and y coordinates) where that object should be, ‘spd’ is the velocity (with vx and vy coordinates) with which the object moves, and ‘size’ is the dimensions (with w and h coordinates) of that object. The dimensions are required because the position of a jQuery object (with ‘absolute’ positioning, as we are using here) is expressed as an offset between the top-left corner of the screen and the top-left container of the object itself, whereas the position in the model is the offset between the center of the playing field and the center of the object. So, variables ‘x’ and ‘y’ are computed to represent the object’s position on the HTML page.

This function stops the current movement of the avatar with ‘stop()’ then sets the left and top coordinates with ‘css()’, and finally asks the object to move with ‘animate()’ by specifying the destination (which we compute by adding the distance traversed in ten seconds to the current position), the duration (10 seconds = 10000 milliseconds) and the animation style (“linear”, which means there are no accelerations and no brakes).

In short, this function should be called whenever the movement of an object changes: jQuery then takes care of animating the object until its movement changes again. This way, we don’t have to change the movement of objects every ten milliseconds.

However, this requires the view to store the previous value of movement, in order to determine when movement changes by comparing the new value and the old value (if they’re the same, no changes happened). So, the view object would look like this:

function view()
{ this.ball   = {   vx: null,    vy: null };
  this.scores = { left:    0, right:    0 };
  this.paddle = { left: null, right: null };
  this.avatar = { ball: $('div#ball'),
                  sc_l: $('div#score_left'),
                  sc_r: $('div#score_right'),
                  pa_l: $('div#paddle_left'),
                  pa_r: $('div#paddle_right'),
                  play: $('input#playfield') }; 

  this.avatar.ball.width(1.9*ball.w)  .height(1.9*ball.h);
  this.avatar.pa_l.width(1.9*paddle.w).height(1.9*paddle.h);
  this.avatar.pa_r.width(1.9*paddle.w).height(1.9*paddle.h);
  this.avatar.play.width(2*field.w)   .height(2*field.h);
}

This class does the following things:

• It defines members “ball”, and “paddle” which contain the velocities (but not positions) of paddles and the ball. So, when velocities change, the view notices and asks jQuery to change the trajectories. It also defines the currently displayed score (so that, when these change, they are updated).
• It defines the avatars: this is done by using the jQuery selector: $(‘div#paddle_left’) selects the DIV element with the identifier ‘paddle_left’ that we defined in the HTML page earlier.
• It resizes the avatars based on the constants, with the functions ‘width()’ and ‘height()’. Note that the width and height of the ball and paddles are smaller than they should be: this is a common trick for games, since players are bound to notice some close misses and interpret them as “this shouldn’t have missed”, making the image of the paddles and ball smaller reduces near misses and keeps the players happier.

Next, the view object uses a ‘render()’ function to display things. This function will use the ‘move()’ function we defined earlier:

view.prototype.render = function(model)
{ var move = function(avatar,pos,spd,size)
  { var x = pos.x - size.w + field.w;
    var y = pos.y - size.h + field.h;
    avatar.stop()
      .css({left:x,top:y})
      .animate({left:x+10*spd.vx, top:y+10*spd.vy},10000,"linear");
  }; 

  if (this.ball.vx != model.ball.vx || this.ball.vy != model.ball.vy)
  { this.ball.vx = model.ball.vx;
    this.ball.vy = model.ball.vy;
    move(this.avatar.ball,model.ball,this.ball,ball) } 

  if (this.paddle.left != model.left.vel)
  { this.paddle.left = model.left.vel;
    move(this.avatar.pa_l,
         {x: -paddle.x, y:model.left.pos},
         {vx: 0, vy: this.paddle.left}, paddle) } 

  if (this.paddle.right != model.right.vel)
  { this.paddle.right = model.right.vel;
    move(this.avatar.pa_r,
         {x: paddle.x, y: model.right.pos},
         {vx: 0, vy: this.paddle.right}, paddle) } 

  if (this.scores.left != model.scores.left)
  { this.scores.left = model.scores.left;
    this.avatar.sc_l.html(model.scores.left) } 

  if (this.scores.right != model.scores.right)
  { this.scores.right = model.scores.right;
    this.avatar.sc_r.html(model.scores.right) }
}

The render function always checks whether the current value inside the model is different (!=) from the value stored in the view (this). When this is the case, the ‘move’ function is called to move the appropriate avatar in the appropriate fashion (or, in the case of scores, the inner text of the score avatar is changed using the ‘html()’ function from jQuery).

The Controller

The last piece of the game is the controller. It should gather information from the user, compute the AI’s response to ball movement, and measure how long has elapsed since the last time the view has been refreshed and update the model accordingly.

This time, the controller has no reason to be an object, because nobody will manipulate it (except, of course, itself). Instead, we can just define some values inside a function and use them to do the job:

var gameModel = new model();
var gameView  = new view();

As a first step in implementing the controller, we need to extract the keypresses from the user and write a function that applies them. This is done as follows:

  var keys  = { up: false, down: false }; 

  gameView.avatar.play.keydown(function(event){
    if (event.which == 38) keys.up = true;
    if (event.which == 40) keys.down = true;
    return false
  }); 

  gameView.avatar.play.keyup(function(event){
    if (event.which == 38) keys.up = false;
    if (event.which == 40) keys.down = false;
    return false
  });   

  var playerMoveLeft = function(model)
  { model.moveLeft((keys.up ? -1 : 0) + (keys.down ? 1 : 0)); }

The ‘keydown’ function provided by jQueryhas a single parameter, which is a function. That parameter will be called whenever an unpressed key is pressed when the playing field is selected. The same happens for ‘keyup’, which reacts when a pressed key is released. The functions check what the key was by looking at ‘event.which’: a value of 38 is the “up” arrow key while a value of 40 is the “down” arrow key (39 and 41 are the left and right arrow keys, respectively). The functions also use the statement ‘return false’: this notifies the playing field (which is originally a text field from a form) that the key press should be ignored, instead of adding the letter to the field.

What the functions do is set the value of keys.up and keys.down: the “playerMoveLeft” function then reads the value of the keys to determine which keys are currently pressed. The “a ? b : c” construct uses “b” if “a” is true, and “c” otherwise. So:

• If the up key is pressed but the down key is not, the direction is -1 + 0 = -1
• If the down key is pressed but the up key is not, the direction is 0 + 1 = 1
• If neither key is pressed, the direction is 0 + 0 = 0
• If both keys are pressed, the direction is -1 + 1 = 0

So, the code above correctly responds to player input whenever the ‘playerMoveLeft’ function is called.

Another step is to define a similar aiMoveRight function for computing the AI response. We want the AI do to something smart enough to be challenging. However, since the ball moves slowly from left to right, a perfect AI could simply compute where the ball will land and wait there: it would therefore never lose. This is a good thing for computer science, but a bad thing in game: a good game AI is not an AI that always wins, but an AI that loses in a challenging and fun manner.

The following code accomplishes this:

  var aiMoveRight = function(model)
  { var dir = 0;
    if (model.ball.vx > 0)
    { var dist = (paddle.x - model.ball.x);
      var target = model.ball.y + model.ball.vy * (dist / model.ball.vx);
      while (target > field.h-ball.h || target < ball.h-field.h)
      { if (target > 0) { target = 2*(field.h-ball.h) - target }
        else            { target = 2*(ball.h-field.h) - target }
      }            

      dir =
        (model.right.pos + paddle.h < target ?  1 : 0) +
        (model.right.pos - paddle.h > target ? -1 : 0)  

      var accuracy =
        field.h * Math.exp((model.scores.left - model.scores.right)/3); 

      if (dist > accuracy)
      { dir = -dir }
    } 

    model.moveRight(dir);
  }

The general structure of the code is reasonably easy to get: the code computes the direction in which the AI (right) paddle should move, then sets that direction on the last line. If the ball is not moving right (vx > 0) the AI paddle does not move (dir = 0). However, if the ball is indeed moving right, then the computation starts: the algorithm computes the distance between the ball and the paddle. From that, it computes the point where the ball should meet the paddle (and stores the vertical coordinate in the ‘target’ variable). Once the target is known, the direction is computed: if the paddle is below the target, it moves up, and if it’s above, it moves down. This is a perfect AI: it never loses because it always knows where the ball hits and moves there immediately. So, we dumb it down by adding accuracy: if the ball is further away from the paddle than a certain distance threshold (stored in the ‘accuracy’ variable) then the paddle does the opposite of what it should do (dir = -dir).

The two important questions here are: how is the target determined, and how is the accuracy determined?

The target is computed by determining where the ball would end up if there were no top or bottom edges: one simply calculates the horizontal distance and deduces from the horizontal and vertical speed ratio the vertical distance that it will go from its current position. Once this position is known, the code takes into account bounces: if the target is outside the top or bottom edges, then it will bounce, which means that the target position should be reflected around that edge. For the bottom edge, reflection is done with ‘target = 2*(field.h-ball.h) – target’ and for the top edge it’s done with ‘target = 2*(ball.h-field.h) – target’. The AI repeats this reflection process until the target is within the playing field.

The accuracy is computed by getting the exponential of the score difference (with a few modifiers, ‘field.h’ and ’3′, obtained through playtesting). The point of using an exponential is that, as the score difference increases (in favor of the player) the exponential increases substantially and so the accuracy also increases, and as the score difference increases (in favor of the AI) the exponential decreases substantially without going below zero. So, the point of the exponential is getting an accuracy that increases when the player is doing well, without going below zero.

As a result, the AI starts playing perfectly when the player has three more points than the AI.

The last thing the controller does is keep the model and view up to date. To do this, it computes the current time (in seconds, with decimals) and also remembers the last time it was updated. Then, if the last update is more than one timestep ago, it updates the model and increases the last-update-time by one timestep, and repeats this process until the model is up-to-date. Then, it renders the model.

  var time = function() { return +(new Date) / 1000 };
  var last = time(); 

  var act  = function()
  {
    playerMoveLeft(gameModel);
    aiMoveRight(gameModel); 

    var now = time();
    while (now > last)
    { gameModel.update();
      last += timestep } 

    gameView.render(gameModel);
    setTimeout(act,50);
  }

The time function uses a common trick: it creates a date object (which by default contains the current time), converts it to the number of milliseconds since a fixed point in time, and divides it by 1000. The ‘return’ statement means that when the function is called, it will be replaced by the returned value (var last = time();).

The ‘act()’ function applies input to the game model, then performs as many updates as necessaryand finally renders the model. Then, it asks Javascript to execute ‘act()’ again in 50 milliseconds (that’s 20 times per second).

The result is to wrap all of this in a single ‘controller()’ function and ask jQuery to execute the entire thing when the document has finished loading:

function controller()
{ var gameModel = new model();
  var gameView  = new view();
  var keys  = { up: false, down: false }; 

  gameView.avatar.play.keydown(function(event){
    if (event.which == 38) keys.up = true;
    if (event.which == 40) keys.down = true;
    return false
  }); 

  gameView.avatar.play.keyup(function(event){
    if (event.which == 38) keys.up = false;
    if (event.which == 40) keys.down = false;
    return false
  });   

  var playerMoveLeft = function(model)
  { model.moveLeft((keys.up ? -1 : 0) + (keys.down ? 1 : 0)); } 

  var aiMoveRight = function(model)
  { var dir = 0;
    if (model.ball.vx > 0)
    { var dist = (paddle.x - model.ball.x);
      var target = model.ball.y + model.ball.vy * (dist / model.ball.vx);
      while (target > field.h-ball.h || target < ball.h-field.h)
      { if (target > 0) { target = 2*(field.h-ball.h) - target }
        else            { target = 2*(ball.h-field.h) - target }
      }            

      dir =
        (model.right.pos + paddle.h < target ?  1 : 0) +
        (model.right.pos - paddle.h > target ? -1 : 0)  

      var accuracy =
        field.h * Math.exp((model.scores.left - model.scores.right)/3); 

      if (dist > accuracy)
      { dir = -dir }
    } 

    model.moveRight(dir);
  } 

  var time = function() { return +(new Date) / 1000 };
  var last = time(); 

  var act  = function()
  {
    playerMoveLeft(gameModel);
    aiMoveRight(gameModel); 

    var now = time();
    while (now > last)
    { gameModel.update();
      last += timestep } 

    gameView.render(gameModel);
    setTimeout(act,50);
  } 

  act();
} 

$(function(){new controller});

The Article

This game uses 200 lines of Javascript and 50 lines of quick-and-dirty HTML. It took me about three hours to develop. This article is the longest article so far on Nicollet.Net and took me an entire day to write. You can expect other video games and maybe even other tutorials in the future, in the same vein as this one. If you have questions, or if you have enjoyed this, make sure to add a comment below. Links to this tutorial from places where beginners ask a lot of questions are also most welcome.