camelot-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Camelot-discuss] Organisation


From: Sven Luther
Subject: Re: [Camelot-discuss] Organisation
Date: Mon, 3 Feb 2003 13:15:39 +0100
User-agent: Mutt/1.5.3i

On Mon, Feb 03, 2003 at 10:54:41AM +0100, Luc Mazardo wrote:
> 
> > Oui, c'est l'objectif mais nous pensons qu'il est plus intéressant
> > de réunir nos forces pour coder tout ce qui peut être fait en
> > commun : bibliotheques de sprite, de scrolling, de detection de collision
> > et la scenarisation des jeux en 2D.
> Nous devrions inventorier les besoins sous la forme d'une liste
> et developper point a point chaque element de cette liste afin d'arriver
> a une description bien precise des modules.
> 
> Je pense qu'une bibliotheque de gestion de ressources serait utile
> afin de pouvoir concentrer images/sons/fichiers divers dans un seul
> fichier. Y a t'il ce genre de bibliotheques ecrite deja en caml ? 
> Je ne pense pas, nous pourrions nous baser sur une gestion simplifiée 
> de filesyteme virtuel ou alors sur un truc du genre CamlZip.
> 
> > Le but est d'avoir un prototype au plus tôt et de tester avec
> > un jeu, en même temps et non pas de faire un jeu une fois
> > que tout est fini.
> Pour un jeu simple, je pensais a un tetris, pourquoi pas adapter la
> version de lablgtk ?

Il y a un tetris dans lablgtk ?

En fait c'est pas une si mauvaise idee de commencer par un tetris, cela
met deja a jour un certain nombre de besoin.

Pour un tetris (ou tout autre jeu de plateau similaire) il faut :

  o des graphismes, briques qui tombe, 'skin' du jeu (avec score,
    instructions, prochaine brique, etc.).
    En fait, il faut plus que cela, il faut une maniere de stocker les
    graphismes dans un fichier, si possible compresse, de pouvoir les
    lires facilement, de pouvoir les mettres a l'echelle voulu, et les
    desiner a l'ecran, ce qui nous amene au second point.

  o Pouvoir desiner des choses a l'ecran, cela inclus l'affichage de
    graphismes statiques, mais aussi le deplacement des pieces vers le
    bas et leur rotation. J'imagine qu'on peut simplement effacer
    l'ancienne piece et redesiner la nouvelle, mais quelque chose de
    plus fluide serait sympa aussi.

  o Il faut un module de saisie d'interaction, clavier, souris,
    joystick, autre.

  o Et finalement, il faut le coeur meme du jeu. l'algorithme
    relativement simple qui genere les nouvelles pieces, les fait
    apparaitre dans la prevue et en haut de l'ecran, leur chute et le
    test de ligne complete lorsqu'elle arrive en bas.

  o On rajoute un module de sauvegarde de score, et eventuellement de
    partie en cours, et cela y est.

Je pense que la partie la plus complexe ici, au niveau des
bibliotheques, est la premiere partie, sur, on peut simplement desiner
des blocs mono-color et avoir un graphisme simple pour l'interface, mais
il serait sympa d'aller plus loin ici, permettant au jeu de s'adapter a
la resolution choisi par l'utilisateur, non comme frozen-bubble ou
d'autre jeu sdl qui persiste a vouloir switcher en 640x480 alors que mon
moniteur ne le supporte pas, et ceci en depis du fait que je n'ai pas
configurer de mode 640x480 dans mon XF86Config.

On peut utiliser, soit ce que gtk/gnome utilise, soit camlimages. Est-ce
qu'il y a quelqu'un d'assez familier avec camlimages pour donner son
avis a ce sujet ?

Amicalement,

Sven Luther




reply via email to

[Prev in Thread] Current Thread [Next in Thread]