Liste des trucs et astuces

Par Gargantuel le 5/7/2002 à 21:25:00 (#1764663)

Je propose un thread qui liste nos suggestions pour créer un module.
Simplement parce qu'il en existe certaines qu'il vaut mieux connaitre AVANT de démarrer son module qu'APRES !

Je commence :
Construire un module va vous amener à gerer pas mal de portes (surtout en ville).
Et rien n'est plus pénible que de s'apercevoir qu'il faut repasser toutes ses portes en revue après les avoir créer.
Donc je vous suggère d'avoir un modèle customisé de porte (blueprint) qui possède les caractéristiques suivantes :
- Plot activé (indestructible)
- Locked (need a key to open)
- Un script de fermeture automatique de la porte (sur OnOpen)

Utilisez autant que possible dans votre module des instances de cette porte plutot que les portes standards.
Ca vous évitera des mauvaises surprises nottament si un joueur veut ruiner votre scénario en détruisant toutes les portes qu'il peut trouver.

Sur ce, je vous laisse, j'ai des portes qui m'attendent :sanglote:

Script de fermeture de porte :
// close open doors after set time
void main()
{
DelayCommand(5.0, ActionCloseDoor(OBJECT_SELF));
}

Par Lumina le 5/7/2002 à 22:40:31 (#1765009)

Donnez un nom uniformisé à tous vos scripts. En effet, il y en a tellement que c'est galère pour s'y retrouver, surtout qu'on est limité à une longueur de nom de 15 caractères. Voici un exemple pour proceder :
- il commencera par s_ pour un script
- il commencera par c_ pour une conversation
- il commencera par sc_ pour un script de conversation
- suivi de bl_ si il est dans OnBlocked
- suivi de cre_ si il est dans OnCombatRoundEnd
- suivi de co_ si il est dans OnConversation
- suivi de da_ si il est dans OnDamaged
- suivi de de_ si il est dans OnDeath
- suivi de di_ si il est dans OnDisturbed
- suivi de hb_ si il est dans OnHeartbeat
- suivi de pe_ si il est dans OnPerception
- suivi de pa_ si il est dans OnPhysicalAttacked
- suivi de re_ si il est dans OnRested
- suivi de sp_ si il est dans OnSpawn
- suivi de spa_ si il est dans OnSpellCastAt
- suivi de ud_ si il est dans OnUserDefined
- suivi de taw_ si il est dans Text Appears When ...
- suivi de at_ si il est dans Action Taken
- suivi de ecs_ si il est dans End Conversation Script
- suivi de en_ si il est dans OnEnter
- suivi de ex_ si il est dans OnExit
- suivi de op_ si il est dans OnOpen
- suivi de cl_ si il est dans OnClose
- suivi de lo_ si il est dans OnLock
- suivi de ul_ si il est dans OnUnLock
- suivi de acq_ si il est dans OnAcquireItem
- suivi de ai_ si il est dans OnActivateItem
- suivi de ce_ si il est dans OnClientEnter
- suivi de cl_ si il est dans OnClientLeave
- suivi de ml_ si il est dans OnModuleLoad
- suivi de pd_ si il est dans OnPlayerDeath
- suivi de pdy_ si il est dans OnPlayerDying
- suivi de plu_ si il est dans OnPlayerLevelup
- suivi de prp_ si il est dans OnPlayerRespawn
- suivi de pr_ si il est dans OnPlayerRest
- suivi de uacq_ si il est dans OnUnacquireItem
- etc. il en reste plein ...

De maniere générale, et pas que pour les portes, utilisez un blueprint pour tous les objets que vous placerez en deux exemplaires ou plus dans votre module, meme si il y a de legeres variations entre les deux : marchands, gardes, monstres, tonneaux, coffres, pieges, etc.

Pour tout, utilisez la case plot lorsque vous voulez avoir un objet de quete indestructible, une porte indestructible, un pnj indestructible, etc. Ca ne sert a rien de se compliquer le vie autrement.

Par loyus le 6/7/2002 à 0:36:41 (#1765556)

.: Quelques conseils d'organisation :.

1) dessinez
2) coloriez
3) détaillez

Exemple : Si vous avez plusieures zones qui se complètent ou sont plus ou moins en rapport, commencez par faire tout le décor de ces zones, sans toucher aux options ni sans les remplir de NPCs, boutiques, marchands, transition etc....

Pour tout ce qui est à la même surface, exemple, une ville et ses proches alentours décomposés en plusieures zones plus ou moins dépendantes ou en rapport (des docks etc...), commencez par planter le décor de toutes les zones. Si vous ne les remplissez pas, vous serez en mesure très vite de vous rendre compte des incohérences, des transitions un peu violentes, de changer à volonter la taille des zones, de changer le décor. TAndis que si vos zones sont remplies, ça va être le bordel, vous allez devoir déplacer/supprimer des trucs, réajuster des waypoints ou alors vous serez tenté par ne rien modifier "tellement c'était long à faire".

Si vous êtes méthodiques, vous ferez mieux et plus vite. Une fois que vous êtes fier du décor, vous pouvez commencer à détailler et caser des NPCs, et vous avez en + une idée des zones aux alentours ce qui vous aidera.

Et croyez moi, travailler sur tout ce qui est scripts ensuite sera très facilité, vous imaginerez tout de suite ce qui peut-être foutu en blueprint pour faciliter les choses, vous aurez un "espace" de plusieures zones qui sont censées avoir les mêmes règles, donc configurer tout ça s'averera beaucoup plus rapide et facile. (et surement moins décourageant que si on s'applique à faire une seule zone pour ensuite passer à la suivante). Je pense surtout aux villes et aux zones "NPCs" avec des guards et tout le bordel, qui sont sans doute les plus difficiles à paramétrer.

.: Faire du bon avec du simple :.

Le talent du developpeur, c'est de faire le mieux possible avec le moins possible.

Cela apportera t'il vraiment un gros + à votre module que vos 10 guards possèdent 10 waypoints bien précis ? Ou encore que votre module soit le plus réaliste possible, en laissant tous les objets et les NPCs basiques vulnérables, avec à côté des scripts complexes et chiants pour les gardes qui tâcheront de défendre tout ça ?

Pesez le pour et le contre. Si vous estimez que tel paramètre rendra votre module vraiment plus fun magré la complexité de l'affaire, alors faites-le, mais soyez sûr que ce "détail" qui fera la différence ne vous apportera pas une tonne de complications et d'effets non-souhaités au final.

Au final, 10 guards en patrouille avec 10 waypoints différents et bien précis, ça pourrait-être à peine plus impressionant que 2/3 gardes en vadrouille, avec le reste qui occupe quelques postes stratégiques pour montrer une présence.

Voilà mes conseils... Vraiment, le joueur aussi aime les choses simples mais bonnes.

Edit : je dis ça parceque je me rends compte en feuilletant les forums officiels qu'il y a bcp + de questions qui relèvent du détail que des trucs plus généraux et important à corriger. On se retrouve avec une tonne de messages du genre "comment on fait pour le guard défende les portes". Bon, c'est moins réaliste, mais qu'il foute ses portes en plot, je suis pas sûr que les joueurs s'amuseront plus parcequ'ils peuvent défoncer les portes du village. Et il est mal partit, parcequ'il devrait commencer par le simple au lieu de tout de suite vouloir tout faire dans le détail, ce genre de "fonction" relève du script pour les portes, il peut très bien commencer par faire un blueprint de portes invulnérables, pour pouvoir toutes les modifier après et changer leur script (ainsi que celui des gardes).

A l'heure actuelle, les joueurs se plaignent trop pour les détails, avec ce qu'on a comme outils, on peut déjà faire des trucs sympas et simples, puis facilement les faire évoluer ensuite.

Edit2 : ce que j'aurais à rajouter, y a des scripteurs très comptents qui bossent dur et pondent de vraies petites merveilles déjà, pour les paramètres d'un module, ou un NPC spécial comme le vaultkeeper. En attendant encore un peu, nul doute qu'on aura droit à d'autres scripts super qui nous faciliterons la tâche en plus de combler nos attentes.

Par Tyriael le 6/7/2002 à 0:40:13 (#1765568)

"blueprint"
qu'est ce donc??

Par loyus le 6/7/2002 à 0:50:50 (#1765603)

tu créés n'importe quoi, une porte, un panneau, un NPC, un monstre.... Tu règles ses propriétés, une fois que tu en es satisfait, clique-droit dessus => add to palette.

Il sera alors disponible quand t'en auras besoin, t'auras rien besoin de reconfigurer.


tu savais déjà ce que c'est si tu fais un module, mais le terme t'as pas marqué

Par Cassin le 8/7/2002 à 10:06:33 (#1775195)

J'avoue que pour moi ce terme de blueprint est assez vague... :doute:

Pourquoi faire Add To Palette ? Quand on créé un objet ou un PNJ (ou autre hein ;) ), on choisit où on veut le mettre dans la palette custom, et basta ! Je n'ai jamais utilisé Add To Palette (sauf dans le tutorial de Bioware mais j'ai pas compris le sens) et j'ai toujours retrouvé mes petits !

De plus, quand je fais Build Module, il me sort toujours des blueprints inutilisés, en général ce sont les objets que j'ai placé dans des coffres ou autre...

Quelqu'un pourrait-il apporter plus de précisions là dessus ? :merci: