More definite look

Dear readers,

Last week we had a 'tech meeting' for the platform game which means we talk about the technicalities of the game. During this meeting we decide what can or can't be done and how it should more or less be implemented. The game is now starting to have a more definite feeling. As shown here:
 

In the image above there's a lot of textures and objects which are still just a place holder. At the moment some of that art is already coming along nicely (made by Matthew). It's very pleasing for me to see as a programmer how the art is really making the game look great. Unfortunately for you I'm not allowed to show you anything too revealing.


-- Stijn

Explosion in action!

If you’ve been reading this blog you should know I’ve been working on the 3D model and animation of a exploding and sinking ship for our “water race game”. Yesterday the head programmer on this project (Pieter) found some time to work on the explosion sequence. Implementing it turned out to be a bit harder than planned. The scene is set up like this, the ship model and debris parts are part of the track scene, the harbor track in this case. I’ve placed seven bomb dummy’s at key positions in the ship model, next I’ve linked unique debris parts to each bomb (i.e. hull debris linked to a bomb placed in the hull, cabin debris parts linked to the cabin etc.). The actual sinking of the ship is animated in a separate file, only the animation transforms need to be exported.  

Now it’s up to Pieter to blow it all up, this is how it works: When bomb trigger is activated, a ingame pickup in this game, the game camera switches to a camera which focuses on the ship, next the exported sinking animation is assigned to the ship model and starts playing. Explosions are spawned at the seven bomb dummies with short intervals, each explosion gives a impulse to the debris parts linked the corresponding bomb which causes the debris to fly around. I can tell you it’s quite spectacular! Check out the screen! 

Matthew

Sprites in 3D games

Hello all,

The time management game is making good progress. Richard started to work on the interface animations this week. We are using 3d models to display the interface elements. Some of them need to be animated. Imagine appearing. disappearing or animated icons in general. Such as coins or clocks which need to have some sort of animation. Not only to make it look better, it's also important information for the player to see what is going on. It shows the player the status of an object/item for example.

These animations are done by changing the 3d mesh of a model realtime. Imagine a clock icon playing a 'Ticking' or 'Counting' animation. The image below shows a mockup animation sheet of this icon.

Every so called 'Frame' or 'Sprite' is actually a seperate 3d mesh. These are all flat objects consisting of 2 triangles forming a quad, but have different UV coordinates to display another frame of the animation. The model which is displayed ingame will change it's mesh during the animation. It will switch between resource frames in about 50 milliseconds, so it will look like a 'Ticking' , fully animating, clock.

This technique is often used in 3D games. Smoke, fire and debris particles can be done this way for example. Also explosions can be made using this technique, as seen in burnin rubber 4.

Thanks for reading :)!

--Joep

Regional Heroes

Hi Everyone,

As you might have read from Pieter in yesterday’s post, the Xform office 2.0 is now officially opened! Bear in mind that’s finally official, because we’ve been busy behind the scenes for almost two months. It was ready a while ago, but is now officially open for business now that everyone has collectively spilt some of their beer on our floor. We don’t give it to our dead homies here in Holland, we just spill it on your floor at parties when getting drunk, in honour of the host ofcourse!

More miscellaneous news that I can tell you about is Xforms’ appearance on RTV Utrecht. This is a regional (local) channel here that’s taking a closer look at Utrecht (Utrecht is both capital city of-, and an actual province, same name). They’re not just looking at Utrecht, but at developing businesses worthy of a special mention for students. So it might not be national television, it’s still a nice bit of publicity for the company. Plus, you get to see our (2.0) office and Diederik. Unfortunately, I wasn’t there because I had the flu and Diederik had to do all the dirty work himself. Luckily he knows his own business like no other and he did an excellent job telling everyone about his company!

So, if you’re Dutch or admire the way our throats sound when we spit out our barbaric language, please take a look here: http://www.rtvutrecht.nl/content/rtvgids&dag=1

Click on “Campus Cam” at 18:10 to view the show, our segment starts at 11:40 minutes into the video. I'll have a decent post for you guys again next week :)

Enjoy!

-- Erik

Blown away...

Hi all,

Another day, another post…

Before I get into all kinds of nagging I want to thank everyone who was at our official opening last Thursday. We had a couple of drinks and a good time, celebrating the Xform 2.0 office. Furthermore, I am proud to say that we have finally got our own Xform theme song!  It has a very 80’s style feel to it. Think about the intro themes for Mask, He-Man, etc. The only thing left we need now is our own cartoon… That would be awesome ;)

Anyways, on to more pressing issues. As you might know we’ve been hard at work on a couple of games. My main responsibility is getting the ‘water-game’ technically up and running. I talked about water before so I won’t touch that subject anymore. At the moment I am doing a lot of ‘boring’ stuff.

Implementing and tweaking the general flow. It is boring to make, but it is extremely important for a good user experience. We have to think about how long loading the game takes, initializing the world, when we should start a countdown sequence, in which order do we show the end results of a challenge. Do we show the game character first celebrating his victory and then show the end results (time , rewards, etc.)? Or do we show him celebrating in the back ground while displaying the result? It all sounds very boring and trivial, and for some things it is, however timing and anticipation can hugely influence the user experience. While typing this I think this might be a great subject for another blogpost, because today I wanted to talk about something else; explosions. I love explosions. I really do. I could look at and talk about them for hours,…

For this game we need more and bigger explosions! IMHO. Matthew told you about destructing the ship a couple of posts ago and this will be my test case for a new and improved explosion system. In our previous games we’ve tweaked and created some cool explosions already, but you haven’t seen anything yet. In Burnin’ Rubber 4 we had to cut our new explosion system, because it was, at that time, too slow. If you look at one of the first trailers of that game you can see some of them in action. I have been working on optimizing that system.  Furthermore, I have added and will add more features ;) The planned shockwave effect will be implemented and I want fire trails for debris. That would look awesome with all the parts exploding. Hopefully, I’ll have some ingame, instead of editor, screenshots for you next week!

Off to explode some more…

-Pieter

Moving platforms

Dear dear readers,

This week I've worked with Joep on fixing bugs in ****. Pretty much all bugs have been fixed, so we're happy about that. One bug in particular was nasty as it happened only in the online version. In the end it turned out to be an old online file which apparently was out of date since a long time ago, but up until this moment it didn't cause any problems.

For the Rhino Rush game, we've had another meeting discussing what should be in the game and how we're going to do it. The... frolicking... ;) game designers thought it would be fun to put in some moving platforms. Easier said then done as is the case in almost every feature they come up with. But it's also a challenge of course.

As we're using physics on the character for collision detection and resolving, the platforms have to be done using physics as well. I started out with a box as a platform and making it move by interpolating the platform's position between its begin- and endpoint. Well... the platform moves but when the player stands on it while the platform moves up, he was hardly able to move due to constant collision resolving by the physics engine. And when the platform went down the player suddenly moved normally again as the platform wasn't constantly placed in the player anymore. Also by bluntly setting positions of objects the physics engine won't know the linear velocity of the object so I'm not surprised this didn't work very well. Anyway it should be clear that this is not the way to do it.

So I turned to my spring constraints, attached 1 spring constraint (a very strong spring with rest length 0) to the platform and another constraint to keep the platform in a set orientation (you don't want the platform to rotate when the player stands on the edge of the platform). Then instead of setting the position of the platform, I set the endposition of the spring and linear interpolate that between the desired begin- and endpositions of the platform. That worked a lot better, but the platforms were a bit wobbly: they would move around when you jump and land on them and when they reached their begin- and endposition. But when I showed it to the game designer he wasn't too pleased with it. Although wobbly platforms can actually work fine a game if you give it an appearance of not being to sturdy. But ok, let's try to get the wobbliness out of the platforms as well.

This required me to use the 6DOF joint. A joint that is very generic and allows you to do many things. As such it comes with a great deal of variables you can set: axisDrive, axisMotion, biNormalDrive, biNormalMotion, driveAngularVelocity, driveLinearVelocity, driveOrientation, drivePosition, globalAnchor, linearLimit, localAnchorA, localAnchorB, localAxisA, localAxisB, localNormalA, localNormalB, normalDrive, normalMotion, swing1Limit, swing1Motion, swing2Limit, swing2Motion, swingDrive, twistDrive, twistLimit, twistMotion. Well, ok that's all fine and dandy, but where's the documentation? Well... there was very little documentation about it. So I just had to experiment a bit with it. And I also found this image, which was also helpful in figuring out variables:

I mean seeing a variable named swing1Motion, it isn't exactly clear what it's for. But from the image we can see it's actually pitch. And twistMotion is yaw, while swing2Motion is roll. We can prevent changes in pitch, yaw and roll by locking them because we don't want our platform to do any of these movements. There is actually only one kind of movement we want and that's along the local axis (See platform image, where A is platform beginposition and B is platform endposition).

 

So we set our local axis to the direction the platform is moving which is the normalized vector of B - A. Then our normal axis should be set by rotating the local axis 90 degrees on the z-axis. And the binormal axis will be calculated by the physics engine (using a cross product). But we're actually working in the 2D plane and we might as well pick the z-axis to be our normal axis, which is simply (0,0,1), thereby avoiding doing a vector rotation. The result is satisfying: no more wobbliness. Unfortunately I can't show you that in an image, so you'll just have to believe it and verify it when the game is finished :P

Till next time,

-- Stijn

BOOM!

 

If you've ever played our games you should have noticed that we like really like explosions, I mean really, really like them! So when we discussed which features the "race game on water" should have we all agreed this game needed explosions, but not like we've done before. The idea is that you as the player create shortcuts by blowing up environment objects which will be unique for each track. For the Harbor track I've created a ship which will blow up, break in half and sink. The rear end of the ship sinks half way into the water creating a huge ramp which the player can use as a shortcut. When the explosion occurs we'll switch to a cinematic camera to give the whole scene a more dramatic effect.

 

At this point I  finished the ships mesh, debris parts and sinking animation, It’s up to Pieter now to dynamically blow the debris parts away and insert the explosion graphics. I'm really curious on how this will turn out in the game, I guess we all have to wait and see...

Matthew