[RFC] Slime Volley 3.0

tout ce qui concerne directement le jeu, ses images ou son code. (pour les bug report voyez sur le traqueur de bogues)

[RFC] Slime Volley 3.0

Postby VinDuv » 18 Jun 2009, 20:26

Petite intro avant d'entrer dans le vif du sujet :
Je ne pourrais pas recommencer à coder Slime Volley avant un certain temps, mais cela ne m'a pas empêcher de réfléchir au futur de ce jeu ;)
RFC signifie Request For Comments. Cela veut dire que si ce que je dis n'est pas clair, ne semble pas faisable ou ne vous plaît pas, ou que vous avez des idées supplémentaires n'hésitez pas à le dire : ça sera plus facile à changer maintenant que quand la moitié du programme sera écrite :P

J'ajoute que les images sont juste là pour illustrer mon propos, dans la réalité ce sera sans doute plus joli :?

Design général du programme
  • Pour améliorer la lisibilité et la modularisabilité du code, certaines sections du code (si ce n'est la totalité) seront réécrites en C++.
  • Les valeurs de retour des appels systèmes comme malloc et realloc seront systématiquement vérifiées (sachant qu'ils peuvent échouer sur des systèmes qui utilisent une allocation mémoire statique, comme Mac OS 9)
  • Les dépendances aux bibliothèques sdl_image et sdl_net seront supprimées : utilisation de la libpng et des sockets UNIX à la place (peut-être également utilisation directe de la libfreetype au lieu de sdl_ttf)
  • Une fonction d'affichage de message d'erreurs, spécifique à l'OS, sera utilisée.

Jeu
  • Deux modes principaux : le mode solo et le mode libre. Le mode solo se fera contre IA, et permettra de "débloquer" des graphismes supplémentaires qui pourront être utilisées dans le mode libre. Ce dernier fera s'affronter un certain nombre d'équipes, définies à l'avance. Les joueurs pourront entrer à l'avance leur pseudonyme (et leur configuration clavier préférée) pour rendre la constitution des équipes facile :
    Image
  • Le mode réseau évoluera : il permettra la découverte automatique des serveurs, au choix soit sur le réseau local, soit sur Internet (via une liste sur le site Web, téléchargée et mise à jour automatiquement).
    • Une fois le mode réseau activé, les clients pourront se connecter à tout moment sur le serveur, qui affichera le nombre de connectés dans le menu principal, notamment.
      Image
    • Lorsqu'un joueur réseau sera placé dans une équipe, il recevra son image de slime (qu'il pourra éventuellement modifier pendant la partie), ainsi que sa position. Le jeu essayera d'utiliser les mêmes graphismes que sur le serveur (quitte à les télécharger - voir plus bas)
      Image
(animation)

Ressources externes
  • Les fichiers de données utilisés par le jeu seront "aplatis" dans un seul fichier. Le format global de ces fichiers reste déterminer, mais il est probable que 1) les données (images, sons, polices), soient enregistrées telles qu’elles et que 2) les valeurs numériques de l'en-tête soient stockées en big endian, pour éviter les problèmes d'endianness.
  • Le mécanisme de chargement de ces données sera modularisé : Il y aura un "chargeur" qui cherchera des fichiers de données dans divers dossiers prédéfinis de l'ordinateur (dans le dossier d'installation, dans celui de l'utilisateur...), un autre qui lira les ressources Mac OS/BeOS, un autre pour télécharger les thèmes lors d'un jeu en réseau... A noter qu'il y aura en général deux phases de chargement : Dans une première phase, on construira la liste des ressources disponibles, et celles-ci seront effectivement chargées plus tard, quand elles seront utiles. Durant l'énumération des ressources (au démarrage), le jeu affichera de quoi faire patienter l'utilisateur (sachant que l'on ne pourra pas afficher de textes ou d'images à ce stade, on se contentera probablement d'une barre de chargement).
  • Il y aura deux types principaux de ressources :
    • Les thèmes : ils définiront l'apparence de l'interface du jeu (menus, éléments d'interface, éventuellement sons...)
    • Les “niveaux” : contiennent les fonds de jeu et les images des slimes (FIXME : musiques de fond ?). Le designer choisira à quel "niveau" seront associées ces ressources.
      A ce propos, il y aura trois réglages pour les images des slimes : uniquement à gauche, uniquement à droite, ou les deux (image de slime pouvant être "renversée" et placée de n'importe quel côté). De plus, les designers pourront utiliser des images de slimes plus grandes que 50x100, et spécifier la position d'affichage (en d'autres termes, on pourra faire des slimes avec des antennes qui dépassent)

Pistes à étudier
  • Utilisation d'un moteur 2D pour la physique du jeu : Chipmunk pourrait convenir mais en fait peut-être un peu trop...
  • SVG : La bibliothèque SDL_svg permet d'utiliser de graphismes vectoriel au format SVG dans un programme qui utilise SDL. Ceci pourrait être très intéressant, notamment pour pouvoir gérer des résolutions plus grandes que 800x600 sans pixellisation. En revanche, celà rajouterai une dépendance à Slime Volley (et cette biblothèque est rarement présente dans les distributions Linux — en revanche, il serait envisageable d'intégrer directement le code). Si les designers de thèmes sont motivés à passer au SVG…
User avatar
VinDuv
Administrateur du site
 
Posts: 20
Joined: 30 Jan 2008, 21:40

Re: [RFC] Slime Volley 3.0

Postby MCMic » 19 Jun 2009, 20:23

Cool tes schémas :) (avec la tite animation).

Pour le fait d'être connectés en permanence et de voir le nombre de joueurs, est-ce que ce n'est pas trop? est-ce vraiment utile?
Pour les menus il faudra être plus vigilant sur la logique, dans la version actuelle on choisis la vitesse de jeu et le nombre de balles dans le menu principal, ç'aurait été mieux dans le menu de nouveau match.

Je suis plutôt opposé à l'idée d'une musique de fond, je pense pas que ce soit très adapté au jeu, mais c'est mon avis. Les sons doivent faire partie du niveau pour coller à l'ambiance. Éventuellement le thème du menu peut choisir les sons du menu.

Je voudrais aussi revenir sur le système de skin pour les slimes, dans la prochaine version on choisira le skin utilisé par son équipe avant le début du match.
Chaque joueur se voit attribuer une déclinaison différente du skin. (la plupart du temps les déclinaisons seront plusieurs couleurs d'un même skin)
Éventuellement durant le match on pourra choisir parmi les déclinaisons du skin.
Les skin seront disponibles des deux cotés (on fera un miroir sur l'image dans le code pour l'équipe de droite)

Je me dis qu'on pourrait afficher les noms des joueurs en dessous de leur slime. (bien sûr ce serait désactivable)

Pour l'idée de se baser sur un moteur 2D existant, je sais pas trop...
Ça signifie tout réécrire non?
Par contre ça voudrait dire plus d'erreur de collision et une physique plus réaliste.
Mais est-ce que ça ne déservirai pas le gameplay? (s'il faut prendre en compte le vent, les frottements, l'angle de frappe et la vitesse de la slime pour un tir précis....)

L'idée d'utiliser du SVG c'est alléchant, mais c'est vrai que je suis beaucoup moins à l'aise avec Inkscape qu'avec GIMP, et on a déjà pas mal de data qui ne sont pas vectorisée. (j'ai déjà deux niveaux pour le mode solo que j'ai fait designer, ce serait dommage de ne pas les utiliser, idem pour les différentes skin proposées sur ce forum)

Pour le réseau, il faudrait pouvoir démarrer la partie sans attendre tout le monde, si certaines places sont toujours libres au bout d'un certain temps.
User avatar
MCMic
Administrateur du site
 
Posts: 90
Joined: 30 Jan 2008, 22:17
Location: Ubuntu 8.04

Re: [RFC] Slime Volley 3.0

Postby MCMic » 19 Jun 2009, 20:53

Voilà le genre de menu que j'aimerai pour configurer un match (les tournois si on les code se configureront différemment) :
Menu - mashup.png
ya même un niveau du mode solo en avant-première
User avatar
MCMic
Administrateur du site
 
Posts: 90
Joined: 30 Jan 2008, 22:17
Location: Ubuntu 8.04

Re: [RFC] Slime Volley 3.0

Postby yagraph » 20 Jun 2009, 01:20

Salut à vous deux !
Content que le projet reprenne vie ;)

j'ai déjà un peu répondu à McMic, mais je le répète ici : je suis dispo si vous avez besoins de graphismes (themes, niveaux, slimes, interfaces...)
et également si vous avez besoin de trier dans l'existant.

Avant de vous lancer dans une refonte de l'interface je pense que ça vaut le coup de faire une esquisse sous forme de plan de site (une arborescence dessinée : de la page d'accueil on va à la page truc, puis à la sous-page machin, quand on finit tel niveau on débloque tel theme)...
C'est tout bête mais vous allez gagnez des heures.

je vois qu'il y a un volet pour les designers de thèmes et des améliorations prévues ça me fait chaud au cœur (les slimes avec les antennes qui dépassent :P ) !

Concernant le SVG personnellement ça me parait une bonne idée (tout ce que je vous ai déjà donné a des sources au format SVG) mais ça a deux défauts dont il faut bien être conscient :
- ça oriente en partie le style du jeu (plus de traits et d'aplats, moins de "textures" et d'effets matières)
- si le dessin SVG est complexe (beaucoup de points, flous) ça peut demander beaucoup de ressources au processeur ... en général ça ne se sentira pas mais sur une vieille machine (- de 1 GHz) ça peut être un problème... Après je ne connais pas "SDL_svg" et je ne sais pas exactement comment ça peut modifier les performances. Peut-être qu'il faut garder les fond en bitmap et des personnages en vectoriel...
Un avantage auquel vous n'avez peut être pas penser c'est que SVG a des capacités d'animations, donc vous ajouteriez les fonctions d'anim du même coup.
Mais si il faut je peux passer du temps à convertir le bitmap existant en SVG (c'est du boulot, mais pas tant que ça vu le style... disons une grosse journée)


Sinon j'ai deux idées à vous soumettre :

- faire une partie "tutoriel" : un ami avait tester le jeu, ça ne lui a pas trop plu... jusqu'au moment où il s'est rendu compte par hasard qu'on pouvait sauter :roll: (il le testait chez lui, je n'étais pas là) !
l'idée du tutoriel demanderais peu de chose : un niveau en mode solo contre une IA 0 par exemple, où est dessiné en fond (en thème ou en niveau plutôt) des indications sur les quelques mouvements de bases et les règles du jeu... Si il faut on le sépare en 2 ou 3 tableaux, en augmentant progressivement le niveau de l'IA.
Le seul souci c'est de dessiner ça (je peux le faire) et de mettre un bouton Tutoriel dans le mode Solo, et éventuellement de coder un peu pour passer d'un tableau à un autre (je me rends pas compte, mais j'imagine que c'est pas le bout du monde, si ?).

- une petite demande de graphiste : ça serait vraiment bien de pouvoir avoir un "calque" de premier plan dans les niveaux :ugeek:
je m'explique : pour l'instant quand on joue, on a un fond ... et des slimes qui jouent devant. C'est bien mais du coup c'est difficile de donner l'impression de profondeur...
Ajouter un calque au premier plan, qui cache les objets en dessous, ça permettrait toutes sortes de petits bonus intéressant graphiquement.
Le cas classique c'est de mettre un rocher dans un coin... qui permet juste de marquer le premier plan.
Mais par exemple on peut imaginer dans un niveau "foret" que la balle envoyée assez haut pourrait être partiellement cachée par le feuillage, ou qu'elle disparaisse rapidement dans un nuage...
ou encore on peut mettre un filtre semi transparent bleuté à droite et semi transparent rouge à gauche, etc, etc.
Pareil, je ne sais pas trop si c'est compliqué niveau code... mais en tout cas ça impose un format d'image : soit PNG, soit SVG, pour avoir de la transparence (par défaut ce calque doit être transparent).

Ce sera tout !
yagraph - motivé par la reprise :)
yagraph
 
Posts: 21
Joined: 06 Nov 2008, 15:26

Re: [RFC] Slime Volley 3.0

Postby MCMic » 20 Jun 2009, 01:34

Merci de tes commentaires, pour l'arborescence des menus ce sera fait. (mais c'est assez difficile de savoir quoi séparer, tournoi/match simple? local/réseau? libre/solo?)

Le passage au SVG ne me tente pas plus que ça, ça me parait beaucoup de boulot pour pas grand chose et d'après les premiers tests de MacMan la lib SDL_svg gère peu de chose. (elle ne semble pas gérer la transparence à première vue donc elle ne gère sans doute pas les animations)

Pour le tutoriel c'est pas idiot, j'aurai tendance à simplement faire un niveau qui serait le premier du mode solo avec en fond les touches et quelques astuces. (sautez en avançant pour faire un saut circulaire, sautez verticalement au filet pour contrer les attaques adverses, essayez de taper la balle avec le bord avant de la slime en sautant pour smasher, trompez votre adversaire en utilisant les rebonds, ...)

Pour le calque de premier plan je suis assez sceptique, ça me parait nuire au gameplay si la balle disparait derrière les nuages ou les arbres, j'ai ajouté une flèche qui indique où est la balle quand elle sort de l'écran, c'est pas pour ajouter des objets qui la cachent.
User avatar
MCMic
Administrateur du site
 
Posts: 90
Joined: 30 Jan 2008, 22:17
Location: Ubuntu 8.04

Re: [RFC] Slime Volley 3.0

Postby VinDuv » 20 Jun 2009, 13:06

MCMic wrote:Pour le fait d'être connectés en permanence et de voir le nombre de joueurs, est-ce que ce n'est pas trop? est-ce vraiment utile?

Ben justement, ça permet d'éviter de devoir réfléchir au problème de
MCMic wrote:démarrer la partie sans attendre tout le monde, si certaines places sont toujours libres au bout d'un certain temps.


MCMic wrote:Pour les menus il faudra être plus vigilant sur la logique, dans la version actuelle on choisis la vitesse de jeu et le nombre de balles dans le menu principal, ç'aurait été mieux dans le menu de nouveau match.
C'est le cas ici (première capture).

Mon idée première, c'est d'avoir des "comptes utilisateur" sur le jeu : chacun entre son pseudo et sa configuration clavier préférée.
Quand un joueur réseau se connecte au serveur, il choisit un de ses pseudos : C'est ce pseudo qui sera affiché sur le serveur (et qui déterminera les touches qui seront utilisées).
Sur l'écran de nouveau jeu, sont affichés dans la colonne "Autres joueurs" (où on vient choisir les joueurs à intégrer dans les équipes), on trouvera les joueurs locaux (les "pseudos"), les joueurs réseau connectés, et les IAs. Il n'y aura plus qu'à former les équipes...

MCMic wrote:Je voudrais aussi revenir sur le système de skin pour les slimes, dans la prochaine version on choisira le skin utilisé par son équipe avant le début du match.
Chaque joueur se voit attribuer une déclinaison différente du skin. (la plupart du temps les déclinaisons seront plusieurs couleurs d'un même skin)
Éventuellement durant le match on pourra choisir parmi les déclinaisons du skin.
Les skin seront disponibles des deux cotés (on fera un miroir sur l'image dans le code pour l'équipe de droite)
Il faudrait effectivement réfléchir à la question...
Personnellement, je reste très attaché à l'idée d'avoir des slimes particulières pour un thème de terrain particulier, afin d'avoir une certaine unité graphique par défaut (utile notamment pour les thèmes Mushrooms et Arash).
Néanmoins, je ne suis pas opposé à l'idée de permettre à l'utilisateur d'utiliser des slimes d'un autre thème. Il faut juste que ça reste simple à gérer.
Ce que je propose :
• Lier toutes les slimes aux "niveaux" (au sens que j'ai entendu dans mon premier message).
• Chaque équipe utilise normalement le thème de terrain pour ses slimes, mais il est possible de changer le thème des slimes d'une équipe :
Image
En revanche, ça va rendre la synchronisation client/serveur des thèmes plus délicate... Si un client doit télécharger 4 thèmes avant de démarrer le jeu, ça va prendre un peu de temps.

MCMic wrote:Je me dis qu'on pourrait afficher les noms des joueurs en dessous de leur slime. (bien sûr ce serait désactivable)
J'y ait pensé, mais ça dépend un peu de ce que l'on fait.
Déjà, ça pourrait être une bonne idée de donner au joueur réseau la même représentation des équipes que celle du serveur, pour que chaque joueur sache précisément dans quelle équipe il est, quelle est sa position et son image de slime.

MCMic wrote:Pour l'idée de se baser sur un moteur 2D existant, je sais pas trop...
Ça signifie tout réécrire non?
Bah ça, c'est déjà prévu :mrgreen:

MCMic wrote:Par contre ça voudrait dire plus d'erreur de collision et une physique plus réaliste.
Mais est-ce que ça ne déservirai pas le gameplay? (s'il faut prendre en compte le vent, les frottements, l'angle de frappe et la vitesse de la slime pour un tir précis....)
Je pense que l'on doit pouvoir tuner le tout pour que l'ensemble se comporte à peu près comme actuellement, à part peut-être en ce qui concerne la collision balle/balle.
Mais ça rendrait aussi bien plus facile l'implémentation d'options supplémentaires (vent, ...)

yagraph wrote:Avant de vous lancer dans une refonte de l'interface je pense que ça vaut le coup de faire une esquisse sous forme de plan de site (une arborescence dessinée : de la page d'accueil on va à la page truc, puis à la sous-page machin, quand on finit tel niveau on débloque tel theme)...
C'est tout bête mais vous allez gagnez des heures.
C'est une bonne idée.

yagraph wrote:Concernant le SVG personnellement ça me parait une bonne idée (tout ce que je vous ai déjà donné a des sources au format SVG) mais ça a deux défauts dont il faut bien être conscient :
- ça oriente en partie le style du jeu (plus de traits et d'aplats, moins de "textures" et d'effets matières)
- si le dessin SVG est complexe (beaucoup de points, flous) ça peut demander beaucoup de ressources au processeur ... en général ça ne se sentira pas mais sur une vieille machine (- de 1 GHz) ça peut être un problème... Après je ne connais pas "SDL_svg" et je ne sais pas exactement comment ça peut modifier les performances. Peut-être qu'il faut garder les fond en bitmap et des personnages en vectoriel...
En fait, si j'ai bien compris, SDL_svg transforme les données SVG en surface SDL (en bitmap).
Donc si l'on fait ça à l'avance, il n'y aura pas de différences de performances lors du jeu. En revanche, les temps de chargement seront allongés.

yagraph wrote:Un avantage auquel vous n'avez peut être pas penser c'est que SVG a des capacités d'animations, donc vous ajouteriez les fonctions d'anim du même coup.

Hélas, je ne pense pas que l'on puisse en profiter... SDL_svg fait tout lui-même (il n'a besoin que d'un parseur XML), et certaines fonctionnalités manquent à l'appel. C'est notamment le cas des dégradés vers l'alpha, qui fonctionnent très mal, et des ombres (voir la capture ci dessous)
Image

yagraph wrote:Sinon j'ai deux idées à vous soumettre :
- faire une partie "tutoriel" : un ami avait tester le jeu, ça ne lui a pas trop plu... jusqu'au moment où il s'est rendu compte par hasard qu'on pouvait sauter :roll: (il le testait chez lui, je n'étais pas là) !
l'idée du tutoriel demanderais peu de chose : un niveau en mode solo contre une IA 0 par exemple, où est dessiné en fond (en thème ou en niveau plutôt) des indications sur les quelques mouvements de bases et les règles du jeu... Si il faut on le sépare en 2 ou 3 tableaux, en augmentant progressivement le niveau de l'IA.
Le seul souci c'est de dessiner ça (je peux le faire) et de mettre un bouton Tutoriel dans le mode Solo, et éventuellement de coder un peu pour passer d'un tableau à un autre (je me rends pas compte, mais j'imagine que c'est pas le bout du monde, si ?).
Ça me paraît être une bonne idée. On pourrait peut-être proposer de lancer le mode tutoriel après que l'utilisateur se soit créé un compte...

yagraph wrote:- une petite demande de graphiste : ça serait vraiment bien de pouvoir avoir un "calque" de premier plan dans les niveaux :ugeek:
A priori, ça ne devrait pas être trop difficile (comparé au reste :mrgreen: )
User avatar
VinDuv
Administrateur du site
 
Posts: 20
Joined: 30 Jan 2008, 21:40

Re: [RFC] Slime Volley 3.0

Postby MCMic » 20 Jun 2009, 16:35

Carrément des comptes utilisateur :-/

Comment compte tu gérer les parties en réseau local si on est connecté en permanence?

Pour les skins je pense qu'on doit laisser libre chaque équipe de choisir son skin, je pense même qu'on devrait empêcher que deux équipes ai la même skin.
Les skins accordées avec un niveau se débloqueront dans le mode solo.

Pour l'IA c'est compliqué, soit l'IA a toujours le même skin (qui dépend de son niveau), soit on continue d'avoir une skin d'IA par skin(thème), mais à ce moment là on pourra pas demander au designeur de skin de prévoir 4 skins d'IA...
Je préfèrerais que les IAs gardent leur skin indépendamment du skin de l'équipe.
VinDuv wrote:Je pense que l'on doit pouvoir tuner le tout pour que l'ensemble se comporte à peu près comme actuellement, à part peut-être en ce qui concerne la collision balle/balle.
Mais ça rendrait aussi bien plus facile l'implémentation d'options supplémentaires (vent, ...)

Oui mais une collision balle-balle ça change énormément le gameplay (et slime-slime encore plus), et a-t-on vraiment besoin d'options supplémentaires?
User avatar
MCMic
Administrateur du site
 
Posts: 90
Joined: 30 Jan 2008, 22:17
Location: Ubuntu 8.04

Re: [RFC] Slime Volley 3.0

Postby yagraph » 22 Jun 2009, 11:13

Salut, me revoilà... *pas très réveillé un lendemain de fête de la Musique*

MCMic wrote:pour l'arborescence des menus ce sera fait. (mais c'est assez difficile de savoir quoi séparer, tournoi/match simple? local/réseau? libre/solo?)


C'est justement l'objectif quand on fait un plan de site : voir toutes les étapes en ayant une vue d'ensemble :)
Comme ça on peut modifier tout ça facilement, changer l'organisation, et vérifier que c'est cohérent et simple !

a priori d'après ce que j'ai lu de vos propositions ça serait quelque chose comme ça :
-menu d'accueil (racine)
- mode solo
- - Une partie rapide contre l'IA (options aléatoires automatique)
- - Tournoi contre l'IA
- - - choix d'un tournoi prédéfini qui débloque des items
- - Tutoriel
- - État de thèmes et niveaux débloqués/à débloquer
- mode libre (en local)
- - Une partie libre
- - - menu de match
- - Tournoi
- - - choix du tournoi
- mode réseau (multijoueur sur internet/lan (case à cocher pour limiter au réseau local))
- - Une partie libre
- - - menu de match
- - Tournoi
- - - choix du tournoi
- options
- - Configurer mon équipe (nom, skin...) (mais attention il peut y avoir plusieurs équipes en local)
- - thème
- - langue
- - affichage
- - - plein écran
- - - score On/off
- - - FPS On/off
- - - résolution ?
- - audio
- - - son on/off
- - clavier (définir les touches)
- crédits
- quitter

Évidement c'est à modifier/améliorer...

MCMic wrote:Pour le calque de premier plan je suis assez sceptique, ça me parait nuire au gameplay


Pour défendre mon bout de gras : le but n'est pas de cacher la balle, mais de permettre plus de liberté graphique :
je vais pas mettre un gros carré noir au milieu qui cache tout ! le feuillage ou les nuages devront être léger, éventuellement semi-transparent.
C'est pour renforcer l'immersion, pas pour nuire au gameplay... mais il faut bien sûr que ça soit bien utilisé.

VinDuv wrote:si j'ai bien compris, SDL_svg transforme les données SVG en surface SDL (en bitmap).


Bon, pour SVG, si c'est mal implémenter et que au final c'est du bitmap, ça vaut pas du tout le coup, autant rester en bitmap, qui nous offre plus de possibilités, et ne pas rajouter une couche technique qui ne fera que gêner. En gros c'est intéressant que si ça fonctionne parfaitement et que toutes les fonctions de SVG sont utilisables.

MCMic wrote:Pour le tutoriel c'est pas idiot, j'aurais tendance à simplement faire un niveau qui serait le premier du mode solo avec en fond les touches et quelques astuces. (sautez en avançant pour faire un saut circulaire, sautez verticalement au filet pour contrer les attaques adverses, essayez de taper la balle avec le bord avant de la slime en sautant pour smasher, trompez votre adversaire en utilisant les rebonds, ...)

Alors, c'est faisable, mais je sais pas si ça va tout entrer dans un seul fond ! Est ce que ça serait pas plus clair de faire les choses par étapes dans plusieurs tableaux ? Et est-ce que vous n'avez pas prévu de permettre ce genre de choses pour les tournois par exemple ? Du coup le tutoriel serait organisé comme un tournoi, seulement il aurais sa propre entrée dans le menu.

Enfin, j'ai réalisé qu'il y a un problème pour le tutoriel... Si on écrit les instructions en fond, elles vont être en français ou en anglais ! comment on fait pour traduire ?
je peux essayer de faire un tuto que avec des schémas, sans textes, mais je ne sais pas si ça va être très compréhensible...
Sinon on les écrits dans les deux langues, mais ça prends plus de place, et qu'est ce qui se passe si on ajoute une autre langue ?
J'essaye d'en faire un avec seulement des schémas pour voir ce que ça donne.

MCMic wrote:Carrément des comptes utilisateur :-/


Moi non plus je serais pas trop pour des comptes utilisateurs... pas du tout envie de m'inscrire et d'avoir un mot de passe pour jouer à un "petit jeu" comme Slime volley !
Et ça risque d'en rebuter plus d'un !
Par contre que mon nom d'équipe, les touches et le skin d'équipe soit réutilisé dans les parties en réseau depuis les options que j'ai choisit en local, oui, carrément d'accord.
Un peu comme ce qui se passe dans Tee worlds actuellement quoi.

VinDuv wrote:Utilisation d'un moteur 2D pour la physique du jeu : Chipmunk pourrait convenir mais en fait peut-être un peu trop...


à mon avis le jeu est déjà bien comme ça, mais si vous compter faire beaucoup d'amélioration sur la physique ou si vous comptez à long terme avoir d'autre types de jeu (pas seulement du volley), ça vaut le coup. mais c'est un gros boulot à ne pas prendre à la légère !
yagraph
 
Posts: 21
Joined: 06 Nov 2008, 15:26

Re: [RFC] Slime Volley 3.0

Postby MCMic » 22 Jun 2009, 12:12

Il faut différencier les tournois, qui seront de vrais tournois comme dans tous sports, et le mode solo qui permet d'avancer dans différents tableau en devant battre à chaque fois une IA ou une équipe d'IA.

Pour les menus je ferais un truc ce soir si j'ai le temps mais j'aurai peut-être pas internet. Je pense que yaura moins de trucs que sur ce que tu as mis.

Pour le calque de premier plan effectivement si c'est bien utilisé et principalement transparent pourquoi pas, que dirais tu de faire un charte graphique pour les niveaux et les skins de Slime Volley? (sachant qu'un niveau regroupe un fond de terrain, un jeu de sons, une image de balle et une image de flèche (et une police d'écriture)
Un skin représente un ensemble de dérivation d'un même skin, basés sur le même principe (autant ça peut juste être un changement de couleur, autant la slime gnome et la slime KDE pourrait être deux déclinaison d'un même skin)

On pourrait permettre plusieurs campagnes dans le mode solo, et par défaut proposer le mode solo + une campagne de tutoriel :)
Mais dans l'idéal il faudrait gérer le tutoriel à la main dans le code, pour pouvoir donner des instructions au fur et à mesure et ne pas compter les points. (expliquer comment sauter et attendre qu'il ai sauté, ...)
Ce qui serait bien aussi serait un terrain qui donne toutes les dimensions visuellement (bords du filet jusqu'en haut de l'écran, hauteur de slime, hauteur maximale de saut de slime, ...)

Pour le moteur 2D actuellement les rebonds sous la slime ne sont toujours pas géré correctement, et quand on coince la balle entre deux objets (slime, mur, filet, ...) ça fait des trucs bizarres.
User avatar
MCMic
Administrateur du site
 
Posts: 90
Joined: 30 Jan 2008, 22:17
Location: Ubuntu 8.04

Re: [RFC] Slime Volley 3.0

Postby VinDuv » 22 Jun 2009, 15:19

yagraph wrote:
VinDuv wrote:si j'ai bien compris, SDL_svg transforme les données SVG en surface SDL (en bitmap).
Bon, pour SVG, si c'est mal implémenter et que au final c'est du bitmap, ça vaut pas du tout le coup, autant rester en bitmap, qui nous offre plus de possibilités, et ne pas rajouter une couche technique qui ne fera que gêner. En gros c'est intéressant que si ça fonctionne parfaitement et que toutes les fonctions de SVG sont utilisables.
Ce qui m'intéresse surtout dans le SVG, c'est le fait de pouvoir mettre à l'échelle les graphismes sans pixellisation. Ça serait sans doute intéressant que Slime Volley puisse tourner avec des résolutions différentes de 800x600.
Pour les résolutions inférieures, ce n'est pas trop un problème (à condition d'implémenter une mise à l'échelle correcte, avec antialiasing). Pour les résolution supérieures, ce serait bien plus problématique (on pourrait augmenter la taille des bitmaps mais leur traitement exigerait du coup d'importantes quantités de RAM).
Dans tous les cas, je pense qu'il serait intéressant de rendre le code de Slime Volley indépendant de la résolution (par exemple en utilisant une unité de mesure ne s'appuyant pas sur le pixel).

yagraph wrote:
MCMic wrote:Carrément des comptes utilisateur :-/


Moi non plus je serais pas trop pour des comptes utilisateurs... pas du tout envie de m'inscrire et d'avoir un mot de passe pour jouer à un "petit jeu" comme Slime volley !
Et ça risque d'en rebuter plus d'un !
Par contre que mon nom d'équipe, les touches et le skin d'équipe soit réutilisé dans les parties en réseau depuis les options que j'ai choisit en local, oui, carrément d'accord.
Un peu comme ce qui se passe dans Tee worlds actuellement quoi.
Il n'y aura pas de mot de passe, ça c'est sûr. Le but est de faciliter la vie des joueurs, pas de la compliquer.

En ce qui concerne la réorganisation des menus :
Actuellement, dans le menu principal il y a à la fois des choix qui ouvrent des menus supplémentaires (Options, entre autres), et d'autres qui modifient une option (Vitesse, Balles...). Je pense que ergonomiquement, c'est discutable. Il vaudrait mieux que le menu principal n'ait que des choix qui amènent à d'autres "panneaux".
Ce qui veut dire qu'avant l'écran de sélection d'équipe (si on est en mode libre ou serveur), il faudrait inclure un menu qui propose de régler le nombre d'équipes, la vitesse, le nombre de balles, le thème, le nom et le mode d'annonce du serveur (si on est en mode serveur bien sûr)
User avatar
VinDuv
Administrateur du site
 
Posts: 20
Joined: 30 Jan 2008, 21:40

Next

Return to Le jeu

Who is online

Users browsing this forum: No registered users and 1 guest

cron