[W.I.P] Moon[s] 20.62

Avatar de l’utilisateur
ZJP
Messages : 5301
Inscription : 15 Déc 2009 06:00

[W.I.P] Moon[s] 20.62

Messagepar ZJP » 03 Fév 2013 18:29

Image

Salut,

Moon[s] 20.62 est un Simulateur de vol/TPS (Une option permettant le contrôle des unités à partir d'un périphérique mobile - sous Android - est prévue) à Campagne Dynamique dont l'action se déroule en 2062 sur des lunes très éloignées de notre Système.

Genèse du projet.

Le projet prend sa source de ce que je considère comme un des meilleurs jeu vidéo de l'histoire : Falcon 4 (et 3) grâce à un principe fondamental qu'il y introduit : la Campagne Dynamique (Le réalisme -incontesté- du modèle de vol de Falcon n'est pas a prendre en cause de mon projet.) :

WikiPédia :

Scriptée ou dynamique
Selon les jeux, chaque mission n'influence pas – on parle de campagne linéaire ou scriptée – , peu ou complètement la progression scénaristique – on parle alors de campagne dynamique. Des exemples connus de campagne dynamiques sont : Falcon 4.0 dont l'évolution de la campagne dépend du degré de réussite du joueur, Apache Havoc ou encore dans le domaine de la stratégie Europa Universalis qui est un mélange de données scriptées (évènements historiques) et données aléatoires (les pays contrôlés par l'ordinateur pouvant agir différemment d'une partie à l'autre).
Ce concept n'est toutefois pas très répandu pour une question de performance de l'IA et de difficulté à concevoir et réaliser plusieurs lignes scénaristiques.


Ce type est campagne est EXACTEMENT ce qu'il faut pour introduire une notion toute récente et très populaire des jeux vidéos actuelle : Le "crafting".
En effet, il n'est pas question ici comme dans les RTS de concevoir ex-nihilo des armes/habitations/avatars à partir de...magie ou de ressources, le tout en quelques secondes. Désolé pour les amateurs du genre, mais c'est clairement ce type de GamePlay qui m'a éloigné de la plupart des jeux à succès sortis depuis 15/10 ans.

Le déroulement d'une Campagne de M[S]2062 (et donc du GamePlay ) est le suivant :

a) Le serveur de jeux crée au début de la Campagne un nombre plus ou moins équivalent (pour les deux camps) de :

- D'avatars (personnages) avec des caractéristiques individuelles (Noms - matricules car les avatars sont des robots humanoïdes commandés à partir de bases Terrestres (Il faut bien trouver une excuse aux futurs "lags" et autres bugs d'IA) -,compétence etc,,)

Je reprend ici des explications d'un autre message (sur un autre forum) pour le choix de Robots.

ZJP a écrit : Donc, les robots, car le joueur – humain – les commande grâce à une liaison, sub-spaciale" à partir de bases terrestres. Ce qui sous-entend des satellites en orbite autour de la lune ===> Avantage : une meilleure gestion des "rooms" du moteur réseaux (secteurs), GamePlay étendu (possibilité de pirater un robot adverse etc.. etc...) ... ;)

- Je n'ai aucun problème moral a faire un "Head Shoot" sur un avatar robot.

- Quand l'IA d'un avatar humain dysfonctionne (exemple, persistance à vouloir allez dans un mur) c'est....un bug du projet. Quand un avatar robot fait la même chose, c'est un bug du robot. Normal et...acceptable.

- Campagne dynamique, monde persistant. Des avatars humains qui jamais ne dorment ou se nourrissent!! Ce n'est pas crédible. Cela implique modélisation (et gestion) de réfectoire/dortoir. Avec des robots on se contente d'alcôves de....rechargement.

- A la déconnexion du joueur humain, l'avatar peut poursuivre ses taches avec une IA minimaliste.

- Personnage à "dual-boot". Exemple un programme de réparation et un de combat. Le passage de l'un à l'autre prendra un certain temps. Disons 15 secondes pendant lequel....

- L'identification personnalisée des avatars humains n'était pas évidente. Trouver des noms/signalétiques/visages pour des centaines de persos!!?

Etc...etc...


- D'unités terrestres (Buggys / Tanks / Méccas(?) )

- Unités aériennes (DropShips de combat et de transport, autre.. voir MAJ)

- Personnages non joueurs mais très actifs, qu'il sera possible de "contrôler".

Les autres éléments du jeu (Tourelles diverses – radar, lance missiles, communication etc..-, accessoires, rochers et bases – Souterraines. Seules dépassent les puits d’accès par ascenseurs et/ou plateformes de lancement/atterrissages, les cheminées diverses etc.... Cette solution me permet de compenser les soucis de "Level Design" car placer des superstructures (bâtiments et autres) en surface n'est pas trop à ma portée. De plus, du point de vu développement cela permet de bien séparer la scène extérieure générale et les nombreuses bases souterraines. C'est aussi un bon "cloisonnement" pour les parties en réseau. Meilleure gestion des "rooms". Tout cela est justifié par l'environnement hostile où se déroule le jeu. Éléments figés à la conception du projet. EDIT : Voir messages suivants sur la décision de placer les structures à la surface.

b) Le joueur prend le contrôle d'un avatar (Robot) en se connectant à partir d'une base de communication Terrestre : Liaison "sub-spaciale" vers l'une des deux lunes du projet : La sableuse (première en cours) et l'autre constituée de 99% d'eau. Introduction alors la notion « spatiale (Espace) » du projet (allez d'une lune à l'autre) et de nouvelles unités maritimes. Nouvelle ressource : "le liquide" : Pas forcement le H2O.

c ) Au cours du déroulement d'une partie, le ravitaillement est assuré de deux façons :

- Arrivée régulière (ou pas) de navettes lourdes en provenance de la Terre. La fréquence de ces arrivées dépendra de la "richesse" (à partir de la production d’énergie) accumulée etc.. . Le "contenu" du ravitaillement est bien entendu laissé à la discrétion du joueur.

- Le "crafting" : récupération de pièces détachées et réparations sur place. Exemple. "Head shoot"» sur un avatar = bras, torse, jambes disponibles. J'attire l'attention sur le fait que TOUT les éléments restent sur place et ne se volatilisent pas une fois hors champ de la caméra. Ceci est FONDAMENTAL dans mon projet. Cela disparaît que SI enlevé par un autre joueur. C'est un fondement de la Campagne Dynamique.

d) Les missions sont diverses et non scriptées : Ravitaillement en armes et cellules d'énergie, protection de matériels en transit, protection des navettes (Terrestre ) de ravitaillement, transport de matériels et personnages d'un point à un autre. etc...


PS : la terme avatar revient souvent. Rien a voir avec le film éponyme, même si l'idée de la liaison entre eux et le joueurs semble démontrer le contraire. Un concept popularisé par un ouvrage (cinématographique en l’occurrence) très connu ne signifiant pas qu'il n'existait pas auparavant. L'idée de liaisons "interceptables" date de Stark Trek TNG et les fréquences des boucliers de la Fédération (un analyseur de spectre fera partie des outils des avatars). Les Trekkies comprendront ou apprécieront.




Moon[s] 20.62 déroulement historique (Scénario).

20.37
«ONU 2.0»

Les conséquences de la Grande Crise de 2009 se firent finalement ressentir à partir de 2021 quand l’Europe puis la Russie se déclarèrent en faillite laissant la gestion mondiale de l’énergie aux deux Superpuissances .
Le 4 novembre 2033 débuta ce qui sera appelé la «Guerre Privée». Elle dura 18 mois, faisant plus de 9 millions de victimes, essentiellement dans le pacifique Sud. Les quatre autres conséquences importantes du conflit allaient redéfinir le rapport de force entre nation :

- Les deux Superpuissances s’étaient complètement neutralisés au point que leurs armées n’étaient plus perçues comme dangereuses par les autres états.

- Le système monétaire mondiale subit une complète refonte faisant de L’ONU le banquier de la Planète et établissant le «Crédit» comme devise internationale.

- Les Nations Unies votèrent en 2037 sous la pression des deux protagonistes qui avaient conservés un poids économique non négligeable, la loi «Traidal» ( du sénateur Américain James V. Traidal ). Cette loi rendait illégale toute possibilité pour une nation de disposer d’une puissance militaire suffisante pour attaquer et/ou envahir une nation souveraine. Les états disposant alors à l’instar du Japon et de l’Allemagne au 20ème siècle d’une armée d’auto défense suffisante pour se protéger des groupes isolés et maintenir l’ordre publique.

- L’Organisation des Nations Unies voit son rôle renforcé et pour la première fois depuis sa création dispose de moyens politiques et militaires suffisants pour appliquer désormais toute les mesures jugées nécessaires à la préservation de l’équilibre mondial. Elle détermine aussi les choix et stratégies dans la recherche, l’exploitation et la diffusion des ressources énergétiques, les déplacements aériens (civils et militaires ) inter-nations, l’exploration Spéciale.
C’est l’ère des…..

20.42
Les «Corporations»

Afin d’ éviter des conflits comme celui de 2033, furent créées sous l’égide de l’ONU, des compagnies privées avec mandat d’exploiter et transporter l’énergie. Ces compagnies bien que disposant de moyens financiers colossaux étaient toutefois limitées tant qu’au nombre de leur personnel et moyens militaires à leurs dispositions. Il s’agissait que ces compagnies n’atteignent une «puissance» suffisante faisant d’elles un danger potentiel. De plus, elles étaient cantonnées aux spécialités terrestres ou maritimes. Les mandats d’exploitation concédés imposaient de fait l’association de deux compagnies (MER et TERRE). Des Corporations.

20.49
Le «Flux»

Le 13 Septembre 2049, l’ingénieur danois Jeppe N. Kristiansen suite à une manipulation malencontreuse lors d’un essai, ouvre un tunnel quantique entre le LHC (Large Hadron Collider) et l’orbite basse de Venus. Ce tunnel détruit la moitié du site entrainant la mise en place d’une zone de sécurité de plus de 120 kilomètres de rayon autour de l’installation. Cet « incident » est à ce jour la plus grande catastrophe industrielle de l’Histoire. Le recensement des populations souffrant de grosse lacunes depuis les années 30, le nombre exact des victimes est inconnu. Les dégâts sont en revanche estimés à plus 872 milliards de Crédits, soit en données corrigées des variations saisonnières l’équivalent de 1350 milliards d’Euros du début du siècle.

En moins de trois années, les recherches effectuées mirent en évidence que :

- Les tunnels s’ouvrent toujours dans la banlieue d’une planète à proximité d’un soleil. La température à la surface de l’astre semble être une donnée fondamentale pour l’établissement une liaison quantique stable.

- Le circulation bidirectionnelle de l’énergie et des matières non biologiques est possible. Les missions d’exploitations extra planétaire utilisant ce qui était depuis 2050 appelé le «Flux» nécessitait en conséquence l’emploi de mains d’œuvres robotisées.

- Le VLHC (Very Large Hadron Collider) dont la puissance était six fois supérieure à son prédécesseur permit une liaison entre la Terre et l’étoile la plus proche notre système : Alpha Centauri.

20.56
«AC 11-DP»

Alpha Centauri
11ème Planète
Désertique
Potentiellement riche en énergie

L’identifiant planétaire AC 11-DP fut le plus connu de l’époque. Bien que nettement plus petite que Vénus, son «EE» (Estimation Énergétique) était très largement supérieure. Presque toutes les ressources dont disposait l’ONU furent misent à contribution pour l’établissement d’un «Flux» entre la Terre et Alpha Centauri. Après cinq années de travaux titanesques, vint le moment d’en confier l’exploitation à deux compagnies :

- La PSC (Pluton Sea Corporation). Spécialisée dans les transport maritimes, elle a obtenue une dérogation lui permettant l’usage des moyens aériens de déplacement contrairement aux limitations imposées par la loi de 2042. Les compétences nautiques de PSC ont pesées dans la balance en vu de l’exploitation future de AC 12-MX.

- La ZPJ (Zantrad Petroleum Junction) . Bâtie sur les ruines d’anciennes sociétés du Pacifique Sud, ZPJ dispose d’une énorme expérience dans l’exploitation souterraine. On lui doit en outre, la création et la mise au point du RX-6211D : Le meilleur robot bio-commandé à ce jour.

20.62
«Divergence»

Un an après le début de l’exploitation d’AC 11-DP, un gave différent oppose Bruce «Nox» Sheridan le C.E.O de PSC et Zan Takkey Yimotsuki fondateur de la ZPJ.

[NDLR]
La découverte d’un artéfact serait la cause du conflit. Shéridan et Yimotsuki sont en opposition totale quand à la divulgation ou pas de cette découverte. L’un préférant la garder secrète de peur que l’exploitation ne soit confié à l’ONU, l’autre estimant que la preuve d’une vie humanoïde extra terrestre doit appartenir à l’Humanité.
[/NDLR]

Sur Terre, dans les stations de bio-connection s’engage une lutte pour empêcher ou divulguer l’information au public. Dans Alpha Centauri le conflit prend une autre tournure : Les deux factions suffisamment armées pour lutter contre les hostiles de AC 11-DP se lancent dans une entreprise de destruction mutuelle ……

«Pas de retraite et pas de reddition» J. Sheridan Babylon 5



Notes additionnelles

La collecte d’énergie

Les bases disposent de dispositifs de collecte et de traitement de l’énergie. Celle-ci, une fois en quantité suffisante est « transférée » vers une station orbitale (La même servant a générer et maintenir le «Flux») via des dispatcheurs. Ce qui occasionne de puissantes décharges énergétiques entre elles et la station ( sous forme d’éclairs ??!!) .

L’ID et compétences des avatars.

L’ID des avatars est constitué comme suit (Exemple ):
Carl « GX24C » Evdokimov
Série : 37 / Mise en service : 05/09/2055
Usine : Reykjavík


Le « nom » et le « prénom » sont de la même «ethnie» que leur usine de fabrication. Elles (usines) ont chacune leur spécialité. Les robots sortis de leurs ateliers sont donc plus ou moins qualifiés à certaines taches. Nom, matricule et prénom sont uniques.

Les compétences

Vol : Capacité de pilotage du matériel aériens
Conduite : Capacité de pilotage du matériel terrestre et gestion des tourelles
Combat : Capacité en défense et attaque au combat au sol.
Réparation : Aptitude à la réparation
Récupération/Crafting : Aptitude à la récupération des « pièces détachés »
Management : Aptitude au leadership dans la conduite d’une équipe. (Binôme, Trio, Quatuor). L’IA du projet regroupant les avatars par équipe dans la mesure du possible. Du point de vu GamePlay, l’élimination d’un chef d’équipe entraine une inertie de 3-5 secondes pendant lesquels les rescapés de la dite-équipe détermine le nouveau leader.

Les niveaux de compétence initiaux des avatars évoluent :
- Lorsque ils effectuent des taches.
- Un joueur les « pilote » (évolution plus rapide de 50%). Bien entendu, ceci est fonction du temps passé a contrôler un avatar.
- Remplacement de leurs OS par une version plus évoluée.

Les usines de productions jouent un rôle primordiale dans la capacité maximum «atteignable» par un avatar.
Les dates de fabrications et/ou série détermine la capacité d’un avatar a gérer plusieurs profils : Dual-boot
Les deux autres caractéristiques des avatars sont L’Hydraulique et l’Électrique (autonomie) .

Principe général du « pilotage » des avatars par les joueurs.

La prise de contrôle d’un avatar s’effectue à partir de stations Terrestres. Les liaisons passent par le «Flux» avant d’être redirigées vers des stations orbitales (dispatcheurs). Un joueur ne peut contrôler qu’un SEUL avatar à la fois. Tous les autres fonctionnent grâce à l’IA du projet.
Le passage d’un avatar à un autre entraine la déconnexion de l’avatar en cours qui poursuivra sa tache/fonction sous gestion de l’IA. Une latence de plusieurs secondes (3-4) est observée. Ceci, afin d’éviter le « syndrome du zapping »
Le joueur ne peut par sa prise de contrôle entrainer une efficacité de 100% de l’avatar qu’il dirige : Un modèle à 90% d’hydraulique aura les réflexes réduis de 10%.


Notes additionnelles.(Suite)

Après plusieurs mois (depuis janvier 2013) il est temps faire le point sur l’avancée du projet.

Premièrement, refaire le GDD (Game Design Document) car les informations et notes sont disséminées sous formes réelles (papiers) et numériques : je vais tout regrouper dans un beau et gros cahier acheté pour l’occasion ainsi que de nouveaux crayons, gommes, colle pour y mettre les documents imprimés etc.. La parfaite panoplie de l’écolier. Bien sur, je conserve aussi DES sauvegardes ( x 5) de TOUT ce qui est en rapport avec le projet (Ce message compris) .

J’ai visionné des dizaines de vidéos de jeux plus ou moins récents (Dishonored, Halo, Mass Effect, Crysis, PlanetSide 2, Hawken, Assassin Creed, C.O.D, Hawks etc.. – je suis devenu un « fan » de Naito75 et DaRkFuNeRaL972 -), lu des dizaines de forums, joué et terminé (c’est rare) FarCry 3, résultat :

Confortations :

Le mode FPS c’est le mal (sic). Cette vue renforce le « moi tout seul qui n’a pas besoin des autres », la vélocité du joueur est toujours exagérée et ne reflète pas les déglacement réels, sinon, les joueurs ont le « sentiment » de ne pas avancer. C’est un vrai souci, surtout que mon projet prévoyait un mode FPS/TPS sur Desktop combiné à un application RTS sous Mobile. Le joueur en FPS aurait forcement un avantage sur l’autre, à moins d’augmenter les vélocités du RTS. Pas crédible alors.
De plus, je prévoyais pour ce mode l’usage de la librairie Ultimate FPS Camera, mais, comme TOUT les outils s’appuyant sur le Character Controller d’Unity, il n’est pas possible (à ma connaissance et après moult recherches) d’utiliser celui-ci hors gravité : en d’autres termes, abandonnez l’idée de faire avec lui un Mario Galaxy, le déplacement autour d’une sphère/monde est problématique.
Bonne nouvelle finalement. D’une, je ne suis pas un grand fan des FPS (Wolfenstein 3D, Doom 1, Quake 1, Duke Nukem, Unreal Tournament 1999, Battlefield 1943, Hidden and Dangerous, Farcry 1), de deux, cela m’a «forcé» à mettre un peu plus de moi-même (question coding) dans ce projet, très bon pour l’égo.

Le MMO (voire le multijoueurs) c’est le mal (sic). Ce mode renforce le « moi tout seul qui n’a pas besoin des autres »(bis) très préjudiciable dans un projet où la coopération est… « exacerbée ». Moon[s] est carrément un projet élitiste (la documentation sera plus épaisse que celle d’un C.O.D ou d'un Hawks) conçu comme une partie d’échecs de longue haleine (campagne dynamique) entre deux (ou binômes de ) joueurs.
J’ai littéralement halluciné en découvrant un mode «Suicide» dans PlanetSide 2, entendez par là, la possibilité pour le joueur de trucider son personnage y compris pour des raisons aussi futiles que « j’ai pas envie de marcher jusqu’au prochain poste/base etc…) Woaa !!!!. On en est là dans les jeux modernes ?!! Intérêt de personnaliser aux petits oignons son avatar pour le sacrifier sur l’autel du « Casualing » ??!!!!. Il se dégage de ces multis un sentiment de forte consommation/zapping, un « Rien à fiche, j’en ai plein d’autres (persos, matériels, ressources etc…) » . Beurk !!!!!!.
Finalement, le choix de robots est une idée lumineuse : une auto destruction de ceux ci est plus…morale, sans parler de l’intérêt stratégique. Self Destroy au beau milieu d’un groupe d’ennemis, à l’intérieur d’une base, ou pour éviter la récupération de son « savoir » etc…. De plus, mettre au point un bon système anti-tricheurs est long et compliqué. Donc…finalement, l’idée de deux frangins affrontant deux autres « potes » est jouissive.

J’ai abandonné l’idée de bases souterraines, solution qui avait pour avantage de contourner mes faibles compétences en « Level Design » et de cloisonner la gestion du réseau en « Room » réelles et virtuelles : La version mobile du projet aurait permit aux joueurs de participer à l’affrontement uniquement dans ces lieux isolés du reste car le moteur procédural Etherea(*) ne fonctionne pas sur ces plateformes. De bons avantages, mais, la conséquence primordiale est une absence de vie (moins en tout cas) sur le sol. Pour la partie mobile, je m’oriente vers une gestion de zones de combats autour des édifices dorénavant en surfaces. Une vue/gestion RTS fait l’affaire, ces infrastructures se trouvant dans de vastes plaines.

Travaux et recherches actuels

Le H.U.D (Véhicule et Robot) est d’une importance capitale : je prend le temps car il sera LE visuel du jeu. Inutile de dire que j’en ai ingurgité de la documentation/vidéo (Jarvisss !!!) la dessus. Waoo... les templates sous Adobe After Effect...

Les sigles et abréviations se renforcent, exemple : le P.T.I (Proximity Target Informer) ou D.T.I (Distance Target Informer) des variations du HUD de « tracking », ou le F.A.A.B (Flying Armed Autonomus Bot) - Un truc comme cela-. Cet engin m’a été inspiré par le système Dragoon du Providence de Raw Le Creuset dans Gundam Seed (mon Manga préféré). Le film Oblivion me conforte en cela, le F.A.A.B étant un « mix » des deux usages. C’est lui qui fait par exemple le lien entre un DropShip civil et un militarisé. Bien sur, il sert à la défense rapprochée des bases. Mon ami Google confirme que ces sigles n'existent actuellement pas.

Je caresse l’idée d’un Blog (j’ai déjà l’hébergement). Comme vous le « voyez » , ce projet suit son cours..

(*) Etherea.

Si utiliser un moteur procédural peut paraitre à la base facile et sembler tout résoudre du point de vu de la conception du «Terrain», dans la pratique, pour un projet comme Moon[s] on est très loin du compte.
En effet, en dehors des soucis habituels rencontrés quand on utilise une librairie externe (mise à jour, bugs, réactivité du développeur etc..), il faut aussi s’adapter aux limitations intrinsèques de ce genre de produit : Les élévations (altitudes) ET collisions ne sont gérées qu’autour de la Caméra Principale. Au delà d’un certain rayon, le terrain est plat et il n’y a plus de «Collider». Augmentez ce rayon et la consommation mémoire s’envole ( je parle en giga !!!), processeur et GPU sont littéralement à genoux.
Cette librairie (comme les autres) parfaite pour du solo (Marche, vol, « drive » etc.. Cela dit, pour un MMO/Multi pourquoi pas, si il n'y a aucun NPC) n'est en aucun cas adaptée à une situation où l’on gère des centaines d’objets à vélocités (Robots, véhicules, NPCs etc..) repartis sur la surface d’un monde : ils passent à travers le sol et les élévations montagneuses qui sont présentes à l’approche de la caméra mais, disparaissent dans les autres cas. Pas évident dès lors, de concevoir un projet à Campagne Dynamique dans ces conditions. J’ai trois ou quatre solutions à explorer.

Note à propos d’Etherea (Octobre 2014)
Etherea est actuellement un produit abandonné par son concepteur (fin 2013). Gros moment de solitude lors des essais avec une "bêta" d'Unity 5. Du violet PARTOUT!!! ( :? ). Du coup, j'ai remis la main dans le cambouis (comme pour le passage à la 4.3.x d'Unity mais en pire... . Si je n’avais pas fais Moon[s] serait mort à la sortie d'Unity 4.3.x). Le résultat est probant, car j'ai réussi un mixte des vieux "Vertex Shaders" qui comportaient un effet de brouillard/fog sympathique et des "Surfaces Shaders" (vraiment pourris et buggés qui ont précipités l'abandon du projet par son concepteur).
Ça va, cela fonctionne aussi sous Unity 5.x. Tout est stable et actuellement je suis quasiment (99.9%) que si "memory leak" il y a (ou aura) cela ne provient pas d'Etherea version ZJP.


Notes additionnelles (suite)


Emport et la consommation Électrique du personnage.

Ce qui suit ne devrait pas vous surprendre si vous connaissez « l’esprit ZJP »
La possibilité pour le joueur de transporter (dans des bagages invisibles bien sur), des tonnes de matériels sans incidence pour sa mobilité/vélocité me semble de nos jours aberrante. Dans FarCry 3, le port d’un pistolet, fusil d’assaut, lance roquette, un « snipper » (le tout en full munitions), des mines , des explosifs, le « crafting » en même temps n’a aucun impact sur la…souplesse de Jason Brody qui se déplace toujours avec l’aisance d’un surfeur professionnel en maillot de bain. J’ai sans doute la critique facile, mais en tant que joueur, c’est frustrant. (je ne parle pas de l’option « voir-à-travers-les-obstables-comme-les-cheats-codes-d’avant. Comment « officialiser» la tricherie) …

Dans Moons[s] les emports sont limités par la :
- La MPA (Magnetic Payload Area - Zone magnétique de charge utile) principale (La "zone de warning" au dos du personnage) , capable de transporter trois (3) charges utiles simultanées : Lance roquette, fusils divers, groupe de chargeurs (Tomb Raider, le film), roquettes, parties de « crafting ». Bien entendu, un « JetPack» dorsal occupe toute cette place. Voler ou porter il faudra choisir…
- La MPA secondaire, sur le cuisse droite du perso. Réservée uniquement à l’arme de poing.
- Les «mains» du personnage. Hé oui...

Qui dit magnétique dit aussi consommation d’énergie, donc, la puissance nécessaire pour « verrouiller » un « Jetpack » est sans commune mesure avec celle suffisante pour une boite à munitions.

« Heu, comment ton truc fait pour s’avoir qu’il a tel ou tel élément dans le dos ? ».
« Facile… » TOUT les éléments dans Moons[s] disposent d’un puce sans contact qui permet son identification (genre et numéro de série). Cette puce/tag est aussi présente dans toute les parties d’un Robot, reliées entre elles par un Bus jusqu’au CPU du système. Elles sont désactivées par défaut ( pas question de critiquer les options « voir-à-travers-etc.. » des autres et transformer les protagonistes du camp adverse en balises ambulantes). Un coupure du Bus (membre sectionné) l’active (la puce/tag semi-active - voir les documentations sur le RFID-), ce qui permet de retrouver les éléments disséminées sur le terrain (crafting). Personnages, FAAB et Véhicules sont équipés de lecteur permettant cela. Bien sur, le lecteur des véhicules est plus performant que celui du FAAB, lui-même meilleurs que celui des Robots. Comme pour nos Smartphones actuels, l’OS permettra de connaitre la consommation des diverses zones de MPA ainsi que du reste.

Notez, que la température extérieure joue un rôle directe sur les divers performances énergétiques de l’ensemble (du personnage) : un déplacement en zone « sombre » (Vision Nocturne de mise) du monde aura un bilan énergétique plus favorable que dans la zone (très) ensoleillée. Normal…


Notes sur le déroulement d’une campagne (bis)

AC 11-DP, la lune où ce déroule l’action de Moon[s] est pour des raisons contractuelles partagée de la façon suivante :
Le Nord sous le contrôle de PSC (Pluton Sea Corporation) et le Sud attribué à la ZPJ (Zantrad Petroleum Junction). Chacun de ces hémisphères est constitué de 4 zones abritant chacune onze (11) bases d’exploitation, soit 44 bases par camp pour un total de 88.
Ces bases portent le nom de Constellations – Nom (Indicatif) -:

Andromeda (And), Antlia Pneumatica (Ant), Apus (Aps), Aquarius (Aqr), Aquila (Aql), Ara (Ara), Aries (Ari), Auriga (Aur), Bootes (Boo), Caelum (Cae), Camelopardalis (Cam), Cancer (Cnc), Canes Venatici (CVn), Canis Major (CMa), Canis Minor (CMi), Capricornus (Cap), Carina (Car), Cassiopeia (Cas), Centaurus (Cen), Cepheus (Cep), Cetus (Cet), Chamaeleon (Cha), Circinus (Cir) ,Columba (Col), Coma Berenices (Com), Corona Australis (CrA), Corona Borealis (CrB), Corvus (Crv), Crater (Crt), Crux (Cru), Cygnus (Cyg), Delphinus (Del), Dorado (Dor), Draco (Dra), Equuleus (Equ), Eridanus (Eri), Fornax (For), Gemini (Gem), Grus (Gru), Hercules (Her), Horologium (Hor), Hydra (Hya), Hydrus (Hyi), Indus (Ind), Lacerta (Lac), Leo (Leo), Leo Minor (LMi), Lepus (Lep), Libra (Lib), Lupus (Lup), Lynx (Lyn), Lyra (Lyr), Mensa (Men), Microscopium (Mic), Monoceros (Mon), Musca (Mus), Norma (Nor), Octans (Oct), Ophiuchus (Oph), Orion (Ori), Pavo (Pav), Pegasus (Peg), Perseus (Per), Phoenix (Phe), Pictor (Pic), Pisces (Psc), Piscis Austrinus (PsA), Puppis (Pup), Pyxis (Pyx), Reticulum (Ret), Sagitta (Sge), Sagittarius (Sgr), Scorpius (Sco), Sculptor (Scl), Scutum (Sct), Serpens (Ser), Sextans (Sex), Taurus (Tau), Telescopium (Tel), Triangulum (Tri), Triangulum Australe (TrA), Tucana (Tuc), Ursa Major (UMa), Ursa Minor (UMi), Vela (Vel), Virgo (Vir), Volans (Vol), Vulpecula (Vul)

(Techniquement Moon[s] 20.62 pourra se jouer à 88 joueurs maximum.)

Le nombre de «servants» (Robot RX-6211D ) par base est de 12 (16?) unités (528 (704?) par Compagnie). Leurs rôles en dehors de tout ordre donné par le joueur est d’assurer :

a) L’approvisionnement des tourelles lance-missile utilisées contre la chute de météorites

b) L’approvisionnement des tourelles de 50mm dont l’objectif est la défense de la base contre le principal hostile terrestre. (voir ce pack: . Bonjour l’ambiance…). Bien entendu, missiles et munitions proviennent d’un Dépôt (* voir Infrastructure)

c) Le « Crafting ». La récupération des parties intactes des avatars à l’aide du « Crafteur(* voir Véhicules ) » et la conduite de celui ci vers l’Atelier de Montage (* voir Infrastructure)

d) Le passage régulier à la station de Régénération (* voir Infrastructure )

La règle primaire de survie est donc : « Ne jamais laisser ses tourelles vides »
Sans joueurs et autres ordres/consignes, nos Robots sont de gentils Sims vacant à leurs occupations.


Prise de contrôle du joueur.


Une fois le camp choisi (PSC ou ZPJ) à partir d’une des 8 (16) stations Terrestre, le joueur est "routé" vers une des (88) bases d’exploitation via un Dispatcheur Orbital (* voir Infrastructure). A partir ce cet instant, il est possible de « passer » d’un Robot à l’autre dans un processus de connexion qui est plus rapide que la liaison initiale. Entre 2-3 secondes.



Infrastructure (Jetez un œil à ce message est vous aurez une idée de « qui » fait quoi : )


a) Le Générateur : Il fourni l’énergie électrique à l’ensemble de la base

b) L’ « Émetteur » : Il envoie l’énergie captée par le Collecteur vers le Dispatcheur Orbital, qui a son tour fait suivre vers le «Flux»

c) Le Collecteur : puise dans le sol de la lune l’énergie primaire. Celle-ci est transférée en partie vers le Générateur qui la converti en puissance électrique. Le reste de la collecte est dérivé vers l’Émetteur.

d) La station de Commandement et de Communication.

e). Les Hangars/Dépôts/Entrepôts

f) La station de Régénération : Elle permet la recharge des Robots

g) L' Atelier de Maintenance/Réparation. Ce local reçoit la collecte des pièces détachées et lance les opérations de reconstruction des Robots. Un mot pour dire que ce processus est soit basique (assemblage au fur et à mesure, plus rapide) ou optimisé (recherche des meilleurs éléments pour reconstituer le meilleur Avatar possible. Plus lent) à la discrétion du joueur.


Véhicules Terrestres.


a) Le Buggy léger : Rapide, mais fragile. Un conducteur et un passager

b) Le « Transporteur » : Lourd, lent, non armé, il permet de déplacer matériel et Avatars. Un conducteur, jusqu'à six passagers.

c) Le « Crafteur » : Cet engin lent, est équipé d’un « Aspirateur Magnétique » implanté sous le châssis. Les pièces détachées sont donc aspirées et stockées dans le « Crafteur » jusqu'à la livraison à l’Atelier de Maintenance. La destruction d’un Crafteur entraine la perte de TOUT les éléments entreposés. De manière générale dans Moon[s], la destruction d’un véhicule signifie la perte de(s) passager(s) et de son emport.

S’il n’y à pas de véhicules terrestres lourdement armés, c’est voulu. Moon[s] est avant tout une Simulation de vol et le joueur devra assurer la protection des éléments mobiles grâce aux Dropships.



Véhicules Aériens.


a) Le F.A.A.B (déjà évoqué)

b) Le Dropship Armé : Équipé de missile et de canon, c’est la plaque tournant de la défense.

c) Le Dropship de Transport : Lent est non armé , il assure le même service que son homologue terrestre. Plus véloce bien sur que celui-ci.

d) La Navette de ravitaillement : Elle vient directement de la Terre avec le matériel commandé par la Compagnie (par le joueur). La commande dépend bien sur des crédits accumulés (exploitation) et des disponibilités. Il n’y a par exemple qu’une cinquantaine de RX-6211D en réserve et ils sont hors de prix. D’où l’importance du « Crafting». La Navette quitte son orbite pour un atterrissage quasi à la verticale de la base de destination. Le joueur est responsable de l’approche et du lieu final de l’atterrissage. Il est possible de dérouter une Navette vers une autre base si l’actuelle est sous le feu de l’ennemi. Cette décision comme d’autres n’est possible qu’a partir d’un pupitre de la station de Commandement et de Communication. Les Navettes sont d’une solidité extrême. En réalité, la seule façon d’en venir à bout est d’utiliser l’Émetteur d’énergie qui est orientable mais calibré par défaut vers un Dispatcheur.



Note à propos de la Base « Standard Navigation Way » (SNW).


Au départ, elle s’appelait la SNP « Standard Navigation Path », mais l’expression étant utilisée par Oracle, j’ai préféré utiliser (ou en inventer ?) une autre, inconnue de…Google.

SNW: Kézako ?

La SNW intègre au début d’une partie/campagne toutes les routes reliant les bases amies entre-elles. En effet, avant le déclenchement du conflit nul besoin d’aller chez le concurrent, ressources et moyens étant équitablement répartis. Les Robots d’un camp n’effectuaient jamais de périples chez le concurrent. Les choses changèrent après la « déclaration de guerre » : Il devint alors nécessaire de procéder à des incursions chez l’ennemi et donc de mettre à jour la Base SNW. Le postulat étant :

a) Pas de déplacement des Robots et des FA.A.B sans SNW.

b) Seul un joueur (pilote humain en « remote ») peut créer (enregistrer) une nouvelle SNW. Ce qui implique l’obligation pour celui-ci d’explorer le terrain.

c) N’importe quelle « mobile » ( Robot, DropShip, Transporteur Aérien, Crafteur) peut être utilisé pour enregistrer une SNW. Toutefois, la capacité de mémorisation dépend du « mobile » utilisé : Les Robots ont une faible capacité de stockage, les Crafteurs en revanche disposent d’un maximum de mémoire pour ce genre de tache.

d) Les SNW nouvellement créées doivent être téléchargées au Centre De Communications pour être ensuite transférées à l’ensemble des Robots d’une base lors d’une séance de rechargement/régénération.

e) Les SNW peuvent être récupérées par l’ennemi lors de la capture d’un Robot/Mobile adverse.

Le « pathfinding » et l’IA utiliseront donc la Base SNW.
Dernière édition par ZJP le 19 Mars 2016 22:08, édité 3 fois.
"ça peut bugger mais ce n'est pas du à un bug. Subtile nuance... :mrgreen: " ZJP

Avatar de l’utilisateur
ZJP
Messages : 5301
Inscription : 15 Déc 2009 06:00

Re: Moon[s] 20.62

Messagepar ZJP » 03 Fév 2013 18:30

Notes additionnelles (Octobre 2014):

LES NPCS

L’idée originale pour ce modèle était d’utiliser un sorte de dragon ou "machin-volant-plus-ou-moins-fantastique". Mais à la réflexion, ce n’était pas très sérieux. Syndrome de MMO/RPG/Médiéval en vu. De plus, j’aurai vite atteint la limite du choix du modèle ainsi que les animations adéquates. Pas si évident de trouver l’oiseau rare dans un panel très orienté MMO justement.
Finalement j’ai (comme souvent) transformé mes lacunes en avantage : ce sera une nuée "d’insectes lumineux" dont les contacts provoquent le dysfonctionnement de TOUT appareil électrique. Non seulement je garde le contrôle des animations et des mouvements de ces nuées ( voir Boïd), mais il existe des outils assez sympas pour réaliser cela (Particle PlayGround, Hayate, TC Particles etc…). occasion aussi d’effet intéressant de "Shield Impact" vu qu’il n’y a pas de bouclier de protection dans Moons et que je voulais a tout prix ce genre d’effet (On est Trekkie ou on ne l’est pas).

Presque aussi gros qu’un Crafteur, cuirassé/blindé en quantité limité. J’en prévois moins d’une vingtaine par campagne. Non renouvelable/ «ressuscitable» une fois éliminé (Bon courage tout de même). Modèle a textures uniques.

Plus nombreux (non limités en réalité. Semblables au grosses araignées de "StarShip Trooper".

Petite "araignée des sables" présente dans les plaines. Aucune incidente sur le Gameplay.

Les plaines de Moon[s] ne seront pas vides de vie ou d’objets. Outre ce NPC, on y trouve (petits) cailloux et autres touffes d’herbes. Plus important, les «Cristaux». A la base, l’idée était de remplir ces espaces avec des objets assez gros pour le système de "Cover". Les rochers semblaient tout désignés, mais l’inconvénient majeur de cette solution est ma capacité a en générer de suffisamment nombreux pour éviter les répétitions. C’est là que le choix des "Cristaux" c’est avéré plus judicieux car

Les avantages sont multiples :
* Facile a créer en procédural : modèles (ainsi que les "Colliders"), dimensions (un mètre de haut jusqu’a la taille d’un séquoia) , forme, look (couleur), la fonction ( ?!)

* Les effets spéciaux (visuel et audio). Vibrations (réactions au tirs encaissés), arcs électriques etc.. Il y a de quoi faire (sans tomber dans le syndrome des MMOs Coreens)..

* La destruction procédurale. En temps que modèles (voir primitive de base) c’est autrement plus facile a démolir qu’un rocher. Imaginez un cristal de 10-20 mètres de hauteur dont on détruirait la base. En plus des dégâts provoqués par la chute, ce nouveau "mur" change la physionomie d’une zone.

Etc..
Ah oui, c’est à la «lisière» des plaines que sortent de terre les NPC n° 3 (Sacré boulot pour délimiter tout cela avec un éditeur maison )

Balise de secours

Retrouver un Robot perdu à la surface de Moons risque d’être compliqué dans certain cas. Bien sur, ils sont équipés des petites balises (genre RFID) pour les courtes distances, non efficaces sur les longues. C’est ici qu’intervient la balise de détresse qui peut être activée automatiquement ou pas. Inconvénient : elle est captée par TOUT ceux qui sont à portée du signal. Ami comme ennemi.

Moteurs

Moteur IPE (Ionic Pulse Engine) pour "l’avion" principal et MGE (Magnetic Grav Engine) pour les DropShips de transport. Les deux permettent le décollage et l’atterrissage à la verticale.

Porte/Gate de Flux/Communication et GPS

La communication entre la Terre et les lunes empruntent les portes du "Flux". A l’origine, je pensais les placer sur une orbite plutôt haute, donc, pas vraiment visible de la surface de la lune. Finalement, la disponibilité de ce modèle ( Image ) m’a convaincu de placer ces portes dans l’atmosphère. La aussi occasion d’effets intéressants : arrivées de vaisseaux de ravitaillement, réceptions des vagues de «Flux» envoyés vers la Terre. De plus, ces portes sont aussi utilisable comme antennes de relais pour les communications locales et bien sur le GPS. Vive le Store.

Armes (inhibiteurs)

Il n’y a pas d’arme a particules dans Moon[s] (Laser sans doute...). Cependant la aussi, les "Shield impact" me manquait donc, j’y ai introduit une nouvelle cartouche :

L’inhibiteur :

Tirée à minima par un ShootGun ( a cause de son diamètre) cette cartouche sert à perturber les circuits électrique des robots (et autres). Elle est généralement utilisée par les forces Terrestres lors de missions locales en cohabitation avec des Robots. Façon rapide et..brutale pour les désactiver en cas d'anomalie.


JP
"ça peut bugger mais ce n'est pas du à un bug. Subtile nuance... :mrgreen: " ZJP

Avatar de l’utilisateur
Franck
Bricoleur
Bricoleur
Messages : 2838
Inscription : 08 Jan 2011 18:43
Localisation : Tours

Re: Moon[s] 20.62

Messagepar Franck » 03 Fév 2013 18:36

Trés jolie.

On peut aller sur "saturne"? J'ai pas eu la patiente d'aller jusqu'au noyeau de la planéte.
La "teinte" de l'ensemble est top.
Dés fois j'bug, dés fois j'bug pas.

Avatar de l’utilisateur
Max
Bricoleur
Bricoleur
Messages : 5489
Inscription : 30 Juil 2011 13:57

Re: Moon[s] 20.62

Messagepar Max » 03 Fév 2013 19:06

Je rejoins Franck, c'est bien jolie, la nav douce, le rendu est chaleureux, bref j'aime beaucoup ;)
Par contre le roaming du terrain est souvent violant... (on peut pas tout avoir j'imagine)

Franck a écrit :On peut aller sur "saturne"?
oui, la question est là :mrgreen:
____________________________________________________________________________

Avatar de l’utilisateur
ZJP
Messages : 5301
Inscription : 15 Déc 2009 06:00

Re: Moon[s] 20.62

Messagepar ZJP » 03 Fév 2013 20:16

Par contre le roaming du terrain est souvent violant... (on peut pas tout avoir j'imagine)

La vitesse de déplacement actuelle est trèèèèès nettement au dessus de la vitesse réelle. Tu es presque à un kilomètre/seconde. :mrgreen:

[NB]
Premier post édité.
"ça peut bugger mais ce n'est pas du à un bug. Subtile nuance... :mrgreen: " ZJP

Avatar de l’utilisateur
Max
Bricoleur
Bricoleur
Messages : 5489
Inscription : 30 Juil 2011 13:57

Re: Moon[s] 20.62

Messagepar Max » 03 Fév 2013 20:19

ZJP a écrit :[Tu es presque à un kilomètre/seconde. :mrgreen:
pfff, 3600 km/h, t'imagine pour moi, t'es même pas sur les bases d'un simple scooter spacial :mrgreen:
____________________________________________________________________________

Avatar de l’utilisateur
ZJP
Messages : 5301
Inscription : 15 Déc 2009 06:00

Re: Moon[s] 20.62

Messagepar ZJP » 03 Fév 2013 21:34

UP pour le post des technos/libs utilisées.
"ça peut bugger mais ce n'est pas du à un bug. Subtile nuance... :mrgreen: " ZJP

Avatar de l’utilisateur
Max
Bricoleur
Bricoleur
Messages : 5489
Inscription : 30 Juil 2011 13:57

Re: Moon[s] 20.62

Messagepar Max » 03 Fév 2013 21:46

Super présentation, et surtout bien ambitieux projet, mais tout aussi passionnant ;)
Inutile de dire que l'on va être quelque uns à suivre la chose de près :mrgreen: .

Au delà de la démarche et du roadmap, fournir l'approche et les tools est fort instructif. Image

Sinon, tu es partis sur des fond perso ? ou tu as démarché quelques menu investisseurs ?
____________________________________________________________________________

Avatar de l’utilisateur
HelziX
Messages : 100
Inscription : 22 Sep 2012 22:28
Localisation : Genève
Contact :

Re: Moon[s] 20.62

Messagepar HelziX » 03 Fév 2013 23:13

très intéressant ton projet, hâte de voir la suite des évènement :D

Personnellement je suis allé sur saturne avec la touche maj enfoncé ça va très vite :mrgreen: :mrgreen:
J'adore l'effet glow sur les météorites, ça donne un super aspect!!! La couleur très orangée sur la planète est voulue? j'aurai préféré la rendre moins pétant au niveau de la couleur ( enfin avis perso :p )

Au niveau du pathfinding tu comptes le coder toi même ? ( genre l'algorithme a* ? ) Sur mon projet j'ai l'idée d'un pathfinding a* sans trop de complication pour le moment !!

Bon courage pour la suite :D

Avatar de l’utilisateur
ZJP
Messages : 5301
Inscription : 15 Déc 2009 06:00

Re: Moon[s] 20.62

Messagepar ZJP » 04 Fév 2013 05:32

Max a écrit :Au delà de la démarche et du roadmap, fournir l'approche et les tools est fort instructif. Image

Même si on ne m'a pas fait cadeaux de ses libs/outils, ni sponsorisé, il me semble normal de parler du travail de développeurs indies qui produisent de bon outils.

Max a écrit :Sinon, tu es partis sur des fond perso ? ou tu as démarché quelques menu investisseurs ?

Fonds persos. Etalés sur 10 ans pour la plupart des modèles. Le DropShip a été acheté en...2002. Sinon, pour les Assets d'Unity j'ai simplement attendu les...grosses remises.
J'ai aussi profité des prix de lancements. Par exemple Vectrosity coutait 5 à 8$ au début (25$ maintenant) et les modèles de Dexsoft sont moins chers les 15 premiers jours. Ethérea 38 euros en promo au lieu des 150$ du tarif normal etc etc...

HelziX a écrit :J'adore l'effet glow sur les météorites, ça donne un super aspect!!! La couleur très orangée sur la planète est voulue? j'aurai préféré la rendre moins pétant au niveau de la couleur ( enfin avis perso :p )

TOUT les effets sont voulus. Cela à demandé du temps pour maitriser les paramètres. L'air de rien, il y a une douzaine de shaders dans cette scène.
L'orangée colle bien à l'atmosphère sableuse de la planète (lune). L'effet est surtout saisissant en haute altitude.

HelziX a écrit :Au niveau du pathfinding tu comptes le coder toi même ?

Soit une librairie de l'Asset store. Il y a VRAIMENT le choix ou un "truc" expérimental :
Un mélange de RVO, Machine à Etats, et de System Expert d'ordre Zéro.
Pour information, j'ai créé depuis une bonne décennie une DLL a partir de ceci (Crois le ou non, j'ai encore la version en GWBasic de 1984 :mrgreen: ) avec le sentiment que cela pourrait servir dans un jeu. L’occasion d’essayer.


JP
"ça peut bugger mais ce n'est pas du à un bug. Subtile nuance... :mrgreen: " ZJP


Revenir vers « Vos créations, jeux, démos... »

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 1 invité