Site logo, www.grelf.net
 

The Forest - orienteering simulation

The program described here demonstrates a technique for generating vast terrain by an algorithm rather than storing it in memory or having to download it as a huge amount of data.

A major aim of The Forest, from its earliest version some 35 years ago, has been to help people interpret the contour information in maps. That enables orienteers to navigate without just following roads or streams, it helps hill walkers to avoid getting lost, and more generally it helps anyone reading a map to get the most out of it.

This program also includes a non-trivial game for those who are not orienteers.

The version available here is written in JavaScript for an HTML5 page and occupies only about 100 kilobytes, so it downloads and runs almost instantly.

Try it: The Forest

New alternative URL, easier to remember: myforest.uk

I first used the method in the early 1980s in a program for the Sinclair ZX Spectrum, a machine having only 48 kilobytes of useable memory. That program simulated the sport of orienteering quite successfully despite the severe limitations of the technology. More details can found in the History section below, which includes a link to an archive for obtaining the old program and running it on a Spectrum emulator.

I am keen for other programmers to learn about the technique and perhaps take it further, so the source code of the new program is easily viewed.

 The Forest reincarnated

There are three views of the terrain available in The Forest:

This text is from www.grelf.net

Although there are buttons for switching between these views there are also keyboard alternatives indicated on the buttons.

 Map and 3D plot

The map has 4 states, selectable through a button:

This text is from www.grelf.net

All show north lines 300m apart.

Printed orienteering maps declare their scale and contour interval but we cannot do that here. The scale depends on the size of your display screen. However, 1 pixel on the map represents 1 metre on the ground and the initial map is 800 pixels wide and 600 high. The north lines indicate the scale because they are 300m apart. The vertical scale in the scene display is rather arbitrary, so it is not possible to say what the contour interval is either. Just assume it is the usual 5m.

The map can be rotated clockwise in steps of 90°. North lines on the map have black arrows so that when the map has been rotated the direction of north is clear. Some orienteers find it easier to relate the map to the ground if it is oriented roughly to the direction they are facing.

The aim of the 3D plot is to help people interpret contour lines on the map. It may take several seconds to draw the plot - rather longer than the scene or map views.

 The scene view

The scene view indicates what the observer would see from an eye level 1.5m above the ground. The view indicates whether the ground ahead slopes up or down, according to the contours on the map. The type of terrain ahead is indicated by graphics. One of the advances here is that real photographic images can be used rather than simple drawn graphics. The ground is drawn in true perspective out to a certain distance ahead (the visible range). Initially this range is set to 30m but you can select greater ranges. You will soon find that if the range is too great it will take an appreciable time to draw the scene (depending on the speed of the processor in your computer). For moving through the forest it is desirable to keep the scene drawing time to less than a tenth of a second (100ms) The drawing time is shown in a status line below the display.

The arrow keys are active in the scene and they act as follows.

NB:

  1. The arrow keys may scroll/pan the window in some browsers or on small screens, so letter key alternatives are allowed: initials of Right, Left, Up , Down (upper or lower case).
  2. On touch screens it is possible to tap near the edges of the scene or map instead of using arrow keys. On a PC a mouse click just inside an edge of the image will also work.

Note that the observer's current position (x, y) and bearing (degrees clockwise from due North) are shown in the status line at the bottom of the view. A compass is also shown at the bottom centre of the scene view.

Shallow lakes may be crossable but if the depth becomes greater than a couple of metres you will be told you are out of your depth and you will be turned around to swim back to the shore. So venturing into lakes can be very time-consuming.

Why do level things such as lakes appear to slope down at the edges of the scene? Because we are viewing a circular disc patch of ground from a small eye-level distance above it. The effect becomes less as the visible range is increased.

 Roles

The observer mentioned above may have one of several roles:

 The easy short course

 At the finish

When an orienteer completes a course the full control card and a table analysing the route are shown:

 

How can the orienteer complete a leg of the course by travelling less than the crow-fly distance? Easily because it is only necessary to be within 5m of a control for it to be punched. By approaching and leaving controls in the right direction it is possible to cover up to 10m less than the actual distance between controls. This is not just a feature of this simulation: it now happens in the real sport because electronic devices are used for automatic punching when within 5m of a control.

Try it: The Forest

 Additional keys

Some keys have effects which are not represented by buttons or other controls on the web page. They only work unshifted (lower case). They are perhaps experimental and may or may not develop into something more.

 Two windows

On a PC (but not on a tablet or phone) you may well have room on the screen for part of the map alongside the scene on the ground. This can be achieved by having two browser windows open, each with a copy of the program running in it:

 

 Explorers: a game for you

Now available (version 18.5.15 onwards)

Explorers can see things in the forest which orienteers cannot. Some of these things will suggest a target to aim for (more achievable than in my 1980s Explorer version of this program: see Pixelatron).

You will inevitably want to copy and save images of some of the things you see but this program does not provide any such facility. Instead you will need to use a screen copying program in whichever system you are running, such as the Snipping Tool in Windows.

Hint: there is a short-cut, described in this page, for something which may at first seem very lengthy in your task.

 Further information

There are some pages about my orienteering maps of real forests here. Follow the links there to read more about the original ZX Spectrum simulation of orienteering.

In particular there is a page about why The Forest is designed the way it is, which I wrote in the mid-1980s. It still has some relevance, especially about why I do not attempt to use maps of real forests (a scarce resource in the UK).

I started developing the new HTML5/JavaScript version in 2014 but it was heading more towards my second Spectrum program, Explorer (published by Electric Dreams in the mid-1980s). It included the possibility of falling down mineshafts and navigating underground. It also included a teleportation feature whereby typing a string of characters would take you to a new position on the map, seemingly at random but the same string would always go to the same place. Having got those features to work I rather lost interest in that development and shelved it.

My interest began again in February 2018 with an email out of the blue from Graham Scott of NATO (Newcastle and Tyneside Orienteers). He and I had been members of Tyneside Orienteers (as it was then) more than 30 years ago. I decided to complete the program as a purely orienteering project. Try it: The Forest

 Programming

The original versions of The Forest and Explorer were written in Z80 assembler, in order to fit into the very limited amount of memory available and to run at a reasonable speed (much faster than interpreted BASIC). The new version at www.grelf.net/forest/forest.html is written in JavaScript, a much more easily comprehended language, running within an HTML5 page and doing the graphics within <canvas> elements. If you right-click and "view source" on that page you can see the file names for the JavaScript files and therefore view them also in your browser, to see how it works. If you are not familiar with JavaScript, particularly its object-oriented aspects, you may wish to peruse my introductory programming course.

Note again that the program runs entirely in your browser. After downloading the program and images the server has no further involvement. The browser does all of the hard work of course, and that is a very much larger program. I am amazed by how much detail it is now possible to show in real time by writing some JavaScript and running it in a standard browser.

The contours and terrain types repeat after 33km (32768m to be precise; older programmers will recognise that number instantly) but the point features do not repeat like that.

I am documenting aspects of the software design here.

Programming challenge

If you are already a JavaScript programmer you will be able to explore my code. Then you might like to try this:

Find the (x, y) coordinates of the highest point on the map (in the first block of the 32km repeating terrain, starting at 0, 0). Is this point unique (are there any other points at the same height)? Do the same for the deepest points in the lakes. Please email me with the answers, at gr[at]grelf{dot}net - I will be interested to see whether anyone does this. It doesn't take much code.

 Remaining work

May 2018: I plan to keep adding better graphics and more features, such as alternative games for those explorers who complete the first quest. I am open to ideas for further enhancements.

 Development environment

I am developing the program on a Microsoft Surface Pro 4 running 64-bit Windows 10. I use Netbeans 8.2 IDE (free Integrated Development Environment) with its HTML5/JavaScript plug-in kit, mainly because I already had it for Java programming. An IDE is not essential for this work but it does offer suggestions as I type and it does point out syntax errors immediately. When I am unsure about any JavaScript detail I use the Mozilla reference pages which I find more thorough and up-to-date than the old w3schools site. I test the program by loading the HTML file into the Firefox Quantum browser. I do not use a localhost server (no need). Firefox has a very useful Web Console (under the Web developer menu, or key Ctrl+Shift+K) which gives me the script file name and the line number at which any run-time error is detected. I upload the tested files to my web site using Filezilla FTP (free). To avoid possible probems with script caching in client browsers I increment a suffix letter on the name of each script file that changes for a new version. That way the user would only need to refresh the HTML page to ensure that all the correct script versions are loaded.

I have only tested The Forest in Firefox, Edge and Internet Explorer 11 on PC and Chrome on an Android smartphone. Timings for drawing are fine in all those browsers. I would welcome feedback (gr<at>grelf<dot>net) on performance in other browsers: how long does each take to draw the initial scene, map and 3D plot, as shown in a status line below the graphics? Average of 3 readings please (times vary due to the browser doing other things).

 History

In May 2014 I had a blast from the past about some games I wrote for the Sinclair ZX Spectrum and similar machines 30 years earlier. It seems that the current resurgence of interest in popular programming may be reviving the ideas behind the games. I had a particular technique of my own for generating terrain on a large enough scale to be explorable, despite the lack of memory in those early machines (the Spectrum had only 48k bytes - and that was the larger version). Indeed, one of my games was simply called Explorer. Its predecessor, The Forest, was a simulation of the sport of orienteering.

Explorer was developed as more of a team effort. The programming was still all mine but the graphics were created by Simon Dunstan, of the RamJam Corporation in London. He was able to do wonderful things in the extremely limited graphical environment of the Spectrum. RamJam got the program published through Electric Dreams.

There is a web site called World of Spectrum where a group of people are attempting to assemble an archive of all programs written for the ZX Spectrum and make many of them available to download and run in one of the many Spectrum simulators that are now also available for free. They have listed my two programs here (they have promised to correct the spelling of my name).

There is also an interesting article looking back at Explorer on Mark Green's blog, Pixelatron.

Technology has advanced so much in 30 years that much better versions of such games are now practical. For one thing processor clock speeds have gone up by a factor of nearly 1,000 - the Spectrum ran (I think) at 4 MHz. It is common now to have multiple processors in a single machine (eg, the Intel Core i5 etc), giving another potential speed increase. Also the processing of graphics is now usually hived off to a separate Graphics Processing Unit (GPU) rather than the Central Processing Unit having to do everything, as was the case all those years ago. Today's processors also have special instructions built into their hardware for frequently used computations. I think it was in the mid-1980s that Intel processors (such as 80286) started to have companion chips called coprocessors, for doing non-integer arithmetic. Devices on silicon have now been so much further miniaturised that all such work can now be done on a single chip rather than requiring a coprocessor.

It is now common to have gigabytes of main memory. The Surface tablet/laptop on which I am writing this has 16 Gbytes of RAM, which is 333,000 times that of the Spectrum. It almost goes without saying that we can now have very much better graphics, of photographic quality, something I could only dream of in the 1980s.

I have shown that it is possible to re-implement the Forest/Explorer games in HTML5 with JavaScript, making them available on just about any platform that can browse the web. Despite the fact that JavaScript is run interpretively by the browser, which is in principle much less efficient than the assembly code I wrote for the Spectrum's Z80 microprocessor, speeds are still much better than 30 years ago. The HTML5/JavaScript version can be seen here: www.grelf.net/forest/forest.html. It runs entirely in the browser, there is nothing executed on the server. The entire source program is about 100 kilobytes, so it downloads and starts almost instantly (unlike some Steam programs that take many hours to download because they include vast amounts of data). The JavaScript has not been compacted or compressed because I want others to be able to understand the techniques and perhaps develop them further. This text is from www.grelf.net

 Earlier writings

In 1982 I had two articles published in the now long-defunct British magazine "Practical Computing". The articles described the basic techniques I was using to generate terrain from mathematical functions rather than storing it in memory. Following here are links to scanned images of the articles.

March 1982

Cover image

Page 93

Page 95

September 1982

Cover image

Page 127

Page 129

Page 130

Next page