2010-04-12 5 views
3

Je fais un petit jeu de stratégie pour m'aider à apprendre Java de manière amusante. La chose est que j'ai visionné les unités comme des objets qui se dessineraient sur la carte de jeu (en utilisant des images et un tampon) et réagiraient aux actions de la souris avec les auditeurs qui leur sont attachés. Maintenant, selon certains tutoriels que j'ai lus concernant la programmation de base du jeu, tout semble être dessiné dans la méthode Graphics de ma classe Map. Si une nouvelle unité émerge, je mets juste à jour la méthode Map.Graphics, ce n'est pas aussi simple que de créer un nouvel objet Unit qui se dessine ... Dans ce cas, je serais coincé avec tout un tas de méthodes Map au lieu de utiliser des classes pour rendre de nouvelles choses. Donc, ma question est, est-il possible d'utiliser des classes pour rendre des unités, des objets d'interface, etc., ou je vais devoir créer des méthodes et juste faire une sorte de programmation structurelle au lieu d'orienté objet? Je suis un peu confus et j'aimerais avoir un plan mental sur la façon dont les choses seraient organisées.Java Classes dans la programmation de jeux?

Merci!

Répondre

1

Comme ck dit, vous pouvez le faire avec une interface drawable, quelque chose comme:

public interface GameElement { 
    public void draw(Graphics g); 
} 

public class Sprite implements GameElement{ 
    private Image image; 
    private int x; 
    private int y; 
    public void draw(Graphics g) { 
       g.drawImage(image,x,y,null); 
    } 
} 

public class GameLoop { 

     public void drawElements(final Graphics2D g, final List<GameElement> elements) { 
       for (final GameElement gameElement : elements) { 
         gameElement.draw(g); 
       } 
     } 


} 

mais la façon dont vous avez dit que vous voulez le faire, avec un auditeur, peut vous donner des problèmes à l'avenir. Comme dash-tom-bang déjà pointé, tous les éléments sont rendus dans une seule boucle de jeu, après que tous ont été déjà mis à jour. Si vous faites cela avec un écouteur et que vous avez une boucle de jeu ou tout autre thread modifiant la liste des unités, vous pouvez vous retrouver avec une modification d'accès simultanée. En outre, de cette façon, vous allez dessiner tous les éléments en un seul point, ce qui évitera un scintillement bizarre sur votre jeu.

4

Des sons comme vos objets doivent avoir une interface commune à laquelle ils peuvent tous être redirigés vers le rendu.

E.g. ayez une liste générique de votre type d'interface, remplissez-la avec les objets du jeu, puis énumérez la liste et appelez la méthode commune pour effectuer le rendu.


C'est le code C#, mais il devrait être similaire pour Java

public interface IRenderable 
{ 
    void RenderMe(Graphics graphics) 
} 

List<IRenderable> myGameObjects; 

foreach (IRenderable myGameObject in myGameObjects) 
{ 
    myGameObject.RenderMe(myMap); 
} 

Alors que les objets sont maintenus dans la liste, ils peuvent répondre à des événements et mettre à jour leur état interne prêt pour le prochain cycle rendu .

1

Alors que les projets de « vrai » jeu se présentent sous plusieurs formes, en fin de compte vous avez quelque chose comme ceci:

while True: 
    ProcessUserInput() 

    for o in objects: 
     o.Update() 

    for o in objects: 
     o.Render() 

Utilisez ce mécanisme vous trouvez cher à mettre en œuvre toute de ces fonctions. :) Polymorphisme est très bien, donc vous devriez vous sentir libre d'utiliser cela si vous êtes à l'aise avec cela. La "carte du monde" devrait probablement être le premier élément de la liste, à moins que votre système de rendu ne soit suffisamment avancé pour gérer le dessin en désordre (le tri en profondeur, fondamentalement).

D'après votre question, il se peut que les unités appartiennent à la carte? Dans ce cas, la fonction Map.Render parcourrait toutes les unités qui lui appartiennent, appelant Render sur chacune d'entre elles. Peu importe, c'est probablement le plus propre si le code pour dessiner une unité est dans la classe pour cette unité.

Bonne chance!