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.

29/06/2009

Siggraph 2009 Papers

Le Siggraph approche a grand pas, début Aout à La Nouvelle Orléans, et comme le veut l'usage, Ke-Sen Huang maintient la liste des papiers de l'année.

 

De quoi lire à l'ombre d'un parasol sous la canicule ^_^

 

siggraph-2009-logo.jpg

21:13 Publié dans Code | Lien permanent | Commentaires (0) | Tags : siggraph, conférences, papers

19/05/2009

Dream Build Play

Non content d’être sévèrement jet laggé, j’ai aussi réussi à choppé une grippe pas piqué des vers (et non, elle n’est pas aviaire celle là). Combiné à un emploi du temps un peu dispersé, l’ensemble a été un peu fatal au programme du blog.

 

Ce ne sont pourtant pas les sujets intéressants qui me manquent, des retours de la GDC aux dernières nouvelles de l’industrie, mais je n’ai tout simplement pas la force de mettre mes pensées en un semblant de flot cohérent.

 

Mais bon, ca va revenir… Peut être… ^_^

 

En attendant ce jour béni, je rappelle que la compétition annuelle Dream Build Play de Microsoft est déjà bien entamée, et que même si vous n’avez pas envie de participer, votre inscription vous permet de déployer gratuitement vos applications XNA sur la Xbox360 pour un an.

 

spacer.gif
clip_image002[5]_0225c156-516e-47a6-979b-10f4d3493d84.jpg

 

A 99 Dollar le cadeau, on ne va pas bouder notre plaisir non plus ^_^

06:53 Publié dans Code | Lien permanent | Commentaires (0)

09/02/2009

Script visu-hell

Il y a bientôt presque 10 ans, j’étais en stage à Annecy sur un jeu révolutionnaire pour l’époque : il était scripté à l’aide d’un langage de script partiellement visuel qui s’appelait Piccolo.

 

De nos jours, cette notion de script visuel se retrouve dans pleins de moteurs, Kismet d’UE3 étant l’exemple le plus populaire.

 

 

kismet_2.jpg

 

La dernière fois que j’ai abordé le sujet des éditeurs visuels, c’était pour parler de shaders. Pour être précis, c’était pour se poser la question du bien fondé des éditeurs de shaders visuels.

 

Mais l’idée de scripter visuellement un comportement va bien plus loin que la simple notion de shader. On trouve désormais ces éditeurs aussi bien pour scripter des cinématiques, que des événements dans le jeu, ou pour scripter des IA.

 

D’où viens cette évolution ?

 

Le succès de la notion de langage informatique repose sur les milliers d’années d’évolution du langage humain. En simplifiant à l’extrême, le langage est et reste la technologie la plus avancé pour encoder et transmettre de l’information.

 

Nous utilisons donc des langages de programmation non pas parce que nos machines s’y prêtent particulièrement, mais plutôt parce que nous humains somment des machines incroyablement performantes pour manipuler le langage.

 

Alors, si le langage est la technologie la plus poussé pour manipuler et définir des scripts, d’où viens le besoin de définir des outils graphiques pour faire le même travail ?

 

Le principal problème avec les langages est que le sens de ce qui est exprimé est hautement dépendant du contexte. En d’autre terme, le sens perçus dépend non seulement de la personne qui écrit (l’auteur) et de la personne qui écoute (le lecteur), mais aussi de ce qui a été écris auparavant.

 

En ce qui concerne les langages informatiques, le sens est en règle générale univoque : la machine exécute le code qui a été compilé à partir des textes sources, point barre. Là où le bat blesse, c’est que ce qui a été compilé ne correspond pas forcément à ce que le programmeur pense.

 

Les langages de programmations sont complexes parce que l’ordre d’exécution des instructions n’est pas trivial. Quand on écrit un programme, il ne s’agit pas d’écrire un roman dans lequel chaque chapitre va se suivre les uns après les autres.

 

De plus, la capacité à lire ou à écrire du code source dépend de la capacité de l’opérateur à intégrer non seulement les idiomes du langage, mais aussi le contexte du code en question (ce qui a été exécuté avant, ce qui va être exécuté après, ce qui est attendu en entré et ce qui doit être produit). Le programmeur pour ce faire doit construire un modèle mental du fonctionnement du programme à l’aide du code exprimé dans le langage de programmation.

 

Et ça, c’est dur. Mais alors, vraiment vraiment dur. Et c’est ici qu’entre en jeu la notion de langage visuel.

 

La grande majorité de ces langages visuels reposent sur la même anatomie : Un script visuel est constitué d’une collection de boites - correspondant à diverses actions/états, qui ont diverses entrées/sorties, et des paramètres internes – que l’on a connecté les unes aux autres. Ces boites peuvent parfois s’imbriquer dans des boites conteneurs façon poupées russes.

 

Les scripts ainsi conçus définissent tantôt des machines à états, tantôt des worlkflows, tantôt des graphes.

 

L’attrait principal de ces langages repose sur un principe simple : un dessin vaut mieux qu’un long discours. Et de fait, l’information sur un schéma est incroyablement plus accessible : d’un simple coup d’œil, on a accès à une masse d’informations qui nécessiterait un travail autrement plus ardu si on devait le déduire d’un texte.

 

De plus, il est beaucoup plus facile d’apprendre à lié des boites entre elles que d’apprendre à travailler avec un langage de programmation, n’est ce pas.

 

N’est ce pas ?

 

Tout cela est vrai, tant que les schémas produits sont bons. En fait, en pratique, voilà ce qui se passe.

 

La bonne idée atterrie dans les mains de quelqu’un qui n’est pas programmeur, en général quelqu’un avec un penchant un peu plus artistique, pour qui l’aspect visuel parle naturellement.

 

Cette personne développe des scripts bon an mal an pour définir le contenu du jeu.

 

Quelques mois plus tard, on vous appelle parce que ça « bug », et qu’il faut corriger les problèmes. Quand vous ouvrez le script dans l’éditeur visuel, vous vous retrouver devant un gloubigoulba indigeste de schèma façon spaghetti, avec des dépendances dans tout les sens et au bas mot 3 niveaux d’imbrications.

 

Bref, bienvenu(e) en enfer.

 

Alors, comment une aussi bonne idée peut elle s’avérer aussi dommageable ?

 

Le gain de productivité acquis par l’usage de ces langages visuels est réel. On va plus vite pour assembler visuellement des briques que quand on écrit. Mais la productivité n’est pas forcément positive – en d’autres termes vous pouvez parfaitement plomber un développement si vous ne faite pas attention.

 

Et c’est là le drame. Les langages de programmations sont équipés de toute une batterie d’outils pratiques ou conceptuels pour aider à assurer une productivité aussi positive que possible. Ces outils vont des débuggeurs à l’auto complétion en passant par l’analyse statique du code, les profilers, le développement orienté objet, les design patterns, les différents langages appropriés pour différentes taches, et j’en oublie une pelleté d’autre…

 

Des dizaines d’années de recherches et de développements ont été investis pour permettre au développeur d’aller dans la bonne direction autant que faire ce peux. A minima, ces outils permettent au langage en soi de ne pas devenir par essence un problème.

 

Les abstractions visuelles, elles, n’ont pas eu ce luxe. En somme, en abaissant la barrière de productivité, elles permettent surtout de produire plus facilement du code erroné.

 

Et ce problème n’est pas inhérent aux outils modernes d’un moteur de jeu vidéo. Les langages visuels se retrouvent dans tous les secteurs IT, avec les mêmes symptômes:

 


And in particular, the favorite demo-ware application is their BPEL (Business Process Execution Language) designer. This designer allows you to wire together services by drawing lines between boxes. The lines can include transformations and other sexiness. And it demos great. "Look, just draw a couple of lines here and here, click on the Run button and voila! Instant SOA".


Then, the manager brings it back home and notifies the developers that this is the new tool of choice. When developers start using it, they realize the awful truth: they've been sold a hairball generator. Tools like this work great on really small scales, when it's easy to see all the connections between things. But, as things get complicated, they start suffering from the hairball effect: all the lines start running together, and you can't create a diagram that makes sense to anyone anymore. Perhaps maybe you can fight through this, by creating workflows in chunks, and zooming in and out.


Then reality arrives. Because you create workflows using these tools, you are coding, in the worst possible language (a graphical representation). Thus, you are defining behavior, just like you do when you write source code. But the behavior you define lacks all the benefits you get from writing it in code.


· reuse: you can't really reuse portions of your workflow because their is no method or subroutine functionality (you might get lucky with a sub-workflow). Mostly, people achieve "reuse" by copy and pasting, which you never do in code.


· refactoring: no refactoring, making it harder to identify common workflow chunks for reuse. When you don't have refactoring, you don't watch for opportunities for refactoring as much.


· limited programmability: you don't get if statements and for loops, you get whatever this particular BPEL designer supports. You get flow-chartly looking stand-ins for real decision statements, but they are much more brittle than the facilities offered in modern languages.


· testing: you can't write unit, functional, or integration tests for these workflows. The only real testing option is user acceptance, meaning that the entire universe must be up and running. If you have no unit testing, you also don't have mock objects or other testing techniques common in code.


· hard to diff: lets say you fought the beast and get a non-trivial workflow up and running, and everything is great. In six months, you change it in non-trivial ways, and all is good. Then it comes time to see what's different. BPEL tools don't have diff facilities, so you can either visually diff the diagrams (yuck) or diff 2 10,000 line XML documents (double yuck). BPEL relies on either heavy-weight diagramming tools or raw XML, and nothing in between.


Tools like this fall into the category one of my colleagues identified as doodleware tools. They let you create pretty pictures but collapse under scale.


[ Meme Agora ]

 

Pour conclure, que doit on faire ? Les abstractions visuelles ont une utilité pratique, en particulier là où l’expressivité est un facteur important de la productivité. Difficile de s’en passer.

 

Quelques conseils :

 

- Limitez le scope de ces langages : Si on traite ces langages comme étant des DSL, il est parfaitement imaginable d’en limiter le domaine i.e. scripter un shader ou une machine a état oui, scripter toutes une cinématique, non. Pour les cinématiques, il y a de meilleurs outils (un séquenceur par exemple)

 

- Limitez l’expressivité du langage : Par exemple, vous pouvez parfaitement décider que toute entrée soit liée à une et une seule sortie. Créez des boites spécifiques pour créer des bifurcations par copie si c’est vraiment nécessaire, mais limiter ainsi le nombre de liens qui partent d’un seul point.

 

- Dotez vous d’outils permettant de debugger visuellement le flow : Attention, ce n’est pas une tache aisé. Dans un workflow traditionnel basé sur la notion d’événement, vous pouvez parfaitement passer dans plusieurs boites simultanément.

 

- Agissez en amont : Le comportement est plus facile à exprimer en langage parce que le langage est l’outil le plus puissant qu’il existe pour définir un comportement. Quiconque définit un comportement devient par essence un programmeur, avec tout ce que ça implique.

 

- Exploitez le gain de productivité: En cas de gros pépin, vous pouvez retourner l’avantage des langages visuels à votre profit très simplement. Faites recommencer à zéro le script en question, mais en étant ce coup ci en support de la personne qui l’a écrite à l’origine. Vous irez parfois plus vite à réécrire un script bugée à deux qu’a debugger un plat de spaghetti. Bonus : vous aurez peut être même une chance de faire mieux, plus simple, et plus esthétique.

 

Dans tout les cas, méfiez vous des outils magiques qui permettent de tout faire en connectant 3 boites : ces outils sont toujours merveilleux, géniaux, supers, etc etc… tant que les scripts ainsi écrits fonctionnent…

 

Sinon, ces fameux gains de productivités acquis pendant la production risquent bien de s’envoler en fumée quand le temps du debug viendra.

20:06 Publié dans Code | Lien permanent | Commentaires (2)

26/02/2008

Havok Gratis sur PC...

Dans la rubrique des initiatives qui ne coute rien mais qui peuvent rapporter gros, Havok sera dispo en téléchargement gratuit à partir de Mai pour toute utilisation non commerciale sur PC. C'est une bonne nouvelle, d'autant plus qu'il s'agit quand même de ce qui se fait le mieux dans le domaine.
 
 
Evidemment, avec Intel a la barre, c'est une initiative qui coute peu à Havok. Déjà parce qu'il existe de multiples alternatives sur PC, mais surtout parce que la majorité des revenues d'Havok doivent provenir des développeurs consoles ^_^
 
 
 
 
Havok™, the premier provider of interactive software and services to digital creators in the games and movie industries, today announced that the company will offer the PC version of its award-winning physics and animation software product - Havok Complete - for download free of charge.
 

Available for non-commercial use, Havok Complete for the PC will be freely downloadable in May 2008.

 

Havok's core platform, Havok Complete combines the industry-leading Havok Physics engine and Havok Animation, the company's premier character animation solution. Havok Complete is already the most popular solution in the cross-platform AAA games market, featuring technology used in over 200 games.

 

By making Havok Complete for the PC freely downloadable, Havok will further build on its leading position by completely removing the barriers to entry for the large number of independent developers, academic institutions and enthusiasts in the PC space. 

 

"Havok has an excellent revenue base generated by sales of our three products across multiple platforms and into multiple industries," said David O'Meara, Managing Director at Havok. "This enables us to make an industry-changing move and opens up a much broader market for products such as Havok Behavior - and our new products Havok Cloth and Havok Destruction - that really come alive when adopted on top of our core platform, Havok Complete."

 
 
[ Kotaku

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

24/02/2008

Nocturnal...

Insomniac est peut être à ce jour le studio le plus disposé à parler ouvertement des technologies qu'ils développent en interne. Leurs développeurs sont régulièrement présent aux différentes conférences (GDC, DevStation, etc...), et Insomniac publie régulièrement leurs papiers sur son propre site.
 
 
Cette attitude tranche vraiment avec le reste du secteur, pour qui le code est au mieux un bien précieux à amortir (en exploitant les moteurs et les outils sur plusieurs productions) ou à valoriser (en vendant des licences comme Unreal), et pour au pire une difficultée de plus sur le chemin de la production.
 
 
Dans tout les cas, peu de studio n'aime vraiment partager leurs sources.
 
 
 
 
1791b98b731b2eba4e3b5375b531fb00.jpg
 
 
 

What Insomniac has decided to do was to share and distribute their own technology throughout the industry, in turn encouraging others to share their own tech. The Nocturnal Initiative is not, they stress, a game engine. There will be no snarky comments from Mark Rein about Insomniac stepping on Epic's toes as the program is designed to help game development peers avoid rewriting some of the basics.

 

"Rewriting libraries is a waste of time," said Andy Burke, tools group lead at Insomniac, and the gang on the software side hopes that releasing code into the wild, code that comes with a "liberal" open source license, fosters feedback and may encourage others to share their own work. That can lead to better games, they hope.

 

The first batch of code is now available at the Nocturnal Initiative web site, in easy to read Wiki format, for developers who are interested in the program. They may be interested to learn that this isn't just something that's been whipped up for good PR, this is code that's being used in production, used in development in titles like Ratchet & Clank Future and Resistance 2.

 
 
[ Kotaku
 
 
Loin d'être une opération purement désintéréssé, je crois surement que c'est un signe d'un changement de fond qui s'annonce dans les 5 / 10 / 15 prochaines années.
 
 
Si l'industrie du jeu a jusqu'a présent été principalement une industrie de la technologie informatique - un peu particulière, certe-, elle est définitivement en train d'opérer une mue vers le secteur de "l'entertainement", rejoignant le cadre des producteurs de contenus.
 
 
A ce titre, la problématique technique va devenir de plus en plus irrélevante. Et c'est déjà là, au sens ce n'est plus le jeu qui affiche le plus de sprites ou de polygones qui vend le plus. Ce qui est relevant, c'est le design, la réalisation et la finition.
 
 
En somme, si avoir un bon moteur est utile pour faire un bon produit, faire un bon produit ne dépend pas forcément du moteur. 
 
 
Je crois qu'Insomniac le sais parfaitement, et utilise aujourd'hui l'argument d'ouverture du code plutôt comme un argument marketing pour attirer les talents - "nous seulement nous avons les meilleurs technologies, mais notre code est suffisament bon pour être ouvert au public"....

13:10 Publié dans Code | Lien permanent | Commentaires (0)

23/02/2008

PhyreEngine...

Je ne révèlerai rien en disant que la PS3 n'est pas la plateforme la plus accessible de prime abord. C'est un problème dont Sony a une conscience aigüe, et la préoccupation principale derrière l'évolution des outils sur la plateforme.

 

Dernier venu en date, Phyre est un moteur graphique optimisée pour la PS3, mais disponible également gratuitement sur PC et potentiellement sur 360 (à vérifier). L'idée est simple: amener les studios à investir plus rapidement et à moindre cout sur la console, même pour des jeux cross platforme.

 

d6f47ccc6fad9332ce4b71a28f5c49fb.jpg
 

A ce titre, Phyre n'est donc pas le XNA de la PS3, juste un tool de plus dans l'arcenal de Sony. Reste à savoir comment ce produit va évoluer dans le futur... 

 

But why make it potentially easier to make games on a competing console? Well, it's undeniable that developers are increasingly focused on multiplatform development. It's been rather commonplace for developers to neglect PS3 with inferior and oftentimes delayed versions of multiplatform games.

 

With PhyreEngine, Sony is making a much more attractive plea: make games on PS3 first, guaranteeing high quality games that will not only match their 360 counterparts, but in many cases can exceed them. Sony's message is clear: start games on the PS3, and they will be better for both PS3 and 360 owners. It appears to us that PhyreEngine is a crucial part of that plan.

 

[ Joystiq

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

10/02/2008

Pour gagner, soyez irrationnel...

On parlait d'IA récemment quand je suis tombé sur cette petite perle ^_^
 
 
Apparement, une équipe de recherches en Autriche se serait livré à un petit test en utilisant le jeu Age Of Mythologie. Ils ont simulés le joueur humain à l'aide de 5 IA différentes, chacune programmée pour "ressentir" différement une certaine gamme d'émotion: la joie, la douleur, la perte, etc... 
 
 
Résultat des courses: la personnalité la plus neurotique gagne non seulement plus souvent, mais aussi plus vite. En gros,  être rationnel n'est pas la meilleure stratégie, en tout cas dans Age Of Mythologie... ^_^. 
 
 
1e96a627a842dbb885ce8574db71e5fd.jpg
 
 
They say the meek shall inherit the earth, but these experiments with emotional computer programs (pdf) suggest it may actually be the neurotic. And that they'll probably take it rapidly by military force.


The Austrian researchers want games to be more engaging by having emotional, not just coolly calculating, computer players. Instead of just challenging your rational planning and decision skills, you'll have use your emotional intelligence too.


They created aggressive, defensive, normal and neurotic versions of the AI software in the war strategy game Age of Mythology, drawing on "the big five" emotional dimensions to personality recognised by psychologists.


The bots are able to switch between states of pleasure, pain, clarity, and confusion in response to events. The strength of particular emotional changes is related to the overall personality.


The neurotic bot was more likely than the others to distort hard facts about resources - like the amount of timber around - and flip between extremes of behaviour. And it was better than the rest.


Each bot took on the game's default AI seven times. Both the aggressive and neurotic bots won all their matches - but the neurotic did it faster. On average by around 25%.

 
 
 

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

08/02/2008

VideoTrace

Décidemment, la reconstitution d'objet 3D à partir de vidéo à la vent en poupe en ce moment. Voici l'un des derniers exemples en date, VideoTrace.

 

 

 

 

VideoTrace is a system for interactively generating realistic 3D models of objects from video—models that might be inserted into a video game, a simulation environment, or another video sequence. The user interacts with VideoTrace by tracing the shape of the object to be modelled over one or more frames of the video.

 

By interpreting the sketch drawn by the user in light of 3D information obtained from computer vision techniques, a small number of simple 2D interactions can be used to generate a realistic 3D model. Each of the sketching operations in VideoTrace provides an intuitive and powerful means of modelling shape from video, and executes quickly enough to be used interactively.

 

Immediate feedback allows the user to model rapidly those parts of the scene which are of interest and to the level of detail required. The combination of automated and manual reconstruction allows VideoTrace to model parts of the scene not visible, and to succeed in cases where purely automated approaches would fail.

 

[ VideoTrace

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

07/02/2008

Radiosité temps réel...

Les artistes le savent: un bon éclairage peut rendre fascinante la scène la plus banale qui soit. Et ce n'est pas pour rien qu'on parle de "directeur photo" sur les plateaux de cinéma. Bref, en matière de rendu, le mot lumière est au coeur des préoccupations.
 
 
Et la lumière, c'est le dada de Geomerics. Voici leur vidéo de présentation pour la prochaine GDC:
 
 
 
 
 

"Most likely the single most important aspect of cinematography is lighting.  Lighting contributes considerably to the emotional response an audience has watching a motion picture." (Wikipedia)

 

No-one would claim the visual quality of video games has yet reached that of film, but the challenges faced by the cinematographer and the game artist are the same: to achieve consistent, realistic lighting that creates the desired mood.

 

The cinematographer is typically forced to experiment with extra lights and occluders off-camera in order to achieve presentable results.  With current technology, the game artist is obliged to do the same, in what can be a frustrating and time-consuming process that ultimately only decreases the possibilities for interactivity.

 

With Enlighten, realism comes for free.  Light from all sources in the scene is accurately computed in real-time; and not just the first bounce, but the whole global solution.  With a fully immersive environment guaranteed, the artist is free to concentrate on quality. 

 

And since the lighting calculations are fully configurable, he can even change the laws of physics... what the cinematographer wouldn't give for the possibilities offered by Enlighten!

 

Why is Real-Time Radiosity Important?

 

Current game lighting technology requires large numbers of lights. Artists use additional lights to fill in areas that, in reality, are lit by light reflected off other surfaces in the scene. With dynamically computed radiosity one can achieve far greater realism with only a handful of light sources. Enlighten brings physically correct dynamic lighting to this generation of game development.

 

Enlighten computes all bounced lighting and global illumination in real time – the first time this has ever been possible. By removing the need for artists to painstakingly mimic realistic lighting, time to create artwork is dramatically reduced. And with frame rates over 100fps Enlighten can be incorporated into any game setting.

 
 
 
 [ Geomerics ]

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

30/01/2008

SteamWorks...

Qui prétend qu'il n'y a pas de vie du coté du PC ? Certes, c'est un marché très délicat, mais il y encore de quoi faire de la marge, comme Blizzard ou Valve savent le faire.
 
 
Et en parlant de Valve, ils viennent d'annoncer une petite bombe sous la forme de la mise à disposition gratuite d'une partie des ressources de Steam. SteamWorks, c'est Steam sans la plateforme de distribution, mais avec toutes les features que l'on peut attendre d'un service en ligne: statistiques, mise à jour automatique, mesures anti triches et anti piraterie, chat, DRM, etc etc... Et ce, gratis.
 
 
Si si, gratis, comme gratuit, 0 euro, pas de licence à payer ni de royalties, "free as in free beer"...
 
 
92446c7802458fe88ee298db2918d9f6.jpg
41a01e151a433372373942b4fb0399e0.jpg
 
 
 
Valve, creators of best-selling game franchises (such as Half-Life and Counter-Strike) and leading technologies (such as Steam and Source), today announce Steamworks, a complete suite of publishing and development tools - ranging from copy protection to social networking services to server browsing - is now available free of charge to developers and publishers worldwide.
 
 

Steamworks, the same suite of tools used in best-selling PC titles Half-Life 2 and The Orange Box, is available for all PC games distributed via retail and leading online platforms such as Steam. The services included in Steamworks may be used a la carte or in any combination.

 

 

Specifically, Steamworks offers:

 

 

· Real-time stats on sales, gameplay, and product activation: Know exactly how well your title is selling before the charts are released. Find out how much of your game is being played. Login into your Steamworks account pages and view up to the hour information regarding worldwide product activations and player data.

 

 

· State of the art encryption system: Stop paying to have your game pirated before it’s released. Steamworks takes anti-piracy to a new level with strong encryption that keeps your game locked until the moment it is released.

 

 

· Territory/version control: The key-based authentication provided in Steamworks also provides territory/version controls to help curb gray market importing and deliver territory-specific content to any given country or region.

 

 

· Auto updating: Insures all customers are playing the latest and greatest version of your games.

 

 

· Voice chat: Available for use both in and out of game.

 

 

· Multiplayer matchmaking: Steamworks offers you all the multiplayer backend and matchmaking services that have been created to support Counter-Strike and Team Fortress 2, the most played action games in the world.

 

 

· Social networking services: With support for achievements, leaderboards, and avatars, Steamworks allows you to give your gamers as many rewards as you would like, plus support for tracking the world’s best professional and amateur players of your game.

 

 

· Development tools: Steamworks allows you to administer private betas which can be updated multiple times each day. Also includes data collection tools for QA, play testing, and usability studies.

 
 
 

13:30 Publié dans Code | Lien permanent | Commentaires (0)

15/01/2008

Code size nightmare

Une des leçons que j'ai apprise sur le tas, c'est de se méfier de la taille du code en général (code bloat). Les symptômes du "code bloat" sont aussi variés que leurs sources, et les conséquences peuvent être dévastatrices. En fait, trop de code tue le code.
 
 
Duplication de code (le syndrôme CTRL-C CTRL-V), problèmes de maintenances et documentation, lenteur de compilation (et d'exécution), difficultées de debugage, complication du design... Etc etc. Une base de code trop grosse peut vite devenir le pire ennemi du programmeur.
 
 
Et le pire, c'est que ce problème n'est vraiment pas très bien géré par nos outils. Les IDE s'emmèlent encore souvent les pinceau, même avec "peu" de code (1 millions de ligne), les langages que nous utilisons poussent parfois à être verbeux (C++ n'est pas ce qui ce fait de mieux en terme de concision), même nos façon de penser nous ammènent à écrire parfois de plus en plus de code (certains design patterns par exemple).
 
 
Steve revient sur ce problème mieux que je ne saurai l'expliquer, en prenant l'exemple de Java. Mais ce problème se retrouve tout aussi bien en C++:
 
 
I happen to hold a hard-won minority opinion about code bases. In particular I believe, quite staunchly I might add, that the worst thing that can happen to a code base is size.


I say "size" as a placeholder for a reasonably well-formed thought for which I seem to have no better word in my vocabulary. I'll have to talk around it until you can see what I mean, and perhaps provide me with a better word for it.
 
 
The word "bloat" might be more accurate, since everyone knows that "bloat" is bad, but unfortunately most so-called experienced programmers do not know how to detect bloat, and they'll point at severely bloated code bases and claim they're skinny as a rail.
 
 
...
 
 
My minority opinion is that a mountain of code is the worst thing that can befall a person, a team, a company. I believe that code weight wrecks projects and companies, that it forces rewrites after a certain size, and that smart teams will do everything in their power to keep their code base from becoming a mountain. Tools or no tools. That's what I believe.
 
... 
 
 
I'm going to try to define bloat here. I know in advance that I'll fail, but hopefully just sketching out the problem will etch out some patterns for you.


There are some things that can go wrong with code bases that have a nice intuitive appeal to them, inasmuch as it's not difficult for most people to agree that they're "bad".
 
One such thing is complexity. Nobody likes a complex code base. One measure of complexity that people sometimes use is "cyclomatic complexity", which estimates the possible runtime paths through a given function using a simple static analysis of the code structure.
 

I'm pretty sure that I don't like complex code bases, but I'm not convinced that cyclomatic complexity measurements have helped. To get a good cyclomatic complexity score, you just need to break your code up into smaller functions.
 
 
Breaking your code into smaller functions has been a staple of "good design" for at least ten years now, in no small part due to the book Refactoring by Martin Fowler.
 

The problem with Refactoring as applied to languages like Java, and this is really quite central to my thesis today, is that Refactoring makes the code base larger. I'd estimate that fewer than 5% of the standard refactorings supported by IDEs today make the code smaller.
 
 
Refactoring is like cleaning your closet without being allowed to throw anything away. If you get a bigger closet, and put everything into nice labeled boxes, then your closet will unquestionably be more organized. But programmers tend to overlook the fact that spring cleaning works best when you're willing to throw away stuff you don't need.


This brings us to the second obviously-bad thing that can go wrong with code bases: copy and paste. It doesn't take very long for programmers to learn this lesson the hard way. It's not so much a rule you have to memorize as a scar you're going to get whether you like it or not.
 
 
Computers make copy-and-paste really easy, so every programmer falls into the trap once in a while. The lesson you eventually learn is that code always changes, always always always, and as soon as you have to change the same thing in N places, where N is more than 1, you'll have earned your scar.
 

However, copy-and-paste is far more insidious than most scarred industry programmers ever suspect. The core problem is duplication, and unfortunately there are patterns of duplication that cannot be eradicated from Java code.
 
 
These duplication patterns are everywhere in Java; they're ubiquitous, but Java programmers quickly lose the ability to see them at all.
 
...
 
 
 
The other seminal industry book in software design was Design Patterns, which left a mark the width of a two-by-four on the faces of every programmer in the world, assuming the world contains only Java and C++ programmers, which they often do.
 

Design Patterns was a mid-1990s book that provided twenty-three fancy new boxes for organizing your closet, plus an extensibility mechanism for defining new types of boxes. It was really great for those of us who were trying to organize jam-packed closets with almost no boxes, bags, shelves or drawers.
 
 
All we had to do was remodel our houses to make the closets four times bigger, and suddenly we could make them as clean as a Nordstrom merchandise rack.
 

Interestingly, sales people didn't get excited about Design Patterns. Nor did PMs, nor marketing folks, nor even engineering managers. The only people who routinely get excited about Design Patterns are programmers, and only programmers who use certain languages.
 
 
Perl programmers were, by and large, not very impressed with Design Patterns. However, Java programmers misattributed this; they concluded that Perl programmers must be slovenly, no good bachelors who pile laundry in their closests up to the ceiling.
 

It's obvious now, though, isn't it? A design pattern isn't a feature. A Factory isn't a feature, nor is a Delegate nor a Proxy nor a Bridge. They "enable" features in a very loose sense, by providing nice boxes to hold the features in.
 
 
But boxes and bags and shelves take space. And design patterns – at least most of the patterns in the "Gang of Four" book – make code bases get bigger.
 
 
Tragically, the only GoF pattern that can help code get smaller (Interpreter) is utterly ignored by programmers who otherwise have the names of Design Patterns tatooed on their various body parts.
 
... 
 
 

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

13/12/2007

GameMonkey...

Ce qu'il y a de bien avec LUA, c'est que beaucoup de monde l'utilise. Le problème avec LUA, c'est la syntaxe ^_^

 

Alors, voici une alternative un peu plus "C" friendly: GameMonkey.

 

What is GameMonkey Script?

 

GameMonkey is a embedded scripting language that is intended for use in game and tool applications. GameMonkey is however suitable for use in any project requiring simple scripting support. GameMonkey borrows concepts from Lua (www.lua.org), but uses syntax similar to C, making it more accessible to game programmers. GameMonkey also natively supports multithreading and the concept of states.
 

Can I use GameMonkey freely in my hobby or work project?

 

Yes, GameMonkey is distributed under the MIT license and is free for any use including commercial products. Please read the full license included in the download package.
 

What are the key features of GM?

 

  • Small code base. Compiled code may use about 50kb of RAM. Less when tweaking or sharing with application.
  • Compile source code at run time, or link to precompiled libs.
  • Lightweight, native threading.
  • Soft real-time incremental garbage collection. Controllable memory footprint. No painful reference counting.
  • Easy to bind CC++ functions and call script from CC++.
  • Runtime debugging and reflexion support.
  • C style syntax.
  • Competitive performance when compared to other scripting languages for both CPU and Memory usage. Speed is a trade off for flexibility and simplicity.
  • Easily modifiable as it is written in C++ and uses Flex and Bison.

 

[ GameMonkey

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