samedi 2 juillet 2011

Le système de particules est prêt !

Bonjour à tous !
Un des systèmes les plus importants dans l'Usine en Folie, c'est la gestion des particules. En fait, le plus difficile ce n'est pas vraiment de les gérer, mais de ne pas créer pendant le jeu des instances de particules, et de faire en sorte que la consommation de mémoire reste stable.
Petite vidéo comparative entre la version C# et la version Ruby (dont la consommation de mémoire change d'un Mo par seconde environ).

Maintenant, petits détails techniques sur comment c'est fait...

Les contraintes
Il faut savoir que, la plus grosse contraintes que j'ai niveau programmation, c'est la mémoire. Vous me direz que maintenant les PC ont presque tous 4Go de RAM... oui, mais pas la Xbox 360, qui ne possède que 512Mo !
Une autre contrainte se rajoute aussi, mais cette fois-ci elle vient de C# : la Garbage Collection, qui produit souvent dans les jeux des "glitches" qui durent un court moment. En gros, après une certaine quantité de mémoire allouée, le Garbage Collector supprime tous les objets qui ne sont plus utilisés, ce qui inclut qu'il lui faut qu'il vérifier plus ou moins toutes les références (ce qui signifie une grosse boucle :p).
Du coup, y'a deux options pour éviter d'avoir des tonnes de "glitches" : réduire le nombre de références, ou ne pas faire d'allocations de mémoire (par exemple en créant des objets en jeu).
J'ai choisi la deuxième option, ne pas faire d'allocation de mémoire.
Difficile me direz-vous, lorsqu'on a des centaines de particules qui sont créées à l'écran !
Mais, rassurez-vous, les développeurs ont trouvé une parade pour ce genre de chose, et ça s'appelle...

... Le pooling
Le principe est simple : il faut pré-créer des instances d'objets, les utiliser, et lorsque l'on en a plus besoin ne pas les supprimer, mais les conserver pour les réutiliser : on les stocke dans la "pool". Eh oui, la même instance pourra donc servir pour afficher plusieurs particules différentes à différents moments !!
C'est pas tout ça, mais concrètement, ça donne quoi ?

Le pooling pour les particules de l'Usine
Bon, il n'existe pas qu'une méthode pour faire du pooling, mais je vais décrire celle utilisée dans l'Usine en Folie.
Le principe :
- Une liste d'objets actifs, qui seront les objets sortis de la pool. On pourra utiliser cette liste pour itérer à travers toutes les particules par exemple...
- Un tableau d'objets inactifs : la pool. Eux sont juste stockés, ils ne doivent pas être visibles à l'écran (dans le cas des particules). Ce sont juste des instances
- Une méthode GetFromPool qui retourne une particule. Elle sort un objet de la pool pour le mettre dans la liste des objets actifs, et retourne finalement l'objet sorti. Une exception doit être levée s'il n'y a plus d'instances dans la pool. Après avoir appelé cette méthode, il est nécessaire d'appeler une méthode de l'objet obtenu, qui l'initialise à partir de certains arguments (dans le cas des particules, une classe qui contient des informations comme la position, l'image à utiliser, et quelques méthodes si nécessaire).
- Une méthode Free, qui prend en argument un objet, et qui le retire des objets actifs pour le mettre dans la pool, elle peut appeler une méthode de "destruction partielle" de l'objet à retirer, par exemple, dans le cas des particules, le retirer de l'écran, et réinitialiser les valeurs des variables.

Le problème de cette méthode, c'est qu'on ne peut pas gérer les sous classes de la classe qui est stockée dans la liste, à moins bien sur, de faire plein d'opérations de boxing / unboxing, qui produisent des allocs de mémoire cachée, ce qu'on veut justement éviter. La classe qu'on va créer doit donc être générique, et une instance pourra être crée par sous-classe de particule. Le paramètre de Type aura comme contraintes d'hériter de Particule, et d'avoir un constructeur qui ne prenne pas d'argument.

Voici le code C# utilisé actuellement pour dans l'Usine en Folie pour la ParticulePool. J'espère que vous n'êtes pas allergique à l'Anglais, car je commente toujours mon code en anglais...et j'espère aussi que ça sera utile à quelqu'un =D !

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace UsineEnFolie.Particles
{
    /// <summary>
    /// Particle pool.
    /// An instance must be created for each subtype of particle, because using
    /// a single class handling every subtypes would need to make a lot of
    /// boxing and unboxing operations.
    /// </summary>
    /// <typeparam name="ParticleClass"></typeparam>
    /// <typeparam name="InitClass"></typeparam>
    public class ParticlePool<ParticleClass> where ParticleClass : Particle, new()
    {
        /* -------------------------------------------------------------------------
        * Variables
        * ------------------------------------------------------------------------*/
        #region Variables
        public const int MAX_COUNT = 400;
        private List<ParticleClass> active;
        private ParticleClass[] pool;

        // Use it in iterations.
        private int i = 0;
        private int j = 0;
        #endregion

        /* -------------------------------------------------------------------------
        * Methods
        * ------------------------------------------------------------------------*/

        #region Methods
        /// <summary>
        /// Constructeur.
        /// </summary>
        public ParticlePool()
        {
            active = new List<ParticleClass>(MAX_COUNT);
            pool = new ParticleClass[MAX_COUNT];
            for (i = 0; i < MAX_COUNT; i++)
            {
                pool[i] = new ParticleClass();
                pool[i].DisposeBasic();
            }
        }
        /// <summary>
        /// Returns a List containing every active object.
        /// Use it to iterate through Particles.
        /// </summary>
        /// <returns></returns>
        public List<ParticleClass> GetActive()
        {
            return active;
        }
        /// <summary>
        /// Returns one particle from the pool.

        /// This item becomes active and goes as the first item of the list.
        /// pool -> active.
        /// LoadData() must be called on the returned Particule !
        /// </summary>
        /// <param name="data"></param>
        /// <returns></returns>
        public ParticleClass GetFromPool()
        {
            for (i = 0; i < MAX_COUNT; i++)
            {
                // Removes a reference from the pool and adds it into the active objects.
                if (pool[i] != null)
                {
                    ParticleClass ev = pool[i];
                    active.Add(pool[i]);
                    pool[i] = null;
                    return ev;
                }
            }
            throw new Exception("Not enough objects in pool");
        }
        /// <summary>
        /// Removes an event from the active ones and put in the pool.
        /// active -> pool
        /// </summary>
        /// <param name="p">The particule to free</param>
        public void Free(ParticleClass p)
        {
            // Removes the event from the actives ones.
            active.Remove(p);
            // Adds the event in the pool.
            for (i = 0; i < MAX_COUNT; i++)
            {
                if (pool[i] == null)
                {
                    pool[i] = ev;
                    break;
                }
            }
        }

        /// <summary>
        /// Clears the pool, and marks all item as available.
        /// pool -> active
        /// </summary>
        public void Clear()
        {
            foreach (ParticleClass ev in active)
            {
                for (i = 0; i < MAX_COUNT; i++)
                {
                    if (pool[i] == null)
                    {
                        pool[i] = ev;
                        active.Remove(ev);
                    }
                }
            }
        }
        #endregion
    }
}


vendredi 10 juin 2011

L'Usine en Difficulté...

Cela fait environ 5 semaines que l'équipe n'a pas de nouvelles de kriss, ce qui commence à faire beaucoup.
Lui étant chargé du cahier des charges, je ne peux continuer à développer pour l'instant. Le projet est donc officiellement en pause jusqu'au retour de kriss.
Cependant, s'il n'est pas là d'ici début Juillet, le développement reprendra quand même ; mais on ne fera pas aussi bien qu'on pourrait le faire avec ce cahier des charges.

Donc il est possible qu'il y ait peu de nouvelles de l'Usine ces temps-ci.

Scriptopathe

vendredi 3 juin 2011

Le portage vers XBOX 360, un défi technique !

Bonjour à tous,
Ici Scriptopathe, en ce moment je suis un peu seul à travailler sur le projet, kriss étant parti (en vacances ?)...

Alors, on porte l'Usine vers XBOX 360 ?
En attendant d'avoir le cahier des charges complet, je commence à programmer le noyau du jeu. Et ce n'est pas forcément une partie de plaisir, étant donné qu'il y a d'importantes différences entre Ruby (langage dans lequel le jeu était programmé à la base) et C#.
De plus, il faut faire de nombreuses adaptations dans l'éditeur de jeu, afin d'avoir un système viable.
Le fait de passer de Ruby vers C# a amené son lot de contraintes, et parmi elles...

...Un problème assez gênant
(attention ça devient un peu technique, ça sera surtout utiles aux autres développeurs qui ont un problème semblable)
Dans la version Ruby de l'Usine en Folie, on avait la possibilité d'écrire du code Ruby dans les Evènements (personnages, objets, etc...), et de l'exécuter en jeu, via une fonction Ruby nommée eval(), qui permettait d'interpréter du code.

Dans l'éditeur, si on double cliquait sur un évènement, on pouvait modifier son contenu. Entre autres, dans chaque onglet, on pouvait écrire du code Ruby qui allait être exécuté lorsque une condition était remplie : lors de l'initialisation, lorsque l'évènement est à l'écran, au contact du héros, premier contact héros, héros + touche d'action pressée, contact avec un autre évènement, et contact avec un tir.







Cela était possible car Ruby est un langage interprété.

Or, il se trouve que ce n'est pas le cas de C# : pas de fonction eval(), l'exécution du code contenu dans les évènements paraissait alors impossible !

Mais... comment on fait alors ?
Je me suis posé la question de "Comment intepréter du code C# qui n'est chargé qu'à l’exécution ?".
Après pas mal de recherches, et des questions posées sur développez.net (je remercie d'ailleurs Dom Quiche pour ses conseils avisés) une solution est envisageable :
Compiler le code des évènements dans des dll chargées à l'exécution, puis créer des Delegates utilisés par les évènements pour exécuter ce code.

Alors, ce n'était pas si évident que ça, donc je vais un peu détailler comment il faut faire :

Etape 1 : la compilation !
En C#, l'unité minimale de compilation est l'assembly.
Que devra contenir notre assembly ?
L'assembly créée devra contenir le code de tous les évènements d'une map. Ainsi, on chargera une dll lors de chaque chargement de map. Les fichiers de maps que vous créerez au moyen de vos outils devront comporter le chemin relatif (à partir du répertoire courant du jeu donc) de la dll qui correspond au code de leurs évènement, afin que ces dernières puissent être retrouvées pendant le jeu.

L'assembly comportera un type, qui doit pouvoir être retrouvé par le jeu à l'exécution, donc, par exemple, l'idéal serait de stocker le nom de ce type dans le fichier map, ou de le créer à partir du nom de fichier (en remplaçant les "/" par des "_" par exemple).

Le type ainsi créé comportera des méthodes publiques et statiques, qui prendront en argument l'évènement qui doit "exécuter" les actions, ainsi que d'autres arguments (par exemple, dans le cas du contact avec un autre évènement, donner en argument l'évènement avec lequel il rentre en contact).

Et cela pose un nouveau problème : si vous compilez vos sources sans aucune référence vers vos projets, le compilo vous fera un scandale car les types que vous lui demanderez (par exemple Event pour les évènements) n'existent pas.
Pour remédier à cela,  il faudra ajouter des références vers des dll qui contiennent ces types (il faudra donc mettre les parties de votre jeu qui doivent être accessible depuis les "scripts" des évènements dans des dll).

En pratique ça donne quoi ?
Voici un exemple de code C# qui permet de compiler... du code C# :

            // Ce code devra être chargé depuis un fichier map.
            string code = "Code à compiler"; 


            // Paramètres du compileur
            CompilerParameters cparams = new CompilerParameters();

            // On va générer une dll, pas un exécutable
            cparams.GenerateExecutable = false;
            cparams.OutputAssembly = "Nom du fichier de la dll qui va être créée";
            cparams.ReferencedAssemblies.Add("Chemin d'accès à la dll");

            // Compilation
            CSharpCodeProvider provider = new CSharpCodeProvider();
            ICodeCompiler compiler = provider.CreateCompiler();
            CompilerResults results = compiler.CompileAssemblyFromSource(cparams, code)

            // Gestion de l'erreur
            if (results.Errors.HasErrors)
            {
                System.Text.StringBuilder errors = new System.Text.StringBuilder("Compiler Errors :\r\n");
                foreach (CompilerError error in results.Errors)
                {
                    errors.AppendFormat("Ligne {0}\t: {1}\n",
                           error.Line, error.ErrorText);
                   
                }
                errors.AppendFormat("Code :\n{0}\n\n", str);
                // Créer une fonction WriteLog qui écrive les erreurs dans un fichier,
                // de manière à pouvoir les récupérer depuis un autre programme.

                // Nom du log peut être généré à l'aide du nom du fichier compilé.
                WriteLog(errors.ToString(), "Nom du log")
            }

Voilà, histoire que vous sachiez ce qu'il faut utiliser pour faire quoi. Bien sur, ce code est à compléter et organiser en fonction de ce que vous voulez faire, mais les principales fonctions sont là !

Étape 2 : exécution !
A l'exécution, lorsque vous chargez votre map pour la première fois, chargez votre assembly, et mettez le en mémoire dans un Dictionnary<string, Assembly> :
public Dictionnary<string, Assembly> Assemblys = new Dictionnary<string, Assembly>();
Remarque : ne pas oublier la directive using System.Reflection;au début du code source.

Pour charger l'assembly, il suffit d'utiliser :
string Filename = "Chemin d'accès vers la dll";
Assemblys[Filename] = Assembly.LoadFrom(Filename);


Il va ensuite falloir récupérer le type qui est contenu dedans :
string Typename = "Nom du type" // nom récupéré à partir du fichier map par exemple
Type type = Assemblys[Filename].GetType("Nom du type");

Ou alors, si (et normalement c'est le cas) il n'y a qu'un seul type dans l'assembly :
Type type = Assemblys[Filename].GetTypes[0];

Pour récupérer une méthode :
MethodInfo method = type.GetMethod("Nom de la méthode");

Maintenant, il va falloir créer des délégates dans la classe qui va utiliser ces méthodes (disons Event pour "évènement") :
// Délegate qui acceptera un argument Event
delegate void DelegateSimple(Event self);
// Délégate qui acceptera deux arguments Event
delegate void DelegateWithEvent(Event self, Event evt);
// Ainsi de suite...

// De quoi les utiliser :
// Pour les collisions avec le héros
DelegateSimple MethodOnCollideHero;
// Collisions avec les Events
DelegateWithEvent MethodOnCollideEvent;


Ensuite, on utiliser les infos de méthodes qu'on a récupérées précédemment afin de les initialiser :
// method est un objet MethodInfo qu'on a récupéré précédemment
MethodOnCollideHero = (DelegateSimple)Delegate.CreateDelegate(typeof(DelegateSimple), method);


Et voilà, pour appeler la méthode il n'y a plus qu'à faire :
MethodOnCollideHero(this);

Revenons à l'Usine en Folie
Sur l'Usine en Folie, ce système fonctionne parfaitement. L'éditeur a été adapté à la syntaxe de C#, et permet de tester le code C# tapé pour indiquer des éventuelles erreurs :



Et voilà, comme quoi tout est possible !

Scriptopathe

jeudi 2 juin 2011

Histoire de l'Usine en Folie

L'Usine en Folie est un projet qui ne date pas d'hier.
Il a commencé avec King Kadelfek, et son moteur fausse 3D, qui avec Kriss (qui est la source du concept) avaient mobilisé une bonne équipe composée de graphistes, musiciens, designers... cependant, le projet a été abandonné début 2009.
Le concept de l'Usine s'est donc retrouvé au point mort, n'ayant plus de développeurs pour le mener à bien.

Pendant ce temps... dans une lointaine contrée...
RPG-man (maintenant Scritopathe) créait un moteur de jeu de plateformes (PGE pour Platform Game Editor) ainsi que son éditeur. Kriss, intéressé, prit contact avec lui et ils commencèrent ensemble à faire migrer le concept de l'Usine vers ce nouveau moteur.
Voyant que les possibilités du moteur étaient assez limitées, Scriptopathe eut l'idée (il fallait y penser, bien sur !) de reprogrammer tout le moteur afin d'en faire un qui répondrait aux exigeances du concept.
Kriss et lui élaborèrent alors pendant plusieurs mois un mini (mais vraiment mini) cahier des charges, puis Scriptopathe re-coda le moteur entier, et créa un autre éditeur, afin d'obtenir ce que vous voyez maintenant dans les vidéos. Pendant ce temps, Kriss étayait encore le concept et se chargeait des graphismes.
Durant cette période, de nombreuses personnes ont participé occasionnellement au projet, des personnes entrèrent et sortirent (ces personnes sont citées le post de présentation).
Le compositeur de talent Spiky (Site web ici), rejoint alors l'équipe, remplaçant Roys, qui avait lui aussi fait un excellent boulot, et apporta son lot de contributions à l'ambiance et même au Gameplay.
Emmanuel rejoint ensuite l'équipe et fit accélérer la phase de Design (des niveaux, des ennemis etc...), et insuffla ses idées dans le projet, dont les concepts furent affinés.
D'autres personnes comme froGgy, continuent de suivre le projet, et de participer occasionnellement, ne pouvant pas intervenir de manière régulière pour des raisons personnelles (boulot etc...).

Aujourd'hui, où en sommes-nous ?
Roys, ancien compositeur de l'Usine en Folie, qui est surtout un programmeur, développe, avec Gaetz, un ensemble d'outils, répondant sous le nom de Geex Suite, qui permettent, entre autres, le développement de jeux compatibles PC et Xbox 360.
La partie intéressante (pour l'Usine en Folie), est GeexRun, qui est une bibliothèque de classes semblable à RGSS, mais pour le langage C#, donc, beaucoup plus rapide que Ruby.
Et donc, sous l'influence de Roys, Scriptopathe se mit en tête de recoder (encore une fois !) l'Usine en Folie, en C# cette fois-ci, afin d'avoir de meilleures performances et une compatibilité PC/Xbox 360.
Kriss prépare, pendant que Scriptopathe programme le coeur du moteur de jeu, un cahier des charges complet, qui va permettre de développer correctement le Gameplay du jeu, et d'y porter des améliorations !

Voilà où en est le projet aujourd'hui ! Des news sur le portage vers Xbox 360 devraient arriver bientôt !

Deux mots sur le Gameplay !

Les grandes lignes
L'Usine en Folie est un jeu qui mêle stratégie, plateformes, et tir.
Les casses-tête sont au rendez-vous, ainsi que les séances de tir bien bourines sur des ennemis totalement révoltés, ainsi que des séquences plateformes où la précision est de mise.

Les armes
L'Usine en Folie comporte tout un panel d'armes améliorables au fur et à mesure du jeu.
Chacune de ces armes comporte plusieurs "versions" appelées upgrades, qui se débloquent en investissant des rouages dans l'arme. Ces rouages peuvent être récupérés, cependant, vous n'aurez plus accès aux upgrades que vous avez délaissées (jusqu'à ce que vous réinvestissiez vos rouages dedans quoi)...
De plus, le fait d'investir des rouages dans une arme, en plus de vous permettre de débloquer des upgrades, permet l'augmentation du niveau maximal de ses caractéristiques (munitions, cadence de tir etc...). Une fois ces niveaux débloqués par l'investissement de rouages, il est possible d'acheter, via des fragments (récupérés en général sur les ennemis), des points de caractéristiques, jusqu'à atteindre le niveau maximal de la caractéristique pour un nombre de rouages investis donnés.
Exemple : J'ai investi 3 rouages dans la Gatling, je débloque sa capacité de double tir. En plus de ça, je peux augmenter encore plus ses munitions maximales, en les achetant grâce à des fragments.
Une vidéo vaut mieux qu'un looong discours :


Les armures
Les armures permettent de réduire les dégâts causés par des tirs, des chocs électriques, des explosions ou autres. Chaque armure défend bien contre certains types des dégâts. Par exemple une armure en caoutchouc rendra insensible aux chocs électriques, mais Géo sentira passer les balles ou les explosions !

Les équipements
Il existe dans le jeu des équipements tels que le Jetpack, les Bottes, le Scaphandre, et bien d'autres qui permettront à Géo d'accéder à de nouvelles zones grâce à des actions comme le double saut, ou bien en nageant sous l'eau, etc...

Les alarmes
Faisant partie intégrante du Gameplay, les alarmes sont des dispositifs à éviter à tout prix et qui enverront à vos trousses des hordes d'ennemis robotiques assoiffés de sang...

Les ennemis
L'Usine à la base, n'est pas un endroit qui nécessite d'énormes quantités de robots agressifs, au contraire, tous les robots sont à la base inoffensifs. Ces robots ont leur comportement inscrit sous forme de programme contenu dans des cartes magnétiques perforées.
Cependant, l'Ordinateur envoie d'autres robots afin de remplacer les programmes de ces robots, et de les rendre agressifs. Ainsi, plus Géo progressera, plus l'Ordinateur rendra ses robots agressifs, et il ira même jusqu'à créer des robots exclusivement pour DETRUIRE !!

Une petite vidéo de la démo technique d'Octobre 2010 :



Voilà pour aujourd'hui !

mercredi 1 juin 2011

Courte présentation du scénario du projet...

Étant donné que ce blog concerne le développement d'un jeu, il serait en effet bien de... présenter un minimum le jeu en question !

Sypnosis
Vous êtes Géo, un simple agent de maintenance d'une gigantesque cité autonome, nommée "l'Usine".
Votre rôle consiste à surveiller et réparer des installations pour le bien de toute la communauté de l'Usine
Pendant un contrôle de routine, vous faites un mauvaise manipulation sur un générateur et c'est le drame : pendant quelques instant vous avez privé de courant une partie de l'Usine.
Vous entendez des explosions violentes, le sol tremble, une fois le courant rétabli vous ne pouvez plus activer les ascenseurs : le système de sécurité s'est enclenché et vous êtes considéré comme un intru !
Vous apprendrez vite que le coeur de l'Usine,  l'Ordinateur central, s'est retourné contre les humains.

Comme si cela ne suffisait pas, vous devrez fuir devant un cobaye qui s'est échappé de sa cellule, le Singe Némésis.
En dépit de votre courage, s'il vous touche vous serez atteint de macacophilie, votre corps et votre âme régresseront au stade de nos ancêtres les macaques et l'Usine sera perdue

L'Usine
L'objectif de l'Usine est d'améliorer le genre humain.
C'est un immense complexe constitué de labyrinthes de couloirs, d'ascenseurs et de salles.
Il est dit que l'Usine s'étend jusqu'aux centre de la Terre où elle puise son énergie et seule une élite est autorisée à accéder à la majorité des niveaux.
L'Usine est si vaste qu'il y a des niveaux abandonnés et d'autres où planent des mystères.
Un Conseil administre l'ensemble des habitants (les Factorien) en les éduquants et en usant de propagande intensive pour "leur bien"


Les personnages principaux
Géo 
image
L'agent de maintenance XRQ3, nommé "Géo" a pour tache de réparer et entretenir les innombrables machines de l'Usine. C'est le personnage principal, c'est VOUS.
Depuis quelques temps il s'inquiète de leurs dysfonctionnements.
Il se rend à un des générateurs vieille génération, pour faire un diagnostique, mais une fausse manipulation le surcharge momentanément et toute l'usine se retrouve alors dans le noir.
Des machines semblent avoir souffert de la surtension et les système anti-intrusion s'enclenche quand Géo désire revenir à la surface
Notre héros apprend alors que l'Ordinateur central a perdu les pédales, et décide de rejoindre une équipe de maintenance pour réparer les dégâts.. mais tout ne se passe pas comme prévu.



Newman 

imageGrosses lunettes, coupe au bol : l'archétype du sex-symbol.
C'est un scientifique tres intelligent qui connait beaucoup de choses sur l'Usine et il ne se fait pas prier pour déballer son "savoir".
Il est un ancien ami d'enfance de Géo et le chaos engendré par la folie de l'Ordinateur va les rapprocher dans un objectif unique : sauver l'Usine
Il seconde Géo en lui montrant comment éviter les pièges. Etant pourchassé par une malchance aussi grande que son bagou, il finit inévitablement par se prendre un piège lors de ses explications.
Il a toutefois une intéressante capacité. Il réapparait toujours au bon moment pour vous épauler.

L'Homme En Blanc
image
L'homme en blanc : Il est le grand patron de l'usine depuis des siècles, nul ne connait son age et l'aura qu'il dégage est celle d'un dieu vivant. L'usine est née avec lui, elle partira avec lui.
C'est une icône que peu de personne ont vu de près, il cultive le mystère tout comme ses objectifs pour l'Usine.
Les rumeurs les plus folles circulent depuis des décennies : il pourrait être mi-homme mi-machine.






Les Factoriens : la communauté de l'Usine


LE CONSEIL :il est constitué des représentants des habitants. Ils sont les seuls à côtoyer l'HEB et décident avec lui de la politique de l'Usine : quoi faire et comment.
Le conseil a instauré des règles strictes pour la prospérité de l'Usine et de ses habitants.
Le travail avant tout, du repos un toit et à manger pour tous et pour rémunération : la satisfaction de servir les intérêts de l'Usine.
Tout loisir est banni ainsi que les choses "inutiles" comme les arts (peinture/écriture), le chant est toléré pendant les heures de travail si c'est un des hymnes de l'usine (glorifiant le travail évidemment)

ACTIFS
Ce sont tout les humains qui travaillent pour l'usine:
- Scientifiques : les cerveaux de l'Usine qui élaborent de nouvelles technologies pour le bien des habitants de l'Usine. Leurs labos regorgent de gadgets délirants qui pourraient bien aider Géo dans sa mission
- Ingénieurs : ils font tourner l'Usine grace aux diverses machines qui l'a compose. Ils peuvent donner des conseils précieux pour peu qu'on soigne leur égo.
- Factoriens : pour la bonne marche de l'usine il faut des agents de maintenance, cuisinier, nettoyeurs, tout ce beau monde vie et contribue à épanouissement de la communauté.


Les... MÉCHANTS !!

SINGE NEMESIS
"La mort subite"
Il s'agit du singe atteint de Macacophilie se promenant dans l'immeuble, après la panne de courant, sa cellule s'est ouverte et il est parti en quête de bananes.
Le Singe Némésis n'est pas un méchant en soi.. il désire juste jouer avec des gens à son jeu favori : "pousse-pousse"
Je te pousse, tu me pousse et le 1er qui tombe a perdu ....
Malheureusement le simple contact du singe entraine la contamination du virus de macacophilie:
Le malheureux se transforme petit à petit en macaque et régresse au niveau des primates.
La "bonne" nouvelle c'est que ceux ci ne sont pas contagieux..
Si Géo se fait toucher, c'est la fin de l'Usine..ne l'oubliez pas !



ORDINATEUR CENTRAL


C'est le moteur de l'Usine, il gère les installations du complexe, il est utilisé pour faire des calculs complexes pour la recherche.
il est chargé de contrôler les allées et venues, traquer les espions industriels.
Au départ ce n'était qu'un immense calculateur dénué de conscience, mais l'équipe de chercheurs a recréé une intelligence artificielle à l'aide de machine à bande magnétique et à cartes perforées
Cette nouvelle conscience devait le rendre plus performant et autonome..mais il a acquis aussi un aspect humain: la peur de mourir.
Apres une panne d'énergie il est devenu fou et paranoïaque.
Il est maintenant un danger pour l'Usine et ses habitants (Actifs et Inactifs): vous devez tout tenter pour le réinitialiser

DROIDS

La conseil a mis en place des Gardiens sans état d'ame et serviles : des droids, robots et automates.
Mais ces robots ont aussi des taches particulières à faire, certains sont polyvalents.
Ils sont reliés à l'Ordinateur ils vous mettrons donc des batons dans les roues pendant votre périple.

Dans ce post il n'est fait question que du scénario. En effet, des parties du Gameplay sont encore en cours de re-réflexion, et on attend un cahier des charges définitifs afin de le dévoiler.

mardi 31 mai 2011

Inauguration du blog de développement !

Bonjour à tous !
L'équipe de la Factory est fière de vous annoncer l'ouverture d'un blog qui va présenter l'avancée du développement de l'Usine en Folie, et éventuellement les problèmes rencontrés et (surtout) la solution qu'on a trouvée à ces problèmes, ce qui peut être très utile pour nos confrères développeurs.

Présentation du noyau de l'équipe :
- Kriss : Game-Designer, Level-Designer, Scénariste, Graphiste. C'est en partie lui qui va prendre des décisions concernant le Game Play, l'aspect général du jeu, l'organisation des maps (ce qui est une tâche des plus difficiles) et le Scenario. Il est à l'origine du concept de L'Usine en Folie.
- Scriptopathe : Game-Designer, Level-Designer, Programmeur. Il s'occupe avec kriss de prendre les décisions concernant le Game Play. De plus, c'est lui qui s'occupe de coder toutes les merveilles que vous pouvez voir dans le jeu, et qui crée les outils de développement (éditeur, etc...). Il est à l'origine du moteur qui permet à l'Usine en Folie d'exister.
- Manu : Game-Designer, Level-Designer. Bien que disponible uniquement dans certaines périodes, il contribue activement à l'amélioration du jeu en proposant des idées bien construites au niveau du design du jeu et des niveaux.
- Spiky : Compositeur de talent, c'est lui qui s'occupe des créer les musiques et effets sonores du jeu.

A venir :
- Nuki, Raho : développeurs de l'intelligence artificielle du jeu.

D'autres personnes ont également participé au projet mais ne font pas ou plus partie de l'équipe :
Atom, Arvester, FroGgy, Oyboy, Kriss, Jack*RED, 2deTens, Krän, Le6barbare, Roys et Joke.

Bientôt des nouvelles, ainsi qu'une présentation du jeu !