Un bon début pour la campagne Kickstarter

La campagne Kickstarter a été lancé depuis un peu plus d'une journée, et nous avons déjà eu trois updates de la part de City State Entertainment.
Un bon début pour la campagne Kickstarter

Après une journée, c'est un peu plus de 30% de la somme requise qui est récoltée. Il s'agit là d'un bon départ mais après plus d'un mois de présentation du jeu, on pouvait se douter que de nombreux joueurs seraient dans les starting-blocks pour le lancement.

On commence avec des remerciements de la part de City State Entertainment (lien) puis l'annonce d'une prochaine mise à jour concernant les add-ons (lien). Enfin Andrew Meggs nous parle du moteur de jeu (lien) :

Update #3 - Kickstarter

Bon après-midi de la part d'Andrew ! Cette mise à jour est une démonstration de la technologie du rendu. Et c'est plutôt bien foutu, mais surtout c'est essentiel. Je voulais vous expliquer pourquoi ça l'est. Il y a pas mal de moteurs disponibles, alors pourquoi créer le nôtre ?

Tout d'abord, pour clarifier les choses : nous n'allons pas complètement partir de zéro, car cela serait, pour le dire gentiment, suicidaire. Nous utilisons une base de moteur déjà existante. Nous utilisons pas mal de morceaux d'interfaces utilisateurs open source très connues. Nous utilisons quelques standards de l'industrie du réseau, ce qui nous permet d'exécuter quelques programmes bien connus comme éléments de l'ensemble (ndlr: le stack, pile). Nous testons encore la partie audio, mais nous utiliserons définitivement un middleware.

Donc, quelle est la partie que nous allons développer nous-même ? En gros, tout ce qui implique l'augmentation du nombre de joueurs en même temps. Il y a beaucoup de moteurs qui font un super boulot pour afficher environ 100 personnages à la fois, mais passé ce cap, cela commencer à ralentir. J'ai travaillé avec un tas de moteur et/ou partie de middleware, et il y a une raison simple à cette limite. Ce sont des technologies génériques. Elles sont très flexibles en ce qui concerne l'affichage de cette 100aine de personnages. Le problème, c'est que cette flexibilité se gagne au dépend d'autres éléments. En programmation, spécialement en axée sur l'optimisation de moteurs de jeux, créer de la flexibilité se fait au détriment de la performance. Il y a un coût juste pour vous rendre compte de ce que vous ne voulez pas. Il y a un coût à chaque appel de fonctions polymorphes, juste pour s'apercevoir que, finalement, "Non nous n'avons pas besoin de ça sur le personnage à ce moment-là". Il y a un coût sur les structures de données génériques qui peuvent représenter une possibilité personnalisée.

Pour un jeu avec 50-100 personnages, c'est un bon compromis. Vous pouvez y consacrer du temps. La flexibilité dont vous avez besoin, au final, équivaut une milliseconde ou deux sur chaque frame (ndlr: ref. image / seconde). Mais qu'arrive-t-il lorsque vous multipliez ça par 10 ? Nous ne voulons pas avoir seulement 50 à 100 personnages pour ce jeu, nous voulons que ça soit EPIQUE. C'est une chose contre laquelle nous avons lutté pour Warhammer Online, là où nous avions hérité d'un système de rendu, dû déposer une licence pour un système d'animation déjà conçu, et utiliser des effets déjà existants. Il y avait des outils très simple à utiliser pour les artistes, afin d'avoir des rendus en jeu très proches de leurs visions, mais une fois que vous aviez 200 personnages à l'écran, les performances indiquaient que le jeu ne tournait pas aussi bien que ce que nous voulions. Comme indiqué dans les Principes Fondamentaux, rien de ce qui brille n'a de sens si le gameplay ne peut pas suivre. Nous. Pouvons. Faire. Mieux.

Ce que cela signifie pour nous c'est que nous aurons besoin de quelque chose construit pour arriver à ce but. Nous avons besoin d'une technologie qui n'est pas définie pas ce qu'elle peut faire, mais par ce que nous pouvons mettre de côté pour ce jeu. Imaginez ça comme jeter des choses par-dessus bord pour alléger un bateau, ou retirer les sièges arrière d'une voiture de course. Nous n'allons faire qu'une chose, mais si c'est la seule chose dont nous avons réellement besoin, nous la ferons bien.

L'un des développeurs ici a vu la démo "Electra 10000" et a dit "J'aimerai vraiment voir le code de ça !"

La vérité c'est qu'il n'y a pratiquement pas de code à voir. Mais le code qu'il y a, est le bon code. C'est une ligne, petite simple et propre qui va fait exactement ce dont nous avons besoin et rien de plus. C'est une partie de ce qui fait que cela est réalisable par nous-même. Nous n'avons pas besoin de passer des mois à écrire des centaines de milliers de lignes de codes. Nous avons une vision claire de ce que nous utilisons et n'utilisons pas pour ce jeu, nous avons juste besoin d'une poignée de personnes intelligentes pour écrire cette petite portion de code que nous allons vraiment utiliser. J'ai passé assez d'année à faire ça et j'ai appris assez sur les bonnes (et mauvaises) façon d'intégrer le tout, que je pense que nous pouvons le faire.

Mais c'est un peu facile à dire, donc nous avons aussi fait une démo pour le prouver. Il y en aura plus à vous montrer durant le mois à venir.

Nous sommes même gratifiés d'une petite démonstration en vidéo :

.

Pour information voici la configuration de la machine utilisée dans cette démonstration :

Il s'agit d'un MacBook Pro 15" du début de l'année 2011, comme décrit sur le site d'Apple. Il possède un GPU Radeon 6750M et un CPU à 2.2 GHz. Malgré cela, la charge du CPU n'a pas dépassé 15%. Il tourne sous Windows 7 SP1 via Boot Camp.

Source : http://www.facebook.com/pages/Camelot-Unchained-Communaut%C3%A9-Francophone/506978846010027?ref=stream

Réactions (333)


Que pensez-vous de Camelot Unchained ?

349 aiment, 64 pas.
Note moyenne : (421 évaluations | 0 critique)
7,5 / 10 - Très prometteur