Author Archive

Here is short movie showing current progress of the game. You can see fishes for example, how they know where to swim ? It’s possible to make environment collision sensor but common solution in the gamedev world in this situation is navigation graph. Games are always cheating, don’t trust them ๐Ÿ™‚ Game needs to convince player that something looks natural but hidden method is always something easy to use/easy to compute. Fishes also trying to not to swim too close to each other, but not to far ! Sheep also using same herd algorithm included in the Crystal Entity Layer.

Navigation graph for sheep:
navigraph.jpg

Movie:

Apricot: Crystal Space GamePlay (July 2008) from Pablo Vazquez on Vimeo.

Comments 30 Comments »

NLGD expo in Utrecht was very successful. People likes Apricot and our tools. Most important thing was that organizers supplied free beer for us ! Also we meet some cool guys from other teams/companies (cheers!) so it was very good experience. We have some photos, and also movie with current work-in-progress Apricot powered by Crystal Space 3d engine.

img_1422.jpgimg_1423.jpgimg_1404.jpgimg_1407.jpgdscn2226lo.JPGimg_1411.jpg


Apricot: Crystal Space Preview #1 from Pablo Vazquez on Vimeo.

Comments 43 Comments »

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.

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 !

Comments 17 Comments »

We are preparing to open our repository for a public to feel real Open Source power. At this moment we need people who will help us with making package releases for GNU/Linux, Windows and OS/X. So if you have a time, if you know something about packaging and bug tracking/solving write to us ! Apply to: res[-a-t-]crystalspace3d.org

Comments 19 Comments »

Some people are curious how everything works, so I’d like to explain how we combining every piece together and putting life into it.

What is the biggest obstacle in the typical development process ? Well – let’s divide that process to 3 stages: planning, implementing, watching results.

1) Planning: It’s a very cool stage, you can sit in comfortable place, take a favuorite drink, piece of paper and now you thinking and inventing, nothing is wrong here, you need a good plan.

2) Implementing: So before you start Implementing your brilliant alghorithm you spent a lot of time already, but can you do the same with implementing ? Well, better not too much. It is also nice stage, many people enjoying programming for example, but if implementing stage is harder than planning – then something is wrong. Tool serves for human not human for tool.

3) Watching results: Worst case is when you need to wait too long between implementing and seeing results. It’s a waste of time, really nothing interesting happens there, so perfect time for this stage is 0. Now we have much modern tools but in the 70’s you waited for a result a couple of days waiting in a queue and converting program to punched cards. Later in the 80’s you need to write program, compile, link then see result so it takes a couple of minutes. In the 90’s during game development people need to export 3d model, put into right directory, write in code loading and displaying, initializing etc, then compile, so still a couple of minutes. But today we have 00’s (?) ๐Ÿ™‚ So in our tool this time is Zero. We can see results imediatelly.

When you see on screenshot:

Left-top corner: working game using external engine, you can play there.

Right-top corner: blenders 3d window, you can add, delete, translate and edit objects,just blender.

Left-bottom corner: visual scripting using logic bricks.

Right-bottom corner: python console so you can program in realtime and everything changes in the same time in the game.

logic.png

Comments 30 Comments »