DeepVoid - Main menu

Posted by , on - annonce

 DeepVoid has been in development for exactly a year today ! It's been a lot of hard work, we are not finished with the game but still happy to work on it.

To celebrate this, here is a preview of our new menu system.

Read comments

DeepVoid source code is released

Posted by , on - prog

13,000 lines of open source

Ever wanted to take a look at a game's code ? Working on your own shooter on UDK ? You will like this : most of our source code is being released under the permissive LGPL license. We encourage UDK enthusiasts to check it out and see what we do.

DeepVoid is being developed as an open game with documentation, available source code, technical articles about how we are working. Publishing the source is something we wanted to do for a long time !

Right now, 80% of our source code is released. The upper layer of the game's code is still under heavy development and is technically less relevant ; it will be published as well as soon as we can.

Development news

If you just discovered DeepVoid, here is our last technology demo. This real-time video is a work in progress, showcasing our artistic direction. Hit the HD button and enjoy !

We are working on a large CTF level with a complex gameplay, featuring numerous escape routes, high vantage points, hidden tunnels in an orbital space station. This level will be the first complete multiplayer level we build.  Here is a concept art we made for it...

The game itself is still a work in progress. We now have a complete, secure statistics server that can tell you how much bullets you fire, what weapon you use and how effective you are. We will also provide player ranking, server browsing and more !

FAQ

What is DeepVoid ?

DeepVoid is a free FPS game. It will be released this year and features a fast, hardcore gameplay. This is a game meant for gaming enthusiasts, earning us a selection in the Top 100 of IndieDB's Indie Of The Year 2012 !

How can I get the code ?

You can visit our open-source page here. The code is published on GitHub and will be kept synchronized with our development computers. Every update we make is available at once.

What technology are you using ?

We work with the UDK from Epic Games. It's a very powerful engine. Our code is mainly written using UnrealScript, but you will find native modules in it for some parts that could not be part of the engine's user code.

Can I contribute to the code ?

Shortly put : no. We are keeping control of what's being done and we won't accept external contributions for now. This policy may change when the game is complete and published.

Can I help DeepVoid ?

Yes you can ! If you are an experienced 3D artist, you can apply to help us. We are looking for talented people who want to build a great game, share their passion and knowledge.

If you are a gamer, you can still help by talking about us, sharing news and media.

Can I rebuild the code and make a copy of DeepVoid ?

No, because the released code is just one part of the game. We are not publishing the content, UDK configuration and build system right now, since the game is just not done. We are still working very hard to complete it.

In the upcoming months, we will also release various game elements :

  • Our master server software, to which every client is connected. Written in Python, it handles information about game servers and players, such as accuracy, shots fired, team kills, etc.
  • The last UnrealScript module, in which the gameplay details are defined.

Read comments

Cet article ne concerne pas spécifiquement DeepVoid, c'est un avis général sur le développement de jeux 3D, qui s'appuie sur DeepVoid pour illustrer le propos par l'exemple.

Les projets de jeux vidéo 3D sont nombreux, c'est un rêve pour de nombreux développeurs. Et à juste titre. Curieusement, les moteurs de jeu sont souvent rejetés par ces développeurs. Trop faciles, pas assez complets, pas portables ? On vous conseille plutôt Irrlicht ou OGRE, en C++ ou en Java ? Tordons le cou à quelques idées reçues...

Un moteur de jeu, pourquoi ? C'est quoi au juste ?

Un moteur de jeu, c'est un environnement de développement pour créer des jeux (souvent 3D). On y trouve des outils de création, de déboguage, de collaboration, et surtout le squelette d'un jeu vierge que l'on va modifier au fil du temps. Un des plus connus, celui que nous utilisons, est l'Unreal Development Kit ou UDK.

L'objet de cet article n'est pas de faire une liste de toutes les capacités d'un moteur de jeu, mais de répondre aux questions que se posent les développeurs de jeux. C'est une réponse personnelle, mais qui se base sur le travail effectué pour DeepVoid et que j'espère pertinente.

Mythe #1 : Un moteur de jeu, c'est trop facile

On pourrait effectivement croire, en feuilletant le catalogue d'outils d'UDK, que tout le boulot est fait. Il y a une classe "Personnage" dans le code, on peut importer et animer un objet complet sans sortir d'une interface graphique, les éditeurs de shader, de cinématique ou de système de particules sont impressionnants.

La réalité : il suffit de faire le point sur le travail accompli sur DeepVoid pour réaliser un noyau basique de FPS multijoueurs. Un an de travail, 15 membres d'équipe dont beaucoup sont des professionnels expérimentés. Deux programmeurs de métier qui ont écrit 20 000 lignes de code dans une centaine de fichiers, plus d'un millier de révisions du projet, pas moins de cinq repos Git, et quatre logiciels externes au jeu. Une dizaine d'artistes qui ont pondu plusieurs Go de données sources. Et pour l'équipe de direction du projet, c'est plusieurs dizaines d'heures de travail par semaine en moyenne.

Trop facile.

Mythe #2 : Un moteur de jeu, c'est limité

C'est encore une critique très courante de la part des passionnés : un moteur de jeu, c'est limité parce qu'on ne peut pas ajouter de fonctionnalités. Certes, le moteur embarque un générateur de végétation, un éditeur de terrain et une synthèse vocale, mais il ne gère ni Kinect, ni le shader model 4 !

La réalité : avez-vous vraiment besoin de ce qui n'est pas dans le moteur ? La vidéo ci-dessus est un rendu en temps réel réalisé en quelques semaines. C'est un peu en dessous de ce qu'on trouve dans les jeux du commerce, mais ça reste regardable.

Il vous manque vraiment quelque chose ? La plupart des moteurs permettent, a minima, d'appeler du code extérieur. Si vous avez besoin du support de Kinect et que votre moteur ne le gère pas, c'est quand même faisable. Dans le cas de DeepVoid, c'est un support du protocole SSL qui a été greffé au jeu de cette façon.

Mythe #3 : On est super motivés, on a le temps de tout faire nous-mêmes

Le temps de travail n'est jamais un souci pour des passionnés. Peu importe si ça prend des années, les équipes de création de jeu sont dotées d'une motivation colossale. Il est très courant de voir une équipe, au bout d'une semaine de développement, montrer un site Web, une arme fraîchement modélisée, un scénario de 40 pages et un logo. Très important, le logo.

La réalité : Malheureusement, la motivation ne remplace pas la compétence, et même un programmeur très motivé ne peut pas être compétent en réseau, en sécurité, en shading, en gameplay, en gestion de la physique, en son et en IA. Les gens qui excellent dans une de ces disciplines sont rares ; aucune équipe amateur ne dispose de toutes les compétences nécessaires.

Ce qui est dur dans cette situation, c'est que les membres de l'équipe ont toujours un minimum de compétence, suffisamment pour commencer le projet et rassurer le public sur leurs compétences, mais rarement assez pour venir à bout du projet entier. Vous n'avez jamais bloqué trois mois sur un point auquel vous n'auriez jamais pensé au début d'un projet ?

Mythe #4 : Le moteur de jeu empêche la créativité

Nouvelle critique, cette fois avec un fond de vérité : un moteur de jeu impose la structure des fichiers, le format de stockage, l'architecture du logiciel, et d'une façon générale restreint les choix techniques. Pas question a priori d'utiliser un langage de programmation qui n'est pas prévu dans le moteur.

Deux exemples simples : Minecraft, et World of Warcraft. Aucun de ces deux jeux n'est réalisable avec UDK, le premier parce que les concepts essentiels du jeu l'interdisent, le second parce que la couche réseau est fondamentalement incompatible avec un MMORPG.

La conclusion logique est que le moteur de jeu condamne le développeur à réaliser des jeux tous identiques.

La réalité : Tous les moteurs de jeu permettent de réaliser des jeux complètement différents. Il suffit de regarder la galerie de jeux d'un moteur célèbre pour s'en convaincre. Le moteur de jeu, de part sa conception, n'a pas d'impact sur le gameplay ni sur la direction artistique puisque c'est aux développeurs de s'en charger, entièrement. Enfin, tout dépend du moteur de jeu : Unity3D permet par exemple de changer de moteur réseau...

Vous doutez encore ? Vous pouvez comparer deux jeux réalisés avec le même moteur...

 

Mythe #5 : On ne programme pas dans un moteur de jeu

Quand on parle d'UDK par exemple, c'est un point qui revient souvent. Le moteur embarque un système de script graphique qui permet de réaliser des prototypes de gameplay basiques sans toucher une ligne de code, et d'une façon générale, les interfaces graphiques remplacent l'essentiel de ce qui est fait en code sur des solutions de moindre abstraction.

La réalité : Si vous êtes lancés sur un projet sérieux, vous ne vous en tirerez pas sans des dizaines de milliers de lignes, certaines sur le moteur de jeu, d'autres en dehors. Vous aurez sûrement besoin d'un installeur pour votre jeu, d'un serveur pour stocker des comptes de joueurs... En pratique, dans un projet de cet ampleur, on trouve toujours quelque chose à faire.

Mythe #6 : Un moteur de jeu, c'est cher

Il faut forcément payer pour accéder à ces moteurs, non ?

La réalité : Si vous avez l'intention de vendre votre création, bien entendu, il faudra passer à la caisse. Le modèle commercial dépend du moteur, pour les plus gros c'est un mécanisme de royaltie qui est proposé : vous reverserez à l'éditeur une part importante de votre chiffre d'affaire. Si c'est votre cas, vous trouverez en effet l'addition difficile à avaler.

Si en revanche vous développez un jeu amateur disponible gratuitement, vous pourrez trouver des moteurs gratuits, à commencer par UDK.

Mythe #7 : Les moteurs de jeu sont gratuits, mais ce sont les versions réduites des vrais

La réalité : Pas vraiment. Du moins, CryEngine et UDK, les deux leaders du marché distribuent gratuitement un outil équivalent à ce qui est proposé à un petit studio indépendant. Si un grand studio, lui, aura les moyens de négocier des avantages supplémentaires (accès au code source, support technique ou optimisations), c'est essentiellement le même outil.

La vraie différence réside dans le support du matériel, puisque votre moteur de jeu ne sera probablement proposé que sur PC, voire sur smartphone, et ne proposera pas de support des consoles de jeu. Mais là encore, ne croyez pas que le premier venu peut développer sur le matériel de Sony : l'accès à ces plateformes se paye.

Le bilan

Au fil des années, j'ai vu un nombre hallucinant de projets amateur se lancer. Qu'ils utilisent ou non un moteur de jeu, l'essentiel d'entre eux, quasi tous en fait, ont échoué. Le taux d'échec est incroyablement élevé dans les jeux amateur, le chiffre est bien au dessus de 90%. C'est un fait, et le plus grand piège, c'est de se dire qu'on échappe à la règle et qu'avec de la motivation on y arrivera.

Dans les faits, je ne connais que très peu de jeux réussis qui se soient passés de solutions complètes. Minecraft est l'exemple le plus connu, c'est d'ailleurs un des rares exemples de jeu plus facile à réaliser sans moteur de jeu. Mieux vaut ne pas en faire une règle générale...

On ne pouvait pas réaliser DeepVoid sans une base sérieuse, nous ne nous sommes jamais posé la question d'utiliser autre chose pendant la réalisation. Pour une raison simple : on n'en a même pas eu le temps ! Un jeu vidéo 3D, c'est une tâche titanesque, vous avez l'assurance d'y passer tout votre temps libre, et une bonne part de celui des autres. Ne tombez pas dans le même piège que les autres développeurs.

Read comments

La création d'un niveau par l'exemple

Posted by , on - Level Design DevBlog

L'équipe de DeepVoid travaille activement à la réalisation de son premier niveau multijoueurs. C'est une tâche complexe qui occupe presque la moitié de l'effectif et qui demande de l'organisation, aussi nous vous proposons un aperçu de la façon dont l'équipe travaille avec un exemple : notre premier niveau.

Idée, architecture, level design

Ce qu'un joueur retient avant tout d'un niveau, c'est généralement la façon dont on le joue. C'est du moins ce que nous souhaitons pour nos joueurs, c'est donc la première étape pour nous : une réflexion sur ce que le niveau doit être, le mode de jeu, ce que les joueurs doivent ressentir.

C'est à partir de cette réflexion que le level designer va proposer un plan de map, commencer une ébauche d'architecture dans UDK pour mettre en pratique cette idée.

Les playtests: un outil pour l'équilibrage

La maquette une fois terminée, on s'attaque à l'équilibrage du niveau via des essais. L'équipe se rassemble, des joueurs sont invités, tout le monde teste le niveau pendant une soirée. Les joueurs font un bilan de leurs impressions, tout est noté et c'est à partir de ces retours que le travail continue, le cas échéant avec des modifications au niveau.

Dans notre cas, un mécanisme supplémentaire est utilisé. A partir des logs du serveur de jeu utilisé (plusieurs Mo par heure !), un script extrait les informations de gameplay et les inscrit sur une image 2D représentant une carte du niveau. Il est donc très facile de visualiser les routes de flag, les zones peu fréquentées, les points chauds, l'équilibrage. Cet outil est open-source : http://arbonagw.github.com/GridMap/ .

Position des joueurs 

Tirs effectués

 

Routes de flag

 

Position initiale des sauts

Par exemple, on voit sur l'image que le flag a plusieurs fois été éjecté hors du niveau, et que les combats dans les points de spawn sont courants ! A partir de ces données, le level designer peut vérifier son niveau et corriger des points sensibles.

Avant la production : les concept arts

Pour que les artistes 3D soient efficaces et cohérents, il est important de fournir des concepts du niveau, c'est-à-dire des dessins 2D imaginant le résultat final. C'est le rôle du concept artist et c'est à partir de ce dessin que le niveau est réalisé, pièce par pièce, tout en conservant l'architecture initiale.

La production

C'est ce que nous attaquons désormais. Les artistes 3D vont maintenant travailler ensembles à réaliser le niveau tel qu'il a été imaginé. On pourrait croire que finalement, ce niveau n'est qu'à peine commencé, mais c'est au contraire le plus difficile qui est fait dans ces premières étapes. Les efforts en production ne servent que si tout est clair avant, et modifier un niveau après sa réalisation est beaucoup plus pénible...

C'est donc une affaire à suivre...

Read comments