| Autor | Treść |
|---|---|
| Lam 27.4.2005 19:30 |
Proszę bardzo :) Aktualnie moby mają dwa rodzaje agresywności: 1. bezwarunkowa, 2. rasowa. Pierwszą nazwałem źle, bo można ją ominąć strasząc moba poziomem lub aurą pokoju. Pierwszą ustawia się każdemu indeksowi (rodzajowi) moba osobno. Druga w ogóle nie zależy od moba jako takiego, ale od jego rasy i jej listy wrogich ras. Druga oprócz nie rzucania się na graczy zbyt potężnych, patrzy pobłażliwie na zbyt słabych, by się bronić. Moja propozycja będzie spora. Przewiduje ona następujące zmiany względem obecnego systemu: 1. agresywność rozbita na moralności - złe postacie mogłyby spokojnie chodzić po wieży demonologa czy mieście duchów, ale nie mogłyby po świętym gaju; 2. agresywność wobec ras: 2.1. wszystkich oprócz własnej, 2.2. wszystkich zgodnie z nienawiścią (tak jak teraz), 2.3. żadnych (pokojowy nawet, jeśli jego rasa toczy wojny z innymi rasami), 2.4. opcjonalna lista ras dodawanych do nienawiści rasowej, 2.5. opcjonalna lista ras odejmowana od nienawiści rasowej, 2.6. (zupełnie wszystkie rasy właczając własną można osiągnąć włączając normalną agresywność wobec wszystkich); 3. agresywność bez strachu lub z ustawianą różnicą poziomów inną niż 10 (w górę, czyli mob bardziej nieustraszony, atakujący dużo silniejszych lub zupełnie wszystkich, ale także w dół, czyli np. mob agresywny tylko wobec dużo słabszych); 4. pobłażliwość wobec cieniasów; 5. agresywność wobec mobów. Widzę dwie podstawowe możliwości implementacji: 1. Za pomocą dodatkowych flag "doczepianych" w pliku krainy do definicji indeksu moba. Analogicznie do literek F/S/H można dodać nawet kilka tego rodzaju flag, zmieniających zachowanie względem domyślnego. Można tam umieścić bitowe reprezentacje zachowań moba, liczbowe definicje różnic poziomów, tekstowe listy ras dodawanych/odejmowanych od listy nienawiści (typu A b00|b01 -10 10 b00|b03 wampir~ człowiek~). Niewątpliwą zaletą takiego rozwiązania jest standaryzacja. Taki format może być wczytywany, edytowany i zapisywany z powrotem do krainy za pomocą edytora takiego jak Klacz. Flagi przekładają się bezpośrednio na opcje do "fajkowania", liczby i teksty na miejsca do wprowadzania. Istnienie takiej standardowej możliwości z pewnością jest zachętą dla twórców krain do uczenia swoich mobów różnych zachowań. Oczywistą wadą takiego rozwiązania jest konieczność przesiedzenia długich godzin na implementacji. Dodatkową wadą jest nieczytelność w pliku krainy (trzeba pamiętać, co to jest b00|b03), ale to samo tyczy się każdej innej flagi. 2. To samo można osiągnąć progami, ale... Greet_prog tu nie do końca wystarczy, potrzebny jest (nazwijmy go) aggr_prog wywoływany kiedy tylko stan postaci się zmienia umożliwiając atak, który wcześniej nie był możliwy (konkretnie, komuś spada niewidka lub aura pokoju, zmienia się jego moralność, rasa itd...). Dopisywanie wyzwalaczy tego proga we wszystkich miejscach, gdzie to tylko możliwe to zajęcie za karę dla jakiegoś krnąbrnego programisty, jeśli chcemy, aby umarł przekopując się przez kod. Obecny system bardzo często po prostu sprawdza, czy należy zaatakować, ale obecny kod jest dość wydajny. Odpalanie proga za każdym razem odpada. Pozostawienie tylko greet_proga (plus dodanie funkcji "czy nienawidzę rasy", reszta możliwości już chyba jest) to rozwiązanie połowiczne, ewentualnie mogące być stosowane w przypadku kilku mobów, jeśli nie chcemy popularyzować takich rzeczy. Jest też ewentualność dodania polecenia progowego (powiedzmy mpsetaggr $n), które by zapamiętywało, że mob ma zamiar walczyć z danym graczem. To by mogło być używane z all_greet_proga, ale w entry_progu trzeba byłoby pisać bieganie po listach... Czyli podsumowując, tutaj pisania po stronie programistów byłoby znacznie mniej (wręcz okropnie mało), ale albo by żarło procesor, albo działało słabo, albo wymagało sporych umiejętności po stronie krainkowca (a przecież właśnie o to chodzi, aby krainkowiec mógł być jak najcieńszy, a jednak robić krainy z niespodziankami). Dodatkowo to rozwiązanie eliminuje użycie edytora typu Klacz. Mogę sobie wyobrazić kreator progów agresywności, ale interpretowanie takiego proga po wczytaniu to znowu wyższa technologia. Z drugiej strony, w pliku krainy (a nie w Klaczy) łatwiej zrozumieć if isnpc($n) || isevil($n) niż b00|b03. Aha, flagi również mają potencjał pożerania procesora, ale z pewnością o niebo mniejszy. Na razie chyba tyle, bo piszę to za długo i zacząłem zapominać, o co mi w ogóle chodziło. W trakcie dyskusji wszystko wyjdzie :) Ponieważ od razu postarałem się zawrzeć najważniejszą myśl, że najlepiej będzie to zrobić flagami, proponuję przejść do dyskusji, jak to najlepiej rozpisać. |
| Skifr 27.4.2005 17:51 |
moglbys troche rozwinac :P |