Dr. Vanessa Freudenberg

A multi-player web app needs a backend, right? What if I told you, it doesn’t? Read on for how Croquet gets rid of servers running your multiplayer code. No, really . Instantaneous Shared Experiences  is how we describe Croquet on our website. And while that excellently describes What Croquet does, as Croquet's Chief Architect, I wanted to share a bit about How we do that. So I wrote a Twitter thread . Here it is in blog form, slightly extended. Click the animation above if it does not play automatically Croquet lets you build completely client-side multi-user web apps. Read that again. Client-side. Multi-user. No I’m not kidding. I built it, I know it works. 😁  Croquet apps run completely client-side: are hosted as a static web site no server-side code needed no networking code needed  Croquet is literally virtualizing the server: Instead of running code on a server (or in a serverless function) we run it as a virtual machine (VM) on each client.  Croquet ca...

The Raspberry Pi is a cute little computer. Quite cheap at $35, you plug in USB keyboard+mouse and a TV as monitor. And it is surprisingly capable, even for running 3D games. One particularly interesting game is Minecraft: Pi Edition . As in other Minecraft versions, the main goal is to create a world. But unlike other versions, you can not only use the tools provided by the game, you can make your own tools! That's because it comes with a programming interface. The Minecaft world is made of little cubes, and you normally place or remove these blocks by hand, one after another. This is fun, but for larger structures also quite cumbersome. For example, this rainbow here might take a long time to construct manually: But I did not make the rainbow by hand. I programmed it, using the Smalltalk programming language. It's just these dozen lines of code in the Squeak programming environment: Squeak is already installed on the Raspberry Pi, because Scratch was made in Squea...

Get it while it's hot from the equally new Croquet Consortium web site.

So Qwaq came out of "stealth-mode" and reveiled what they have been working on for a while now, Qwaq Forums : Qwaq Forums, the company's first product, is a secure virtual workspace application that significantly increases the productivity of distributed teams by bringing critical resources together in virtual places, as if they were in an actual physical location. A highly interactive and persistent environment, Qwaq Forums enables users to work, collaborate with others, and identify and solve problems. And I'm proud to say I contributed a little, which most probably will find its way into the next Croquet release. Update: Here's a few nice stories of fellow bloggers who have seen Forums already. From Steve Borsch's Connecting The Dots : Qwaq will get traction only because they completely understand that giving someone a semi-trailer truck (i.e., an engine like There or Second Life) doesn't do much good if the person has a small garage and needs a vehi...

On some modern Linux systems, Croquet does not work anymore because OpenGL failes to initialize. Now, I originally wrote that code, and it worked fine for years. So it can't possibly be buggy, right? Jens Lincke of impara tracked it down to the "Composite" extension that is enabled by default nowadays. With Composite disabled, it works, enable it, and it does not. So I turned to NVIDIA for help, thinking their driver might be buggy. Had to give them an easy way to reproduce the problem, this is the snippet I came up with: | ogl green | ogl := OpenGL newIn: (0@0 extent: 100@100). green := 1. [[ ogl glClearColor(0, green, 0, 1). ogl glClear(16r4000). ogl swapBuffers. Sensor waitClickButton. green := 1 - green. ] repeat] ensure: [ogl destroy] Beauty, eh? ;-) I guess nobody has done this in a workspace for a long time. Stop it with Alt-. Anyway, NVIDIA could reproduce the problem, and found our bug: [...] the app is trying to create a ...

I gave a talk about the $100-laptop at the Magdeburg school of Industrial Design . We did some very inspiring projects using Squeak, Etoys, and Croquet together before. The designers always come up with interesting ideas, even though not everything is directly implementable by us developers. Carola Zwick, dean of the school, wrote a book Designing for Small Screens that certainly gives valuable insight for OLPC developers, and she provided (though indirectly) some very important infrastructure for the OLPC office: her group designed the chairs they are sitting on. I got the actual invitation by Christine Strothotte, who got her PhD doing computer graphics in Smalltalk just a few years before I got mine from the same school. She's teaching interaction design nowadays. I'm looking forward to doing an OLPC-related project with these great folks. A student took some photographs during the talk. Also, from his blog post it seems I convinced him of the merits of the OLPC project...

Get it at opencroquet.org !

Ted Shab posted a job offer to the ECOOP list. Part of it was this: We are currently building a [...] testbed for user-experience exploration in Squeak (Smalltalk) (really). The resulting framework will be used by the various NASA centers [...] to build distributed, multi-mission systems for planning and executing a variety of NASA missions, including robotic (e.g. Mars rovers & deep- space probes) and manned (e.g. the new Moon/Mars exploration effort, including the Crew Exploration Vehicle currently being designed). Andreas Raab commented : FWIW, this project uses Croquet and Tweak. If you ever wanted to work with a bunch of really sharp guys this is definitely a place to consider. Sounds cool :)

The next Croquet release, code-named "Hedgehog", will be centered around a real replicated object model, rather than the ad-hoc meta sends in Jasmine. See Andreas' and David's OOPSLA presentation (PDF) for an overview.

Children "discover" Croquet's collaboration model called TeaTime .

Tao asked for a "Tweak & Croquet" tutorial. I don't have time right now to actually write one, but here's some sample code anyway. Using scripts is easy and useful, even without the Tweak GUI. Just use #startScript: to run some method as a script. Inside a script, you can use loops and anything you like, just throw in a wait to account for time. Like, to animate the color of a frame, you could use this method (just add it to your TeapotMorph ): animateColorFor: aFrame [ 0 to: 360 do: [:hue | aFrame material color: (Color h: hue s: 1.0 v: 1.0). self wait: 0.01] ] repeat This changes the color every 10 ms, and you can start it from the initializeDefaultSpace method: self startScript: #animateColorFor: withArguments: {someFrame}. Here is something that does not loop forever, but finishes after one cycle: jump: aFrame | v g | v := 0@1@0. g := 0@-0.05@0. [aFrame translation y >= 0] whileTrue: [ a...

For high-quality prints you need high-quality screenshots. This means very high resolution, and nice anti-aliasing. Just grabbing the screen produces rather unpleasant results ( screenshot , 80 KB, 800x600 pixels). With normal OpenGL rendering you get rarely more than screen resolution, and anti-aliasing quality very much depends on your graphics board. So what to do? Tiled Rendering comes to the rescue. Instead of rendering the whole image at once, we render smaller portions of the scene, and then arrange the tiles into a large picture. However, just pointing the camera at each tile will not work as intended, the perspective would change from tile to tile. What is needed instead is to construct partial viewing frustums that together exactly recreate the whole frustum. This sounds like a lot of math, but actually it is quite simple: gluPerspective: fov aspect: aspect zNear: near zFar: far tile: rect | cotangent radians w h | radians := (fov/2.0) degreesToRadians. cotan...

We've been wondering for a while, why screen updates are more expensive than expected in the Tweak overlay. Now I debugged into this and it turns out we're uploading the whole texture even if only a small part was changed. The relevant code is in OGLTextureManager>>uploadTexture:dirtyRect: . A partial upload using glTexSubImage2D() is only performed if the texture in use is not static. Having found out what's going on it's easy to fix, a one-line change in TeapotMorph>>glRenderTweakCostume:on: does the trick: texCache isStatic: false. As simple as that - I just posted the update.

So there was a student who implemented a flocking simulation for a virtual fishtank using Croquet. Worked fine with 20 fishes. With 50 fishes it became rather sluggish. Putting in more than 100 fishes the framerate could be measured in seconds per frame. So the rendering in Croquet is too slow, right? Not quite. There are two things you have to keep in mind when it comes to performance: When in doubt, measure. You are in doubt. So we fired up a message tally (world menu - debug - start MessageTally). Turns out only 12 percent of the time were spent in rendering. So it's not the rendering at all. A whopping 80 percent was taken by the flock's step methods. The leaves of the message tally showed that 15 percent of the time went into each of the methods #x , #y , and #z ! So we looked at the code. Every fish was told to swim in the main direction of its neighbors, that is the fishes within a certain radius. Processing continued only for those fishes in range. Sounds quite reas...