Ca fait déjà quelque temps que je suis dans la création de jeux vidéos, sautant de moteurs en moteurs car aucun ne me plaisaient, à cause du langage de programmation qu'il utilisait, (GDscript, Lua), du "design pattern" ("nodes"), les crash et bugs, et surtout la manière dont il était pensé (une seule manière de faire une chose) !
J'ai décidé de créer mon propre "moteur".
Originalité
Le framework
Ce n'est pas vraiment un moteur, plus un framework pour maximiser la portabilitée et minimiser les crashs / bugs, j'ai opté pour une techno. WebGL (au lieux de OpenGL ES 2.0 pour la plupart des moteurs), C'est à dire que la partie moteur graphique du framework seras gérée par Pixi.js un moteur 2D webgl qui à déjà fait ses preuves. Le reste (audio, input, networking..) seras fait maison.
Le crossplatform
Une application Emeraude, seras packagée grâce à des technos. comme Cordova sous Android, blackberry et IOS, en restant accessible à Windows, OSX et Linux grâce à des technos. comme Electron et biensûr sur navigateur !
Design pattern
Ayant utilisé beaucoup de moteurs, je me suis inspiré de plein d'idées, et je pense avoir trouvé le bon fonctionenment pour un framework de jeux, ça fait un peux prétencieux mais ça à l'air de tenir la route;
C'est donc un design pattern très orienté objet, j'appellerais plus ça des shémas, je m'explique,
Dans un jeux il y à beaucoup de composants (scènes, groupes, sprite, collisions, particules, sons, etc.), tous ces composants on leurs classe attitré, puis le dev. crée une nouvelle classe et hérite les méthodes de la classe de base (normal), beaucoup de méthodes prendrons des classes non instanciées et retournerons des instances.
Un bout de code pour illustrer
class Sprite extends Pulsar.Sprite
{
constructor ()
{
super()
// Résoud 'bouftou.png' dans le dossier des assets
this.texture = Pulsar.Texture('bouftou.png')
}
}
class Player extends Pulsar.GameObject
{
create ()
{
// Donne le schéma de notre sprite et le crée
this.setSprite(Sprite)
}
}
class MyGame extends Pulsar.Game
{
constructor ()
{
// Crée le jeu
super( { width: 800, height: 800 } )
}
create ()
{
// Créer notre game object avec le schéma 'Player'
let player = this.addGameObject(Player)
this.render()
}
}
Le but
Le but est d'avoir un moteur open-source qui tourne n'importe où avec de bonnes performances.
Avancement
Je suis en train de coder les bases (bundler, asset manager, template processor) et le design en général.
Rémunération ?
Le projet est open-source, donc donné à tout le monde, c'est la seule rémunération.
Recrutement
Je suis en train de designer le framework, je ne recrute donc que des devs Javascript, des affinités pour Pixi.js (ou même Phaser), Cordova, et Electron seraient appréciées mais non obligatoire
Le but serait d'être 3 devs
Comment postuler
Pour postuler envoyez moi simplement un MP avec: Votre prénom || pseudo, votre âge, vos dernières expériences, pourquoi vous shouaitez rejoindre le projet.
Je compte sur vous pour apporter des critiques dans les commentaires !
Le projet en lui même est plutôt intéressant (étant dans le JV Web depuis un moment aussi je suis plutôt d'accord avec toi). Après moi je trouve dommage que la plupart des moteurs de jeu ne soi pas fait en prenant le back-end en considération. Je fais principalement des jeux multijoueurs et c'est une torture (ont doit juste tout refaire en back-end).
Alors qu'aujourd'hui il est facile de faire un truc compatible front et back (avec NodeJS).
Personnellement je me suis lancé sur un projet de faire un outil pour du développement de jeux temps réel ( qui est en faite le résultat de ma frustration de Superpowers qui n'est pas à la hauteur de Craftstudio, sans parler de PlayCanvas qui est juste terriblement mal fait -_-). Pour le moment j'en suis à une phase de drafts et j'ai pas de préférences en terme de moteur.
Ah et au passage je gère une communauté ECMAscript :
Bonjour, content que ça plaise à certains, cependant, comme beaucoup on dû s'en douter, j'ai dus mettre le "projet" en pause.
D'abord, car j'ai perdu le code (réinitialisation de mon PC en oubliant que j'e n'avais pas push), même si j'avais dus mettre à peine trois jours de code sur le projet, c'est un peux démoralisant.
De plus, j'ai jugé que je n'avais pas encore assez de compétences en matière de JV, car même si ça fait longtemps que j'en fait, je n'ai jamais encore de fait de vrai jeux aboutis, donc je ne pense pas avoir un regard <<complet>> sur la création / gestion d'un JV.
Et pour finir, j'attend de voir ça qui vas se passer avec WASM.
Néamois, je n'abandonne pas, je met "seulement" le "projet" en suspension, en attendant d'avoir plus d'expérience pour bien faire ce genre de projet, je pense que j'ai de bonnes idées, (Schema, unifier back & front), mais je préfère encore attendre.
Pour l'instant je m'amuse un peux à contre coeur sur Cocos Creator (port de cocos2d-x en js), qui fonctionne avec un système de node qui je déteste tant mais ça reste un très bon moteur open source et il à des choses très bien pensé.
En ayant compte de la charge de travaille que ça représente, je préfère simplement me donner du temps, mais c'est sûr, je reviendrais dessus !
Fraxken tu m'as donné une bonne idée, c'est vrai que il y aurait moyen de faire un espèce de wrapper qui gère la synchro front & back !
Gtibo la fonction `this.addGameObject`, est une fonction héritée de `Pulsar.Game`, qui prend une classe, l'instancie et s'occupe d'autre chose que le dev ne veux pas voir pour retourner un gameObject
[JS] Pulsar, framework de jeu cross platforme
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Je ne suis plus modérateur, ne me contactez plus pour des demandes, je n'y répondrai pas.