If you happened to flip through a PC gaming magazine in the late 1980s or early 1990s, you would’ve probably seen an ad for a game called Leisure
Suit Larry, or one of its many sequels. It was a graphic adventure game first released in 1987 with the primary goal of helping its protagonist get laid. Since most games then
leaned heavily into cartoon violence, Larry’s sexual innuendo stood out. To young boys at the time, it had the mystique of a shrink-wrapped Playboy in a convenience store.
After The Obsuritory – a blog providing reviews of old and less-well-known video games – published a
review of 1994’s Wolf, they followed-up with this additional review… written for a wolf.
Coder wants to grow the speech-to-text coding community, uses his fun game to advocate.
Dig Dog is a pretty fun little video game. Call it “Spelunky for kids”—and don’t think of that as a backhanded compliment, either. Dig Dog, which launched
Thursday on iOS, Xbox, Windows, and Mac, shaves away some of the
genre’s complications, controls smoothly, and has depth. It’s as if the modern wave of randomly generated, dig-for-surprises adventures had existed in early ’80s arcades. (And all for
only $3!)
I liked Dig Dog enough when I stumbled upon it at last year’s Fantastic Arcade event in Austin, Texas. But my
interest in the game spiked when its creator reached out ahead of this week’s launch to confirm something I’m not sure any other video game creator has done: coding an entire game by
himself… without using his hands.
Just want to play my game without reading this whole post? Play the game here – press a key, mouse button, or touch the screen to fire the
thrusters, and try to land at less than 4 m/s with as much fuel left over as possible.
In 1969, when all the nerds were still excited by sending humans to the moon instead of flinging cars around the sun, the hottest video game was Rocket (or Lunar) for the PDP-8. Originally implemented in FOCAL by high school student Jim Storer and soon afterwards ported to BASIC (the other dominant language to come as
standard with microcomputers), Rocket became the precursor to an entire genre of video games called “Lunar Lander games“.
Like many pieces of microcomputer software of the time, Rocket was distributed as printed source code that you’d need to carefully type in at the other end.
The aim of these games was to land a spacecraft on the moon or similar body by controlling the thrust (and in some advanced versions, the rotation) of the engine. The spacecraft begins
in freefall towards the surface and will accelerate under gravity: this can be counteracted with thrust, but engaging the engine burns through the player’s limited supply of fuel.
Furthermore, using fuel lowers the total mass of the vessel (a large proportion of the mass of the Apollo landers was fuel for use in the descent stage) which reduces its inertia,
giving the engine more “kick” which must be compensated for during the critical final stages. It sounds dry and maths-y, but I promise that graphical versions can usually be played
entirely “by eye”.
Atari’s 1979 adaptation is perhaps the classic version you’d recognise, although its release was somewhat overshadowed by their other vector-graphics space-themed release in 1979:
Asteroids.
Let’s fast-forward a little. In 1997 I enrolled to do my A-levels at what was then called Preston College, where my Computing tutor was a chap
called Kevin Geldard: you can see him at 49 seconds into this hilariously low-fi video which I guess must have been originally shot on
VHS despite being uploaded to YouTube in 2009. He’s an interesting chap in his own right whose contributions to my career in computing deserve their own blog post, but for the time
being all you need to know is that he was the kind of geek who, like me, writes software “for fun” more often than not. Kevin owned a Psion 3 palmtop – part of a series of devices with
which I also have a long history and interest – and he taught himself to program OPL by reimplementing a favourite game of his younger years on it: his take on the classic mid-70s-style graphical Lunar Lander.
I never owned a Psion Series 3 (pictured), but I bought a Series 5mx in early 2000 out of my second student loan cheque, ultimately wrote most of my undergraduate dissertation using
it, and eventually sold it to a collector in about 2009 for almost as much as I originally paid for it. The 5mx was an amazing bit of kit. But I’ll blog about that another day, I
guess.
My A-level computing class consisted of a competitive group of geeky lads, and we made sort-of a personal extracurricular challenge to ourselves of re-implementing Kevin’s take on
Lunar Lander using Turbo Pascal, the primary language in which our class was taught. Many hours out-of-class were spent
in the computer lab, tweaking and comparing our various implementations (with only ocassional breaks to play Spacy, CivNet, or my adaptation of LORD2): later, some of us would extend our competition by
going on to re-re-implement in Delphi, Visual Basic, or Java, or by adding additional levels relating to orbital rendezvous or landing on other planetary bodies. I was quite
proud of mine at the time: it was highly-playable, fun, and – at least on your first few goes – moderately challenging.
I sometimes wonder what it would have looked like if I’d have implemented my 1997 Lunar Lander today. So I did.
Always game to try old new things, and ocassionally finding time between the many things that I do to code, I decided to expand upon my recently-discovered
interest in canvas coding to bring back my extracurricular Lunar Lander game of two decades ago in a modern format. My goals were:
A one-button version of a classic “straight descent only” lunar lander game (unlike my 1997 version, which had 10 engine power levels, this remake has just “on” and “off”)
An implementation based initially on real physics (although not necessarily graphically to scale)… and then adapted as necessary to give a fun/playability balance that feels good
Runs in a standards-compliant browser without need for plugins: HTML5, Canvas, Javascript
Adapts gracefully to any device, screen resolution, and orientation with graceful degredation/progressive enhancement
You can have a go at my game right here in your web browser! The aim is to reach the ground travelling at a velocity of no more than 4 m/s
with the maximum amount of fuel left over: this, if anything, is your “score”. My record is 52% of fuel remaining, but honestly anything in the 40%+ range is very good. Touch the screen
(if it’s a touchscreen) or press a mouse button or any key to engage your thrusters and slow your descent.
“Houston, the Eagle has landed.” Kerbal Space Program, it isn’t. Here’s a very good landing: 3 m/s with 48% of the fuel tank remaining.
And of course it’s all open-source, so you’re more than welcome to take it, rip it apart, learn from it, or make something better out
of it.
Official Post from The Video Game History Foundation: Something pretty fun happened yesterday that I wanted to share with you all: a bot on Twitter accidentally provided the clue
that finally solved a 28-year-old mystery about a DOS game that never shipped.Yesterday, the VGHF Twitter account was tagged in a thread by @awesomonster, who was frantically
Something pretty fun happened yesterday that I wanted to share with you all: a bot on Twitter accidentally provided the clue that finally solved a 28-year-old mystery about a DOS game
that never shipped.
Yesterday, the VGHF Twitter account was tagged in a thread by
@awesomonster, who was frantically trying to figure out the origins of a screenshot:
The year was 1995, and CompuServe’s online service cost $4.95 per hour. Yet thousands of people logged into this virtual world daily.
WorldsAway was born 20 years ago, when Fujitsu Cultural Technologies, a subsidiary of Japanese electronics giant Fujitsu, released this online experiment in multiplayer communities.
It debuted as part of the CompuServe online service in September, 1995. Users needed a special client to connect; once online, they could chat with others while represented onscreen
as a graphical avatar.
I was already a veteran of BBSes (I even started my own), Prodigy, CompuServe, and the Internet when I saw an advertisement for WorldsAway in CompuServe magazine (one of my favorite
magazines at the time). It promised a technicolor online world where you could be anything you wanted, and share a virtual city with people all over the globe. I signed up to receive
the client software CD. Right after its launch in September, I was up and running in the new world. It blew my young mind.
Sid Meier’s Alpha Centauri[1] (which we fondly refer to here as SMAC,
both as an acronym and in reference to its potent addictive properties) opens in an odd way for a science fiction game. Most such games open with spaceships, star travel,
or some futuristic technology. They seek to hook the imagination. But our game begins much more humbly.
SMAC begins with a largely static image of the stars as a woman reads a passage from the book of Genesis, telling the story of man’s final and irrevocable expulsion from the Garden of
Eden. The reading goes on for about twenty seconds, which is long enough for the lack of action to be quite noticeable. The effect is that we, the players, are being
invited to join the woman in literary contemplation. This, in and of itself, is a strange thing to find in a game – and a strategy game, no less!
The attentive viewer will notice that as the woman ends her quotation, she cites her source as “The Conclave Bible, Datalinks”. Odd … one would normally expect chapter and verse
from a bible quote. What are the Datalinks? And which edition is the Conclave Bible?
There isn’t much time to dwell on those questions, though. As the woman finishes, the music strikes up and we are treated to a series of disjointed images from the Earth we
know. The context isn’t clear, but the message certainly is. These are scenes of chaos: fire; military equipment; rioting crowds; nuclear explosions; escalating debt –
each one flashes by just after it has time to register. The world is out of control. It’s literally on fire. And it’s hurtling toward calamity…
As you may know, I’ve lately found an excuse to play with some new web technologies, and I’ve also taken the opportunity to try to gain a deeper
understanding of some less bleeding-edge technologies that I think have some interesting potential. And so it was that, while I was staffing the Three Rings stall at last week’s NCVO conference, I made use of the
time that the conference delegates were all off listening to a presentation to throw together a tech demo I call Steer!
A player uses their mobile phone to steer a car on a desktop computer, using nothing more than a web browser.
As you can see from the GIF above, Steer! is a driving game. The track and your car are displayed in a web browser on a large screen,
for example a desktop or laptop computer, television, or tablet, and your mobile phone is used to steer the car by tilting it to swerve around a gradually-narrowing weaving road. It’s
pretty fun, but what really makes it interesting to me is the combination of moderately-new technologies I’ve woven together to make it possible, specifically:
The Device Orientation API, which enables a web application to detect the angle at which
you’re holding your mobile phone
Websockets as a mechanism to send that data in near-real-time from the phone to the browser, via a web server: for the
fastest, laziest possible development, I used Firebase for this, but I’m aware that I could probably get better performance by running a
local server on the LAN shared by both devices
The desktop browser does all of the real work: it takes the orientation of the device and uses that, and the car’s current speed, to determine how it’s position changes over the time
that’s elapsed since the screen was last refreshed: we’re aiming for 60 frames a second, of course, but we don’t want the car to travel slower when the game is played on a
slower computer, so we use requestAnimationFrame to get the fastest rate possible and calculate the time between renderings to work out how much of a change has
occurred this ‘tick’. We leave the car’s sprite close to the bottom of the screen at all times but change how much it rotates from side to side, and we use it’s rotated to decide how
much of its motion is lateral versus the amount that’s “along the track”. The latter value determines how much track we move down the screen “behind” it.
The track is generated very simply by the addition of three sine waves of different offset and frequency – a form of very basic procedural generation. Despite the predictability of mathematical curves, this results in a moderately organic-feeling road
because the player only sees a fraction of the resulting curve at any given time: the illustration below shows how these three curves combine to make the resulting road. The difficulty
is ramped up the further the player has travelled by increasing the amplitude of the resulting wave (i.e. making the curves gradually more-agressive) and by making the road itself
gradually narrower. The same mathematics are used to determine whether the car is mostly on the tarmac or mostly on the grass and adjust its maximum speed accordingly.
In order to help provide a visual sense of the player’s speed, I added dashed lines down the road (dividing it into three lanes to begin with and two later on) which zip past the car
and provide a sense of acceleration, deceleration, overall speed, and the impact of turning ‘sideways’ (which of course reduces the forward momentum to nothing).
This isn’t meant to be a finished game: it’s an experimental prototype to help explore some technologies that I’d not had time to look seriously at before now. However, you’re welcome
to take a copy – it’s all open source – and adapt or expand it. Particular ways in which it’d be fun to improve it might include:
Allowing the player more control, e.g. over their accelerator and brakes
Adding hazards (trees, lamp posts, and others cars) which must be avoided
Adding bonuses like speed boosts
Making it challenging, e.g. giving time limits to get through checkpoints
Day and night cycles (with headlights!)
Multiplayer capability, like a real race?
Smarter handling of multiple simultaneous users: right now they’d share control of the car (which is the major reason I haven’t given you a live online version to play
with and you have to download it yourself!), but it’d be better if they could “queue” until it was their turn, or else each play in their own split-screen view or something
Improving the graphics with textures
Increasing the entropy of the curves used to generate the road, and perhaps adding pre-scripted scenery or points of interest on a mathematically-different procedural generation
algorithm
Switching to a local LAN websocket server, allowing better performance than the dog-leg via Firebase
Greater compatibility: I haven’t tried it on an iPhone, but I gather than iOS devices report their orientation differently from Android ones… and I’ve done nothing to try to make
Steer! handle more-unusual screen sizes and shapes
Anything else? (Don’t expect me to have time to enhance it, though: but if you do so, I’d love to hear about it!)
What do you expect for free? Well whatever you expect, you should expect more. This game takes the engine and content you know and love from Half-Life 2, updates it, and dumps you into
a whole new narrative with some fun new concepts (like using lights and darkness to manipulate enemies) and battles that should challenge even the most-hardened Half-Life player.
And did I mention it’s free? Go play it, and then go make a donation to the charity that the author recommends on their website. Worth every penny.
The most intense and engaging VR experience I’ve ever had.
Whether you’re dodging and diving behind cover while you fire your pistol or you’re getting up-close with the androids as you swing your laser sword, you’re always on the move in this
immersive, high-energy VR shooter. The teleport mechanic minimises motion sickness even for those who suffer badly, the graphics are
nothing short of beautiful, and there’s nothing quite so terrifying as the moment that you realise that THERE’S ONE OF THEM BEHIND YOU! MOVE!
Oh… Sir! The Insult Simulator is a light-hearted, (quite literally) Monty Python-silly timed-turns insult-spitting game for one or two players. It’s the perfect casual
luck-heavy puzzler for anybody whose hovercraft is full of eels, whose parrot is pining for the fjords, or who would like to learn The Meaning of Life. There are fun unlockables to keep
you playing for a couple of hours, and it’s worth every penny of the £1.43 I paid for it (I’d have loved it at £1.50, too, except that I wouldn’t have seen it in the first place were it
not on sale).
So the next time somebody tells you that you have a silly walk or you decide that you’d like to have an argument, just remember to tell them: “Your mother secretly admires your liver,
and will soon be dead.” That ought to put them in their place! But until that day, give Oh… Sir! The Insult Simulator a go.
I’ve been happy with my 2016 HTPC, but the situation has changed, largely because of something I mentioned in passing back in November: The Xbox One and PS4 are effectively plain old
PCs, built on: Intel Atom class (aka slow) AMD 8-core x86 CPU 8 GB RAM AMD Radeon 77xx / 78xx GPUs cheap commodity…
