24.11.2007
L'art du script...
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) | Envoyer cette note
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 :)
Ecrit 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...
Ecrit 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 :) )
Ecrit 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... :)
Ecrit 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 ! :-)
Ecrit par : Daz | 25.11.2007
Écrire un commentaire