Code (Aufteilung von den Aufgaben eines Spiels) OK?

Hallo,

bitte sei so gut und gestalte deinen Threadtitel den Regeln entsprechend noch etwas aussagekräftiger, damit andere User besser erkennen können, worum es hier geht.
(Hierfür unter deinem ersten Post einfach auf "bearbeiten" klicken, dann kannst du oben nochmal den Titel anpassen)

Danke

Hallo,
was Du mit Deiner Frage ereichen / bezwecken möchtest - keine Ahnung?
Lob?
Aber zur Frage.

Sollte es Dein (Programmlayout / ... Entwurf) sein - Kompliment!
Hier mache ich weiter!
...
Leider, -> vermute ich, dass Du sich an einem Tutorial, ... Muster bedient hast, und ...
Meine Vermutung basiert an ein paar "Sachen" die eigentlich unkorrekt sind.
Einer, der so artiges Rumpf entwickelt, wird so was (mir bekannte Code- Stellen) NIE! selber implementieren!
Daher, Grundgerüst (ok.) Vermute selbst Implementierung tendiert zu Fehlern.

LG
Georg

— geändert am 04.06.2014, 02:23:16

Hi,
ich habe Dein Projekt NICHT! gestartet, nur den Code mir flüchtig angeschaut.

... Anscheinend ist davon was hängen geblieben und ich habe das, was
hängen geblieben ist, wiederverwendet. ...

An der Stelle Hut ab! (So lernt man ...) Kompliment.

Was mir (negatives) aufgefallen ist, sind:
1) Lasse es mit Interfaces "arbeiten"
2) Du hast (außer Falsche Thread Hierarchie) dein Grundgerüst zum gefährlichen Workaround gemacht
3) Nicht korrekte Namenvergebung

1- Das Schöne in Java sind die Interfaces, damit kann man sich ein STABILES, gut zum WARTEN, und vor allem für die Zukunft VIELSEITIGES Grundgerüst sich "basteln".

2- Die Hierarchie möchte nicht weiter vertiefen: (GameThread extends SimpleThread)
- GameThread soll (wenn überhaupt) die Höchste Priorität haben
Also besser so:
SimpleThread extends GameThread, XYZ Thread extends GameThread
Aber Du machst sich dein Grundgerüst mit den Threads "Abstürzt sicher"
(Ich habe mir den ?lazydragon "unter die Lupe" damals genommen, obwohl der Autor [wenn ich mich gut erinnre] NUR einen Thread hatte, was jedoch Hauptrelevante Objekte gesteuert hat und nicht nur als "Hauptloop-Gamenschleife" diente, war das schlecht im Code zum Laufzeit! kontrollieren ... Fazit - App stürzt ab, und sogar der [Autor] kann es nicht herausfinden ....)

Und dar sind wir bei extends Thread Thema.
Wenn Du eine Klasse vom XXX erben lässt, bist Du schon etwas (im Bezug auf Grundgerüst!) verloren. Bei eventuellem Bedarf (also bei Änderungen), musst du bei eventuellen Änderungen eine Interacen Lösung finden, im schlimmsten Fall, wird dich dass ne Fullrestrukturierung kosten .... .

Abstrakte Threads, haben seine Verwendung als sog. Demon- Klassen in der Große Java, ob es auf dem "kleinem" Android sinnvoll ist?

Selbstkonversation:
Und sonnst hast du nix zu meckern?
Doch.

GameState =/= PosX ...
Status eines Spieles hat nichts mit der Positionen zu tun.
Es könnte:
- isPlaying
- isPaused
- isRunning
... sein.

Wenn Du aber der Meinung bist, es wird schon, da passe ich schon auf .... versuche sich mit dem Thema auseinander zu setzten:
thread-vs-runnable
Auf die schnelle (geguckt) wird wichtiges erläutert:
Link

LG
Georg

Ps.
Ich möchte hier betonen, dass ich kein "King of Java" bin! Sollte ich im unrecht liegen - sorry!

— geändert am 04.06.2014, 21:55:22

Hi,

... Was mir grade sofort auffällt: Du meinst, dass ich GameState nicht
richtig benutze. Deine Vorschläge (isRunning, usw.) klingen sinnvoll,
...

Nicht richtig benutzen ist falsch ausgedrückt. Damit verstößt Du einfach gegen die Namenskonventionen ... - Fertig!

Nachtrag:
Aber nicht nur;
Nach gewiesener Zeit .... (wobei Du dein Grundgerüst wieder verwenden ?würdest) wirst Du sicherlich SELBER! Rätseln müssen was:
c.drawCircle(state.ballPosX, state.ballPosY, 10, paintRed);
bedeutet.
Wäre:
c.drawCircle(ball.get(X), ball.get(Y), 10, paintRed);
nicht mehr aussagenkräftiger?
...
Ohne es Analysieren / Verfolgen! zu müssen, sind deutlich Koordinaten ... zu erkennen!
Nachtrag ende

... aber wie speichere ich solche Daten sonst am besten? ...

GARNICHT!

... und aus meinen Fehlern lernen kann ...

Es ist mir nicht Bewusst, dass Du Fehler gemacht hast! ...

Damit Deine Frage nicht einen "1000 Antworten" Thread generiert, werde ich eine kurze "?Vermerkung" Schreiben, und mich freundliche weise (aus dem Thread) verabschieden.

Damit man "den Rad nicht erneut erfinden muss" gibt es sehr viele sog. game engine!
Also Grundgerüste -> Motoren, .... -> Vorlagen ... wie es man nennen mag.

Google (z.B.) nach:
-> simple game engine for android <-

Bediene sich an einer "Gute" Vorlage (die also Stabil, Flexibel ... läuft / ist) oder investiere die Zeit dafür, - aus einem "Guten" Tut, die Vorlage herauskristallisieren!
Wenn Du einmal "so was" hast, dann bist Du in der Lage sehr viele Deine Ideen im "Augenblick" umzusetzen -> zu realisieren.
Weil:
wenn Dein Grundgerüst gut wird, werden Typische - Game - Aufgaben "pinatz":

Held held = new Held();
Gegner gegner = new Gegner();
Game.add(held);
Game.add(gegner);
...
CollisionDeteckt.check (held, gegner);
...

Nun, -> für so eine "Transparenz", -> sind viele schritte notwendig.

Damit ich mich "ohne schlechtes Gewissen" aus diesem Thread verabschieden darf, poste ich hier Link zum Buch (online Version) aus dem (aber nicht nur aus dem!) ich meine "Klugsch.... wissen" erworben habe.

VIEL ERFOLG! & over

LG
Georg