Paul Evans is a senior programmer in Austin, TX that loves to build great things. Before moving from the UK he worked for Lionhead Studios on tools for the Fable Franchise, Milo and other unreleased titles. He is currently freelancing in Austin after spending some time at Portalarium. You can find him on Linkedin, see other things he has written on his personal blog and You can also follow him on twitter @PaulECoyote. Everything in this article is Paul's opinion alone and does not necessarily reflect his employers views, nor constitute a legal relationship. Contact Paul if you are working on anything interesting!
Posts by Paul Evans
  1. ActionScript Tips for Programmers of C#/C++ ( Counting comments... )
  2. Idempotent - A Word in the Cloud ( Counting comments... )
  3. Behind the Scenes of Bit By Bit Games First Release ( Counting comments... )
  4. Travel Tips from an Englishman in Texas ( Counting comments... )
  5. Let me introduce you to Gameduino ( Counting comments... )
  6. Micro Talks ( Counting comments... )
  7. The XmlSerializer class in C# is asymmetric ( Counting comments... )
  8. JS1K Oregon Trail. Games & Demos in 1k of Javascript ( Counting comments... )
  9. Indies, how do you make a living? ( Counting comments... )
  10. Pop your head up ( Counting comments... )
  11. (Audio Post) Round Table: DLC ( Counting comments... )
  12. Do or do not ( Counting comments... )
  13. Cover Fire for Coders ( Counting comments... )
  14. Cats have nine lives ( Counting comments... )

Paul Evans js1k Oregon Trail entry screen grabI decided to create a game for the last JavaScript 1k competition that recently ended themed around the Oregon Trail computer game.  It was a good exercise in scoping something small, iterating on it a few times and learning a little more about the language.

I am most familiar with Perforce for source control these days because that is what we use for a lot of the code at the studio, so I also took this as an opportunity to try and host something on github:

Unlike compiled languages that can use excellent crunching software like Crinkler to compress the executing code down (excellent article about the process), the interpreted source code has to be 1024 bytes or less.  As JavaScript has 16bit character strings, submissions had to take care they were within the byte limit rather than just counting characters.


First of all I have to admit it, I never played the Oregon Trail game on the Apple II.  I was born and grew up in the UK where I used great 8-bit machines like the Oric-1, Acorn Electron, BBC Micro (at school), Spectrum and C64.  Apparently there was a version for the C64 but I missed out.  Helpfully the demo organizers linked to a play-through on YouTube (just to warn you, there’s some raw language in there).  So one Saturday morning when I got up way too early for my own good, I decided to watch it.

Apparently people often die of Dysentery (eek!) while playing, though that did not happen on the play-through I watched.  I thought of trying to do a simple inventory management trade game, but the sheer volume of text and inputs made me think again.  I then thought I could do something about crossing the river but some people had already made something similar to what I was thinking.

Finally I settled on the idea of traveling down the trail itself.  There was already a nice wagon graphics demo there but with no game play, so the idea was unique enough.  A lot of the game during the play-through seemed to center around a wagon travelling down a trail and stopping at landmarks and rivers.  Crossing rivers involved complex decisions that would take me down the complex text simulation route again.  I decided that my wagon in 1848 had a crazy inventor that fitted the wagon with excellent suspension and a spring wound so tight that it provided a KITT like turbo boost to jump rivers.  It was my little game, I could have some creative license!


I started out by looking at tutorials at the MDN.  First I drew a background using a linear gradient with the help of this tutorial.

Next up I wanted to draw a wagon, I decided to keep it simple and use rectangles and circles to keep the source code simple.  After that I wanted to show movement, so next up was drawing a tree moving along the landscape.  The drawing shapes tutorial helped me figure out how to create the shapes and I wrote the game update function within an interval set every twenty milliseconds.

So I had a wagon that looked like it was moving, then I wanted a river.  I experimented with a few different shapes but a thickly drawn blue line took up little space and got the feeling across of the river.  I animated this at a slightly different speed to the tree to try and get the feeling across that the tree was in the background and the river was in the foreground.

The game never ended, so collision detection with the river was next – as the wagon never moved along the x axis, it was quite simple.  Then to implement the turbo boost – collision with the river only happened when the wagon was at ground level.  Playing the game at that point there was a way to multiple jump… which was kind of fun but made the game too easy.

When the wagon collides with a river the game comes to an end.  Refreshing the browser auto starts a new game.

I needed to display the score next which made it feel more like a score attack game.  The game seemed too easy to me though, so I made the river slowly grow.

Looking at the file size it was over twice the 1k limit, so time to shrink the file.  First I removed all the comments, then all the whitespace.  Still way over.  Renaming the variables to single or double character names shrunk the file to just under the 1k limit.


  • Use some kind of automated code shrinking tool. packer by Dean Edwards looks like a good place to start.
  • Animate the wheels
  • Have scrolling hills going at slower speed than the tree in the background to add more feeling of depth
  • Use mechanized abbreviation to shrink the code further, as explained by Marijn Haverbeke.
  • Experiment more with git – gitflow look interesting


It was a fun little experiment and a nice project to learn a few new things.  The source code is here – I am sure there are a hundred ways to improve on it.  The other entries in this competition can be found here.  Visit to see the entries for all three of the competitions that have happened so far.  It really is incredible what can be done with so little source code.