ocamllabs / 2048-tutorial Goto Github PK

After visiting the link in #16 from my iOS device, I thought it would be cool to add support for swipe input and also fit the board to the browser window.

This obviously won't be ready for the actual tutorial but perhaps can be considered later — or maybe some hints provided for those keen enough to try and implement it.

We discussed setting up Cubieboards and VMs as a contingency plan in case people turn up with Windows computers.

Plan:

• @yallop to write a script that installs the relevant bits and pieces (OPAM packages, a copy of the project repository, etc.) for a fresh user account.
• @avsm to set up VMs (and Cubieboards?)

Prepare an offline OPAM repository (and perhaps a copy of RWO) for distribution on USB sticks (mostly in case the network goes down).

What packages do we need?

@kayceesrk noticed that the instructions are difficult to follow in places, and could be improved with examples or diagrams. For example, the instructions for shift_left_helper currently list various cases like this:

The first two squares are occupied by equal tiles. Merge them together, add an entry to the empties list, and process the rest of the row.

which sounds rather like medieval mathematics and could be made clearer with diagrams, perhaps like this:

shift_left_helper   ..    ..   ↝ shift_left_helper  ..   ..

We might also note that the interpretation of shift depends on the direction of the last move.

Hi,
I'm interested in using and possibly adapting this tutorial for use in a workshop I'd like to teach.
Are there any extra restrictions on re-using this repo outside of the BSD2 license placed on the code in the 2048 directory?
The workshop would not be for profit, just fun.

Thanks

The polymorphic part isn't especially important for the tutorial, but we should note that structural equality is spelt = rather than ==.

A participant at the CUFP 2014 tutorial wrote an implementation of is_complete_row that passed the tests but misbehaved when run as part of the game. It seems that the tests didn't catch the interchanging of the Some and None cases.

• Defining datatypes
  • Very simple records and variants.
  • We won't need to define parameterised or recursive types (but those concepts will be needed to understand list)
• Lists
• Options
  • we should say that option isn't special (i.e. it's not OCaml's equivalent of null, which is sui generis)
• Constructing values
• Pattern matching
  • Using match should be sufficient: no need for destructuring let or for function
  • match for records, variants, options and lists
  • some deep pattern matching
  • when guards
  • nested match: need to parenthesize the inner match

So I investigated a bit. And it seems that the problem is in the canvas rendering performance (i.e. the call to Vgr.render). The numbers are rather astonishing. One thing I don't get is why Safari doesn't call us more often for animating as we are still below the 16ms limit for getting a 60Hz animation.

Here's an example of the render frame timings for a transition in the three browsers:

Chrome

START:
4.244ms; 4.255ms; 2.87ms; 4.163ms; 1.889ms; 2.36ms; 3.311ms; 3.692ms; 1.605ms; 2.658ms; 2.784ms; 2.162ms; 2.258ms; 1.688ms; 1.554ms; 1.951ms; 1.641ms; 1.564ms; 1.242ms;
END : 19 frames @ 63.3333hz 

Firefox

START: 
21.9351ms; 21.316ms; 19.3239ms; 19.8034ms; 23.8123ms; 20.0289ms; 22.8311ms; 21.8929ms; 22.9779ms; 24.0915ms; 21.9377ms; 21.2064ms;
"END : 12 frames @ 40hz

Safari

START:
7.00021ms; 9.00006ms; 16ms; 11.0002ms; 6.99997ms; 7.00021ms; 8.99982ms; 9.99999ms; 11.0002ms; 16ms; 15.0001ms; 9.99999ms; 9.00006ms; 8.00014ms;
END : 14 frames @ 46.6667hz

It'd be useful to have a sheet with a description of the project and an outline of what to do.

It'd be helpful to have an mli file for the Utils module.

• let (rec) for defining functions and values
• if/then/else
• function calls (including partial application)
• labelled arguments (if we're going to use Core)

Probablky just basic modules and signatures (no functors)

• improving representations/types for efficiency
• improving representations/types for correctness
• gameplay enhancements
• ui enhancements

I also think that we could could be less loose with the possible cases in provenance by using a variant (see actual comment above the datatype). This could make this pattern match more obvious. It may however complexify the provenance computation code, so this may turn out to be a bad idea.

https://github.com/ocamllabs/2048-tutorial/blob/master/task.md says

Uncomment the Shifting entry in the tests_enabled list in 2048/tests/test_enabled.ml and run the tests again.

but there is no such file.

The worksheet shows how to build the implementation and run the tests, but not how to build the application itself.