Einsteiger Fragen

  • Einsteiger Fragen

    Hallo zusammen,
    Ich möchte ein iPhone-Spiel entwickeln, hänge bisher aber noch an allgemeinen Dingen. Ich will erstmal mit kleinen Projekten die Grundlagen lernen, bevor ich mich an sowas wie ein Spiel waage. Der oberste Grundsatz "RTFM" ist mir bekannt, allerdings gibt es ein paar Dinge, die ich bisher nirgends gefunden haben.
    Als Hintergrund-Info, damit ihr meinen Wissensstand einordnen könnt ich hab in der Schule früher ein paar Jahre Delphi gelernt (bin also Programmier-Einsteiger mit Grundwissen) und bin mit der Grundlage objektorientierter Programmierung vertraut, hab aber absolut keine C Kenntnisse.
    Ich habe bisher aus verschiedenen Quellen wie Apples Dokus, Büchern und einem Video der Uni Stanford (super für Einsteiger!) Informationen aufgesogen, aber ein paar Bereiche fehlen mir immer.

    1. Sind Namen von Variablen, Klassen und Methoden case-sensitive?
    Mit der Objective C Einführung von Apple bin ich noch nicht ganz durch, aber ich hätte sowas an den Anfang gesetzt, wenn ich sowas schreiben würde, und da hab ichs nicht gefunden.

    2. macht es einen Unterschied ob ich
    NSSTring *string =
    NSSTring * string=
    NSSTring* string=
    schreibe? (analog die Frage ob es für Leerzeichen Normen gibt, außer das sie nicht mitten in Namen von z.B. Klassen und Objekten stehen können.) Wo werden diese... bei Delphi heißen sie "Pointer", erklärt? Steht das in diesem PDF?
    developer.apple.com/iphone/lib…ual/OOP_ObjC/OOP_ObjC.pdf
    Das hatte ich nämlich noch nicht gelesen.

    3. Würde es für mich Sinn machen erstmal C Tutorials und Erklärungen zu lesen, weil diese Dinge in ObjC Docs eher als bekannt vorrausgesetzt werden? Grad was die Syntax von Schleifen angeht und grundlegende Funktionen a la random etc..

    4. Das ist jetzt eventuell das falsche Forum, aber ich versuchs trotzdem, weil ich vermute, dass ich nur eine der Grundlagen nicht verstehe, und es nichts iPhone-spezifisches ist.
    Ich will die Cocos2D Enginge fürs iPhone verwenden um damit die Grafikanzeige zu realisieren. In einem Tutorial dazu habe ich eine Methode gesehen, die aufgerufen wird, wenn man das Display berührt hat und wieder loslässt "ccTouchesEnded". Darauf kann man zugreifen indem man im implementation Teil schreibt:

    Quellcode

    1. - (void)ccTouchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
    2. // hier der code
    3. }


    Das Tutorial aus dem ich das habe ist hier:
    raywenderlich.com/352/how-to-m…ame-with-cocos2d-tutorial

    Und da schreibt der Autor:
    Ok, so onto the code. First we have to enable touches on our layer. Add the following line to your init method:
    self.isTouchEnabled = YES;
    Since we’ve enabled touches on our layer, we will now receive callbacks on touch events. So let’s implement the ccTouchesEnded method, which is called whenever the user completes a touch, as follows:


    Jetzt meine Frage: was genau ist ein Callback und was unterscheidet ihn von einem regulären Methodenaufruf? Für mich als Laie sieht das so aus, als wär der Callback genau so implementiert, als wäre es eine Methode des "Haupt-Objektes", die irgendwo im Code von einem Framework aufgerufen wird, wenn man das Display berührt/loslässt und dann als Aufruf an mein Objekt geschickt wird, und wenn ich das als Methode implementiert hab passiert was, und wenn nicht, dann halt nicht?! Das... versteh ich ehrlichgesagt nicht ganz. Wie kann ich meine Bildungslücke da schließen?

    So, vielen Dank schonmal. Ich hoffe ich habe meine Fragen sinnvoll formuliert :).
  • RE: Einsteiger Fragen

    Original von MartinH.
    Hallo zusammen,
    Ich möchte ein iPhone-Spiel entwickeln, hänge bisher aber noch an allgemeinen Dingen. Ich will erstmal mit kleinen Projekten die Grundlagen lernen, bevor ich mich an sowas wie ein Spiel waage. Der oberste Grundsatz "RTFM" ist mir bekannt, allerdings gibt es ein paar Dinge, die ich bisher nirgends gefunden haben.
    Als Hintergrund-Info, damit ihr meinen Wissensstand einordnen könnt ich hab in der Schule früher ein paar Jahre Delphi gelernt (bin also Programmier-Einsteiger mit Grundwissen) und bin mit der Grundlage objektorientierter Programmierung vertraut, hab aber absolut keine C Kenntnisse.
    Ich habe bisher aus verschiedenen Quellen wie Apples Dokus, Büchern und einem Video der Uni Stanford (super für Einsteiger!) Informationen aufgesogen, aber ein paar Bereiche fehlen mir immer.

    1. Sind Namen von Variablen, Klassen und Methoden case-sensitive?
    Mit der Objective C Einführung von Apple bin ich noch nicht ganz durch, aber ich hätte sowas an den Anfang gesetzt, wenn ich sowas schreiben würde, und da hab ichs nicht gefunden.

    Ja


    Original von MartinH.2. macht es einen Unterschied ob ich
    NSSTring *string =
    NSSTring * string=
    NSSTring* string=
    schreibe? (analog die Frage ob es für Leerzeichen Normen gibt, außer das sie nicht mitten in Namen von z.B. Klassen und Objekten stehen können.)

    Es macht keinen Unterschied.

    Original von MartinH. Wo werden diese... bei Delphi heißen sie "Pointer", erklärt? Steht das in diesem PDF?
    developer.apple.com/iphone/lib…ual/OOP_ObjC/OOP_ObjC.pdf
    Das hatte ich nämlich noch nicht gelesen.

    a) Du solltest es ohnehin lesen.
    b) Aber C-Kram wird nirgendwo bei Apple erklärt.

    Original von MartinH.3. Würde es für mich Sinn machen erstmal C Tutorials und Erklärungen zu lesen, weil diese Dinge in ObjC Docs eher als bekannt vorrausgesetzt werden? Grad was die Syntax von Schleifen angeht und grundlegende Funktionen a la random etc..

    Überwiegend C, siehe oben.

    Original von MartinH.4. Das ist jetzt eventuell das falsche Forum, aber ich versuchs trotzdem, weil ich vermute, dass ich nur eine der Grundlagen nicht verstehe, und es nichts iPhone-spezifisches ist.
    Ich will die Cocos2D Enginge fürs iPhone verwenden um damit die Grafikanzeige zu realisieren. In einem Tutorial dazu habe ich eine Methode gesehen, die aufgerufen wird, wenn man das Display berührt hat und wieder loslässt "ccTouchesEnded". Darauf kann man zugreifen indem man im implementation Teil schreibt:

    Quellcode

    1. - (void)ccTouchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
    2. // hier der code
    3. }


    Das Tutorial aus dem ich das habe ist hier:
    raywenderlich.com/352/how-to-m…ame-with-cocos2d-tutorial

    Und da schreibt der Autor:
    Ok, so onto the code. First we have to enable touches on our layer. Add the following line to your init method:
    self.isTouchEnabled = YES;
    Since we’ve enabled touches on our layer, we will now receive callbacks on touch events. So let’s implement the ccTouchesEnded method, which is called whenever the user completes a touch, as follows:


    Jetzt meine Frage: was genau ist ein Callback und was unterscheidet ihn von einem regulären Methodenaufruf? Für mich als Laie sieht das so aus, als wär der Callback genau so implementiert, als wäre es eine Methode des "Haupt-Objektes", die irgendwo im Code von einem Framework aufgerufen wird, wenn man das Display berührt/loslässt und dann als Aufruf an mein Objekt geschickt wird, und wenn ich das als Methode implementiert hab passiert was, und wenn nicht, dann halt nicht?! Das... versteh ich ehrlichgesagt nicht ganz. Wie kann ich meine Bildungslücke da schließen?

    So, vielen Dank schonmal. Ich hoffe ich habe meine Fragen sinnvoll formuliert :).

    Der Autor gehört offenkundig zur Kategorie: Gestern Blödsinn gelernt und jetzt schon ins Internet schreiben. :)

    Ernsthaft: Der Begriff Callback ist schlicht falsch verwendet. Da hat noch jemand mehr C-vergangenheit als Objective-C-Verständnis.
    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"?
  • Wow, das ging ja schnell! Vielen Dank für die Blitzantwort! Dann werd ich mir erstmal C Grundlagen aneignen und in den Docs schauen ob ich was über Callbacks finde (ich gehe davon aus). Ist ja tückisch, dass sowas in Tutorials falsch verwendet wird. Als Anfänger merkt man das ja nicht, dass das Unsinn ist. Und dann ist die Verwirrung groß :D.
  • RE: Einsteiger Fragen

    Original von MartinH.
    bin mit der Grundlage objektorientierter Programmierung vertraut


    Sagen dir die Begriffe "Model View Controller" etwas? Wenn nicht, würde ich an deiner Stelle überlegen, ob ich mir nicht mehr Zeit lassen bis zu einem Computerspiel und stattdessen nach C erst mal Objektorientierte Programmierung lerne - je nachdem, wie geduldig du bist und wie gründlich du die Thematik können möchtest.

    Falls du einen guten Einstieg in die Objektorientierte Programmierung haben möchtest, kann ich dir - nachdem du C einigermaßen kannst - "Objective-C und Cocoa, Band 1: Grundlagen" von Amin Negm-Awad empfehlen. Meiner Meinung nach das beste und (leider) einzige gute Buch über Objektorientiertes Programmieren (und gleich auch in der richtigen Programmiersprache ;) ).
    Achte darauf, dass du die neuste Auflage nimmst!

    Frohe Ostern,
    Micha
    „Not everyone can become a great artist,
    but a great artist can come from everywhere.”
    (Anton Ego in Ratatouille)
  • @michael: das erste c tutorial von der seite hab ich durch, hat mir sehr geholfen :).

    @remy: hab in meinem einsteiger buch was zu dem model-view-controller design pattern gelesen. so wie ich das verstehe macht das vor allem sinn wenn das interface aus nem nib file kommt. aber sowas wirds bei meinem spiel gar nicht geben. ich schau mir erstmal design patterns für spiele an, da hab ich großen nachholbedarf. vielleicht läuft es ja auf was ganz ähnliches hinaus, wie einen gameloop als model, einen eigenen programmteil der die anzeige immer wieder aktualisiert (view) und einen controller, der die eingaben abfängt und weiterleitet.
    wie geduldig ich bin... ich würde sagen mäßig :D. ich möchte gern direkt an einem spieleprototypen basteln und lieber dann nochmal komplett alles neu schreiben, wenn ich den ersten versuch vor die wand gefahren hab, wovon fast auszugehen ist. ich bin da realist.
    ich schau mal ob ich das buch in der bibliothek finde, danke.


    wie steht ihr zur vermischung von objective-c und c? ich hab in einem interview mit brian greenstone ( youtube.com/user/PangeaSoftwareInc#p/u/4/jjdJR_-ftns etwa ab 2:25 ) gehört, das es im bezug auf spätere portierbarkeit sinn mache möglichst viel in c zu schreiben.
    und noch ne frage, ist in diesem forum eher gern gesehen einen thread lange weiterzuführen auch wenn das thema wechselt, oder lieber für neue fragen jeweils einen neuen thread öffnen?

    ebenfalls frohe ostern an alle!
  • Gleiche Themen von verschiedenen Leuten: Alter Thread
    Neue Themen von gleichen Leuten: Neuer Thread

    Man sucht später ja nach Themen, nicht nach Leuten.

    Mit Nib-Files hat MVC nichts zu tun. MVC ist deutlich älter.
    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"?
  • model-view-controller ist ein Grundprinzip in der OOP (korrigiert mich, wenn ich blödsinn erzähle) und ist eigentlich für jedes objektorientierte Programm die Basis, deshalb hab ich gefragt^^

    Wenn du eher an praktischen Dingen interessiert bist, wo man evtl. schnell ergebnisse sehen kann.... mh, ich wage mal einen vllt. etwas gewagten Schritt: Vier Ideen, die für dich interessant sein könnten (gewagt ist vor allem die letzte, aber ich finde sie tatsächlich eine der besten Ideen für Spieleentwicklung... :(

    1) Blitzbasic
    wahrscheinlich schreihen jetzt viele "BASIC???", aber für Anfänger ist es imho eine Sprache, die man nicht unbeachtet lassen sollte, auch wenn ich nicht enttäuscht bin, dass ich sie nie gelernt habe.
    Blitzbasic und Blitzbasic 3D sind Basic-Dialekte, die für Spieleentwicklung entwickelt wurden und daher diese sehr einfach gestalten (so liest man zumindest). Haken der Sache: a) es ist nicht kostenlos; b) iPhone entwicklung afaik unmöglich und späterer wechsel zu anderen sprachen evtl. nicht so einfach c) keine Ahnung, obs ne Mac Version gibt

    2) Python mit PyGame
    Python ist eine weitverbreitete Scriptsprache, die einfach zu erlernen ist und dir gleich auch ordentliche Code-Einrückung beibringt (da Python es da sehr genau nimmt).
    Mit PyGame bietet Python ein Modul zur Spieleentwicklung. Vorteil der Sache: Python ist einfach zu erlernen und OOP ist auch erst mal nicht so das Problem - zumindest die Anfänge in Python sind eh nicht OOP. Nachteil der Sprache: Keine Ahnung, wie es mit iPhone Entwicklung aussieht, da musst du dich mal informieren. Zudem ist Python eine Interpretersprache, also langsamer als Objective-C, wobei das anfangs wahrscheinlich kein Problem darstellt.

    3) Unity
    Unity ist ein "Game Development Tool", das auch von Profis genutzt wird. Es gibt eine kostenlose Version, das ganze ist sehr einfach (.NET Javascript, C#), dank Mono plattformunabhängig und bietet professionelle Features (z.B. Import aus Maya, Blender und Photoshop, Physik Engine, Audio&Video, versch. Grafik Features etc etc. Infos bekommst du auf deren Homepage.
    Vorteil: Alles mit drin, inkl. iPhone Entwicklung, einfach zu lernen
    Nachteil: der Lerneffekt ist vermutlich eher eingeschränkt, sofern zu mal auf ObjC umsteigen willst

    4) XNA Game Developer Network
    Das XNA Studio bietet eine komplette Entwicklungsumgebung für Spieleentwicklung auf professionellem Niveau - inkl. OOP in C# und etlichen Werkzeugen (u.a. ein kostenloser 3D-Modeller "ModTools" von Autodesk, den Machern von Maya&Softimage). An dem ganzen hängt eine komplette Community mit Tutorials, Entwicklerteams etc., wo man mitmachen kann und es ist kostenlos!
    Vorteil: Professionelle Werkzeuge (C#, ModTools etc), OOP ist auch gleich mit dabei, sodass du die Grundlagen lernst und (sofern du sie verstanden hast) auch auf ObjC anwenden kannst
    Nachteil: Das ganze ist von Microsoft. Dreimal darfst du raten, wies mit iPhone- und Mac Unterstützung aussieht.

    Original von MartinH.
    wie steht ihr zur vermischung von objective-c und c? ich hab in einem interview mit brian greenstone ( youtube.com/user/PangeaSoftwareInc#p/u/4/jjdJR_-ftns etwa ab 2:25 ) gehört, das es im bezug auf spätere portierbarkeit sinn mache möglichst viel in c zu schreiben.

    Ich hab zwar noch keine soo große Erfahrung, aber eine Vermischung von ObjC und C sehe ich eher kritisch. C ist fehleranfällig und oft umständlicher - es hat schon seinen Sinn, dass die Sprache weiterentwickelt wurde!
    Die Portierbarkeit ist trotzdem ein wichtiger Punkt. Gerade deshalb ist das MVC Modell wichtig, da man so die einzelnen Teile eines Programms trennt. Ich weiß incht, wie die professionelle Praxis aussieht, aber ich als Laie könnte mir Vorstellen, - wenn es auf Portierbarkeit ankommt - das M und C in MVC in plattformunabhängigen Sprachen (z.B. C++, nicht aber C) zu gestalten, sodass man nur noch das V für jedes System extra anlegt. Oder eben gleich auf Bibs wie Qt oder ganz auf Sprachen wie Java setzen, dann macht alles kein Problem mehr.
    Wie gesagt, nur eine Überlegung eines noch-Laien/Anfängers, also mal abwarten, was die Pros sagen ;)
    „Not everyone can become a great artist,
    but a great artist can come from everywhere.”
    (Anton Ego in Ratatouille)
  • Original von Remy
    model-view-controller ist ein Grundprinzip in der OOP (korrigiert mich, wenn ich blödsinn erzähle) und ist eigentlich für jedes objektorientierte Programm die Basis, deshalb hab ich gefragt^^

    Das ist absoluter Blödsinn, MVC hat mit OOP absolut gar nix zu tun.
  • Aber das man MVC quasi überall anwenden kann, egal ob Spiel oder Bürosoftware, das habe ich schon richtig verstanden, oder? Ich mein... ein Spiel hat doch prinzipiell auch die MVC-Schichten?
    „Not everyone can become a great artist,
    but a great artist can come from everywhere.”
    (Anton Ego in Ratatouille)
  • Original von Remy
    Aber das man MVC quasi überall anwenden kann, egal ob Spiel oder Bürosoftware, das habe ich schon richtig verstanden, oder? Ich mein... ein Spiel hat doch prinzipiell auch die MVC-Schichten?

    Nein ein Spiel folgt überhaupt nicht dem MVC-Prinzip. MVC sagt ja nix anders als das mann die Daten (model) durch einen Controller (controller) in einem View (view) abbildet. Der Vorteil dabei ist, das man seine Daten in verschiedenen "Ansichten" visualisieren kann im besten Fall muss man nur das View neu machen, bzw. durch was anderes ersetzten.

    Bei Spielen gibt es in der Regel kein View (mal abgesehen vom Telefon) dort gibt es auch kein Model und auch keinen Controller im Sinn von MVC.
  • Original von wolf_10de
    Original von Remy
    Aber das man MVC quasi überall anwenden kann, egal ob Spiel oder Bürosoftware, das habe ich schon richtig verstanden, oder? Ich mein... ein Spiel hat doch prinzipiell auch die MVC-Schichten?

    Nein ein Spiel folgt überhaupt nicht dem MVC-Prinzip. MVC sagt ja nix anders als das mann die Daten (model) durch einen Controller (controller) in einem View (view) abbildet. Der Vorteil dabei ist, das man seine Daten in verschiedenen "Ansichten" visualisieren kann im besten Fall muss man nur das View neu machen, bzw. durch was anderes ersetzten.

    Bei Spielen gibt es in der Regel kein View (mal abgesehen vom Telefon) dort gibt es auch kein Model und auch keinen Controller im Sinn von MVC.


    Auf die Gefahr hin, dass Du das ironisch gemeint hast und ich zu blöd bin, es zu kapieren:
    Deiner These, dass Spiele nicht MVC folgen, würde ich jetzt aber vehement widersprechen.
    Natürlich hat ein Spiel Views (manchmal eben nur ein Vollbildview), Controller, die die Spiellogik implementieren und Modelle (Maps, Dungeons, Charaktermodelle, Spielfiguren etc.).
    Zumindest macht man sich damit die Arbeit ungemein einfacher. Das wird auch in den ganzen Gameprogramming Gems-Büchern angesprochen.

    Gruß, Markus
  • Original von Markus Müller
    Original von wolf_10de
    Original von Remy
    Aber das man MVC quasi überall anwenden kann, egal ob Spiel oder Bürosoftware, das habe ich schon richtig verstanden, oder? Ich mein... ein Spiel hat doch prinzipiell auch die MVC-Schichten?

    Nein ein Spiel folgt überhaupt nicht dem MVC-Prinzip. MVC sagt ja nix anders als das mann die Daten (model) durch einen Controller (controller) in einem View (view) abbildet. Der Vorteil dabei ist, das man seine Daten in verschiedenen "Ansichten" visualisieren kann im besten Fall muss man nur das View neu machen, bzw. durch was anderes ersetzten.

    Bei Spielen gibt es in der Regel kein View (mal abgesehen vom Telefon) dort gibt es auch kein Model und auch keinen Controller im Sinn von MVC.


    Auf die Gefahr hin, dass Du das ironisch gemeint hast und ich zu blöd bin, es zu kapieren:
    Deiner These, dass Spiele nicht MVC folgen, würde ich jetzt aber vehement widersprechen.
    Natürlich hat ein Spiel Views (manchmal eben nur ein Vollbildview), Controller, die die Spiellogik implementieren und Modelle (Maps, Dungeons, Charaktermodelle, Spielfiguren etc.).
    Zumindest macht man sich damit die Arbeit ungemein einfacher. Das wird auch in den ganzen Gameprogramming Gems-Büchern angesprochen.

    Gruß, Markus


    Nein das war nicht ironisch gemeint. Ein Spiel hat keine Views (in aller Regel läuft das ja im Vollbild, wie du ja gesagt hast), damit wars das aber schon wieder.
    Die Controller die die Spiellogik abbilden haben ja nix mit denen von MVC zu tun. Ein Controller im Spiel (nehmen wir mal einen Textur-Controller) macht nix anderes als Texturen verwalten sonst nix, ein Controller im MVC bildet das Bindeglied zwischen Daten und View, das ist ein großer Unterschied.
    Was in den Gems geschrieben wird, ist das was ich als Beispiel mit dem Texture-Controller geschrieben habe.
    Bei Spielen geht es sehr viel um Geschwindigkeit, was nicht immer genau das ist was man bei der "normalen" Softwarentwicklung hat. Hier werden sehr viele Sachen immer noch in reinem C gemacht.
  • Original von wolf_10de
    Original von Markus Müller
    Original von wolf_10de
    Original von Remy
    Aber das man MVC quasi überall anwenden kann, egal ob Spiel oder Bürosoftware, das habe ich schon richtig verstanden, oder? Ich mein... ein Spiel hat doch prinzipiell auch die MVC-Schichten?

    Nein ein Spiel folgt überhaupt nicht dem MVC-Prinzip. MVC sagt ja nix anders als das mann die Daten (model) durch einen Controller (controller) in einem View (view) abbildet. Der Vorteil dabei ist, das man seine Daten in verschiedenen "Ansichten" visualisieren kann im besten Fall muss man nur das View neu machen, bzw. durch was anderes ersetzten.

    Bei Spielen gibt es in der Regel kein View (mal abgesehen vom Telefon) dort gibt es auch kein Model und auch keinen Controller im Sinn von MVC.


    Auf die Gefahr hin, dass Du das ironisch gemeint hast und ich zu blöd bin, es zu kapieren:
    Deiner These, dass Spiele nicht MVC folgen, würde ich jetzt aber vehement widersprechen.
    Natürlich hat ein Spiel Views (manchmal eben nur ein Vollbildview), Controller, die die Spiellogik implementieren und Modelle (Maps, Dungeons, Charaktermodelle, Spielfiguren etc.).
    Zumindest macht man sich damit die Arbeit ungemein einfacher. Das wird auch in den ganzen Gameprogramming Gems-Büchern angesprochen.

    Gruß, Markus


    Nein das war nicht ironisch gemeint. Ein Spiel hat keine Views (in aller Regel läuft das ja im Vollbild, wie du ja gesagt hast), damit wars das aber schon wieder.
    Die Controller die die Spiellogik abbilden haben ja nix mit denen von MVC zu tun. Ein Controller im Spiel (nehmen wir mal einen Textur-Controller) macht nix anderes als Texturen verwalten sonst nix, ein Controller im MVC bildet das Bindeglied zwischen Daten und View, das ist ein großer Unterschied.
    Was in den Gems geschrieben wird, ist das was ich als Beispiel mit dem Texture-Controller geschrieben habe.
    Bei Spielen geht es sehr viel um Geschwindigkeit, was nicht immer genau das ist was man bei der "normalen" Softwarentwicklung hat. Hier werden sehr viele Sachen immer noch in reinem C gemacht.


    Du stehst da sicher mehr im Stoff als ich (mache ein paar 3D-Sachen nur zum Spaß nebenher), aber das MVC-Prinzip an sich hat ja erstmal nix mit Geschwindigkeit zu tun. Denn auch in einem Spiel müssen Zustände gespeichert werden etc. Sicher stehen die Schichten viel dichter beieinander, aber die grundsätzliche Aufgabenstellung ist ja die gleiche (eine Modellschicht darstellen).
  • Du hängst da mehr an Begrifflichkeiten, denn an Funktionalität.
    Original von wolf_10de
    Nein das war nicht ironisch gemeint. Ein Spiel hat keine Views (in aller Regel läuft das ja im Vollbild, wie du ja gesagt hast), damit wars das aber schon wieder.

    Das Vollbild ist auch ein View.

    Auch eine App mit nur einer Darstellung aller Daten, kann sinnvoll nach dem MVC-Muster aufgebaut werden, weil es auch eine funktionale Trennung ist. So kann etwa die Anzeige mittels GL vollständig davon losgelöst werden, was mit einem Gegner passiert, wenn man ihm ins Knie schießt.

    Original von wolf_10de
    Die Controller die die Spiellogik abbilden haben ja nix mit denen von MVC zu tun. Ein Controller im Spiel (nehmen wir mal einen Textur-Controller) macht nix anderes als Texturen verwalten sonst nix, ein Controller im MVC bildet das Bindeglied zwischen Daten und View, das ist ein großer Unterschied.
    Was in den Gems geschrieben wird, ist das was ich als Beispiel mit dem Texture-Controller geschrieben habe.

    Weil irgendwas Controller genannt wird, bedeutet das nicht, dass es keine Controller mehr gibt.

    Selbstverständlich kann es Controller geben, etwa, wenn auf eine Nutzereingabe hin die Position einer Figur verändert wird, Kollisionen erkannt werden müssen usw. usf.

    Original von wolf_10de
    Bei Spielen geht es sehr viel um Geschwindigkeit, was nicht immer genau das ist was man bei der "normalen" Softwarentwicklung hat. Hier werden sehr viele Sachen immer noch in reinem C gemacht.

    Auch C-Software kann im MVC-Muster geschrieben werden. Es ist nur weniger bequem.

    MVC ist ja ein Entwurfsmuster, nicht eine Implementierung.
    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"?
  • wow, der thread ist ja ganz schön gewachsen. auch wenn ich nicht immer sofort antworte les ich alles interessiert mit, hab die email benachrichtigung aktiviert.

    @remy: danke für die vorschläge zu den engines. aber um das nochmal klarzustellen, ich möchte definitiv etwas fürs iphone entwickeln. XNA wäre für mich interessant, wenn ich mein iphone projekt erfolgreich abgeschlossen hab und mich längerfristig für spielentwicklung interessieren sollte, da ich selbst auch ne xbox360 hab und soweit ich weis XBLA für indie entwickler durchaus interessant ist. aber das ist noch zu weit weg um da jetzt irgendwie zeit reinzustecken.
    mit python hab ich mal was gemacht, zusammen mit der blender game engine. für simple 3d spiele ist das sicher für viele interessant. blender ist ein opensource und cross-plattform 3d programm mit integrierter game-engine und bullet physik-engine.
    fürs iphone gibt es noch sio2, eine relativ günstige (gibt eventuell sogar ne free version) 3d engine fürs iphone. dann gibts noch shiva 3d von stonetrip, dürfte sowas ähnliches (nur im weitesten sinne) wie unity sein. und dann gibt es noch torque, sowohl als 2d als auch 3d variante.
    ich hätte prinzipiell kein problem gehabt eine kommerzielle engine zu kaufen, aber weil ich mit blender so gute erfahrungen gemacht hab, bin ich gegenüber open scource recht aufgeschlossen, und cocos2d sah so aus als wärs genau das was ich brauche.
    leider hab ich mittlerweile den eindruck, dass die api sehr dürftig dokumentiert ist. wenn ich das recht verstanden habe ist die iphone variante eine portierung der ursprünglich in python verfassten engine. ich werd auch mal in die docs zur python variante schauen.
    cocos2d-iphone.org/
    cocos2d.org/

    das feld der spieleentwicklung ist sogar noch einen tick breiter als ich das eh schon befürchtet hab ;). ich werd jetzt erstmal schauen das ich die grundlegenden funktionen von cocos2d angesteuert krieg, damit ich mir dann entsprechend was anzeigen lassen kann wenn ich die anderen dinge lerne und ausprobiere.
    ich muss mir mal ein paar beispiel spiele ansehen die mit der engine gemacht wurden, hab auch schon ein paar runtergeladen. das ist vielleicht einer der vorteile an open source, ich weis nicht wie leicht es ist an beispielprojekte mit closed source engines zu kommen. kann natürlich sein, dass da sehr gute vom entwickler mitgeliefert werden. ich hab mir unity und co gar nicht erst installiert. schlecht sind die bestimmt nicht.

    zu der MVC diskussion, da blick ich jetzt nur mäßig durch. was ich mich frage ist, ob nicht cocos2d schon so strukturiert ist, dass es eine gewisse architektur begünstigt. ich hab mal nach "cocos2s mvc" gegooglet und z.b. sowas gefunden:


    Hi all,

    I just finished putting together a model-view-controller framework for cocos2D called cocosMNC (for model-node-controller). It's built on top of the existing framework, so you can bring it into any project without altering the base cocos2D sources (only tested in 0.8.2 so far). I'm hoping to build more tools on top of it (e.g. a drag and drop dispatch), but in the meantime you can check it out here:

    github.com/jeremyflores/cocosMNC/

    Hope you find it useful!



    das klingt für mich jetzt so, als ob cocos2d ohne zusätzliche dinge NICHT dafür optimal ist, etwas in ein MVC pattern zu bringen.
    und weil ich mich ungern auf noch mehr fremde projecte stützen möchte und derjenige selbst schon schreibt:

    cocosMNC has only been tested against the 0.8.2 version of cocos2D. Since cocos2D is still heavily in development and may therefore be unstable, there may be changes to this code base as the main project evolves.


    und die engine gerade bei 0.99 irgendwas ist, denk ich mal damit tue ich mir keinen gefallen das zu verwenden.

    ist es mit MVC auch so wie mit manchen anderen fragen der softwareentwicklung das es da wiedersprüchliche meinungen über den nutzen der sache gibt? (z.b. mega ausführliches design document oder flexibles design document, streng geplante entwicklung oder itterativer workflow mit stetiger revision, scrum oder streng geplante aufgabenverteilung, usw... euch fällt sicher mehr ein als mir, ich bin ja kein programmierer).
    ich mein, dass es die portabilität erhöht ist ja schonmal ein großer pluspunkt. aber wenn mir das egal wäre, wie schlagend sind die übrigen gründe für MVC und welche wären das?

    hier ist in einem diagramm erklärt wie sich eine cocos2d apllikation aus einzelnen szenen zusammensetzt:
    cocos2d-iphone.org/wiki/doku.php/prog_guide:basic_concepts

    [Blockierte Grafik: http://www.cocos2d-iphone.org/wiki/lib/exe/fetch.php/prog_guide:scenes.png]
  • Möglicherweise spielt es eine Rolle, ob eine Spielsitzung als Ganzes von Interesse ist / bleibt oder aber nicht. Bei einem Brettspiel - wie etwa beim Schach - interessiert eben der komplette Partieverlauf. In PGN Dateien sind ggf. mehrere Parteien gespeichert, von denen jede einzelne als Dokument aufgefasst werden kann. Das Partiebild wäre dann eine View dazu, die Notation eine andere, evtl. auch noch der Verlauf der Materialbilanz etc..

    Im anderen Fall, der Spielverlauf ist nach dem Spielende (es sind keine bloßen Unterbrechungen gemeint) regelmäßig uninteressant, da gibt es also kein Dokument von Session-übergreifender Relevanz. Möglicherweise kann man zwar den Status Quo trotzdem zeitweise als Dokument auffassen, es wäre dann aber vom Wesen her ein Wegwerfdokument. Dort würde ich dann eher auf eine solche Sichtweise verzichten.
    Dem 10x8-Schach gehört die Zukunft !
  • Noch ein paar Einsteigerfragen...

    Liebe Community,

    da ich nicht extra einen neuen Thread für meine wirklich sehr, sehr triviale Anfängerfrage anlegen möchte, poste ich diese nun hier. Ich hoffe das ist erlaubt - wenn nicht, dann entschuldigt bitte.

    Kurz zu meiner Person: Das objektorientierte Paradigma ist mir durch viele Jahre der Java- und PHP-Programmierung bekannt und geläufig - in jungen Jahren habe ich auch viel C und Pascal (prozedural) programmiert.

    Da ich nun seit kurzem iPhone und MacBook Pro Besitzer bin, möchte mich nun gerne in Objective-C einarbeiten und habe auch schon ein paar kleine Erfolge erzielt - vorerst jedoch nur auf der Konsole... Besser kleine Schritte, als keine Schritte :).

    Hier nun meine Frage(n):

    1) Sollte das @interface immer in einer eigenen Datei (Präfix .h) stehen und nur die Implementation des Objekts in der Datei mit dem Präfix .m?

    2) Wofür genau sind die Bezeichner für Übergabeparameter da und wieso funktionieren diese bei jedem Parameter, nur nicht beim Ersten? Ist ein aussagekräftiger Variablen/Parameter-Name nicht genug?

    Bsp.: Ohne Bezeichner (wie ich es gewohnt bin)
    - (void) setBeginAndEnd : (int) begin : (int) end;

    Bsp.: Mit Bezeichner (für mich noch etwas ungewohnt)
    - (void) setBeginAndEnd : (int) begin bezeichner : (int) end;

    Bsp.: Mit zwei Bezeichnern (wäre für mich logisch, funktioniert aber nicht!)
    - (void) setBeginAndEnd bezeichner1: (int) begin bezeichner2: (int) end;

    Vielen Dank für eure Mühe und liebe Grüße
    Loo.