spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »DeKugelschieber«

Meine "Konzepte" sollen übrigens nur als Diskussionsgrundlage dienen, ich denke ist gut wenn man was zum diskutieren hat. Dabei kommt man schneller auf Probleme die man berücksichtigen muss.

Ich hoffe es ist OK, wenn ich meine Gedanken dazu in den in Raum werfe, auch wenn ich nicht am Projekt mitarbeite.

Zitat

Bei der Verteilung gibt es zwei Möglichkeiten:

1. die Job queue verteilt die Jobs, kennt also alle Arbeiter und ihre Fähigkeiten (push)
2. die Arbeiter ziehen sich selbst Jobs (pull)

Ich würde hier Variante 2 wählen, weil die Job queue dann nicht alle Arbeiter kennen muss. Das ermöglicht wie schon angesprochen dem Arbeiter selber zu entscheiden ob der Job ausgeführt wird oder nicht.
z.B. Könnte der Arbeiter eine gewisse Reichweite haben in der geschaut wird, ob es überhaupt möglich ist den Job durchzuführen (Bäume in der nähe, Material auf Lager etc.)

Das JobEvent mit "Job* next" auszustatten klingt erstmal gut, allerdings wäre es ja auch schön (für den Spieler) wenn ein andere Arbeiter den Abtransport von gefällten Bäumen gleich über nimmt wenn der erste Arbeiter noch am fällen ist.
In Vielen Spielen ist es ja auch so, Baum fällen, Abtranportieren und wieder ein Baumfällen, Abtransportieren und wieder von vorn.

Zitat

Ändern sich diese Umstände müssen die Jobs mit neuer Priorität in die Queue eingeordnet werden.

Wer soll das machen? Wenn die Jobs aus der queue geholt sind liegen sie dort nicht mehr und der Arbeiter ist denke ich der falsche Ort die Prio zu ändern (aus Design sicht).

Zitat von »Koschi«

Zitat von »DeKugelschieber«

Meine "Konzepte" sollen übrigens nur als Diskussionsgrundlage dienen, ich denke ist gut wenn man was zum diskutieren hat. Dabei kommt man schneller auf Probleme die man berücksichtigen muss.

Ich hoffe es ist OK, wenn ich meine Gedanken dazu in den in Raum werfe, auch wenn ich nicht am Projekt mitarbeite.

Klar, tob dich aus.

Zitat von »Koschi«

Das JobEvent mit "Job* next" auszustatten klingt erstmal gut, allerdings wäre es ja auch schön (für den Spieler) wenn ein andere Arbeiter den Abtransport von gefällten Bäumen gleich über nimmt wenn der erste Arbeiter noch am fällen ist.
In Vielen Spielen ist es ja auch so, Baum fällen, Abtranportieren und wieder ein Baumfällen, Abtransportieren und wieder von vorn.

Stimmt, man könnte den Job auf der Queue lassen, so dass der Zwerg (oder was auch immer unsere Viecher sind) zumindest nachschaut ob der Job dann immer noch da ist, bzw. evt. sich für diesen als nächsten entscheiden kann. Ich glaube das ergänze ich noch im Wiki.

Zitat von »Koschi«

Wer soll das machen? Wenn die Jobs aus der queue geholt sind liegen sie dort nicht mehr und der Arbeiter ist denke ich der falsche Ort die Prio zu ändern (aus Design sicht).

Weiß ich noch nicht. Der Anstoß soll in die Richtung gehen das Aufträge gar nicht erst verteilt werden wenn sie nicht durchführbar sind.
Wie z.B. wird bestimmt welches Feld beim Bergbau als nächstes abgebaut wird? Bei Erstellung des Jobs könnte man jetzt sagen Gebiet XY und der Zwerg guckt selbst, welches frei ist. Oder man erstellt für jeden einen Auftrag wobei die inneren erst auf DISABLED stehen, bis ein Event kommt "Fels abgebaut" und daraus kann man die Umliegenden Felder prüfen.
Alles noch nicht wirklich durchdacht. Das ist auch denke ich eins der komplizierteren Probleme, die Auswahl welcher Job erledigt wird usw.

Zitat von »DeKugelschieber«

Weiß ich noch nicht. Der Anstoß soll in die Richtung gehen das Aufträge gar nicht erst verteilt werden wenn sie nicht durchführbar sind.
Wie z.B. wird bestimmt welches Feld beim Bergbau als nächstes abgebaut wird? Bei Erstellung des Jobs könnte man jetzt sagen Gebiet XY und der Zwerg guckt selbst, welches frei ist. Oder man erstellt für jeden einen Auftrag wobei die inneren erst auf DISABLED stehen, bis ein Event kommt "Fels abgebaut" und daraus kann man die Umliegenden Felder prüfen.
Alles noch nicht wirklich durchdacht. Das ist auch denke ich eins der komplizierteren Probleme, die Auswahl welcher Job erledigt wird usw.

Beim Überprüfen des Jobs könnte jeder Arbeiter selber schauen ob die Voraussetzung für ihn gegeben sind zum erfüllen des Jobs, also ist z.B. Holz oder Fels in einem Radius von X Einheiten da.

Wenn man dem Job ein Counter hinzufügt der den Wert enthält wieviel Arbeiter es gibt und jeder Arbeiter der diese Überprüfung durchführt dekrementiert den Counter, bei 0 bekommt der Job den Status DISABLED. Natürlich nicht wirklich die Aufgabe der Queue.

Es würde sich eventuell ein art ManagerKlasse anbieten. Eventuell kann diese Mangerklasse da eine Nachricht vom Arbeiter bekommen "Job id XYZ" ist in arbeit. Falls nötig mit nen Pointer auf den Arbeiter damit man einen Bezug zwischen Arbeiter und Job hat.

Aber auch da kann es zu Problemen kommen.
Es sind 5 Holz vorhanden. Arbeiter 1 benötigt 4 für seine Aufgabe und guckt ob genug vorhanden ist. Es sind 5 Einheiten vorhanden also macht er sich auf den Weg. Arbeiter 2 benötigt 3 Holz und guckt auch ob genug vorhanden ist. Es sind immer noch 5 vorhanden also macht er sich auf den Weg. Irgendwann ist das Holz verbraucht und einer der beiden Arbeiter hat seine Arbeit noch nicht beendet. Wenn es doof läuft sind beide Arbeiten nicht fertig geworden.
Arbeiter könnten jetzt Holz reservieren, wobei mir persönlich die Variante besser gefallen würde in welcher der Arbeiter los legt und sich beschwert wenn er nicht weiter machen kann. Ansonsten wird dem Spieler da vielleicht etwas viel abgenommen.
Was aber noch viel grundlegender zu überlegen wäre, wie funktioniert so ein Lagersystem. Läuft das wie in Siedler wo die Rohstoffe wirklich in ein konkretes Lager gebracht werden und nur dort vorhanden sind und eben auch abgeholt werden müssen um weiter verarbeitet zu werden? Oder läuft das wie man es aus RTS Spielen kennt, wo die Rohstoffe alle in einen gemeinsamen Pool kommen?
Ich fände die Siedler Variante schöner, eben auch weil das Management eine große Rolle des Spiels einnehmen soll.

Naja für dieses Spiel, wenn es an DF angelehnt bleiben soll, macht eigentlich nur das echte Lager Sinn.
Ansonsten kann es auch gar nicht so viele Güter geben, oder meinst du quasi eine Tabelle in der steht: Holz 100, Stein 23, ...?

Die erste Implementierung kann (bzw. ich finde sollte) so stumpf wie möglich sein. Die Arbeiter rennen los und holen sich ihren Kram. Wenn nichts vorhanden ist beschweren sie sich und lassen den Job fallen oder geben ihn zurück.
Wenn sich das als zu nervig für den Spieler herausstellt kann man es ändern. In DF gibt es z.B. einen Arbeiter der das Lager verwaltet. Zu dem könnten andere dann laufen und "nachfragen".

IRC #onyx am besten dort einfach mal gucken.

Wie siehts aus? Um das Task System testen und einbauen zu können müsste sich mal jemand um die Map und die Darstellung/Bewegung der Entities kümmern.
Evt. kann ich das grob schon mal anfangen, aber eigentlich wollte ich da nicht drim rumwursteln.