Often (but not always) we are trying to "optimise"
to make things faster i.e. optimising for time.

In the "olden days" this was relatively simple.
The procedure was roughly as follows:

But, on modern systems, it's no longer as easy as that...

Caches are a hugely important part of modern computer systems, and you really ought to be aware of them.

The simple version is that a cache is just a smaller,
higher-speed area of memory in which important data 
can be temporarily stored (yes, I'm simplifying!)

In fact, it's "Caches All The Way Down!"

Compare: "Turtles All The Way Down"

It turns out that the issue of whether your data
(and, indeed, your code) is in one of these cache layers
has a huge impact on runtime performance.

Main memory access speeds can actually be hundreds
of times slower than our CPU clock rates these days!

Caching often dominates any other performance factors
(including algorithmic ones!)

But caches are strange and unpredictable beasts...

The fact that caches are (largely) automatic,
history-dependent, and not directly under your
control, makes them difficult to reason about...

So, today, the advice is simple: "Always Measure"

If you aren't actually measuring your performance,
you are working blind, and will make invalid choices.

Many techniques which were once "optimisations"
(e.g. loop unrolling) can sometimes be "pessimisations"
in the presence of caches! So be careful.

In the land of Hard Cache, a good strategy is to start by implementing a simple, and obviously correct, version
of something and then get some measurements on it.

Then (and only then), if it isn't as fast as it needs to be,
look at algorithmic changes which might improve it
e.g. moving from O(N^2) to O(N), and redundancies
which could be eliminated e.g. stuff that isn't changing.

The "simple" version can then serve as a perf. baseline,
and a correctness check, for the "complex" one.

You can actually do decent performance analysis in the browser these days: modern browsers now have quite fancy "call-graph tracing" facilities which you can use to explore what's really going on in your JavaScript code.

In other contexts (e.g. C++ stuff) you often have to write your own call-tracking infrastructure (my preferred approach),
or use 3rd party tools which do something similar
(usually with higher overheads though).

It can be a pain (PC timers are crap!), but it's always worth it.

You might also have to find yourself optimising for
memory usage. Often, the strategy here is one of avoiding redundancy (don't store the same data in multiple places,
and consider whether it's better to recompute than to store!)

There are various ways of packing data into more compact formats too, but I won't go into them here.

I'll just tell you one evil trick, which some people use...

In game development, memory is usually at a premium,
and is always being stretched to the limit by the demands
of the "content" people. Being forced to cut "completed" features due to lack of memory is painful for all involved.

Having seen this once too often, some (slightly evil) programmers have adopted the following tactic:

On day one of a new project, preallocate a secret, unused, Megabyte (or 2?) somewhere in your personal diagnostic routines. Later, when "all is lost", take it out again, sit back,
and savour the accolades for your heroic "optimisations".

Also, it's sort of the wrong question.

The map is not the territory, and the exam is not the course.

Learning the subject is the important thing.

The exam is simply a crude instrument to assess that.

Concentrate on the former, and the latter will take
care of itself. Also, you will actually learn something.

...in fact, from what I can tell, you already have! Yay!

There are around 10 or 12 main areas in the course material, and I'll probably ask 4 or 5 questions about a subset of these.

I've decided to put more weight on the course work this year, so the exam will only count for 1/3 of your total mark.

There might be a little bit of coding involved,
but nothing too tricky, and I won't be pedantic about minor syntax errors, of the kind that would be caught easily if you were working on a real machine. If you've been able to do
the homeworks, you should be able to handle this too.

Read the slides, dummy!

In each main topic, there are a bunch of key principles,
and a cluster of related side-issues. You should learn these.

I don't expect you to memorise fine points of detail if they
are mere "factoids" that you could look-up when needed...

...but I do want you to understand orders of magnitude and rough chronologies e.g. knowing that Space Invaders was made in the 70s (not the 60s or the 80s) and that it ran on a 1MHz machine (not 100Hz; not 10MHz). You get the idea.

If you've been paying attention and doing the homeworks, and if you spend some time going over the slides again,
then you should do just fine...

...you may still want to keep up with the subject.

At least, I hope you will. Games provide a nice, interesting angle on Computer Science as a whole. They can sometimes be pretty "cutting edge" in fact, and are quite a fun way of staying in touch with developments across the field.

If you take the idea of being a programmer seriously, you'll want to go on learning new things and growing your skills.

The Internet is a godsend when it comes to this!

It's so easy these days, to learn almost anything...

In addition to just searching for things of interest, it can be useful to hook into some of the better online "communities" as a way of seeing what's going on, and discovering new things.

Twitter, for all its flaws, is actually pretty good for this.

Here's a decent list of people (and "entities") to follow.

It contains a mixture of the serious and the not-so-serious,
and I don't necessarily approve of, or agree with, all of them
(in fact, some of them are "old farts") --- but they are there for
a reason, and provide an interesting perspective on things.

I've been very pleased with the standard of the projects,
and the fact you've been able to make these things
in just three weeks, with just four people per team.

I hope you learned something from the exercise,
and that it was a relatively enjoyable thing to do.

If you're interesting in continuing to program computer
games (or anything else really), my main suggestion
at this point would be to "make another one".

If you tackle something a little bit different from what
you've already done in the course, it'll help you to extend
your capabilities and make you a bit more fluent.

Another thing worth trying would be to try revisiting some
of what you've done in the course in a few months, and to check that you can still do it e.g. try doing "Breakout" again.

If you want to go even further, there are a couple of things
you could pursue: an obvious one would be to look at 3D.

I claimed at the start of the course that this was "easy",
and was really just a matter of "adding another D".

That may only be partially true. ;-)

3D is, of course, a big subject... but the core of it is not that complex, and you can take a course on it here, I believe.

You can even do it in JavaScript now, with WebGL.

How did you find learning/using it?

I think that, despite some odd warts here and there,
it's a pretty decent language, and its importance
on the Web can't be denied.

The main language for high-end games in still C++,
(although I think there's room for innovation there now).

King Solomon once played a trick on his aides by asking
them to locate a mythical (non-existent) "magic ring",
which had the mysterious property of being able to
"Make A Sad Man Happy, and A Happy Man Sad".

After many months of searching, an aide returned,
bearing what he claimed to be such an ornament.

It was plain and simple, and not supernatural at all,
but it was inscribed with the following remark...

...as, I hope, will you... in the exam. :-)