in Apricot Press, Blender Institute, Blogroll, Development, Media Gallery, Production, Random Fluff
Monday, January 14th, 2008 at 3:15 pm
Last weekend we had the first workshop for the Apricot project. Frank Richter from Germany, Pablo Martin from Spain, Campbell Barton from Australia,
Dariusz Dawidowski from Poland, Marten Svanfeldt from Sweden, Jorrit Tyberghein from Belgium, Brecht van Lommel from Belgium, Margreet Riphagen from the Netherlands, and Ton Roosendaal from the Netherlands met at the very nice and new Blender Institute Location in Amsterdam. There we discussed plans, ideas, and practical arrangements for his ambitious Open Game project. In the mean time we also met with the Peach team and saw the amazing work they have been doing so far. The work they did and are still doing will provide the perfect foundations for the Apricot game project.
1. Type of Game
One of the first things that we have discussed is what the type of game? After seeing the first version of the Peach animatic the team got a nice idea
about the story and setting. The nice thing is that the story lends itself perfectly to adaptation in some kind of game format. Still there are several options. In this meeting we discussed several possibilities and came up with five realistic possibilities:
Idea 1: Platformer style
The objective of this game could be to collect nuts for example. Remember that we’re in a cartoon setting.
- Relatively low technology on game logic side so less work on CEL side.
- Well known concept. Easy to get into.
- Very extendable. This kind of game is ideal to create a community adding new levels and stuff to the game even after the Apricot project has officially finished.
- Not much competition in the Open Source world right now.
- Relatively big levels. Lots of work to create them. Heavier on the engine.
- Many great commercial games to compete against.
- Lots of models to make.
Idea 2: Shooter game
Again, to stay in the cartoon style and theme of the movie this could be a shooter game based on shooting nuts for example.
- Same possibility to create a big user community modifying and extending the game later.
- Smaller maps are possible (compared to the platformer type).
- In a smaller map it would be nice to concentrate on detail to make really nice scenery. In faster games or games with bigger maps that is not as possible.
- Overused concept.
- Lots of Open Source shooters already.
- Relatively violent.
- More work to make computer AI.
Idea 3: Racer game
No nuts this time 🙂 But still it is possible to make a racer type game that fits with the theme of the Peach movie.
- Relatively low technology on game logic side again.
- Well known game concept.
- Almost the same extendibility of the game.
- Slightly less competition in the Open Source world.
- There is a need for rather big levels again. So harder to create for artists and heavier for the engine. On the other hand, the levels don’t need to be as detailed.
- There is at least one great game (Super Mario Cart) to compete with.
- This type of game is more suitable for game consoles and Apricot will not be for consoles.
- This type of game is slightly harder to fit with the story of the movie. The theme could be the same but other than that the match with the story is not as good.
Idea 4: Trap/puzzle game
Here is the idea is to have a more strategic game where you have to plant traps and solve puzzles in order to win against the computer opponent.
- Nice possibility to extend again although this time slightly more complicated since levels have to be created with traps and puzzles in mind. You can’t just slap in any odd level here.
- This game can be a perfect fit for the movie. Both with the theme and story.
- This kind of game has good replay value.
- Maps could be made smaller (compared to platformer).
- Again the advantage of having more detailed maps.
- More work to make the computer AI.
- Like said above a bit more complicated to make fun levels because of the traps.
- The game is not as easy to start playing with. First you have to learn a bit more controls (like how to set up traps and so on).
Idea 5: Party games or collection of mini-games with one bigger game combining them in a central theme
- This type of game is easier to extend and the advantage is that when Apricot runs out of time we can simply drop a few mini-games.
- Harder to come up with different game concepts. Instead of having to think about only one game you actually have to think about multiple (smaller) games.
- More artwork needed.
- Probably more suitable for consoles instead of PC gaming.
There were several other possibilities that we talked about like adventure, RPG (or even MMORPG) but these types of games are really not possible given
the limited timeframe and resources we have. In the end we didn’t decided the type of game yet given that not the entire team was present at the
workshop. The type of game will be decided during the first week of the Apricot project. But we already have a preference for either a platformer or trap/puzzle game or maybe a combination of those two. Like a platformer with smaller levels where you have to concentrate more on solving puzzles,
placing traps and things like that.
2. Technology Discussions
Depending on the type of game there are a number of technology improvements that we have to make in Crystal Space, Crystal Entity Layer, Blender, and
Blender2Crystal. One of the most important results of this project should be the improvement of the Open Source game creation pipeline using Blender
and Crystal Space. One of the basic principles of this pipeline is that it is the artist that creates the game. Not the coder. The coder provides
the tools, the logic blocks, the scripts. The artist then creates his art, assigns logic to the level or models and assembles the game.
The first technology we discussed is character animation. The movie is a cartoon. In cartoons you need really good character animation. Also in the
game we want to have really amazing character animation. Here a short summary of how this technology affects the four projects:
- Crystal Space:
- In Crystal Space we currently have two skeletal animation systems already: one is based on the external CAL3D project and the other is a system made in the past. Both systems are usable to some extent but don’t live up to the standards we expect for this game.
- So the idea is to start a new animation system. To that end Marten Svanfeldt will work on a new design and document where all the requirements and concepts are documented. After that is done this document will be discussed in the team and at some point implementation will start by another team member. By the end of March we should have a working system here so that the artists can start exporting their animations into the prototype game and see how it will really look like.
- Some of the desired features are:
- Bones (obviously) with the possibility to have vertices being attached to multiple bones.
- Morph Targets would be *very* nice to have.
- Define transition animations. For example, to go from walking to standing there should be a transition animation so that the walking animation doesn’t suddenly change into standing. Could be done with a kind of matrix describing how to go from animation A to animation B.
- A good way to specify synchronization points. These are specific frames in the animation where it is good to switch from one animation to another. For example, if you want to switch from walking to standing it would be great if that could happen at well-defined points so that you don’t see disturbing jumps in the animation.
- Good animation blending system and the ability to play multiple animations at once (like head/ear movement together with the normal walk cycle).
- Perhaps the possibility to have the animation adapt to the environment somehow? For example if an actor moves on uneven ground it would be nice if the right foot didn’t sink in the floor when the ground level at the right foot happens to be higher than the ground level at the left foot.
- Perhaps also the ability to have the secondary animations be controlled by physics (for example, a tail flapping around as controlled by the physics system).
- Crystal Entity Layer:
- The movement system needs to know about animations so that the object only moves just as far as the feet are able to move it. That way you can avoid the skating effect you often see in Open Source games. One way would be to use a callback system in the Crystal Space animation system that would send a callback to the CEL movement system every time the foot hits the ground (that callback could also be used for the sound system for example).
- We have to think about what we can do to allow for climbing. This is something that affects movement and animation system as well. Perhaps some way to place and use feet/hand constraints on surfaces (ladders, trees, …).
- Blender and Blender2Crystal:
- The artists need a very good way to make their animations in Blender and see how they would look like in the game. We have to see what we can do about in-blender preview in a way that is really compatible with how the game engine does it (in this case Crystal Space). Probably the best way would be to have a fast way to export the current animation and then have the game engine have a window in Blender itself where it can show the animation as it will work in the game itself. Also the ability to see how physics reacts with this and how the animation works on uneven terrain.
- We also need the ability to specify more complete animation sequences in Blender and export them as complete scripts. These kinds of animations can be used for cut-scenes or predefined places in the game where a very specific type of animation is needed.
Then we talked a bit about physics. One thing that we decided is to try to avoid to use physics for things that affect game play. It would be better to use physics only for secondary visual effects like parts of the scenery animating. In cases we need physics for game play stuff (like some of the traps or puzzles) we have to consider to use of fake physics because that is usually easier to control and make behave like you want it to behave. On the other hand the Bullet physics plugin is mostly working and can be used already. We just have to extend it whenever the need arises.
The next subject was rendering, lighting (shadows), materials, and shaders. The new renderer is in a good shape right now and is progressing well. Using the new renderer it will be possible to create really great effects for the game. Frank Richter will be the member of the team responsible for working on shaders and more advanced rendering features (among other things). As one of the main authors on the new render manager he is the right person for the job. At this moment the new renderer is not yet completely ready but we estimate that we only need the full feature set of the new renderer about three months after starting the project. And even before that the team can most likely already use parts of it. Similar as with the animation system we will
also need an in-blender preview (possibly using an integrated Crystal Space window) of materials and shaders.
Given the theme of the game we will also need good looking trees and possibly a forest of trees. The easiest way to solve this would be to just use manually created trees (manually created in Blender by one of the artists) and also have manually created lower detail versions. At the lowest detail we could let Blender generate billboard clouds. Depending on the status of imposters in Crystal Space we could also try to use a more automatic approach where imposters would be generated at runtime by the engine. This is less work for the artist of course. Automatic generation of lower level of detail for the trees can also be considered.
Other things to do are features like fur and grass. At worst we can always fallback to using a regular texture for fur. But if we can find a nice and usable technique to make fur that actually looks good in real time then of course we’ll use that. Same for grass although using a texture only for grass that is nearby is not really a good option. In this case we will have to find some better technique. Perhaps instancing or something similar could be done.
To make the scenery really alive we probably also want to use various things like nice water (ponds), falling leaves, bugs that walk around, dust that appears at the feet of a moving actor, footprints, and stuff like that. Most of that can already be done with existing Crystal Space technology.
Given the philosophy of letting the artists make the game we need a good foundation on which the artists can actually do that. To that end we decided to use a mix of C++, python scripts, and CEL quests to handle the game logic. C++ would be used for parts of the game logic that require a lot of cpu intensive code. For example, AI could be one of those things. If C++ modules are generic enough they can of course also be put in the CEL or Crystal Space projects but if they are very game specific we’ll keep these C++ modules as part of Apricot. The python scripts would be used for most game logic and the CEL quests would be used by artists so that they can control and edit a lot of the game logic parts from within Blender
itself. To that end blender2crystal has very recently been extended with a very nice quest editor.
We also need sound effects and music of course. For the creation of the sounds we are going to depend on external contributors. We already got a
few offers here. The actual coding of the sound system will be done by the team itself and most likely it will involve some kind of property class in CEL to control when and how to play sound effects. One example of this could be the sound of footsteps. If the animation system sends out a callback every time the feet hit the ground then this callback can also be used by this new property class.
Most of the discussion above focused on improvements in Crystal Space and Crystal Entity Layer. But to improve the game creation pipeline we also will have to do a lot of improvements to Blender and blender2crystal. Here is a short list of improvements we already came up with during the workshop:
- Extend the Blender Python API to make it easier for external tool writers (like blender2crystal) to access certain parts of Blender.
- Especially around user interface the Blender API could be extended considerably. Currently there are lots of small problems in the blender2crystal user interface.
- We need an easier way to interface Blender with an external game engine so that it would become easier and faster to program an engine specific preview. Not only for Crystal Space, but also for other game engines.
- Billboard cloud generation would have to be improved.
- We have to examine all the things we can do to help improve the animation tools available in Blender so that they are better suited for game animation. This also includes the ability to define, preview, and export full animation sequences for cut-scenes (for example).
- With such a preview it would of course also be nice to be able to have that animation preview work in a semi-realistic environment so that the artist can really test his animation cycles (for example walking cycles) against a real environment (like walking on a sloped terrain for example).
So it was a very productive weekend and I’m really very excited about this new game project. It really will be a very ambitious project and I think the Open Source game development community will benefit a lot from it.