[Long rant] Making the game non-coder contributors friendly
Posted: Fri Feb 12, 2010 12:27 am
Hello,
Maybe some of you remember me. I proposed some units models months ago. But, like in a lot of others games a tried to contribute, i stopped it.
Because i can't AND because i won't include them in the game. Well, it's not totally exact but.. well, read before.
What pushed me to write this is another post in the "Battle for Wesnoth" game. The post was a long article that said, basically, most "free" games projects are very artist unfriendly (who said "Spring" ?).
It's something i hear often when talking with others peoples who want, something after being asked, to contribute to this or this free game project : Coders, as known by all Technical Writers around the world, have the communication skills of a pee-wee... and don't care for it.
My english is not very good, then i can't write a long explanation. Then let's go directly technical, will you ?
First, read this. My post is based on it, and the guy explain pretty well the "why" :
http://forums.wesnoth.org/viewtopic.php ... 6&start=15
There is a first version of his text at the start of the thread, and a new in this page.
1°) I don't care for the name of your last subroutine ! I want to know what this tag do, what values it can take !
One of the bigger problem i run into, in all theses "projects", is the total void of commands / tags / variables list. You always have to search (if somebody want to kill the guy who invented the wikis, i'm willing to pay for the ammos), and you rarely find it.
Say, for example : Where is the complete list of tags you can use for create/change a fbi file ?
What are the ones that are optionals, and what are the ones that make the game crash if you forgot them ?
Do you need to write them in some order ?
What are the values they can take ?
Do some have default values ?
Can some be included multiple times ?
Do some of theses take automatically their default value if you don't include the tag at all ?
Do some have effect on others ? What are theses effects ?
Do some values have to be unique for the entire game ?
Do some words/values are reserved ?
My suggestion : Give the damn list ! I can write it clearly if you want, but give ! Or die alone in the dark !
2° Death for the HPI ! Death for the COB !
Another think that stop me in my run : Why do i have to "zip" the data ? Okay, it's cool to create your own "zip format", but what is the use ?
I need to search for the software that can run that damn "hpi/cob" (and that's two different softwares, grr).
I need to lean how to use that software, and it's really rarely well thinked.
I need to lose my time by using it.
Not only it's take time for nothing, but that's really not fun.
What the use ? What stop TA3D to use a simple folder tree by unit, with files in clear ? You still have your old hard disk from 11 years ago ? Why can't i change the Hit Point from my unit without having to "unzip" and "rezip" ?
My suggestion : Use files in their normal state. No more HPI, no more COB !
3° 3DM is an OBJ for geek.
Another thing that bother me it's that "3DM" format and, of course, its reserved editor.
What you can do in your special editor your can't put in an OBJ file and it's MLT companion ?
What 3DMeditor can do you can't do with Maya, 3Dmax, Wings or Delgine (this last one it's totally free since a few weeks) ?
I don't know how to use 3dmeditor, and i don't want to learn. I want to make units and seeing them as fast as possible in the game. Using my personnal 3D editor is fun. Needing to put my model in a second totally different 3D editor after that slow me and is NOT fun.
The only problem with OBJ is some editors save it with linefeed for end lines, when others use carriage return, but that's nothing simply reading the file can't overcome.
In an OBJ, i have :
- The three coordinate of each vertex.
- Each normal (line between two points), if you need it.
- Each poly.
- The name of the material used for each poly, if existing.
- The name of each group and sub-group of polys.
In the MTL, i have the list of the materials, and for each :
- The color, the transparency, the texture name, etc...
For textures, the editor just put them in the same folder than the OBJ and MTL files.
The same MTL can be used by more than one OBJ, do i have to explain the advantages of this ?
You can even use your standard 3D editor for put the "team" color : Since TA3D don't use polys without texture (if i understand well), i just have to give some color value to the poly used for team color. Say, red : 0 mean no team color, 1 to max mean a team color more and more pronounced.
4° No Scriptor anymor !
In fact, i don't even need some "scriptor" thing for making animations :
The joins between the poly groups are where the animations are, no ?
Then, in my standard 3D editor, i add boxes. Perfectly boxed boxes.
Two by "join".
Example :
I have a kbot.
I give the "central" poly group the name of "Mother". If ta3d see that, it understand it's the "Mother" group.
This kbot had a torso, and the torso act like a turret (standard kbot, as you see). I give it the name "Torso" and, of course, sub-group it to Mother.
At the point on the Mother where the Torso attach, i draw a box. The centre of the box is the exact point on the Mother where i want the Torso to be attached.
I give it the name "join_mother_torso".
I draw another box. I give it the name "join_torso_mother". Its center is the exact point on the Torso where i want the Mother to be attached (theorically, the two boxes have the same center).
I subgroup the first box in Mother, and the second in Torso.
Technically, Ta3D know now how to attach the Torso to the Mother.
Now, for each box, i rename one of their face "up", and another "face" : The engine know now how is oriented each join box, and what are their rotating axis (up-down, face-back, right-left).
For making some animation, i give a box some "rotating around your center in this axis", and him, the group from wich he is sub-group, and all the other sub-groups of it (even boxes), rotate.
Of course, the "boxes" are not rendered by the engine : Just used for their center (center the engine can calculate at the loading of the game. Save 7*3 datas for each boxe).
There can be other boxes type :
flare_gun1 => Position of the flare from the weapon "gun1".
shoot_gun1 => Position where the "bullet" from the weapon "gun1" appear.
point_x => where "x" is the characters you want. Boxe who is not a join, but can be used for other things (smoke start, loading position, etc.).
...
5° Using tags for animations !
Using "luas" and other languages for making animations is maybe fun for coders, but you have here one of the biggest reasons why you have so few new units : Most "artists" are not good with computer languages, and absolutely don't care for learning that.
If you look at how new units are done for other 3D games, like Spring, you will see nearly no finished unit is made by lone modellers. Mean if you want artists taking fun at making units, and that mean effectively making units, you need to offer them (us) something simplier than a language, letting the coders using the "evolved" language if they like, maybe for more advanced animations.
And that mean tags.
Modellers can understand tags. They use them all the time. In fact, tags is why HTML kicked XHTML and XML in the balls : It's simple to understand, and you don't need to be a coder to use them.
Hey, i have a defense turret !
[Targeting]=gun1
// If the turret want to target something with it's weapon "Gun1".
Rotate_up_Speed(join_torso_mother) = *some speed unit*
// Rotate the "join_torso_mother" box (and all polys grouped with it) around it's center at "some speed" for reducing the distance between the center of his "face" poly and the target, using the axis "Up-Down"
Rotate_up_Max = 30
// don't rotate more than 30 degrees from normal position by using the axis Up-Down.
Return_up=yes
If the target is lost (out of range, destroyed...), rotate the "face" in it's normal position by using the axis Up-Down.
[Targeting_end]
See ? Even pure artists can find that fun, because if you have the tag list and the value each can use, you don't need to learn language grammmar.
Here some a little list of possible tags.
[Z]=x Bloc of tags for differents situations.
[Z_end] End of the tags used for the last bloc.
[Targeting]=x Following tags are used if the unit want to target with it's weapon "x". Value is the weapon number in the unit file.
[Firing]=x Following tags are used if the unit want to fire it's weapon "x". Value is the weapon number in the unit file.
[Moving]=x The unit move (by itself). The value can represent differents moves if the unit had more than one (jumping kbots like in C&C, walking ships like in SupCom). Some possibilities : Walk, Walk_undersea, Walk-onsea, floating, Hovering, Run, Jump, Taking_off, Landing, Docking, Loadin, Unloading, Climbing, etc ad vitam nauseam.
[On]=y(x) Following tags are used if the unit had is in "on" state. Paused if a bloc "y" with "x" value is activated (example : AA turret rotating peacefully, then facing a targeted ennemy).
[Off]=y(x) Following tags are used if the unit had is in "off" state. Paused if a bloc "y" with "x" value is activated (example : AA turret rotating peacefully, then facing a targeted ennemy).
etc.
In the tags bellow, "y" is the name of the box.
Rotate_up_Speed(y)=x
Rotate_face_Speed(y)=x
Rotate_right_Speed(y)=x
Rotate the box around it's center at speed x, using the axis Up-Down | Face-Back | Left-Right, and with it all it's group and groups attached.
Rotate_up_Max(y) = x
Rotate_face_Max(y) = x
Rotate_right_Max(y) = x
Can't rotate farther than x degrees from it's normal state, using the mentioned axis.
Return_up(y)= x
Return_face(y)= x
Return_right(y)= x
If the target is lost (out of range, destroyed...), rotate the "face" in it's normal position by using the axis mentioned
X can be "yes" (return), "no" (remain in the last position), "forced" (return and ignore all rotate orders until move is finished).
Rotate_up(y) = +x
Rotate_face(y) = +x
Rotate_right(y) = +x
Rotate the box around it's center using the axis mentioned. x is the number of degrees. + is clockwise (default), - is counter-clockwise.
0 => immobile (default)
361 => don't stop to turn.
target => Turn in direction of the target and try to follow it (only work in a "targeting" bloc, probably).
Step
Wait until all the tag before in the same bloc have finished their actions.
Wait=x
Wait x time units before continue to the next tags in the same bloc.
Show(y)=x
yes => Show the group of polies called "y" if invisible.
sub => Same, but show also all the subgroups.
Hide(y)=x
yes => Hide the group of polies called "x" if visible.
sub => Same, but hide also all the subgroups.
Explode(z)=x
Ungroup the group called "z" and all its subgroup and send them flying in all directions. x=yes or no.
Show_weapon(y)=x
Make the weapon called "x" appear at the box called "y".
Fire_weapon(y)=x
no => After a "show_weapon", make the weapon model placed on box "y" immobile and grouped with the box where it appeared.
yes => Cancel "immobile_weapon" on all weapon grouped with box "y" and "fire" them.
sfx(y1,y2,y3)=x1,x2,x3...
Show a sfx animation randomly choosen in the "x" list, starting randomly on one one the boxes mentioned (for smoke, fire, etc...)
alternate =x1,x2,x3,x4...
x1 and co are polies, groups or boxes (named, of course)
Used for alternate the use of polies. Like the three guns of a Gaat tower.
The second time the same unit use the same bloc with the same value, the engine replace all occurences, in the bloc, of the first listed by the second. And so on. The next after the last one is the first.
The target is to make modelling fun. Actually, it's not because there is a lot of things that not only slow the process, but have nothing to do with "fun".
6° On the ressources
- Don't make ressource hardcoded. Use "ressource[x]" and not "Metal" for naming, please. A lot of modders want to create their own ressources, and often more than two.
Maybe some of you remember me. I proposed some units models months ago. But, like in a lot of others games a tried to contribute, i stopped it.
Because i can't AND because i won't include them in the game. Well, it's not totally exact but.. well, read before.
What pushed me to write this is another post in the "Battle for Wesnoth" game. The post was a long article that said, basically, most "free" games projects are very artist unfriendly (who said "Spring" ?).
It's something i hear often when talking with others peoples who want, something after being asked, to contribute to this or this free game project : Coders, as known by all Technical Writers around the world, have the communication skills of a pee-wee... and don't care for it.
My english is not very good, then i can't write a long explanation. Then let's go directly technical, will you ?
First, read this. My post is based on it, and the guy explain pretty well the "why" :
http://forums.wesnoth.org/viewtopic.php ... 6&start=15
There is a first version of his text at the start of the thread, and a new in this page.
1°) I don't care for the name of your last subroutine ! I want to know what this tag do, what values it can take !
One of the bigger problem i run into, in all theses "projects", is the total void of commands / tags / variables list. You always have to search (if somebody want to kill the guy who invented the wikis, i'm willing to pay for the ammos), and you rarely find it.
Say, for example : Where is the complete list of tags you can use for create/change a fbi file ?
What are the ones that are optionals, and what are the ones that make the game crash if you forgot them ?
Do you need to write them in some order ?
What are the values they can take ?
Do some have default values ?
Can some be included multiple times ?
Do some of theses take automatically their default value if you don't include the tag at all ?
Do some have effect on others ? What are theses effects ?
Do some values have to be unique for the entire game ?
Do some words/values are reserved ?
My suggestion : Give the damn list ! I can write it clearly if you want, but give ! Or die alone in the dark !
2° Death for the HPI ! Death for the COB !
Another think that stop me in my run : Why do i have to "zip" the data ? Okay, it's cool to create your own "zip format", but what is the use ?
I need to search for the software that can run that damn "hpi/cob" (and that's two different softwares, grr).
I need to lean how to use that software, and it's really rarely well thinked.
I need to lose my time by using it.
Not only it's take time for nothing, but that's really not fun.
What the use ? What stop TA3D to use a simple folder tree by unit, with files in clear ? You still have your old hard disk from 11 years ago ? Why can't i change the Hit Point from my unit without having to "unzip" and "rezip" ?
My suggestion : Use files in their normal state. No more HPI, no more COB !
3° 3DM is an OBJ for geek.
Another thing that bother me it's that "3DM" format and, of course, its reserved editor.
What you can do in your special editor your can't put in an OBJ file and it's MLT companion ?
What 3DMeditor can do you can't do with Maya, 3Dmax, Wings or Delgine (this last one it's totally free since a few weeks) ?
I don't know how to use 3dmeditor, and i don't want to learn. I want to make units and seeing them as fast as possible in the game. Using my personnal 3D editor is fun. Needing to put my model in a second totally different 3D editor after that slow me and is NOT fun.
The only problem with OBJ is some editors save it with linefeed for end lines, when others use carriage return, but that's nothing simply reading the file can't overcome.
In an OBJ, i have :
- The three coordinate of each vertex.
- Each normal (line between two points), if you need it.
- Each poly.
- The name of the material used for each poly, if existing.
- The name of each group and sub-group of polys.
In the MTL, i have the list of the materials, and for each :
- The color, the transparency, the texture name, etc...
For textures, the editor just put them in the same folder than the OBJ and MTL files.
The same MTL can be used by more than one OBJ, do i have to explain the advantages of this ?
You can even use your standard 3D editor for put the "team" color : Since TA3D don't use polys without texture (if i understand well), i just have to give some color value to the poly used for team color. Say, red : 0 mean no team color, 1 to max mean a team color more and more pronounced.
4° No Scriptor anymor !
In fact, i don't even need some "scriptor" thing for making animations :
The joins between the poly groups are where the animations are, no ?
Then, in my standard 3D editor, i add boxes. Perfectly boxed boxes.
Two by "join".
Example :
I have a kbot.
I give the "central" poly group the name of "Mother". If ta3d see that, it understand it's the "Mother" group.
This kbot had a torso, and the torso act like a turret (standard kbot, as you see). I give it the name "Torso" and, of course, sub-group it to Mother.
At the point on the Mother where the Torso attach, i draw a box. The centre of the box is the exact point on the Mother where i want the Torso to be attached.
I give it the name "join_mother_torso".
I draw another box. I give it the name "join_torso_mother". Its center is the exact point on the Torso where i want the Mother to be attached (theorically, the two boxes have the same center).
I subgroup the first box in Mother, and the second in Torso.
Technically, Ta3D know now how to attach the Torso to the Mother.
Now, for each box, i rename one of their face "up", and another "face" : The engine know now how is oriented each join box, and what are their rotating axis (up-down, face-back, right-left).
For making some animation, i give a box some "rotating around your center in this axis", and him, the group from wich he is sub-group, and all the other sub-groups of it (even boxes), rotate.
Of course, the "boxes" are not rendered by the engine : Just used for their center (center the engine can calculate at the loading of the game. Save 7*3 datas for each boxe).
There can be other boxes type :
flare_gun1 => Position of the flare from the weapon "gun1".
shoot_gun1 => Position where the "bullet" from the weapon "gun1" appear.
point_x => where "x" is the characters you want. Boxe who is not a join, but can be used for other things (smoke start, loading position, etc.).
...
5° Using tags for animations !
Using "luas" and other languages for making animations is maybe fun for coders, but you have here one of the biggest reasons why you have so few new units : Most "artists" are not good with computer languages, and absolutely don't care for learning that.
If you look at how new units are done for other 3D games, like Spring, you will see nearly no finished unit is made by lone modellers. Mean if you want artists taking fun at making units, and that mean effectively making units, you need to offer them (us) something simplier than a language, letting the coders using the "evolved" language if they like, maybe for more advanced animations.
And that mean tags.
Modellers can understand tags. They use them all the time. In fact, tags is why HTML kicked XHTML and XML in the balls : It's simple to understand, and you don't need to be a coder to use them.
Hey, i have a defense turret !
[Targeting]=gun1
// If the turret want to target something with it's weapon "Gun1".
Rotate_up_Speed(join_torso_mother) = *some speed unit*
// Rotate the "join_torso_mother" box (and all polys grouped with it) around it's center at "some speed" for reducing the distance between the center of his "face" poly and the target, using the axis "Up-Down"
Rotate_up_Max = 30
// don't rotate more than 30 degrees from normal position by using the axis Up-Down.
Return_up=yes
If the target is lost (out of range, destroyed...), rotate the "face" in it's normal position by using the axis Up-Down.
[Targeting_end]
See ? Even pure artists can find that fun, because if you have the tag list and the value each can use, you don't need to learn language grammmar.
Here some a little list of possible tags.
[Z]=x Bloc of tags for differents situations.
[Z_end] End of the tags used for the last bloc.
[Targeting]=x Following tags are used if the unit want to target with it's weapon "x". Value is the weapon number in the unit file.
[Firing]=x Following tags are used if the unit want to fire it's weapon "x". Value is the weapon number in the unit file.
[Moving]=x The unit move (by itself). The value can represent differents moves if the unit had more than one (jumping kbots like in C&C, walking ships like in SupCom). Some possibilities : Walk, Walk_undersea, Walk-onsea, floating, Hovering, Run, Jump, Taking_off, Landing, Docking, Loadin, Unloading, Climbing, etc ad vitam nauseam.
[On]=y(x) Following tags are used if the unit had is in "on" state. Paused if a bloc "y" with "x" value is activated (example : AA turret rotating peacefully, then facing a targeted ennemy).
[Off]=y(x) Following tags are used if the unit had is in "off" state. Paused if a bloc "y" with "x" value is activated (example : AA turret rotating peacefully, then facing a targeted ennemy).
etc.
In the tags bellow, "y" is the name of the box.
Rotate_up_Speed(y)=x
Rotate_face_Speed(y)=x
Rotate_right_Speed(y)=x
Rotate the box around it's center at speed x, using the axis Up-Down | Face-Back | Left-Right, and with it all it's group and groups attached.
Rotate_up_Max(y) = x
Rotate_face_Max(y) = x
Rotate_right_Max(y) = x
Can't rotate farther than x degrees from it's normal state, using the mentioned axis.
Return_up(y)= x
Return_face(y)= x
Return_right(y)= x
If the target is lost (out of range, destroyed...), rotate the "face" in it's normal position by using the axis mentioned
X can be "yes" (return), "no" (remain in the last position), "forced" (return and ignore all rotate orders until move is finished).
Rotate_up(y) = +x
Rotate_face(y) = +x
Rotate_right(y) = +x
Rotate the box around it's center using the axis mentioned. x is the number of degrees. + is clockwise (default), - is counter-clockwise.
0 => immobile (default)
361 => don't stop to turn.
target => Turn in direction of the target and try to follow it (only work in a "targeting" bloc, probably).
Step
Wait until all the tag before in the same bloc have finished their actions.
Wait=x
Wait x time units before continue to the next tags in the same bloc.
Show(y)=x
yes => Show the group of polies called "y" if invisible.
sub => Same, but show also all the subgroups.
Hide(y)=x
yes => Hide the group of polies called "x" if visible.
sub => Same, but hide also all the subgroups.
Explode(z)=x
Ungroup the group called "z" and all its subgroup and send them flying in all directions. x=yes or no.
Show_weapon(y)=x
Make the weapon called "x" appear at the box called "y".
Fire_weapon(y)=x
no => After a "show_weapon", make the weapon model placed on box "y" immobile and grouped with the box where it appeared.
yes => Cancel "immobile_weapon" on all weapon grouped with box "y" and "fire" them.
sfx(y1,y2,y3)=x1,x2,x3...
Show a sfx animation randomly choosen in the "x" list, starting randomly on one one the boxes mentioned (for smoke, fire, etc...)
alternate =x1,x2,x3,x4...
x1 and co are polies, groups or boxes (named, of course)
Used for alternate the use of polies. Like the three guns of a Gaat tower.
The second time the same unit use the same bloc with the same value, the engine replace all occurences, in the bloc, of the first listed by the second. And so on. The next after the last one is the first.
The target is to make modelling fun. Actually, it's not because there is a lot of things that not only slow the process, but have nothing to do with "fun".
6° On the ressources
- Don't make ressource hardcoded. Use "ressource[x]" and not "Metal" for naming, please. A lot of modders want to create their own ressources, and often more than two.