Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

24/11/2007

L'art du script...

La plupart des moteurs de jeu modernes ont plus de rapport avec des systèmes d'opérations qu'avec des jeux. Contraint d'être souple et versatile, les moteurs sont amenés à être exploité dans de multiples productions.
 
 
Du coup, la "logique"  d'un jeu - le flow des niveaux, les évènements, le scénario, l'IA - tous ces élèments sont passées du coté des données, au même titre que les textures ou les meshs 3D.
 
 
Et la meilleur façon de décrire des élèments logiques, ça reste le langage. D'ou la multiplication des systèmes de scripts, de LUA à Quake C, de Kismet à Ruby...
 
 
1133eb103a0e79c50ceace6c3024c8cf.jpg
 
 
 
Seulement, ça n'est pas sans problèmes. Ou placer la disctinction entre ce qui relève du script et ce qui relève du moteur ? Est ce que les designers doivent apprendre à programmer ? Comment débugger et maintenir ce qui ressemble à du code sans avoir les outils appropriés (debuger, analyseur de flow...) ?
 
 

It seems like everyone got together and decided to have an interesting discussion right as I was out of town. The issue brought up by Joe Ludwig was: No designer scripting. This assertion created a lot of discussion, including a followup post by Joe.

 

...



I wrote a post about scripting languages years ago on this blog. My core assertion was that for online RPGs, you want to give non-programmers the ability to create content easily. But, the larger issue is that you need to use the tool that's appropriate for your situation.

 

If you need a fast-and-lean solution, then that limits what tools are appropriate for your task. But, taking this a step further, you need the right tool for the resources you have, particularly the people in your team and the schedule you have to meet.

 

Damion explained the issue with scheduling with a fair amount of snark. Programmers, especially ones with experience, don't grow on trees. Therefore, expecting all game implementation to only happen with programmers is usually something that hurts the schedule.

 

Having designers wait on a programmer to implement a feature is a waste of time that can impact the schedule; if you have programmers sitting around idle waiting for things to implement from designers, then you're wasting money.

 

However, you also need to keep in mind the type of people you have on the team. A designer like myself, with a Computer Science degree, shouldn't fill the "real" programmers with a sense of dread because of having to deal with my code...

 

Other people have other strengths, and this is the point that Raph and Sara are talking at each other about. Someone like Sara, with a background and keen interest in data, will work better in a system that allows for interesting combinations of data. I, however, would probably find such a system very limiting since I probably don't think in terms of data as well as Sara does; I think in terms of code.

 

Raph makes the comment that data-driven systems designers don't have as much of a career path. I disagree slightly, because given that the position of "designer" is so ill-defined, any designer will have to make his or her own career path.

 

However, I think it's important for designers to understand the basics of coding and computer science even if they can't sling C++ code around like an expert, because it gives insight into what can and cannot easily be done. For example, if a programmer notices that a design is NP-hard, I know what that means and won't argue the point. :)

 
 

13:00 Publié dans Code | Lien permanent | Commentaires (5)

Commentaires

Moi je me demande toujours comment on peut tracer un script ecrit à partir de boites...
Mais peut-etre que ca ne derange que moi :)

Écrit par : Vincent Hamm | 24/11/2007

Vincent : c'est pourtant une facon classique de representer un algo, non ? On ne peut pas faire un programme qui va simplement avancer de ligne en ligne...

Daz : On a un peu ce genre de reflexion en ce moment au boulot. Les game designers "sachant coder" sont encore assez rare en Coree, et en tant que boite de taille relativement importante on se met a la recherche de ce genre de profil.

A cote de ca, on essaie de scripter une bonne partie de notre programme (l'IA notamment dont je me suis charge en partie, et maintenant plutot le gameplay lui-meme), pour rendre le jeu plus simple a entretenir (tres important pour un jeu online et actuellement c'est pas gege : des qu'on veut faire la moindre modif dans une carac du jeu, ajouter un element graphique, modifier la position d'un bouton dans l'interface, il faut programmer, et bien souvent compiler).

Je pense qu'a ce niveau la les boites europeennes ou americaines sont pas mal en avance...

Écrit par : MMoi | 25/11/2007

Le problème est loin d'être résolu en occident non plus pour ce que j'en sais.

Même dans des grosses équipes où il y a une distinction "programmeur moteur" et "programmeur gameplay", ces derniers pouvant être plus réactifs sur des demandes design que les premiers, chargés des fondations.

Le problème général est : où mettre le curseur, la limite entre le game play et le moteur. Comment ne pas, parce que c'était une demande pressée, se retrouver avec un algo lourd et complexe programmé en script qu'il devient compliqué à remettre au "propre".

À peu près tous les projets que je connais ont essayés des choses différentes, sans jamais tomber sur la méthode 100% satisfaisante.

Il y a encore un sacré boulot !

À la lecture de certains articles (et par expérience), je pense que le game design est en train de vivre un tournant qu'il doit absolument prendre. Si un jour j'arrive à terminer mon entrée de blog à se sujet, je le posterai (je suis loin des deux messages par jour moi :) )

Écrit par : Mokona | 25/11/2007

Mokona, je serais tres interesse de lire un pareil article, car ma faible experience se limite a ce qui se passe en Coree... :)

Écrit par : MMoi | 25/11/2007

Vincen a raison, les scripts visuels sont encore plus compliqué à debugger que les scripts en codes, mais c'est principalement due au fait que nous - programmeur - sommes plus à l'aise dans l'environnement code avec des debuggers plus proche de ce qu'on utilise d'habitude.

Ceci dit, c'est clair, l'avenir du "gameplay" n'est plus - et ne doit plus être - entre les mains du programmeurs. C'est pour ça que ces langages de scripts connaissent un tel essort ^_^

C'est sur, les programmeurs ont en principe une culture de la "mécanique" plus aboutie que celle de la plupart des créatifs, mais ça n'en fait pas des candidats idéaux pour juger de la maniabilité ou de l'interface utilisateur ! :-)

Écrit par : Daz | 25/11/2007

Les commentaires sont fermés.