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.
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 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 js1k.com 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.