The event is a platform and a meeting point for the European games community. NLGD is one of the sponsors of the Apricot game. The NLGD offers a platform to the strongly upcoming game-industry. Too often one tends to think about games as merely games for the youngsters. The NLGD shows by means of activities, publications and events that games and the game-industry have a huge social, economic and cultural impact.
Blender Institute will give short demonstrations on Thursday and Friday in the Expo Village. If you are interested please pass by and on the artists or main developers will give you a demonstration about Blender and Crystal Space. Also Ton Roosendaal will give a presentation on Friday in the Central Museum, de Refter, from 10.45 till 11.30. For more information about the venue, route description and speakers download here the pdf.
Planning a game project is not easy… and especially not to define when things are really good enough. On many parts you can work virtually forever! To ensure we have a good balance between quality and quantity, we’ve defined three main focus points for the next 6 weeks.
1) Full functional CrystalSpace game prototype
the main character in perfect user control, well animated, and with advanced interaction with environment
stunning visuals
one quest (the “sheep game”)
game intro “cinematic”, menu and overlays
2) Project presentation
CS players + game running cross platform (Linux, OSX, Windows)
Getting the main character system finished on industry quality level is most probably going to take Pablo and Darius full-time. Frank will continue work on visual quality and speed.
To allow Chris and Pablito to work ahead, and provide them with sufficient challenges, they’ll work on prototyping the other characters and a new level in Blender’s game engine:
3) Blender Game Engine version (new!)
use Blender GE as design and rapid prototyping tool for new characters and levels
test implementation in Blender GE of current game ideas
It’s been surprisingly easy already to quickly rebuild in Blender the basic Apricot game experience. Will be interesting to see in a couple of weeks how it compares! However, I still expect that CS will allow far more detailed and advanced games… and Blender GE prove its value as tool for artists to design and develop ideas with.
But, we’re glad that there’s time and interest in using and hopefully improving this part of Blender!
-Ton-
(Images: today’s snapshots of work in progress. All with unfinished shadow/light mapping. First and third is CS, others is Blender GE.)
GLSL shading is now in blender, thanks to the work of our rockstar coder Brecht. Just enable it in your preferences under System & OpenGL, and change to the shaded draw type. Among other amazing things, this means normal maps in 3d view!
Along with this also comes the ability to paint multiple textures directly onto your objects using texture paint mode in the 3d view. Because with glsl blender can draw materials with texture stacks that contain stencil maps, splatting grass and dirt onto your terrain is as simple as using texture paint mode with a stencil map assigned to the uvs. It’s such a beautiful thing. Watch the video to learn how this is done. The idea is that this same texture stack will then be exported to crystal space for splatting for the game.
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 !
margreet | 
06 16th, 2008 
