“Flow, you newbie…!”

What?

“Is that permanent marker? What does it mean anyway??”

As every noon, we are sitting in the break room eating take-out. (We call it “lunch at Google’s”, because the room has fancy soft seating and gaudily colored glasswalls. It’s supposed to be relaxing and inspiring — or so they say — I don’t know, I don’t work for Google.)

The junior is still glaring at the white board. The cryptic exclamation standing above other meaningless scribbles has been there since before I started working here. I always assumed it referred to a hard-to-remember project working title. Nobody remembered who wrote it or why, and nobody had ever managed to erase it. “You’d need a spray… it’s permanent…”, the seniors shrug wearily.

Another colleague on his way out casually adds:

“Or grab a non-permanent marker, write over each word, and then erase it. I do it all the time.”

He leaves us dumbfounded. What did he just say? It almost made sense… But… What…?

With everyone stunned, I walk over to the whiteboard and put the claim to a test. The original scribble is black, my non-permanent marker is green. I single out a permanently black spot and doodle a big green dot over it. I swipe it with the eraser and — the dot is gone! What magic is this?! I give another spot the same treatment. He was serious: An average non-permanent marker can erase a permanent marker. :-o

Another colleagues picks himself up and joins me. While he writes green over black words and erases them, we get more and more bemused about how clever we are. OMG! Finally something we can submit to the company innovation project!

One of the QA managers walks by and watches us through the glass door. He smiles and it’s clear that he appreciates our enthusiasm for what it is — totally bat shit crazy. I call out to him that, although it may look as if we were re-writing permanent scribbles, the truth is, we were erasing them.

“Sure” he says with the same frozen grin on his face, and absconds.

Well, just another normal lunch in the “Google” room…

I assume that this manual is an art project and not an existing product. These books would be quite expensive to produce, especially if they are used only once. The target group is “total newbs”, while the majority doesn’t really need instructions this detailed.

I rather take this as a lesson of good usability and creativity. Most people laugh/grin when they watch the video the first time (I heard a few giggles in the office) — it strikes a chord. Even if you don’t actually want your next phone to be packaged like that, you might think, “If that had been my first phone, it would have been fun to get started…”

It’s a good example of what good self-paced teaching methods could look like. Something similar to this book would (made out of a sturdier material) also work embedded in a workbench, where it shows you how to, dunno, build a radio, or other devices. It doesn’t even have to be a book. Picture a music player with an intro mode, where it plays its own intructions and blinks the buttons to be pressed; or a model of a car engine with labels and arrows that pop up, and guide you through the concepts? A sewing machine with a special piece of “cloth” that has instructions on it where to place your hands and where to sew?

A hypothetical training based on these kinds of interactive teaching materials would clearly be targeted at self-study students. The students would probably not buy them — the catch is that these types of materials need to be “reset” to be used again. In the example with the phone, the SIM card and the battery need to be taken out and placed back into their compartments. The example with the sewing machine cloth would be harder to reset though, did we already invent the selfdestructing thread? :-D

The materials could be made available at libraries or schools, and students could book timeslots to use them in the afternoon. Just like they put returned books back, the school or library staff resets the materials for the next visitor. I don’t know how much overhead this would incur for the staff, and whether repeated use would wear the materials out quickly. But for quick and easy how to things that are not obvious, and cannot be truely taught hands-off (by text or a video), such teaching implements would be an cool option…

This is the good part, the bad part is: To get this far, I had to restart the demo four times. I simply kept getting killed before I could fathom what was going on: “Am I aiming wrong? Is this thing I’m holding really a weapon, or am I shaking my fist? Am I wearing any armour at all? Am I supposed to be shooting these big guys, or am I pointlessly irating high-level NPCs? Did I prompt the attack, or does every NPC randomly attack? What– *BAM* Argh…”

After the fourth time or so, I finally survived long enough to reach a merchant and a quest master. I had learned how to land savely on the ground without breaking the character’s neck and losing all newbie equipment. I could tell mosts friends from foes, and distinguish which faction owns which building (so I could stay close to the one faction that was neutral towards me). I learned how to interact with friendly NPCs, how to use elevators, and I understood that, somewhere, there is a lot of equipment worth trying out. However, the demo’s time limit always ran out before I even remotely started to solve the mission (so I can’t tell you anything more).

Under different circumstances, I’d be pretty annoyed by this first impression. I left the author a bit of feedback and asked whether he could lower the bar a bit. I think the single most helpful thing for this type of game would be something like an embedded implicit training level.

Optimally, a training level is smoothly integrated into the game and the player hardly notices it is there. Having a training level basically means that the game does not bring out the big guns from the first second on. It gives the player a limited save environment to acclimatize and learn the user interface.

In the case of 3079, a training level could have been introduced on one of the cloud-cuckoo islands. An experienced player knows how to steer clear off the newbie island and how to go on parachuting straight to the surface — he should be allowed to just skip it. A newbie would be curious about the floating island under his feet, he doesn’t know yet there is a planet surface. The game pops up tooltips that advise him which keys to press to land smoothly, how to walk along a trail on the island, how to pick up and load a newbie weapon, how to aim and shoot at a non-lethal target, how to open a door, how to use a grapling hook (“I HAVE A GRAPLING HOOK?!”), etc. If the player fails at any task on the floating island, he can try again without penalty. At the end of the floating island, the tooltip advises the player how to continue his journey to the surface.

Now the newbie player is prepared for the landing, if he crashes now, he thinks “I know how to avoid that”. If the player gets shot at, he can now draw more confident conclusions: “I know I have a weapon, and I did shoot back, but the NPC is not down. I assume the NPC is too strong and I must use a different strategy.” Although the same events happen, the player is less frustrated by them. He no longer doubts his skills and is not slowed down by newbie questions (“How do I tell whether I’m holding a weapon??!”)

In other words: If your game must use more inputs than Myst, consider adding a short training “level”.

Myst, for the record, handled only one input: “Left click” covered everything from walking, to opening doors, pulling levers, and pressing buttons… Beat that!

I assume that Evan uses the Lemma world as backdrop for this Parcour Ninja game.

In his blog, Evan also makes some interesting points about game development and tools (he’s writing his own engine). Many developers set out to write their own game engine instead of using existing tools. This approach has pros and cons: If you are a very expecienced developer, you can of course do what ever you want, and you’ll be successful. For beginners, having access to tried and tested tools speeds up game development significantly, and you don’t lose artistic freedom only because you use a preexisting engine (like my favorite jMonkeyEngine). It makes a huge difference whether you simply add a powerful feature by calling one method, or whether you avoid good features, only because you dread the overhead of code it incurs…

This kind of usability is a goal that you mustn’t let go “out of sight, out of mind”. Evan says about designing tools for game development:

The question should not be “how many shiny graphics techniques can I incorporate?”. It should be “how easy is it to create content for this game?”.

Since the jMonkeyEngine is a Java framework, and not a “visual MMORPG-generator”, the first step is actually to create “your own engine” based on jme3: You extend the SimpleApplication class and configure it the way you need. You add your branding and your defaults, your screen switching states and your GUI. When all the generic pieces are ready, you compile your custom game classes into a little JAR. This JAR depends on the jMonkeyEngine, and your upcoming games depend on your custom JAR (and indirectly also on the jMonkeyEngine). Hook in your content and off you go. Evan shares a similar experience:

[...] I didn’t really take advantage of [the audio] features, because it was a pain. I got away with the bare minimum. [...] Suddenly I’m adding new sounds, playing with the settings, and actually enjoying it. What changed? [...] The tool made the difference. It made it easy for me to go in and control sounds without writing code and recompiling. Now there will be a lot more variation in the sound, because it’s so easy to do.

Although the jMonkeyEngine SDK is no drag&drop “GarageBand” for game developers (where every chord is so restricted that it magically falls into place), it has sped up the development process drastically compared to jMonkeyEngine 2. No more worrying about classpath and build scripts and asset paths and packaging of the executable… No more switching between web browser and code editor for javadoc, code samples, or API details… Common tasks like converting, laying out, and previewing scenes is a context-menu away. When I started with jme1 and jme2 four years ago, I spent most of time figuring out the back-end. In jme3, I create a new game project and focus on my game content right away. That’s what a good tool should do.

I also liked Evan’s Global Game Jam 2012 Liveblog, it shows a realistic approach to game design. Yes yes I know, “Keep your realism out of my dream game!!” Every new developer crams as many ideas as possible into one game — and then gives up half-way through because it’s too complicated. (I am also guilty of that, I have restarted variations of the same game idea… how often now…? in the last four years.) Evan shows the evolution of a game idea that is simple enough to implement, and fun enough to play:

The game idea is a variation of Snakes, set inside a skyscraper. The snake travels through floors, staircases, elevators. The snake grows longer by eating people. The player strategically opens doors to lure the snake towards people and away from himself… When the snake is long enough, the player must trick it into biting its own tail to win. :-)

“The jMonkeyEngine is a game engine that provides a framework for the development of 3D games.” — “… What?”

When I mention the jMonkeyEngine, I often have to explain what these terms mean: What’s a library, a framework, an engine? Who uses that stuff? And what do these abstract things look like?

Let’s compare them to something from Real Life™. Technically you can grab a pair of scissors and cut your own hair. You can cultivate sourdough and bake your own bread. You can grab a chisel and whittle a tree into a chair. You can, but in reality you typically don’t. The task would take quite some time, and the quality of the haircut, the pretzels, or the living room furniture will be dubious.
In reality, you rely on experts to do these jobs for you, hairdressers, bakers, or carpenters. You don’t know what their tools are called or how to use them. And you don’t need to. You only know that if you hire them, they will do the job, and do it faster and better than you.

Now, when developers write a new application, they can technically write everything from scratch. They can draw countless colored rectangles that lay out the user interface. They can write code that calculates which rectangle the user has clicked, and write code to resize and redraw all these rectangles. Or — they can load a “library” that draws functional windows and buttons for them. Creating an application window is such a common task that there is no need to reinvent the wheel. Just like you wouldn’t cut down a tree if you can buy a chair.

A framework is an abstract collection of functionality. — A bakery without a baker and flour, just an empty room with an oven and a few recipes. It makes no sense to “be using a framework” just by its own. You always use frameworks to create something, typically, a larger application.

Some examples of frameworks: The Java Spring framework helps you lay out the visual building blocks of an application: windows, buttons, menus, text fields, dialog boxes, etc. A lone Swing menu or button doesn’t do anything but look pretty. The developer adds functionality to the abstract buildings blocks, and combines them to a working whole.
The NetBeans Platform is another example of an abstract framework. It helps you create complex modular applications such as the jMonkeyEngine SDK. It provides a frame in which you create custom file editors, various file views, an update center, etc. An “abstract editor” or an “abstract plugin” doesn’t do anything. The developer adds the actual functionality to the given frame. The NetBeans Platform itself uses Swing — which shows that frameworks can also build on one another.

An engine is also a collection of functionality — but in contrast to a generic framework, an engine’s methods are highly specific. An engine is similar to an engine in your car. It’s so specific that the driver is not expected to know more than how to switch it on, accelerate, and decelerate. While a framework is just a static frame whose gaps you fill, an engine is something that runs and regulates itself for the duration of the task. After the engine is switched on, there is no need for the driver to worry about internal details, such as torque and air and fuel flow: An engine performs its very specific job with minimal user interaction.

Some examples of engines: Developers use graphic engines (to calculate 3D transformations), rendering engines (to draw colored pixels to the screen fast), and physics engines (to simulate the interaction of physical forces and physical objects). A game engine can join these three engines into one cohesive framework. You switch the engines on and they do their thing on your loaded game data, constantly re-calculating the ever changing positions of game entities and immediately drawing the new image to the screen.

A library is just a generic word for a data container: You can have libraries of common programming methods, of assets, of utilities. Developers and graphic designers package reusable chunks of code or media into libraries because they want to reuse them later. The components in libraries are re-combined for each new job. In real life, a library can contain engines, frameworks, or multimedia assets.

How are libraries used? Back to our real life experts. Hairdressers, bakers, and carpenters usually have a list of services and prices. “You give me a dollar and I give you a loaf of bread, we both are happy, have a nice day.”
If you take the hairdresser’s chairs, or ask the carpenter to work on your hair, your day will be less nice. You didn’t look at the list of services, didn’t pay the agreed-on price, and made a fool of yourself asking the wrong expert.
In programming terms, this corresponds to the libraries interface. A specific programming library expects to be used in a specific context. It needs specific input to produce specific output. If you don’t read the API (application programming interface) first, your use of the library will either produce spectacularly wrong output, or (more likely) no output at all.

Now that you know how and why programmers use libraries, you maybe wonder what these abstract things look like. You already know that applications and documents come as files. You install the application and open the document to edit it. For example, you install the MS Word application to write a letter in a Word document.

Libraries also come as files. In Java, these are JAR files. (*) A library’s installation process can be different from an application — often you merely have to download and save the JAR to a specific directory. When writing your program, you specify the relative paths to the functionality that you intend to load from the libraries.

package mygame; // package this program for others to load
import com.jme3.app.SimpleApplication; // load a library from another package
public class MyGame extends SimpleApplication {
/** Start the jMonkeyEngine application */
public static void main(String[] args) {
MyGame app = new MyGame();
app.start();
}
@Override
public void simpleInitApp() { /** load game assets */ }
@Override
public void simpleUpdate(float tpf) { /** make them interact */ }
}

Here I create a MyGame object, which is an instance of a jMonkeyEngine SimpleApplication. I adhere to the API by calling the start() method to start the engine. I override the SimpleApplication’s simpleInitApp() and simpleUpdate() methods to fill the empty framework with my actual game content. Just like with the hairdresser, the libraries and you have to meet with the agreed-on payment, at the agreed-on time, at the agreed-on place for the deal to work.

(*) PS: JAR files are not exclusively used for libraries, they can also contain applications, just like .exe files on Windows or .app files on Mac OS. A JAR that contains only a library doesn’t do anything if you try to double click it (although some developers decide to set their library JAR up like an application, so it at least plays a demo of the library).

“Apple never again brought to market anything resembling HyperCard. [...] The reason for this is that HyperCard is an echo of a different world. One where the distinction between the “use” and “programming” of a computer has been weakened and awaits near-total erasure. A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone. A world in which Apple’s walled garden aesthetic has no place.”

I didn’t understand what he meant by the weakened distinction between user and programmer, but in another blog entry he explains it as:

“The distinction between “user” and “programmer” is an artifact of our presently barely-programmable and barely-usable computing systems.”

So his point is, that as far as HyperCard is concerned, you are neither a user nor a programmer, you are an operator. In contrast to today’s developers and users, operators are more independent and self-sufficient, operators create the software they want to use.

Today’s users depend on programmers to provide them with tools; users just passively adjust to what they get (think of iPhone apps). Today’s programmers make money by being the high priests who keep the secret of “making stuff work”; programmers are not interested in creating competition by making it easy for users to become programmers themselves.

What would happen if a big company decided to cater to operators? In a world (and economy) full of operators, empowered by a hypothetical modern-day version of HyperCard, companies would lose some control and market opportunities: It’s hard to sell a custom shop database to operators who can “roll their own” (or can easily find a neighbor who can).

Possibly HyperCard was successful because it ran on relatively simple and small systems, and only therefor it was easy to learn. Could such a simple concept scale to today’s mesh-ups of networks, databases, mobile devices, web browsers, and web services? HyperCard was well integrated into its OS (it was practically a Mac’s commandline interface — remember the message box?). To revitalize HyperTalk, its API must be able to reach out to all these new components consistently.

AppleScript tried and failed to be as user-friendly as HyperTalk: I recall I spent hours tweaking one line of AppleScript code that tried to reach an embedded field inside another application: Something like “put blah into line 5 of the content of field A of panel B of element C of window D of application E”… I gave up because, without API documentation or automatic code completion, it was impossible to drill down and reveal all the required layers of the external application. To be able to compete, a modern HyperCard would have to be able to deal with the increased depth of modern PCs, where applications may be spread over networks and frameworks, without losing its simplicity. Platform independence is quite a challenge, as we see today with Java.

As opposed to Java and Linux, the original HyperCard was never open-sourced. The HyperCard community eventually splintered and fizzled out after various unrelated (and unsuccessful) attempts to recreate the former glory. Would open-sourcing it have prevented that? Did we miss our one-time chance for an über-awesome HyperCard-Linux hybrid…? :-o

But then, this mainframe is the development system. It’s a playground for DEV and QA (development and quality assurance) where abends are caught before the program’s final recut (the release build, alluding to old paper punchcards) for production.

So where are these mainframe that “never” need rebooting, doing monotonous work in the basement of some bank? How literally do I take this “never”? Surely they must be rebooted after a random power outage, or for maintainance of their parts, or… don’t know, after, say, an earthquake?

Here are some photos from an IBM data center in Tokyo containing a variety of IBM servers (mainframe and non-mainframe). Many of these IBM machines fell horizontally to the data center floor, bending frame metal and stretching cables.

However, all these IBM servers kept running, which is a testament both to the IBM engineers who designed and built them and to the IBM data center planners and managers who sweated all the little details, including leaving enough slack in the cables.

The IBM storage units kept running, too, with some concurrent error checking automatically triggered as a precaution. There were no service interruptions, and there was no need to switch over to a disaster recovery site.

— from Earthquake in Japan: IBM Machines Kept Running

Oh. So that’s what they mean. o_o

Glenn Marshall uses the jMonkeyEngine to develop Hexyle, a super awesome looking open-gaming universe.

Hexyle fits into the growing category of lego-brick styles games like Minecraft and Mythruna. These open-world or sandbox games are non-linear, level-less, border-less games where players set their own goals. You can tell by my use of three negations that this concept (allthough around since the 80ies) opens up so many new game opportunities that we don’t even have words for them yet.

Not all sandbox games are made up of voxels like Minecraft: Grand Theft Auto, for instance, is a sandbox game set in a city. Your game entities are physical “crash cars”, complete with guns, explosions, buildings, and ragdoll physics. Catch is, to create a cityscape sandbox you need to be a good 3D modeller… :-/ This is why the rest of us says Hello to procedural fractals, and fills up the world with docile voxels and polygons.

I’m curious about the progress of multiplayer networking and the flexible gameplay that Glenn intends to add. The video that you see is not yet the finished game, but a demo + visualization that he created to attract funding.

The Hexyle page doesn’t give us many details yet, so it’s hard to judge gameplay. For comparison, Secondlife also promised “in-game games”, but I never saw any. There was some gambling where avatars just sat there and pressed buttons. But I never saw teams of avatars who met and voluntarily ran through a parcour, or, defended a base, or played soccer. I assume the SL controls aren’t responsive enough for that, so that is one important feature that makes or breaks such an idea, especially with the added complexity of 3D. Another successful example of a game editor is Little Big Planet, a cute cartoonish Playstation game where you create your own interactive jump’n'run levels and parcour puzzles. If Hexyle’s interactions are planned to be similar and as easy to control, this could turn out to become popular.