@Kogoro-Christopher muss dass mit dem addn auf github leider übernehmen, ich hab nicht genug permissions dazu :(((((
1) Was ist mit evtl Unterarten ? --> Bsp: Hund --> Dackel ? Dogge ? Jack Russel ? (klappt auch mit Katzen etc)
Diese Unterarten haben verschieden gelagerte Bedürfnisse. --> evtl kann man diese dann in Punkt 2 einfliessen lassen.
Finde ich eine gute Idee, müsste man eine Liste mit TIerarten und Rassen erstellen und dann ein Mapping der Bedürfnisse.
2) Was ist mit der Gewichtung von den Bedürfnissen ? --> Bsp: Essen geben: 2x am Tag, Gassi gehen, 1x am Tag, Spielen 5x am Tag ??Dies kann dann ja bei den Unterarten variieren....Dogge isst dann z.b. 3x am Tag, dafür aber nur 1x am Tag spielen ...
antwort wie bei erster frage, liste mit mapping müsste man dann integrieren. Von mir aus könnte man das auch über eine API abfragbar machen, dann kann man da vllt im nachinein noch nachjustieren ohne die app updaten zu müssen.
3) Was passiert, wenn die "Zufriedenheit" bei 0% ist ? --> Wie bekommt man dann ein neues Tier ?
Gute Frage, dann kommt das veterinäramt Umso weniger die Zufriedenheit wird umso mehr notifications generiert die App um den user zu nerven xD
4) Automatisierbar .....denkst Du da an den spielerischen "Erwerb" von Futterautomaten ?? Wenn ja, wie wurde dieses Geld dann erwirtschaftet ?
Nein ich denke eher daran, dass der nutzer mit hilfe einer scriptsprache selbst befehle wie "gehe gassi" automatisieren kann. Man programmiert sozusagen als App nutzer, den Tierhalter den man in der App spielt.
5) Späteres Level --> Ausbau als Tierpension ??
Wäre z.b. eine option, daran könnte man die Storyline des "Spiels" anlehnen. Man startet mit eigenen Haustieren und irgendwann erreicht man das lvl einer Tierpension und kümmert sich mit um die Tiere anderer virtueller Tierhalter.
6) Wie möchtest du die Arbeitsteilung beim Programmieren realisieren ? (Hab zwar Erfahrung was Projektierung angeht, allerdings nicht im IT-Bereich, daher die Nachfrage...)
Kommt drauf an wie viele entwickler wir dafür aquirieren können. Würde dann anhand der anforderungen tickets erstellen und allen jeweils zuweisen. Der workflow wird dann folgendermaßen aussehen:
1. Ihr müsst das Repo auf github forken
2. clont den fork lokal auf euren arbeits-pc
3. macht eure änderungen
4. commitet die änderungen lokal und pusht sie auf den fork
5. erstellt einen pull request (äquivalent zum merge request bei gitlab) auf den master branch des haupt-repositories
wie würdet ihr das Layout gestalten?
Wollen wir ein klasisches Layout oder alles auf dem Canves machen?
Ich würde ganz traditionell mit xml layouts arbeiten. Canvas ist zwar schön und gut, aber ihr sollt ja was allgemeingültiges lernen was ihr für alle apps nutzen könnt und nicht nur für spiele. Bzw. vllt kann man ja XML und canvas mischen, müssen wir mal schauen, wo sich das anbietet.