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