Gamedesign oder "Wie spreche ich Buttons über einen String an?"

  • Gamedesign oder "Wie spreche ich Buttons über einen String an?"

    Hallo,
    wollte mich mal ein bisschen an einem Spiel probieren, nicht um etwas für den AppStore zu produzieren, sondern einfach weil .. so halt :) Meine grundsätzliche Idee war einen Spielplan zu erstellen auf dem Spielfiguren stehen und diese können unterschiedlich weit bewegt werden und andere Spielfiguren attackieren, wenn sie am Nachbarfeld stehen. (Prinzipiell so ähnlich wie die Kämpfe der Spiel Serie Heroes of MIght and Magic, falls das jemanden etwas sagt)

    Nun habe ich mir überlegt wie viele Felder ich integrieren will und wie ich diese Felder ansprechen und auch graphisch verändern kann. Einen Spielplan von 8 * 10, 10 * 12 oder 12 * 14 Felder würde mir vorschweben.
    Es werden also 80, 120 oder 168 Felder angelegt. Rechteckig wie bei einem Schachbrett.

    Da die Figuren immer auf diese vordefinierten Felder müssen, dachte ich zuerst an eine Menge an Buttons. Diese würde ich entweder in ein Array geben und so könnte ich sie dann ansprechen, leichter wäre es vermutlich wenn ich sie Feldxy nenne und dann über einen String ansprechen könnte, nur geht das? Habe dazu nichts gefunden oder übersehe ich da etwas?

    Andere Überlegung wäre einfach den touch zu nehmen und die Position im View zu finden und dann das gemeinte Feld somit zu finden, dann fällt aber die Möglichkeit weg dieses Feld leicht graphisch anzupassen (aufhellen, abdunkeln, etc.) und ich müsste eventuell Views zeichnen die dann draufgelegt werden, nur denke ich ist die graphische Veränderung nur mit sehr großem Aufwand zu bewerkstelligen?

    Meine Fragen an euch sind nun:
    Kann ich ein View Element mittels String ansprechen?
    Wie würdet ihr so einen Spielplan anlegen? Buttons? Ohne Buttons?

  • MCDan schrieb:

    Du könntest die Buttons/Views z.B. auch in ein (Mutable)Dictionary packen und dann über die Position xy, also z.B. 1-1 für links oben, 8-1 für rechts oben, 1-10 für links unten und 8-10 für rechts unten ansprechen.

    Wenn die Schlüssel allerdings ganze Zahlen sind, spricht einiges für Arrays. ;-)
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Hier wurden ja schon einige Wege erwähnt, wie man die Buttons wieder zuordnen kann. Das geht alles mehr oder weniger elegant, für mich sieht das alles aber eher nach Notlösung aus.

    Ich würde den anderen Weg aus dem OP gehen: Ein Custom View. Anpassungen des Aussehens halte ich da nicht für schwieriger, sondern einfacher. Man braucht im Wesentlichen nur eine Methode, die die das Spielfeld malt und einen touch-Handler. Immer wenn sich etwas ändert muss halt ein Redraw ausgelöst werden - das ist aber kein Problem, wenn man sich halbwegs ordentlich an MVC hält.

    Buttons gehen zwar für den Zweck, sind aber eigentlich nicht dafür gemacht. Spiele unterscheiden sich häufig im Aussehen und Verhalten von der Standard-GUI - der Anfang ist mit Buttons vielleicht einfacher, aber an irgend einer Stelle wird's dann ein erheblicher Aufwand, das Verhalten und Aussehen von Buttons so umzubiegen, dass es passt. Im Gegensatz dazu kannst du in einem Custom View das tun, was du willst. Nur ganz einfache Spiele nutzen die Standard-GUI-Elemente, über kurz oder lang wirst du wahrscheinlich eh bei Custom Views (oder OpenGL oder irgendeiner Engine) landen.
    Multigrad - 360°-Produktfotografie für den Mac

  • Hallo und danke für die vielen tollen Antworten. :)
    Ich habe jetzt die letzten zwei Wochen genutzt um endlich richtig mit diesem Projekt zu beginnen.
    Nach langem überlegen habe ich mich doch für Sechsecke (Hexagons) entschieden und bin bis jetzt ziemlich zufrieden damit. 165 Felder und ein implementierter A* später stehe ich vor einem weiteren (hoffentlich kleinen) Problem.


    Ich habe nun meinen View, den ich im xib file ein bisschen auslege, also buttons und log box etc.
    Dann zeichne ich mein Spielfeld mit 165 UIControl-Subklassen die jeweils auch gleich meinen Touch entgegennehmen.
    Mein Controller kümmert sich nun drum, dass das Spielfeld an der richtigen Stelle gezeichnet wird und kümmert sich auch um das anzeigen aller begehbaren Felder.
    Der Controller kümmert sich zusätzlich um die Wegfindung. Nach einem Touch in ein begehbares Feld, findet er einen der kürzesten Weg dorthin und zeichnet ihn dem Spieler an.

    Mein Model hat im Moment nur die Aufgabe meine verschiedenen Spielfiguren zu halten und sich um die Zug Reihenfolge der Kreaturen zu kümmern.

    Jetzt habe ich allerdings zu meinen UIView Subklassen, die meine Spielfiguren darstellen auch einige Informationen die ich zu diesen gleich dazu speichere (Anzahl, Lebenspunkte, Reichweite der Bewegung, etc.)

    Um meine Figuren aber im Controller verschieben zu können , wenn es nötig ist, brauche ich aber auch hier wieder zugriff darauf und sie müssen ja außerdem vom View gekannt werden.


    Mein Problem besteht also darin, dass ich einfach in diesem Fall keine schöne MVC Trennung habe, bin im Moment leider etwas ratlos, wie ich das Umsetzen soll, denn so wie es im Moment ist ist ein Model überflüssig und der Controller macht zu viel und wird schön langsam unübersichtlich.

    Würde mich über Tips, Ratschläge oder Hinweise freuen :)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von triplejberger ()

  • Ich hab den Thread nur kurz überflogen, aber im Prinzip ist es nicht schwierig.
    Kurz angerissen:
    Soundmanager -> verwaltet alles was mit Mucke zu tun hat
    Grafikmanager -> wie der Name schon Sagt, Hintergrundgrafiken, Sprites, usw...
    Gameobject -> abstrakte Klasse (Interface) von dem Du deine Spielfiguren ableitest, in aller Regel hat die nicht als, Position, Geschwindigkeit, ist Tot, usw... solche Dinge halt.
    Gamemanager -> der den kompletten Renderloop, Kollisionsabfrage usw... enthält
    AIManager -> der für deinen Path zuständig ist, berechnen, usw...

    usw...
    Am besten malst du dir das mal auf ein Blatt Papier auf und verbindest die Objekte mit Linien, dann weißt du wie die grob zusammen spielen.

    Noch ein Tipp am Rande, ich würde nicht mit den mitgelieferten Views (UiView) Controllern arbeiten, je mehr du davon auf deinem Spielfeld hast um so mehr geht deinen Kiste irgendwann in die Knie.
    Du brauchst in aller Regel die ganze Funktionalität von den Klassen gar nicht, eine simple Kollisionsabfrage ob eine Figur angetippt wird ist eigentlich schon fast alles.
    Zeichnen tust du mit OpenGL, bzw. der neuen Spriteklasse (ich glaub auf dem Telefon gibts die schon länger)
    Nimm nicht die Klassen, die für die "normalen" Apps gedacht sind.

    Hier mal ein kleines Tut, ist zwar schon älter aber so im Prinzip passt das auch auf dein Vorhaben:
    wr-media.net/worm-x.php

  • Danke. Das hat mir einiges weitergeholfen. So ist das ganze schon mal viel wartbarer und übersichtlicher geworden, doch ich bin immer noch nicht ganz sicher, ob ich mit meiner neuen Implementierung dem MVC Konzept entspreche und ob es überhaupt Sinn gemacht hat was ich meiner App angetan habe, nämlich:
    Einen AIManager/GameboardManager, der alle Informationen über das Spielfeld hat und die Laufwege berechnet. Habe hier eine Klasse die alle Daten pro Feld speichert und die vom View gefragt wird, wie es sich genau präsentieren soll.
    Also ist das ja irgendwie eine direkte Kommunikation von Model und View die laut MVC ja eigentlich strikt verboten ist.

    Der Controller hat nur weak Verbindungen zu den ganzen View Objekten und spricht diese auch niemals an, denn sie Fragen selbst beim Model nach.

    Kann mir wer noch einen konkreteren Tipp zur MVC Implementierung geben?
    Danke. Wäre sehr dankbar. :)

  • Dein GameboardController holt die Daten beim Model und gibt sie an dein View weiter. ich versteh nicht so richtig wo das Problem ist.
    Ganz abstrakt so ungefähr

    Quellcode

    1. MyModel
    2. {
    3. char checkerBoard[5][5];
    4. }
    6. MyView
    7. {
    8. id view recnderView;
    9. }
    11. MyController
    12. {
    13. MyModel *model;
    14. MyView *render;
    15. }
    17. void* data=[model checkerBoardData];
    18. mach was damit
    19. [render renderData:data];
    Alles anzeigen