                            THE HUMAN CPU EXPERIMENT
                      SpeedHack 2015 - Ben Wieczorek-Davis
                         www.speedhack.allegro.cc/2015
                             ben@wieczorekdavis.com


Do you take your computer for granted? Have you ever wondered what it must be
like to be your computer? Now you can try it. (Some programming experience may
be required to get the most out of this game.)


                                    LICENCE

You may distribute this game unmodified, or with minimal portability fixes, or
with an added executable, or both - provided that you do it strictly for
non-profit purposes.

You may of course enjoy the game to your parts' content.

All other rights are reserved.


                                     RULES

SpeedHack is a competition to write a game in a weekend. When the competition
starts, some rules are published. Below is how I have approached the rules. You
can read the full rule descriptions on the website.


                               Genre requirements

Seedlings ................. Your computer's wellbeing is in your hands. You will
                                soon see what human error does to your computer.


                             Technical requirements

Text Interactivity ............................ Ah, text. So easy for computers.

Particle Madness .............. You will see up to 2000 particles when you fail.


                             Artistic requirements

Sound Annoyance .............. Your computer is equipped with a state-of-the-art
                                 sound chip. Shame you don't know how to use it.

Physical Criminality ..... My favourite. See the section about hyperbolic space.


                                  Bonus rules

Act of Sequel (optional) .......................................... Not invoked.


                                HYPERBOLIC SPACE

Hyperbolic space seems to be exciting a lot of mathematicians at the moment, and
The Human CPU Experiment takes place in it. You will see this when you fail.

To grasp the intuition, start by thinking about a flat plane with tessellating
hexagons on it. Then think about what happens if instead of a plane, it's the
surface of a sphere. As you radiate from a point, the amount of space you have
is less than you expected, and you end up having to insert pentagons into the
tessellation to make it work. Hyperbolic space is the opposite. As you radiate,
you get more space than you expected, and you have to insert heptagons.

The above is a summary of 2D hyperbolic space. The Human CPU Experiment takes
place in 3D hyperbolic space, but the same intuition applies if you think of
having to tessellate dodecahedra instead of cubes.

In The Human CPU Experiment, the hyperbolic space affects the particles in two
ways. Once the effect has begun and the particles have their trajectories, they
proceed unaffected by any further forces; yet since there is more space than
expected around any given point, the space between the particles can be seen to
grow disproportionately fast. (If you like being able to find things, hyperbolic
space is not a pleasant place to live.) Secondly, you will sometimes see the
particles trace out strange curves. It is almost as if you are on the north pole
of a sphere and are watching them trace out a curved shortest path around the
equator, except of course it's the opposite type of curvature. You will need to
accept that these strange curves are in fact the shortest path.

If your brain is now bursting apart at the seams, then now is the perfect time
for you to jump in and play the game. This should be a hoot. Muahahaha.


                                    ABOUT ME

You might notice that instead of the usual

                        Ben 'Bruce "entheh" Perry' Davis
						       entheh@cantab.net

I have instead decided to list myself as

                              Ben Wieczorek-Davis
                             ben@wieczorekdavis.com

My secret is that I have been sitting on some musical compositions I'm rather
proud of for most of my life. This year I finally had the time, the means and
the resolve to start putting them out into the world in the form of YouTube
videos. It's slow-going - difficult to fit in around full-time work, and of
course on hold this weekend because SpeedHack always comes first! - but there
are two piano pieces published so far. If you're interested, you can find me by
searching for the new name, Wieczorek-Davis.

The name 'entheh' was borrowed from a friend of my brother's in Buxton where I
grew up. He was a little bitter that I stole it. All I can say is that I didn't
think it through: I just needed a name when I first went on IRC #allegro, and it
stuck. Sorry.

As for 'Bruce Perry', I was messing around on allegro.cc. There was a Chris
Barry and a Steve Terry and I was jealous, so I chose a name that followed the
pattern. Of course, with me also temporarily changing my name and picture so I
could impersonate poor Chris, and other members of the community being equally
silly, Matthew took away the automated name change facility - but Bruce Perry is
a nice name, so I felt happy to be stuck with it.

But then, Wieczorek was my maternal grandfather's name, and aside from making me
much easier to search for, I just think it sounds fantastic - and with a name
like that, my thinking is that perhaps it's finally time to create a consistent
identity across all my activities. If you disagree, at least you now have two
ways to tell me!


                                   COMPILING

I've written my entry in D again. D is a wonderful language which offers a lot
of the safety you get from Java or C# - things like garbage collection, bounds
checking, everything initialised to a default value - while still compiling to
native. Also, the deeper I get into it, the more fantastically good design
decisions I find - global variables being thread-local by default, type syntax
like const(char)* being less confusing ...

However, that does mean it might be one of the less trivial entries to compile.

The blurb above and the compilation instructions below are largely copied and
pasted from my SpeedHack 2014 entry Badonkadonk, where they were in turn largely
a copy and paste from my TINS 2012 entry Period Dragon. It's a while since I
actually set D up. So I hope the "bare minimum of instructions" I wrote last
time will be sufficient again! Unlike last time, however, I have been able to
provide a Windows executable within the timeframe of the competition. The
executable and necessary DLLs make the zip too big for the official SpeedHack
upload, but there will be a link in my progress blog on the SpeedHack site. If
you don't have the executable, have a look there.

               http://www.speedhack.allegro.cc/2015/blog/view/270

If you want to compile the game yourself, you will need Allegro 5.1, and you
will need it built with libpng. Many of my games require DUMB, but for a change,
this one doesn't.

You can get D from:

                               http://dlang.org/

I wrote the game using D 2.066.0. The language does evolve, so other versions
may require tweaks to the code, but hopefully nothing major.

You will also need to get SiegeLord's D bindings from here:

                     https://github.com/SiegeLord/DAllegro5

Follow SiegeLord's instructions to get up and running. You'll probably need to
generate D-format 'lib' files that map on to Allegro's DLLs. You might also need
other D dependencies.

D has the concept of 'import' paths - these are directories where other .d files
can be found, sort of. To be precise, if my file says "import allegro5.allegro;"
in it, and you've specified an import path of "C:\DAllegro5", then the D
compiler will need to be able to find "C:\DAllegro5\allegro5\allegro.d".

D also has library search paths - just specify the directories containing
Allegro 5's lib files.

You may need to mess around with DAllegro5's 'pragma(lib, "...")' lines - search
for pragma. It depends how your Allegro build is arranged. Or alternatively you
can just specify the required libraries on the command line.

Other than that, note that D tends to like to compile everything together.
Specify all the .d files at once.

For Windows, you're best building it as a console application until you've
established that it runs without crashing, as exceptions are logged to the
console. Once it works, I recommend compiling with -L/SUBSYSTEM:WINDOWS:4.0
- this will make it a Windows application instead of a console one.


                                      GIT

For the first time in one of these competitions, I made a git repository. In it
you can find some snapshots of the game as I was developing it. This is only for
people who have already tacked the COMPILING section above, as you will only get
source code, not an executable, by poking around in the repository. Even so, it
might prove interesting for someone.


                                  SCREENSHOTS

Pleasingly, it worked out that the screenshots were taken in alphabetical order.
