Last weekend I’ve been out of the Blender Institute, spending it in what would be a presentation of Yo Frankie! on the Game Development Campus 2008, in the University of Aalborg, Denmark.

The goal of the Camp was to share ideas about games, get to know each other, make groups, and then each group (7 groups in total, with 6 people each) will have to develop a game for the end of the week, using Blender as the Game Engine where all the games will run.

It ended up being lot more than that!  met a lot of people and made very good friends over there.

But the good news are that they are releasing all the games under the Creative Commons license! quoted from the Press Release:

“Inspired by the open-source game project, Yo Frankie!, all the teams have decided to release their games under the Creative Commons license.
The teams decide on the specifics for the licenses individually. This means that the games created at the summer camp will be made available on the website, along with all the code, 3D models and textures. All the games will run on all operating systems (Mac, Linux and Windows).”

And is all thanks to you people for making this game as Open as it is, sharing characters, animations, textures, and helping with constant feedback.

Also, the Game Development Camp is going to be giving away each student in the camp a copy of Yo Frankie!, and the Essential Blender book. Isn’t that awesome?

Sadly I had to hop back to Amsterdam and couldn’t spend the entire week there, we have to finish a game here!, but I will love to attend next year 🙂

Here you can see the Official Press Release.

Games OnLine!:
Check them out here.

Each game have its own section there, where you can see:

• Group’s Blog (Danish)
• Download Source Code (.blend file)
• Download Game (.zip)
  It’s .exe, but they run perfectly under Wine, however you can always download the blend file and press P, or save your own runtime file. 🙂

Updated the Press section in this site as well.

Thanks to everyone there, I had a great experience and learned a lot, see you next year!
(charlieee!)

Yo!, we got a name:  Yo Frankie!: A Furry Vendetta

People voted for this names (ain’t open source beautiful? =), and we sorted them out like: Yo Frankie! the main name, and “A Furry Vendetta” as the name of this episode, now is your time to start thinking/making the next episodes 🙂  Yo Frankie: “Point Blank Frank”, or “The Rise Of Frank” are the most voted, pick which one is going to be the name of your own level (s)! 😀

You can download our new logo in all this flavours:
Big 3DLogo, with background – 1440x810px
Big 3D Logo, no background (alpha) – 887x670px

2D Yo Frankie! Logo – Small Size / Bully Size
2D Yo Frankie! Text – Small Size / Bully Size
2D Frankie Icon – Small Size / Bully Size

.zip file with all this (~2.2mb).

Peace.

“Hola!, this is Pablo..”, that’s the first thing I say in this video that tries to explain a couple of effects I came up with the last week, playing around with shading nodes in real time.

The thing was that Mist option is still not supported in GLSL, how can I work around this?, Nodes! the great “Camera Data” is an input node that let you use information from the camera view to play with, such as the View Vector, View Z Depth, and View Distance (which is the one i’m using in this video). After playing for a while, I found out that this method was much more better than the boring Mist!

I ended up using this method for effects such as:

• MultiColor Mist:  Color in front of the camera is more peachy, slightly noticeable, then more far away is a bit orange/red, and veery far away the color tries to mix with the sky.

• SunRays: Just planes with a bright alpha texture, the trick is made by the View Distance factor of the camera, changing the alpha to zero when you get close to them, or far away from them (you don’t want to always see sunrays).

• ChangeAlpha: for walking through trees leaves in a way that they don’t block the view, they have a node setup that makes them alpha zero when they get close to the camera, so you can see through.

Here the video:

Download the OGG version. (~30mb)

Nothing of this is actually new, you can do this for rendering since past year, and for GLSL is also there since weeks, so you can play with this by using any barely recent build.

* by the way, expect more videotutorials like this one (but better explained, better quality, etc), in the Apricot DVD! 🙂

That’s all folks! Enjoy!

More awesome blender dev. It’s there at last, the bake panel has existed far too long without the shadow bake option. Thanks Cambo! The plan for the BGE game is to use dynamic shadows for the character, and bake shadows for the level.

Note the quad split option in the image above. Blender’s baking needed an option for quad splitting as well. Internally, most systems will split a quad into 2 triangles, and blender’s no exception. It checks for non-planar (bent) quads and splits them in the direction that gives the least distortion.

While good for rendering models, this causes a problem for baking because the split direction can differ from the one used to display and export. One solution is to triangulate all faces before baking and exporting, but this isn’t ideal since it would loose the edge loop topology and make models harder to edit later. To make matters more confusing, graphics card don’t all split quads the same way, but many game engines just convert to triangles when exporting.

Campbell was also kind enough to add this option to split quads in a predictable manner (0,1,2) (….) etc.

From Amir, one of the Crystal Space developer working on camera and movement system improvements:

No it’s not the new Hollywood blockbuster, it’s my test application for developing the camera and character movement controller! Because it takes a while to update python bindings when developing C++ code, I use this interim solution while doing heavy development.First you see character walking in and out of the camera. There is a slight spring, but only within a certain range of the relaxed position. You can visualise the camera as having a hard pole with a spring attached to the player. When the player walks into the camera, the spring becomes depressed and the camera will start to move backwards. If you move beyond the spring then you will just push the camera. So we calculate the desired forward movement to reach the player within our range for the camera using the equations:

cos (x) = camera_direction . camera_to_player
move = distance * cos (x)
=> move = distance * (camera_direction . camera_to_player) – forward_position_offset
Then you next see tilting the camera up and down. There is no standard or universal behaviour in games really for tilting so I took a bit of creative license here. Annoying the player with too many controls for just a camera can just be well, annoying. So how to incorporate the zoom? Well this looks like a nice solution. We actually describe the ‘hard-pole’ positional offset of the camera we just described as an elevation angle from the ground and a distance and can use the normal circle equations to find the camera position for tilting. For this zooming effect I just make the distance proportional to the elevation angle. You can follow this link to know best cameras.

Then it’s collision detection when you walk into the wall. This more than anything causes lots of pain. Some games don’t even let you pan into the wall 🙂 cheaters. Not only is the collision detection dependent on a calculation in one place, but another calculation is dependent on the collision detection in another place. Throw in 2 or 3 more of these cases and then you have dependency nightmares. Then panning into walls at large perpendicular angles when you first touch the wall when panning, usually means that the camera is oriented halfway between nothingness and the world. Therefore you need to offset the camera from the wall. But if you get in close, then this offset will cause the camera to flip on the otherside of the player and so you need to linearly decrease this. Then you also need a vertical offset for the camera, above the players collision box if the target is inside the player… and you need to interpolate this value too. Coming out of the zoomed-iness the camera will jump, so you must interpolate the zooming out also. This needs some more work, but well everything interferes with each other 🙂

To finish off there’s some preliminary character movement demonstration. I haven’t worked too much on this yet so it’s a bit rough. TODO: Fix the jumping of the camera between movement modes. 🙂 The first mode is when you go into fighting mode. No enemy is around so you just strafe around. Suddenly an enemy enters the view! The camera locks onto the target and you move around the enemy, rolling and dodging and doing attacks. The player movement needs work though yet, like smoother turning when moving diagonal after moving straight. Straight to straight movement should be fast though we think.

Any suggestions for you preferences? What do you think of mouse control for the camera? This is popular but I sometimes get annoyed when I’m accidentally knocking the camera. Below is the written document for player movement.

From Apricot:

Beside of developing in the Blender Institute we working remotely with other Crystal Space developers, they made a lot of new amazing improvements like new animation system, smoother collisions, new logic system, also camera, movement system and many other things. So without their work it would be impossible to release an industry-quality game. Cheers guys !