ECLERD (v0, remplacée bientôt)
#91
je dirais qu'ici, le seul défaut que je peux "voir" provient de l'ordre des sprites...
les sprites sur les cases qui sont les plus "basses" (au sud ?) doivent être placé au "dessus" (plus en avant/ 1er plan) pour éviter que, par exemple, les sapins se retrouvent sous les bâtiments.

Mais je viens de voir que tu avais déjà régler ce problème :
Citation :Prise en compte d'une forme de z-buffer: les villes ne sont plus "posées" par dessus les arbres http://pic.twitter.com/9yYt34PZHD

=D

J'ai franchement hâte de voir le résultat en vrai.
Il te faudra en revanche énormément de ressources en .svg pour avoir une bon "graphisme" dans ton jeu. (ici, /!\ attention aux copies à l’intérieur des svg mais favoriser le clonnage ! [ Alt + D dans Inkscape plutôt que Ctrl + D] ça allégera les fichiers svg.)

J'avoue ne pas savoir ce que représentera toutes tes illustrations de ressources : bâtiments, arbres, animaux, etc. (e sais que sous l’ancienne version tu avais un tripoté de petits .gif)

As-tu fais un estimation ?
combien de fichiers, de combien de Ko ?

En tous cas, les quelques images que tu nous dévoiles ici, et sur twitter, sont alléchantes, et sobre. (tu m'avais habitué à des choses moins jolies dans tes codes couleur. x) )
** Exept les quelques bâtiments **

Bonne continuation en mode vectoriel ! 16
"Somewhere, something incredible is waiting to be known..."
Carl Sagan.
#92
(TL;DR? Lisez que le gras!)


Les sprites sont maintenant dans le bon ordre, mais c'est exact, je n'ai pas reposté l'image ici...
D'où l'intérêt de suivre le Twitter d'Eclerd 2



○ Le SVG est généré dynamiquement, puisque la carte évolue avec les actions des joueurs.
Par exemple, exploiter le bois d'une case ou drainer toute l'eau des nappes phréatiques aura une incidence sur l'apparence de la case. Dans le premier cas, les sprites des arbres disparaitront, dans le second cas, le sol se sèchera et la case ressemblera à un désert.
Donc, Inkscape n'est absolument pas utilisé 34
Toutefois, tu as raison: le clonage SVG est utilisé. Techniquement, il s'agit d'utiliser la balise <use> (voir spécif en anglais pour les courageux) qui permet effectivement de référencer un élément plutôt que de le cloner "à la main", à l'image d'un raccourcis windows qui permet d'éviter de copier le fichier vers lequel ce raccourcis pointe.



Coté ressources, c'est effectivement gourmand si on veut afficher des tas de jolies sprites, voire les animer. En revanche, sur la carte basique (si on enlève les arbres par exemple pour ne laisser que la couleur de la case du terrain), la fluidité est très bonne. Je jouerai là dessus pour permettre de se déplacer dans la carte, à la google maps, sans que tout ne rame.



La tripotée de petits GIF (en fait, des PNG 34) est toujours présente, faute de mieux :\ Une fois le canvas complet du jeu en place, je me pencherai sur l'idée d'avoir des sprites plus adaptées. Et même, puisque la structure du jeu le permet, il sera possible pour les joueurs de définir leurs propres sprites 16 Tu pourras alors t'amuser à changer toutes ces micro-images plutôt moches pour en faire des feux d'artifices graphiques :p



○ Pour l'estimation, je n'en ai pas de précise au niveau de tous les sprites, car les sprites ne sont pas "intégrés" au mécanisme du jeu: ils sont intégrés au skin du jeu. On pourra donc installer un skin personnalisé sur Eclerd, un peu comme sur firefox ou windows.
En revanche, coté batiments, le nombre sera bien réduit, puisque le système des "générations" est parti aux oubliettes. On part sur une vingtaine de bâtiments, répartis entre "Ressources Naturelles", "Agriculture", "Energie", "Industrie" et "Tertiaire" (armée, villes, déchèteries,...)



○ Oui, j'ai revu mes codes couleurs, y'en avait besoin XD Mais les bâtiments sont encore moches car bien trop petits pour du SVG... Si tu es partant pour m'aider et concevoir des sprites pour cette nouvelle version, je suis totalement intéressé 2


Merci et vive les vecteurs ! ←↑↓→
#93
Je suis justement entrain de réfléchir à un système de carte similaire (avec les arbres et autres ressources représentées visuellement). Je vais un peu plus loin puisque tout est généré procéduralement, notamment les limites entre types de terrain (courbes), la position des ressources, la forme des cours d'eau et des routes.
Par contre j'utilise canvas et pas svg, je me suis dit que les performances seraient meilleures vu le nombre de sprites que je compte afficher (mais en fait j'en sait rien).
#94
Le moteur fait maison que j'utilise se base sur des shapes pré-définies, dans le skin, pour placer les cases. Il serait possible de le moduler pour afficher une shape générée par le serveur 34 En fait, je vais surtout m'en servir pour changer d'architecture de carte (passer de losange à hexagone par exemple, ou utiliser des pavages apériodiques, pourquoi pas).

Je ne sais pas si je diffuserai le code en open source. C'est possible... Je verrai plus tard.

Pour canvas/SVG, canvas sera plus rapide si tu as de nombreuses sprites. D'après Microsoft:

[Image: IC627296.png]

En revanche, j'ai pris SVG car je voulais une belle structure (DOM), accessible et modulable via CSS. Canvas ne le permet pas. Et ayant des cases avec des formes parfaites, ainsi que le besoin d'afficher des symboles, des textes, des flèches de flux... j'ai choisi SVG. En plus, croisé avec XML/XSL, cela me permet de laisser le navigateur du client faire le travail pour passer des données du jeu à la vue graphique 16


D'ailleurs:
Seriez-vous intéressé par une forme de tutoriel sur la conception d'une carte de jeu format SVG?
#95
Cette comparaison on la ressort à toute les sauces mais quand on veut une carte en plein écran avec beaucoup de sprites (comme dans la plupart des jeux), ben ça nous dit pas quoi choisir.
De toute façon c'est pas les perf qui dictent le choix puisque ces deux technologies sont très différentes dans leur fonctionnement (bitmap vs vectoriel) et dans leurs possibilités.
#96
Dans ce cas, je vais m'amuser à tester 34
#97
(04-15-2014, 03:16 PM)Xenos a écrit : D'ailleurs:
Seriez-vous intéressé par une forme de tutoriel sur la conception d'une carte de jeu format SVG?

ben moi oui

sachant que ce n'est pas forcément une carte telle que tu as fait qui m'intéresse plutôt que l'aspect positionnement d'objets.

Typiquement je suis plutôt en train de construire un paysage dynamiquement (ie je suis sur une case, vue première personne et je vois les cases devant moi) mais on est sur le même principe : chaque case a un type, des décors, une altitude, etc... dont je déduis par algorithme (enfin pas fini) une représentation graphique

mon point dure aujourd'hui est le positionnement du décor arbre, etc... en fonction de la courbure du sol

j'ai une case à une altitude 0 voisine d'une case à altitude 1, en mode panorama, ce ne sont pas des escaliers mais une jolie courbe (ligne de crête, etc...) que doivent suivre les arbres

mathématiquement j'ai enfin réussi à imaginer qqchose, maintenant c'est l'implémentation : javascript sur le dom ?, précalcul et sauvegarde en BDD du svg ?, use d'un arbre ?, transformation que je n'ai pas trouvé ?(quelque part j'aurais besoin des courbes quadratiques du path pour positionner les objets en x,y alors qu'ajourd'hui je ne sais que découper le sol suivant les paths, etc..), comment loader en ajax une fois pour toute la ressource arbre (histoire de ne pas recharger n fois le def "arbre" à chaque fois que je tourne la tête et que je recalcule le panorama, etC...

mais bon je pollue ton sujet
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
#98
D'accord.
Je pense que je m'y attacherai après un ou deux projets de jeu, histoire d'avoir quelque chose de robuste (et pas des morceaux théoriques comme actuellement 34).

J'avais fait un pseudo-article sur une forme de "régression" polynomiale, cela pourrait te servir pour tes paysages (puisque cela m'a servit pour les miens, sur une autre ébauche de projet jamais terminée 34). L'avantage sur les courbes de Bézier (ou similaires) réside dans la meilleur intégrabilité/dérivabilité de ces fonctions. Mais on ne peut pas faire de "grottes", puisque c'est une fonction (aka 1 seule valeur de Z pour un couple [x,y], comme une heightmap).
SVG te fournira de très bon outils pour ce genres de calculs.


Pour en revenir au sujet, le moteur affichant les cartes et le mécanisme pour définir ce que l'on souhaite voir à l'écran semblent terminés. Voici quelques images des cartes actuelles:


On aura donc la possibilité d'avoir un recul important (vue de la planète entière, comme planisphère) ou au contraire, d'aller descendre très finement, jusqu'à voir les arbres (ou les voitures!).
Il sera également possible de personnaliser la vue, de changer les sprites, de créer de nouvelles cartes,...
A noter que les sprites sont, pour l'instant, reprise de deviantart/google.


Vous retrouverez les images sur le twitter d'Eclerd.
#99
(04-24-2014, 12:02 AM)Xenos a écrit : Il sera également possible de personnaliser la vue, de changer les sprites, de créer de nouvelles cartes,...

Il faudra pour cela que les personnalisation soit en ligne, sur un espace de stockage de type ftp...

donc si le joueur n'a pas de serveur, il ne pourra pas changer son "skin" par lui-même.

A moins que tu ne donnes de l'espace de stockage sur ton serveur (ce que je doute) , je ne vois pas comment faire "simplement" un skin modifiable.


Edit : A moins de donner la possibilité de mettre des url d'image pour chacune des images présentes sur ton jeu. (ou une page d'attribution des url images)

je me rappel que quand j'ai fais mon propre skin sur l'actuel version, j'avait du copier tout un dossier sur ftp, et même les images que je ne modifiais pas.
j'aurais voulu ne mettre sur mon serveur que ce que j'avais modifié, et non tout le dossier contenant css, img, etc...
"Somewhere, something incredible is waiting to be known..."
Carl Sagan.
La mécanique de stockage en ligne des skins serait plutôt déléguée à un autre site (perso aussi :p). De là, le site de skins permettrait de personnaliser non seulement ECLERD (en mettant en ligne son propre skin/jeu de sprites, mais aussi en choisissant un skin déjà existant et créé par quelqu'un d'autre, voire acheté), mais aussi les skins de d'autres potentiels jeux et sites à venir. Cela me centralise la mécanique de gestion des skins (plus simple de mon coté), et cela ne pollue pas les jeux/sites par des options dont peut-être 75% des visiteurs se moquent (plus léger et moins complexe de leur coté).

En revanche, pour la "modularité" des skins (modifier juste certaines URL), ce sera envisageable, mais un peu plus délicat. Je n'ai pas envie de créer un cas particulier "laisser le sprite par défaut". Ce serait alors plutôt du type "uploader un sprite ou utiliser un sprite déjà présent en ligne". Donc, par défaut, on aurait une page avec la liste des sprites du skin original, et là, on upload seulement les sprites qu'on veut changer.

Tout cela sera une question d'interface 2 En tous cas, la mécanique sous-jacente des sites le permet. Après, peut-être que l'utilisateur final ne pourra que choisir parmi N skins officiels... Je n'ai pas encore développé en détail la conception de cette partie.


Sujets apparemment similaires...
Sujet Auteur Réponses Affichages Dernier message
  ECLERD, nouvelle mouture Xenos 9 4 693 03-23-2019, 02:32 AM
Dernier message: Xenos
  Crazyland bientôt ! chapatiz 6 3 985 04-02-2010, 09:18 PM
Dernier message: chapatiz



Utilisateur(s) parcourant ce sujet : 1 visiteur(s)