The graduation exhibition, which was held this week, was very interesting as well. It gave me the opportunity to meet some people who have taken an interest in Second Life and would like to have my expertise at their side when developing their projects. It’s too early to give you any more details on this though.

I do have another interesting observation I wish to share. During the exhibition I invited people to play the Babel (tower building) game. Some of the children that were present went at it with great enthousiasm, having full control of the interface with only the slightest bit of support form my side. The adults on the other hand had a lot of trouble just moving their avatar in the desired direction. Even my fellow students, who live with computer technology constantly, had some trouble controlling the game. This makes me wonder what this younger generation will be capable of as they grow up and learn to operate even more complex interfaces. It can almost make you feel old.

For those of you that are interested in the finer details of my explorations I’ve finally put my finished thesis online. You can find it under ‘Documentation’ to the right. It offers a detailed explanation of my game concepts, research and observations regarding Second Life.

Elbereth has yet again been a great help in developing teh required script for teh game, but as I’m building more tiles for teh obstacle course I’m second-guessing my design motivations. The structures I have now might be interesting challenges, but are quite bland geometric shapes. It doesn’t look all that exciting.

Then sudenly I realized what had been the allure in the original physBall game. The fun part was working with the actual world as the playing field. Now that’s gone there’s nothing left but a run-of-the-mill puzzle game, and a frustrating one at that.

That’s why I’ve been thinking of incorporating the Second Life landscape into the game again. The obstacle course is tile-based, the SL grid is too. It could be quite funny to recreate teh tiles in the image of famous SL locations, like Luskwood, Caledon, Sheep Tower, Club BadGirls and other places. It would increase the visual aesthetics and the connectedness with the world, but it might deteriorate teh clearness of the obstacles.

As a stepping stone to full-scale physBall it might be the best solution to draw the connection though.

Wait… I’m just thinking of something. What if the game board and the world are actually the same. If the ball moves into an area on the board, a corresponding ball would move in the actual world. Now that could casue some mayhem. Especially as the unsuspecting players don’t know what they’re doing.

I do want to have some more playable content, a least for the exam exposition in September, because one basic game seems a little too little to make for a proper presentation. That’s why I want to revisit physBall and make the game a little

easier development-wise, while also working a bit on the context in which the game takes place. Because the first attempt didn’t get the response I hoped for I think people have to

be eased into the concept som more. That’s why I decided to create a smallerscale obstacle course. The principle of the game is still the same, but the environment in which it takes place is very obvious and the challenges are very direct.

The obstacles will be tile-based, so I can grow or shrink the entire track as desired. Coming up with a variation of obstacles is a challenge, but I’m sure that will work out. I don’t have much trouble with building objects in the Second Life editor. Instead of a money prize, the game will feature a grab bag to which people can make donations of virtual objects, preferably tools to play the game with. Winners of the game will get a chance to take a random onject from the grab bag. In this way I like to encourage the sharing of ideas and resources and more collaborative design.

After I did some work on the website’s presentation today I logged into Second Life to see how I could go about kicking off Babel as a game event. I learned that I can only host official events on land that I own or that’s owned by a group that I’m a member of. But because the Babel game requires so many prims it’s best played in a spacious sandbox. So I guess I have to talk to some friends, gather people on the spot and rely on word-of-mouth to spread the buzz about this game.

Unfortunetely there weren’t any friends online, and the sandbox-dwelling crowd was rather unresponsive. So I started to play around with prims myself, to test what kind of structures could build the most stable tower. After 2 unsuccesful attempts I came up with a 2-layer structure of an ordinary cube, bracketed at the top with 4 corners. The brackets would keep the next block in place, in a way gripping onto it. This worked great until someone decided to place a bomb on the side of my tower. The blast pushed the tower over, making the topmost blocks disappear off-world, and then… it got stuck. The brackets held the tower up, even though it was now leaning over in a very disconcerting way.

The guy with the bombs kept trying to topple the rest of the tower and I had to get away to get some dinner. Afterwards I came back to see if he had managed to break down the tower, but it was still standing. I think I’ll leave it for the moment to draw some attention from teh sandbox crowd. And then it’s on teh the next sandbox to make abother attempt.

Attached to the site is a forum where the games as well as Second Life in general can be discussed. Please, have a look and tell me what you think of it. And if you have a Second Life account don’t forget to sign up for the forum.

www.secondstrife.com

Here’s the video of today’s testrun.

I’ve uploaded the latest version for your viewing pleasure. And don’t worry, it has some pictures too.

The first example stands about 5 meters tall. That’s twice as big as an ordinary avatar, but not big enough to make a real impression. That’s why I decided to explore how far I could push the size before it would become unmanageable. It turns out that size is pretty big.

I browsed SL a bit as I was sure some people would have tried to make mecha’s before. As expected the virtual world is riddled with Gundam, Macross and Evangelion replica’s. Unfortunately most of these copies were reduced in size to match an ordinary avatar. Visual detail seems to be preferred over actual scale. I did find some interesting attempts though. The most spectacular being the large mecha’s designed by Detect Surface, a resident I coincidentally met a few weeks ago. He demonstrated some of these and told me they could move quite accurately on the basic avatar animations.

That sounded hopeful. I’d already tried to script the attachments to follow my movements, but that just didn’t work… at all. The next model I made by scaling up the first one and extending the limbs. I made use of thin sticks to extend the range at which I could place the attachments from the actual limbs of my avatar. They also helped to align the attachments properly.

This model stands about 20 meters tall, a size that makes quite an impression and is clearly visible from across an entire sim. It also moves quite well, with only the lower arms and legs stretching and bending too far during extreme movements. Some careful tweaking of the basic alignment should alleviate this problem for the most part.

As I was happy with the model I made the next step was dressing it, to make it visually attractive. I’d already decided to stick with the Victorian visual style, so these wouldn’t be Japanese, high-tech, manga mecha’s. Instead I choose to create giant versions of stereotypical Victorian people in traditional dress. this is the result so far.

I’m still working on the face. Creating fluid curves is extremely hard in SL, as the editor’s based on geometric shapes that can’t be twisted and contorted all that much. When the shapes are done I’ll have another pass to adjust relative proportions and make the model look right. Then I’ll perhaps add some textures, although I actually like the plain colours better than most of the texture work done in SL.

That’s it for project progress. I’ll have to focus on my thesis next week.

In the last couple of days i created a set of basic objects for the ‘Beacon’ game. I kept with the victorian ‘arcane technology’ theme to make these objects stand out from the rest of SL, which is generally modern/photorealistic.

I wrapped the objects in a box and sent them to Elbereth so he can have a go at scripting the game mechanics into the objects. In the meantime i will look further into a way of making the game more presentable to an audience outside SL. I’ve been thinking about a web-based forum and a player-updatable map, but I’m not sure if these will be useful tools to the game. I have to look for some succesful cross-media games as a point of reference.

Below the line is a more detailed description of all the game props.

The first beacon to use is the detector beacon. At first the treasures and keys will be hidden from sight. A detector beacon can point out their location and proximity. When the detector gets within a certain range a treasure/key will become visible.

* The detector consists of 2 parts, a ‘pointer’ and a ‘spinner’.
* The pointer shows the directions of all treasures and keys within 100 meters.
* The closer the detector is to a treasure, the more dominant that treasure will become to the pointer.
* The spinner indicates the distance to the closest treasure. The closer the detector is, the faster the spinner will spin.

When a treasure or a key is found an attractor beacon is needed to pull the treasure/key towards its counterpart. Multiple players can each draw the treasure/key in different directions. Each beacon will exert an equal force on the treasure/key. The actual direction and speed will be the average of all applied forces.

* An attractor can rotate 360 degrees on the horizontal plane.
* An attractor projects its beam along a horizontal line.
* An attractor can attract a treasures, keys and players.
* An attractor can only attract one object at a time.
* An attracted object moves at 1m/s towards the attractor.
* An attracted object won’t move within 5 meters of the attractor pulling it.
* If movement looks better when applying some inertia, don’t hesitate to include it.

Players can increase the force their Attractor beacon exerts by linking it with amplifier beacons. Each amplifier beacon will increase the force of the linked attractor beacon (1x, 2x, 3x, 4x, etc.)

—————-
* An amplifier can rotate 360 degrees on the horizontal plane.
* An amplifier projects its beam along a horizontal line by default.
* An amplifier can rotate 45 degrees up or down along the vertical axis.
* An amplifier can benefit all other beacons, but not other amplifiers.
** Each attached amplifier will increase the detection range of a detector. (range = 100*(numberOfAmplifiers+1))
** Each attached amplifier will increase the attracting speed of an attractor. (m/s = 1*(numberOfAmplifiers+1))
** Each attached amplifier will increase the destruction speed of a shatter beacon. (b/s = 1*(numberOfAmplifiers+1))

A shatter beacon can destroy another beacon by applying a force on that beacon for a certain amount of time. Several shatter beacons could be used together to increase the speed of destruction. Another option would be to link a shatter beacon with a couple of amplifiers to quicken the process.

* A shatter beacon can rotate 360 degrees on the horizontal plane.
* A shatter beacon projects its beam along a horizontal line by default.
* A shatter beacon can rotate 45 degrees up or down along the vertical axis.
* A shatter beacon will project a beam at 1 burst per second.
* Each burst will decrease a target beacon’s hitpoints by 1.
* When a target beacon reaches 0 hitpoints it will shatter (hence the name.) and be deleted.

The treasures are the objectives of the game, and the main motivation to play it. Every time the games revenue passes a certain amount a part of that money will be put inside a treasure, which will then be hidden somewhere on the SL grid.

* A treasure will be invisible (transparant) when placed on the map.
* A treasure will become visible (textured) when a detector comes wihtin 10 meters of it.
* A treasure can’t be destroyed.
* Each treasure has a single corresponding key.
* A treasure will align itself to an attractor that is pulling it.
* A treasure will open when the right key is inserted in the lock.
** The contents of the treasure will be payed to the player that turned teh key.
To each treasure there will be a corresponding key. The treasure and the key have to be joined together for a player to claim the treasure. The key will always be placed a fixed distance away from the corresponding treasure.

* A key will be invisible (transparant) when placed on the map.
* A key will become visible (textured) when a detector comes within 10 meters of it.
* A key can’t be destroyed.
* Each key has a single corresponding treasure.
* A key will align itself to an attractor that is pulling it.
* A key has to be aligned to a treasure to be inserted in the lock.
** Alignment doesn’t have to be pixel-perfect. As long as it approaches from the right side.
** On a collision with the lock the key will align itself to the lock.
* When a key is inserted in the right lock the treasure will open.

General Properties
* Beacons are always ‘on’. Players can’t deactivate them while maneuvering.
* Only 1 beacon can be active per player.
* The active beacon is placed above the player’s head.
* Beacons can be switched from inventory at any moment.
* Every beacon has 100 hitpoints.
* A destroyed(shattered) beacon will be removed from inventory.
* Beacons can be ‘locked on target’ as long as the target is within range.
** Targeting range is 100 meters.
* Beacon rotation should be about 10 degrees per second.
* Player movement should be fairly slow. SL wasn’t made for real-time, so we shouldn’t force it.
** The players will be large, cast-iron mecha’s in the final version, so maneuvering should feel heavy and clunky.