as a side project of another game I started the project[INDENT][INDENT]BitOfMagic
[/INDENT][/INDENT]Idea:The idea behind this project is to provide an open source rigged BGE-compatible character for other projects and a frame work to setup interactions with the environment as easy as possible.
If you think the model looks familiar, you are right, it is ManCandy by Bassam Kurdali.
[INDENT][INDENT][INDENT][INDENT]
[/INDENT][/INDENT][/INDENT][/INDENT]Requirements:You should at least know a little bit of Python. But it should be fine to use the final framework without that (I’m not sure about this point by know).
Story:As this is a demo the story seems to be not that important, but I do not want to understimate the “showeffect”. The following posts will contain the sketches of the story board.
The story will show:
character animation
user interaction
automatic processing (usage of an FSM)
interacting with objects
interacting with other characters
everything must be linkable
everything must be “addObject”-able
Status:
The character tree is present.
ManCandy is rigge.
ManCandy can stand and walk.
The character physics is done and applied.
Some ManCandy animations are done.
The character logic is mainly done.
Table modelled
Crayon modelled
Team:Project lead: Monster
by now everything else: Monster
Credits:- Idea: Monster
The rigged Model is based on ManCandy by Bassam Kurdali under Creative Common Licence
Other Models, Animation, Logic, Scripts: Monster
Textures: not yet
Sounds: not yet
Demos: The first WIP-demo is part of the project. It is the ActionPlayer containing the ManCandy rigged model for GE. The file already includes the current poses. The final game will have the poses in an separate file.
Here is the ManCandyActionPlayer. Please read the AAREADME text file.
Yes, the player is supposed to “draw”. That means the players moves the crayon with the mouse. As long as the crayon is “near” the right path the mouse will follow the draw path and draw otherwise not. The user does not need to be an artist. It will be just simple outline drawing. When most of the drawing is complete (I think 90%) the outline will start glowing and some special effects will assemble the object to appear. That is the “magic” part.
By now this is just an idea, but I do not expect much problems there. Most of that will run automatic like a cutscene but inside the BGE.
I think the user will need some guidance to discover what the game expect. My current idea is that a speaker is telling the story via the sound module. Additional some very transparent “helper” objects can show (like ghosts) what to do.
Edit:
I continued with this. What I have now is a mouse controlled pen. The pen is able to draw by adding planes with a texture.
The advantage
the trail follows the movement.
The disadvantage is
-with fast motion it will result in a dotted line.
-as it can be drawn everywhere there are a lot of added objects.
How to restrict the drawing to the sketch path?
A) - add an hidden object to draw on. When the crayon hits the objects face it will draw. Otherwise not
disadvantages:
The lines might not be straight
Difficult to determinate that the drawing is complete
B) if the crayon comes near a “path” the crayon snaps to the path. If the mouse is to far away the crayon leaves the path.
advantage:
straight lines
easy for the user to follow the path
disadvantage:
difficult to determine that the drawing is complete
C) similar to A) but the crayon does not draw. Instead there is a preset of hidden marks. The marks will become visible when the crayon was over them.
advantage:
straigth lines
easy to determine that the drawing is complete (e.g. all visible 90% visible)
limitted number of trail objects
D) a combination of B and C. The crayon snaps to a path and unhides the trail marks.
Avantage:
I will use this post for problem that I discovered during the project. I will add the solutions when found. That might help me and others in different projects. We do not all need to fall over the same obstacles.
This is additional work. Lets see how organize I am to write that down :D.
By the way a first WIP-Demo can be found at the top post.
Linking armatures:
Blender and the GE use armatures in diffent ways.
Blender wants the armature added as modifier to th skin mesh, while the GE wants the skin mesh armature parented to the armature.
This is usually not a big deal, but the problems start when linking these objects. First what to link? The skin mesh or the armature. The easiest thing is to link the skin mesh. The armature is linked through the modifier.
Unfortunately the linked mesh cannot be parented to the linked armature or any other armature.
Also it is not possible to add logic to the linked armature.
Solution:No solution.
Workaround:copy the skin mesh,
copy the armature.
The final armature/mesh object tree can be linked as group to a later file.
2. Action linking:
It might make sense to create the used actions in a separate file and just link the actions to the final file. It seems to be difficult to link all actions at once to the final file.
Solution:add a default armature (“actionHolder”)
add an action actuator for each action (no activation needed)
(optional: let the armature and itself with an always sensor)
link this armature to the target file
3. Execution order and python path:
To keep the python scripts in an folder it seems to be good to extent the python search script by this folder.
But this extention must be added before calling any script from this folder (or it will not be found). The priority button of the python controller seems to be the solution. But this does not work if there are other scripts that run in priority mode as well.
Solution:the first frame is for extent the python script path only
all other initializations start with frame two.
Better Solution:
all objects calling objects from the scripts folder get a python controller calling the initialisation in priority mode. As this is done just once it is not a performance problem.
