Army Compresser-Optimalizer

[Liir6676]

Program do konwertowania wyeksportowanej w zipa armii #22 . Konwertowałby przyduże wieloelementowe armie, w jeden optymalny jpg.

Byłby on szczególnie przydatny do optymalizowania nowych armii oficjalnych.

[Liir6676]

Tutaj pragnę dodać, iż bardzo przyjemną możliwością byłoby, gdyby łączenie grafik w jedną i generowanie współrzędnych odbywało się osobno od kompresji, ponieważ może zdarzyć się tak, że w przyszłości będzie zapotrzebowanie, na grafiki wyższej jakości, natomiast łączenie pliku w jeden zawsze będzie dobrym rozwiązaniem z tego co mi wiadomo.

Pytanie. Może jest możliwe, by łączenie w jeden plik odbywało się zawsze i pasywnie w tle? Użytkownicy nawet by nie wiedzieli. Możnaby wówczas zoptymalizować w ten sposób również wszystkie armie fanowskie. Jak by to mogło działać:

• Robimy podział na armie złączone (przeznaczone do wyświetlania na stronie) oraz armie komponentowe (przeznaczone do interakcji w create/edit army form)
• Gracz zapisuje swoją armię w serwisie.
• automatycznie usuwana jest stara złączona armia (czy tam nadpisywana)
• tworzona jest nowa złączona armia na podstawie widniejących w armii żetonów i znaczników
• w panelu admina widniałyby tylko armie komponentowe, albo tylko armie złączone wzajemnie zależne od siebie- jeśli ktoś usunie armię komponentową Detroit, to armia złączona Detroit (do której nie ma bezpośredniego dostępu) też zostaje usunięta- nie jest to problem skoro edycja armii odbywa się aktualnie tylko poprzez formularz clienta. *** TUTAJ nowy pomysł- jeśli się podoba, zrobię osobne issue. Wówczas możnaby zrezygnować z listy: A w jej miejsce dać linka kierującego do edycji armii (również nie swojej).

[baktrius]

Pomysł z transparentną optymalizacją armii jest fajny (nawet nie muszą to być dwie armie, tylko jedna, która ma podwójne grafiki: inne wyświetlają się na developmencie inne w grze). Niemniej może prowadzić do problemu, który negatywnie wpłynie na cały serwis i nie będzie to oczywiste. Operacja optymalizacji armii jest relatywnie droga (bez testów ciężko mi ocenić jak bardzo). 1) Dlatego naiwna strategia stwórz zoptymalizowaną kopię za każdym razem gdy coś się zmieni w armii raczej nie zadziała (gość dodaje armię token po tokenie, a serwis za każdym razem ją optymalizuje). 2) Można by optymalizować armię na żądanie (za pierwszym razem gdy ktoś o stworzy nową wersję na stole). To jest całkiem łatwe, ale możliwe, że za pierwszym razem będzie musiał dłużej zaczekać (i tak pewnie będzie to autor armii). Wydaje się to całkiem sensowna opcja. 3) Ostatecznie można próbować dodawać optymalizację armii do kolejki zadań w tle ale to będzie trudne do zrobienia. 4) W kontraście przycisk zoptymalizuj armię pewnie będzie używany znacząco rzadziej niż dowolna z powyższych aptymalizacji co będzie mniej obciążać serwer. Dlatego według mnie opcje 2) albo 4) są osiągalne. Problem z 2) jest taki, że problemy z wydajnością nie są oczywiste i mogą się pojawić dużo później niż rozwiązanie zostanie wprowadzone.

Ostatecznie "utajnienie" całego procesu optymalizacji sprawi, że wszelkie bugi w tym procesie będą nieoczywiste dla użytkownika (sytuacja grafiki mam dobre, ale w grze już nie). W przypadku osobnego przycisku oczywistym będzie gdzie się psuje.

[baktrius]

Z drugiej strony wymuszona optymalizacja każdej armii może znacząco poprawić działanie serwisu (przez zmniejszenie ilości danych do wysyłania klientom). Ostatecznie: ciężko stwierdzić.

[Liir6676]

• Ad.1 To może, zamiast tego dodać guzik save, o którego oparłoby się tę funkcjonalność? Dopiero, jeśli guzik zostanie naciśniety, zmiany zapiszą się i zostanie utworzona połączona grafika. (Warto by wówczas zaopatrzeć ten etap formularzu z dymkiem ostrzeżenia "Are you sure you want to leave without saving your army", czy coś w tym stylu).
• Ad. 2 Brzmi ciekawie. Trudno mi sobie wyobrazić ile trwałyby lagi. Rozumiem, że wystąpiłby po każdej ingerencji w grafiki armii?
• Ad. 3 Jak działałoby to w praktyce? Raz dziennie w godzinach małego natężenia na serwerze robiony byłby skan wszystkich armii w kierunku: czy zmieniła się grafika- jeśli tak tworzona byłaby nowa połączona grafika? Wówczas warto by np. nowo utworzone armie bez grafik byłyby pomijane podczas skanowania. TA OPCJA BYŁABY NAJLEPSZA [ponieważ pozwalałaby na pozostawienie obecnego systemu zapisu (dodanie jednej grafiki, od razu zapisane bez zabawy w guziki save), dałoby to również przyjemność z korzystania twórcom armii, jako że nie mieliby lagów po każdej zmianie grafiki. Jedyny minus to lekkie odroczenie optymalizacji, co moim zdaniem miałoby niesamowicie mały impakt. Ewentualnie można wyważyć, że skan robi się nawet częściej, jeśli serwer zauważy, że nie ma ruchu sieciowego. Okey widzę jeszcze, że problem może być w implementacji. Trudno mi powiedzieć jak trudne to jest).
• Ad. 4 to ten sam pomysł, co wpadłem w Ad.1?

Zachęcam do wymuszenia optymalizacji. Jeśli coś (nie wiadomo co) nie będzie działać użytkownikom jak np. "sytuacja grafiki mam dobre, ale w grze już nie", to zapewne zgłoszą to, nie rozumiejąc, co za tym stoi, a ważne, żeby to osoba odbierająca zgłoszenie wiedziała. Jako administrator będę w stanie monitorować takie zgłoszenia i osobiście testować grafiki, przy okazji wrzucania swoich armii, chociażby. Poza tym odpowiedzialny admin daje linki do miejsc, w których można zgłaszać błędy. Jeśli błąd zgłoszony byłby zatem tutaj w issues, od razu byłoby wiadomo, o co chodzi.

No i widzę jeszcze jeden problem. Czy gdy dojdzie już do podmiany sliced version na połączone grafiki version, to czy na stołach graczy, na których znajdowała się dana armia, nie dojdzie przypadkiem do zjawiska zaniknięcia grafik? Jeśli nie- bądź, tak, ale da się zrobić tak, by problem ten znikł, a lagi z Ad. 2 byłyby nieprzyjemne (załóżmy, że optymalizacja = łączenie grafik, bez kompresji, którą wolałbym zostawić w rękach graczy), wówczas wygrywa dla mnie opcja z Ad. 3 Jeżeli problem zniknięcia grafik jest nie do obejścia, lub i lagi Ad. 2 wynikające z łączenia byłyby niezauważalne, a implementacja tego pomysłu okazałaby się łatwiejsza, wówczas wygrywa dla mnie opcja z Ad. 2