My Life in Video Games: The Klik & Play Days

June 28, 2009 – 5:18 pm

Let me start this episode by saying the history of Klik & Play is a confusing one, and nearly all of my work created using this legendary program are long lost to the sands of time. You’ll just have to trust me.

In desperation, the image to the left was unceremoniously stolen from SixSecondFiesta, and I think it accurately describes much of the style you’d get from Klik & Play: heavily-aliased Win32 fonts, remora-like attachment to 16-bit lopsided gradients, and mountains of uncoordinated, disturbing clip-art.

With that said, I’m going to chat a little bit about how my early years intertwined with this program to create some of the worst games ever. Strap in.

The Klik & Play years began during the eventual sunset of my beloved Level B4 BBS, sometime around 1993. MS-DOS 6.0 and the DOSSHELL environment inevitably lost ground to Windows 3.1, but in the transition away from EGA/VGA or text-based console interaction, gaming suffered greatly. Most of us, in search of gaming satisfaction in this new age, were expecting all of the fruits afforded by the confluence of the CD-ROM, the Windows GUI, and rapid advances in hard drive space and RAM. Instead, we got Jewel Thief.

(To be fair, we did get Inner Space and Proliferation, eventually).

If playing games in the hybrid space between console mode and genuine graphical UI was difficult, making them was damned near impossible. You’d have to ask Charles Petzold what was so difficult about getting access to the video layer in the Windows 3.1 days (between 1992 and 1994), but it’s telling to realize that Microsoft themselves (including Alex St. John, who had the honor of speaking in the illustrious basement meeting room of the Sea-Tac Marriott at my college commencement) didn’t decide something needed to be done to open up Windows to game programmers until Windows 95, three years later.

I feel obliged at this point to include a shot of Jewel Thief.

jewelthief3

Notice our main character - controlled entirely and unmolestedly by the direct mouse movements of the player (he is essentially a cursor), trying to grab gems on the surface of Mars while avoiding what are either flying elephants with swords or miniature cartographic drawings of Angola.

To be sure, we, the game players now itching to be game creators, took a serious blow to the heart (and head and neck) by what looked all the world like a regression.

We had MS-DOS still at the heart of it all, of course, and most games of the time were still made to be run in command mode at the prompt; indeed, the games themselves would unceremoniously puke if any attempt was made to run them in Windows 3.1. But if you weren’t a big-budget title good enough to make people want to back out of Windows into DOS mode to run you, (I’m not kidding, this was a serious consideration) and you knew Windows 3.1 turned your entire idea of a game into shuffling around random dialog boxes, what was left for the little guy?

In 1994, the answer came, published by Maxis and appearing in the mysterious CD-ROM format that the kids were whispering about in hushed tones along the hallway: Klik & Play.

g02715tw06t

While the title was developed by a European consortium, you’ll notice that Maxis, as the American publisher, put all the necessary stuff on the box to make an implicit promise of fulfillment to every single demographic they could think of:

  • D&D Nuts (Dragon)
  • Simulation Junkies (Stealth Fighter + Tank)
  • Fans of the Atari 2600 “ET” (Jetpack and UFO)
  • Your Mom, Who Thinks Games are the Devil (Clown)
  • Your Dad, Who Just Discovered Solitare on Win 3.1 (Playing Cards)

It’s hard to fault them (I’m talking legally here) for overpromising the wages of their product, as by rights you *could* make any of those games, though they weren’t necessarily already in the box - the ingredients to do so were there or easy enough to make with the included tools.

But of course, that’s not quite true either.

Klik & Play was revolutionary, but that in no way should that superlative ever apply to actually using the thing. Computer usability in 1994 was hardly an established science, but American users of the product suffered two strikes against them: the standard horrible usability, plus European iconography.

Let me put it to you, the reader - could you use this?

WTF si tihs a monstar

Among the icons that stand out at first glance you’ll notice TWO identical clapboard icons, the door to 10 Downing Street in Westminster (the UK Prime Minister’s house), an amateur sketch of the Mona Lisa’s enigmatic half-smile as described by Max Fleischer, an English court judge, and something I can only describe as a nightmarish scenario involving an annelid worm and a waiting Yellow Cab/Angler fish transformer.

Despite your first impulse, these are not images that psychiatrists show to children to diagnose hidden problems at home.

They are buttons, and by clicking them, you’re supposed to make a game. I’m not kidding.

Were there other limitations? Of course.

  • Images needed to be made up of uncompressed single-frames with manually drawn-in transparent regions. Too big and the program would flop over dead or drop frames until it was on par with a PowerPoint slideshow - this of course included small images scaled up to large ones on the fly, as there really wasn’t such a thing as hardware scaling at the time.
  • Logic was defined using a complicated if-then matrix of icons that would put the ones above in the category of high art.
  • Sounds were a combination of 16 kHz uncompressed waves and MIDI music tracks that started about 3 seconds after you called them.
  • There’s a button for a gradient there - I know you see it, and you’re tempted. Don’t. We’re working in 16-bit color and that means all gradients not only band into ugly stairstep-looking things like this, but on some video cards, they end up with a snot-green tint as well, since three colors don’t share 16 bits equally and the extra bit usually went to green.

Finally, if you really did get through all of that, you’d get a game that ended up looking something like this (and thanks to Glorious Trainwrecks for this one):

mooon

Pragmatists have finally already blown their stack and asked, “So, with all of these obvious handicaps and failures, why did you use it?”

Well, because it was there, and it made games that other people liked to play.

We knew that the future would be brighter.

We knew that one day we’d have the tools to do great things.

Until then, we used what we had.

Just like now.


The Word is Up: Interactive Fiction as a Social Dialetic, Dogg

April 9, 2009 – 10:33 am

It had really ought to come in a packet you can open when you’re old enough to read: “Welcome to life. You will experience this as a set of endless disagreements about perceptions orbiting an unobservable yet objective core set of thermodynamic rules.”

I’ve already had my fill of (and subsequent detox sessions from) radical relativism, far enough removed to be able to convince myself that there is a definitive is separate from our own perceptions (see Berkeley’s rock test), but I run almost immediately into an intractable problem when I get to work, and that is this: I don’t work in objectivity.

I’m paid, as a technical game designer, to create frameworks to support perceptions around an obfuscated set of assumptions. A game is more about trickery and flash than just about any other medium of creative expression; in fact, in handling the very real constraints of the hardware we test against, we gain a great deal of performance by removing unperceived elements (see Propaganda Village for a close physical metaphor).

Refuters will immediately seize on the fact that I work against very real hardware limitations, and this should be enough to form the Berkeley’s Rock against which I can gleefully dash my foot. Sure, if I were working in a vacuum, concerned only with technical input and output against a quantitative metric.

But I play the same games I create, and each time it grows more and more subjective as costs to performance are weighed against visual, audio, and kinetic aesthetic. Hedonics precedent usually winches one or two of these arguments mercifully out of the mud, but all too often in games the dialectic argument rings hollow against the bulletproof plate armor of gamer perception. If not historical precedent, then modern trends. If not trends, then usability and focus testing. If not those, then vaporous demographics.

Often it just feels like a Goldilocks problem - when I entrench in code, I lose sight of the game. Too low. When I fire up the Peter Copter and look down at the game from a conceptual standpoint, I lose the beacons of objectivity that give me the kind of confidence I want to make an informed decision.

Is there a way that I can quickly craft game interactions that give me both the low-level geekiness I want and the high-level conceptual exercise I need? For a while, I thought XNA Game Studio might be it, but no language there ever emerged that operated on a higher level than C#, and so I was stuck endlessly bit-twiddling.

Imagine my surprise when the answer made itself both new and old in one breath: Interactive Fiction. What it took was a new way to create an interactive fiction project; through a tool called INFORM 7.

You’ve probably already seen it, but I was absolutely blown away when I first saw the concept: create interactive fiction by using natural language sentences - definitive statements.

  • Martha is a woman in the vineyard.
  • The wind is a direction that varies.
  • If Jerry doesn’t pay his rent, beat him.

I confess, I made that last one up. But it’s interesting to see how complex things can get.

In fact, by constructing a simple fiction out of english-language rules, you can actually begin to notice how dialectic patterns emerge and grow rapidly into subjective patterns, even in the code itself, not just in the interpretation of interactive fiction’s typical flowery language.

Take a look at this example screenshot below - the code is on the left, the game it produces is on the right.

And as an added bonus, you can play it (all eight heartstopping seconds of it), special thanks to GrimJim’s BLORBFork of Russoto’s zplet:

Play “The Box” now! (Java Required)

Word is a direction that varies. Word is up.

It is indeed.


ZSim - A Text-Based Simulation Framework

March 28, 2009 – 1:16 pm

It was simple enough - how could I do interesting things with particles, physics, and more in 2D without having to draw sprites?

Seriously, my “artwork” is crap - you don’t want to see it. If I could simply substitute in text characters for graphics, and yet still animate a 2D simulation at 30 FPS, couldn’t that be just as interesting?

Things get tough once you realize most emulations of console-mode functionality are completely OS-dependent. Sure, Linux and Windows and Mac OSX all have their own consoles, but they don’t share the same API.

What I needed was something that ran in a browser. What about Java?

Turns out someone had done some interesting work in that regard already - Matthew Russotto, who ported Infocom’s Z-Machine to Java and called it ZPlet (if you click this link, you can play Zork - watch out, I almost get suckered into spending a whole day doing this).

ZPlet is a Sourceforge’d project based in Java that mocks up a traditional fixed-width font console using a resizable, self-regulating drawing class called ZScreen.

It also eats and operates entire Infocom adventures (like Zork) and provides lexing, parsing, and full simulation of the adventure - even saving and loading.

The console was perfect. Fixed-width text, keyboard input trapping, re-size-able buffer width and height, and even color. The only thing it didn’t do was draw in real-time.

A great starting point for an animated, OS-agnostic, browser-based, text character animation framework. Now, all I had to do was add the real-time stuff.

I started with the abstract ZSim class, which handles timing as a current count of milliseconds, and calls a child SimUpdate method with the delta between the last update and this. It also exposes a method to output a 2D-array of chars that can then be drawn frame to frame by whatever wants to call it.

The rendering was quick to set up - ZScreen draws line-by-line, so feeding it multiple lines is a quick for-loop. The whole thing is thrown into a while(1=1) loop, and delayed by a basic frame limiter.

while(1 == 1)
{
	now = Calendar.getInstance();
	ticksNow = now.getTimeInMillis();
	dachshund.Update(ticksNow);

	if(ticksNow >= ticksNext)
	{
		//we need to draw.
		char[][] drawthis = dachshund.GetDrawContents();

		for(int k=0; k < zapp.screen.getlines(); k++)
		{
			zapp.screen.settext(k, 0,
 			drawthis[k], 0,  zapp.screen.getchars());
		}
		ticksNext = ticksNow + (1000/fps);
	}
}

First test: Make a little ASCII dog wag its tail. Alicia kindly provided the dog (a dachshund):

Success!

The next move here is to make something that simulates particles - I think a waterfall is a good example, and have a child class of ZSim (ZSimWaterfall, I suppose) handle all of the physics and tracking of each drop, and draw different characters based on the direction of the water droplet.

One limitation is that ZScreen refreshes the entire draw surface after drawing a line - it’s not double-buffered. I can understand not needing double buffering, since ZPlet was never meant to run in real time (as far as I can tell). I’ll need to get that in before I go too much further, since right now it tears at anything close to 30 FPS.

I suppose I should see if it runs in a browser at some point, too.

All of this has been new; I’m doing the coding using XCode on Mac OSX in Java using an open-source library. Not one of those things I’ve done before now. It feels good.


This Message Will Repeat Every 30 Seconds: Information Horror

January 27, 2009 – 10:15 pm

What does a thing need to do or be outside of the everyday to be horrifying? Not much, as it turns out. A particular value of horror seems reserved for the ubiquitous.

Read more…


The Cornbread Hour, Ep. 2: On Throwing Away Guns

November 20, 2008 – 9:00 am

Mirror\'s Edge ScreenshotUnsurpisingly, I’m having a bit of trouble getting into the once-a-week rhythm, but it’ll work itself out. Got a small one for you while I try to find some time.

Read more…


The Cornbread Hour Ep. 1: Fallout 3, Cricket, and On Strategy

November 7, 2008 – 5:44 pm

What’s up, Pawkeegan! Equally spurred on by the spirit of Sam Neill’s grapeblogging enterprise (complete with him headbutting goats) and by the realization that both of my blogs run the risk of rotting away like overripe pinot, I’m going to try for an at-least-weekly serial. Expect less polish, more frayed ends, and random topic shifts. In other words: the Internet. You kids like that kinda thing, right?

Read more…


PC Games Stress Me Out

October 20, 2008 – 2:26 pm

I’m getting worried. I can’t walk three steps without realizing that, on the twisted, creeping path to my turning thirty, some piece of my brain - usually a piece I rather liked - at some point had stood up and wandered across the aisles to take a different seat in the auditorium, or, worse yet, simply tore up its ticket and left - no refunds, and no longer a fan of my ongoing mental concert.



Read more…


Ending This Project

October 5, 2008 – 4:31 pm

I resigned from Microsoft just this Friday. This blog will be taken down and replaced with something new, possibly related to my new work at Zipper Interactive as a Technical Designer.

For those that followed me on my quest on the XNA team, thank you! Keep up with your games and don’t forget to get up to speed with the XNA Game Studio 3.0 Beta, as Community Games is right around the corner.

See you soon, right here at www.the-agent.net.
Charles


Moving My Game to XNA Game Studio, Part 4: Slow Motion and Time Rates

September 11, 2008 – 1:56 pm

What happens when a simple math change gets into Training Center? The answer: Slow Motion.

Read more…


Moving My Game to XNA Game Studio, Part 3: Serializing Mah Lazers with XML

September 1, 2008 – 5:55 pm

The Old Weapons.dat File from Training Center 2005Time to tackle data file handling with the XMLSerializer class in .NET - and find out that yet another piece of my old game is no longer necessary!

Read more…