Why HyperCard Was Killed

Posted by admin on December 18th, 2011 filed in Mac, Open Source
Comment now »

Interesting read about Why HyperCard was killed — the SlashDot article quotes Stanislav Datskovskiy’s blog:

“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


Your PC is a Wimp

Posted by admin on November 5th, 2011 filed in Computers, Mainframes
Comment now »

When I first heard about mainframes, one of the things that struck me funny was the claim that mainframes are “never” IPLed (rebooted, as in Initial Program Load). The development system that we use at work, however, is getting IPLed every week… ;-) Those 30-year-old mainframe newbs constantly mess something up, and a harmless submitted batch job runs amok and abends (crashes, as in Abnormal End) over and over. Just as with rebooting modern PCs, an IPL is the fastest way to get back to square zero and re-evaluate where the problem started.

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.

funny mainframes during earthquake

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


jMonkeyEngine 3 Beta Released!

Posted by admin on October 24th, 2011 filed in Java, jMonkeyEngine, Open Source
Comment now »


Living in Polygonic Hexyle

Posted by admin on October 16th, 2011 filed in Games, jMonkeyEngine
Comment now »

Is this an awesome jMonkeyEngine 3-based game or what?

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.


Epic Mission Statement

Posted by admin on October 8th, 2011 filed in jMonkeyEngine
Comment now »

Found an epic forum quote by one of the jMonkeyEngine 3 core members from the very start of the project (February 2010):

Naturally, our end-goal (did I say end-goal? I meant goal for tomorrow, before lunch) is to use jMonkey to build the largest MMMORPRTSFPDSS ever conceived, let alone attempted. Did I mention there will be free handouts of preposterone and 7D glasses upon release day for a megamaximized experience of our rendering system which has been banned in 17 countries on the account of being ‘too real’?

Rumor has it that the acronym stands for:

Mega-Massively-Multiplayer-Online-RolePlaying-Real-Time-Strategy-First-Person-Driving-Simlike-Simulation

As awesome as that sounds, our forum members are still able to one-up us:

Did I mention I’ve already designed all the magic spells for one of those? ;)

Oh snap! :)


Freee Bacon!

Posted by admin on September 27th, 2011 filed in Open Source
Comment now »

Did you see the cute cartoon with the two pigs who agree on how they enjoy life on the pig farm — because they get free food and housing?

If you're not the customer, you're the product.

The punchline is “If you’re not paying for it, you’re not the customer. You are the product being sold.”

The cartoonist was of course thinking of Facebook and the big advertisement machine powering it, and (s)he makes a pretty good point. That made me wonder to what extend this aphorism can be generalized: Especially, what about open-source software? Nobody is paying for that, either. Are open-source fans “being sold”, too?

Firstly, open-source users don’t consider themselves customers. (There are only very few clueless enough to complain on forums why somebody dared to release free software that isn’t the perfect custom solution they, “the customers”, expected it to be). Secondly, a few users –the contributors– have “paid off” the software by investing time, expertise, bandwidth and hardware.

These contributors also get something in return for their investment: A highly specialized software that would never have come into existence otherwise. Each contributor only knows how to do his part and they are all aware of the mutuality of this deal. They all take the gamble and put their work openly on the table, knowing that every member is a volunteer and could back out unannounced. In the worst case, if the team disbands, you haven’t lost anything and you just have to finish what you gained on your own. Even though nobody is accountable, there are enough open-source enthusiasts who complete projects successfully. When the core investors got their unique payoff, they give the product away for free to others, new users who may not have invested anything themselves, but who do not take anything away either by making copies.

[ Spending time for answering questions on free support forums, and paying for the server hosting does cost time and money, but apparently not so much that it would make open-source projects impossible. Users often give back by posting ideas and solutions, and by reporting bugs -- free QA! ]

How is that different from Facebook? Facebook gives its users something they want. But as opposed to open-source projects, the “core users” have not joined Facebook with the intent of giving Facebook something (personal data for targeted marketing). The deal is not as obviously mutual as an open-source project is. These pigs do not stay at the pig farm with the intent of giving the pig farmer something. But the pig farmer gets what he wants anyway, because the pigs are already “trapped” and not worried about the payoff.

Does anyone know a good “animal” metaphor for open-source projects? Maybe we can say, an open-source community is not a pig farm, it’s a pack of animals that works together to survive outside the farm, in the wild. Some pack members have better hunting skills and share the loot, others are good at keeping watch and protecting the pack, etc. One animal cannot do all survival tasks on its own. Together they take the gamble to make this work, and they can afford to feed a few extra lazy pack members who don’t contribute much. Or throw them to the lions as a distractor, muhahahahaha! … Uh. Wait. No. Bad metaphor.

Reminds me of a phrase used in Agile development teams: They say, in this breakfast, you’re either a pig or a chicken. When preparing ham&eggs, the pigs are commited, while the chicken are contributors… ;-)


Vacation in Cubeland

Posted by admin on September 19th, 2011 filed in Games
Comment now »

Am I the only one who thinks this OpenGL 4 Rendering Experiment is sexy? <3 ;-)

If Myst and Minecraft fell into the Star-Filled Fissure together, that’s what you’d get. Add a little lake and it’d be the perfect spot for a vacation home, don’t you think?


Capture Live Video from JME3 Games

Posted by admin on August 14th, 2011 filed in jMonkeyEngine, Open Source
Comment now »

You have created a cool demo or video game and want to post a video — and you quickly realize that screen recording software slows down the running application while recording. In a video game, this either results in jagged video with skipped frames, or jagged performance with low accuracy (e.g. the physics simulation accidentally drops objects through the floor). Bummer!

But hey, you wonder, isn’t each rendered frame already one high-quality frame of your future video? If you only could output these frames (not only to the screen, but also) to a file…

So a smart man by the name of Robert McIntyre took the bull by the horns and found one way to solve this problem: He hacked JMonkeyEngine’s built-in timer and cheated the engine into believing that time had slowed down enough so it would always have enough time to calculate full-accuracy, high-quality video, and at the same time, write the video to an output file. Of course this flexible time hack slows down the game sometimes (you woudn’t keep the recording running all day while playing) — but it always results in constant-framerate high-quality output.

Read more on how to Capture Live Video Feeds from JMonkeyEngine on Robert’s home page.


Cute Rooftop Elephant in Prague

Posted by admin on August 13th, 2011 filed in Uncategorized
Comment now »

Was looking for a restaurant and found this cute little rooftop elephant on google maps!

Is this real or do google employees have a habit of doodling on rooftops?


Love the Voxel, Hate the Snakeoil

Posted by admin on August 2nd, 2011 filed in Computers, Games
Comment now »

Do you remember the whole story about the “Unlimited Detail Renderer” that started in 2010? A bunch of anonymous Australians (I think) aggressively advertised the latest revolution in 3D engine design. Of course we were courious what that would be, and looked at their videos. (I’m not linking them on purpose.) In contrast to the unlimited copy&paste armies of 3D rendered statues, ruins, and trees, the amount of information on their web page was, well, limited.

Lots of unanswered questions here: How can they do this with software rendering only? How does it distinguish itself from, or compare to, voxels? Why are they silent about the drastic limitations displayed in the demos (no animations, repetitive content, lame lighting/shaders)?

The reason why 3D designers choose polygons over voxels for game scenes is not ignorance, it’s because games must actually fit on a normal user’s harddrive. Strangely, they say nothing about generating, compressing, or even storing these amounts of data they speak of (literally, pieces of gravel)? Currently voxels are mostly used for scientific visualizations of molecules, or to view 3D-scanned objects. We already knew that, they don’t say how they are more efficient than the existing solutions (other than claiming to be “infinitely” better).

One would think they could pick a game dev company to work with. Instead they post marketing videos, advertising their idea — well, to who? Venture capitalists? Why is their technology such a hard sell to the real target group?

Well, they fell silent and disappeared and we forgot about them. The topic came up again today, because they posted a new video, and indie game hero Notch promptly commented in his blog: It’s a scam. Notch is practically asking the same question as we did (he also includes a link to the Unlimited Unlimitedness, if you are curious).

For comparision:

Lords of Uberdark is a voxel-based game (in progress) where you construct and destruct the world around you. It’s like Minecraft, but round, and minus the zombies. :-o It uses a cute cell shader that gives it a neat cartoon-like style (admittedly, such a filter is mostly to cover up voxel glitches, but it works well). Some people on the jme forum said it was only an approximation and not real voxels, I can’t tell, in any case, it’s innovative and sandbox/crafting is a popular genre.

This is Branislav’s Atomontage, a real voxel destruction engine. You can modify the world live (e.g. add stuff to the scene, leave tyre tracks, punch holes in buildings — and then throw tanks though the holes…), including a physics simulation. Listen to the videos: When this guy says “physics”, you know that he means physics as in “physics and chemistry”, and not just collision physics. The Atomontage demos also show simple animations (he mixed in a working polygon-based truck and tank). He says he generates the (rather small) terrains procedurally, and it takes him hours. In his demos, Branislav is capable of explaining what the engine can and cannot do, in detail, without repeating the same two “unlimited!!” sentences. Call me gullible, but if I was to invest money, I’d choose Atomontage in a heartbeat over “Unlimited Unlimitedness”.