Créer une carte Wargame

[Anthor]

Je réagis :

Et dans un second temps, on génère une feuille de style à la volée afin de positionner ces blocs.

Peux-tu détailler ? Tu créé un nouveau fichier CSS pour ça que tu inclue ensuite ? ça marche ce genre d'opération ?

Kéké

tu link juste un fichier php ^^

[Sephi-Chan]

J'utulise l'architecture REST pour ce genre de chose. Grâce à elle, j'inclus une feuille de style comme d'habitude, sauf que ce fichier CSS n'est pas un fichier statique : il est généré à la volée par le serveur.

Voici un exemple (en imaginant que je sois dans la partie d'id 24) :

<link type="text/css" rel="stylesheet" href="/games/24/map.css" />

Côté serveur, j'ai configuré des routes :

# On déclare une ressource game. Chaque ressource game dispose d'une ressource map.

resources :games do

  resource :map

end

Ça permet à mon application d'être capable de reconnaître les requêtes HTTP de la forme :

GET       /games/:game_id/map(.:format)      { :action => "show",    :controller => "maps" }

POST      /games/:game_id/map(.:format)      { :action => "create",  :controller => "maps" }

PUT       /games/:game_id/map(.:format)      { :action => "update",  :controller => "maps" }

DELETE    /games/:game_id/map(.:format)      { :action => "destroy", :controller => "maps" }

En l'occurrence, l'attribut href de notre balise link va envoyer une requête GET, c'est donc la première route qui va être utilisée. L'action "show" du contrôleurs "maps" va être exécutée. Cette action est configurée pour répondre quand on demande du CSS (ainsi que du JS ou du HTML).

class MapsController < ApplicationController

  def show

    @game = Game.find(params[:game_id])

    @map  = @game.map

  

    respond_to do |format|

      format.html # Rend la vue /views/maps/show.html.erb

      format.js   # Rend la vue /views/maps/show.js.erb

      format.css  # Rend la vue /views/maps/show.css.erb

    end

  end

end

Ensuite, la vue est toute bête. On a l'habitude de générer du HTML avec le serveur, ici c'est pareil sauf qu'on génère du CSS. Et bien sûr, on envoie le type MIME qui convient (text/css), mais ça c'est Rails qui s'en occupe, dans mon cas.

Comme d'habitude, les frameworks ouvrent souvent les yeux sur des solutions.


Sephi-Chan

[php_addict]

générer du css en php, c'est super ingenieux! en plus ca repond à un probleme que j'ai en tete depuis 1 mois...je me voyait mal faire un fichier.css avec plusieurs milliers de ligne...

[christouphe]

tu génèrerais le fichier .css ou tu l'intègrerais dans le fichier php où tu veux l'avoir ?

[Sephi-Chan]

C'est toi qui voit. Tu peux générer un fichier statique et le ranger quelque part puis l'appeler ensuite, ou bien faire un script PHP qui produit du CSS (et envoie le type MIME qui convient).


Sephi-Chan

[christouphe]

chui con, moi j'incluait mon fichier css.php, maintenant je comprends que ce soir j'ai du boulot, lol. Enfin, pas côté css ça va aller assez vite

[Ter Rowan]

n'empêche pour générer le fichier css...

ca revient pas à faire une double boucle pour créer toutes les positions ?
pour identifier les classes css "tile-x-y" ?


je vois pas d'un point de vue algo la différence avec la génération d'un tableau HTML.

Ce que je trouve intéressant par contre, c'est la gestion "native" des objets plus grands qu'une case.

Par contre un point qu on oublie (même si, fonction du marché ciblé, il n'a pas forcément d'utilité) c'est que le système des div fait perdre tout sens au positionnement par rapport à une table.
Je m'explique :

je ne connais pas trop jaws ou autre outil d'interprétation HTML pour non voyant mais ces outils doivent être capable de dire ce qui est au dessus (au nord) au dessous (au sud) à gauche (à l'ouest) ou à droite (à l'est) de la cellule <td> "active"

maintenant avec les div... ben on perd tout, on les a les uns après les autres

Conclusion, avec une table tu sais "voir" les positions, avec des div non

La séparation Présentation / Données n'est pas respectée avec ces div car le positionnement est une donnée et non de la présentation


Enfin je dis ça mais j'aime bien la notion de div quand même ^^ simplement je ne la trouve pas "super" pour autant

[Sephi-Chan]

n'empêche pour générer le fichier css...

ca revient pas à faire une double boucle pour créer toutes les positions ?
pour identifier les classes css "tile-x-y" ?

je vois pas d'un point de vue algo la différence avec la génération d'un tableau HTML.

Tu dois faire une double boucle si tu affiches une portion de la carte, car tu dois réindexer pour l'affichage.

En revanche, dans le cas où tu affiches l'intégralité de la carte, tu n'as alors qu'à lire les coordonnées de chaque entrée de la table.

Par contre un point qu on oublie (même si, fonction du marché ciblé, il n'a pas forcément d'utilité) c'est que le système des div fait perdre tout sens au positionnement par rapport à une table.
Je m'explique :

je ne connais pas trop jaws ou autre outil d'interprétation HTML pour non voyant mais ces outils doivent être capable de dire ce qui est au dessus (au nord) au dessous (au sud) à gauche (à l'ouest) ou à droite (à l'est) de la cellule <td> "active"

maintenant avec les div... ben on perd tout, on les a les uns après les autres

Conclusion, avec une table tu sais "voir" les positions, avec des div non

La séparation Présentation / Données n'est pas respectée avec ces div car le positionnement est une donnée et non de la présentation


Enfin je dis ça mais j'aime bien la notion de div quand même ^^ simplement je ne la trouve pas "super" pour autant

Je ne connais pas bien le fonctionnement des lecteurs d'écran non plus. Il faudrait demander des précisions à des personnes plus habituées (Kéké ?).

Je te rejoins sur le fait que la position est une donnée, mais je ne pense pas que le tableau soit une bonne manière d'indiquer cette donnée.

Si on vise un public comprenant des aveugles, je penche plutôt pour une description textuel (en listant les cases par direction) ou la présentation des coordonnées : si on dit à la personne qu'il est sur la case 1-1 et qu'il peut aller sur la case 1-2, il comprendra que cette case est à droite de celle où il est.


Sephi-Chan

[Argorate]

Là tu vas chercher loin quand même ^^ C’est vraiment spécifique.

Quand a l'avantage lorsqu'on affiche toute la map, ce n’est pas vraiment le plus utile car la plus part des mmo php sont sur une map monde plutôt grande où le perso/vaisseau/unité est limité par sa "vision".

M'enfin admettons. Il y a un truc que je me demande justement concernant les éléments de plus d'une case.
Comment gères-tu les bords?
Admettons qu'il y est un bâtiment de 2x2 cases en haut a droit de la vision d'un joueur, mais que ça vision ne lui permette de normalement voir uniquement le coin inferieur gauche de se bâtiment. Comment fais-tu pour n'afficher que cette partie du bâtiment si tu n'a uniquement en bd qu'une seule série de coordonnée x;y pour ton div?

(Moi je comprends mais je ne sais pas si je suis clair^^)

[QuentinC]

Puisque quelqu'un a posé la question, il est temps de crever l'abcès sur ce forum : pour ceux qui ne seraient pas au courant, je suis non-voyant et utilisateur d'un lecteur d'écran. Voilà, c'est dit.

Comme ça a été si bien dit, un ramassis de div ne nous done en effet aucune information géographique, contrairement à un tableau.

Pour représenter une carte dynamique, à mon avis, il y a 3 solutions possibles. Je développerai plus tard car je dois y aller malheureusement.