Biblioteka rejestrowania gier (c ++) [zamknięta]

Znam wiele bibliotek rejestrujących, ale nie testowałem ich wielu. (GoogleLog, Pantheios, nadchodzące ulepszenie :: biblioteka dzienników ...)

W grach, szczególnie w zdalnych grach wieloosobowych i grach wielowątkowych, logowanie jest niezbędne do debugowania, nawet jeśli ostatecznie usuniesz wszystkie logi.

Załóżmy, że tworzę grę na PC (nie na konsolę), która potrzebuje dzienników (tryb dla wielu graczy i wielowątkowość i / lub proces wieloprocesowy) i mam dobre powody, aby szukać biblioteki do logowania (np. Nie mam czasu lub jestem nie jestem pewny, czy potrafię poprawnie napisać jedną dla mojej sprawy).

Zakładając, że potrzebuję:

1. występ
2. łatwość użycia (zezwalaj na przesyłanie strumieniowe lub formowanie itp.)
3. niezawodny (nie wyciekaj i nie upaść!
4. wieloplatformowy (przynajmniej Windows, MacOSX, Linux / Ubuntu)

Którą bibliotekę logowania poleciłbyś?

Obecnie myślę, że boost :: log jest najbardziej elastyczny (możesz nawet logować się zdalnie!), Ale nie ma dobrej aktualizacji wydajności : służy do wysokiej wydajności, ale nie został jeszcze wydany. Pantheios jest często cytowany, ale nie mam punktów porównawczych dotyczących wydajności i użytkowania. Używam własnej biblioteki od dłuższego czasu, ale wiem, że nie radzi sobie z wielowątkowością, więc jest to duży problem, nawet jeśli jest wystarczająco szybki. Dziennik Google wydaje się interesujący, muszę go tylko przetestować, ale jeśli już porównałeś te biblioteki i więcej, Twoja rada może się przydać.

Gry często wymagają dużej wydajności, a ich debugowanie jest skomplikowane, dlatego dobrze byłoby znać biblioteki rejestrujące, które w naszym konkretnym przypadku mają wyraźne zalety.

zaloguj się za pomocą gniazda (wystarczy dowolne opakowanie gniazda) + przeglądarka internetowa websocket => najbardziej uniwersalne, dyskretne narzędzie do rejestrowania, zyska godziny debugowania i pozwoli uniknąć bólu oczu.

• asynkryfoniczny (szybkość, ponieważ odkłada wszystkie zadania w przeglądarce)
• sformatowany (kolor, rozmiar itp.)
• niezawodny (gniazda ...)
• wieloplatformowy (przeglądarka)

Teraz bonus:

• bardzo łatwe do wykonania filtrowanie dynamiczne (w razie potrzeby użycie wyrażenia regularnego javascript)
• z historią dziennika, pamięcią i porównaniem (specyfikacja HTML5 w bazie danych „w przeglądarce”)
• Łatwy sposób na sporządzenie wykresu dowolnych danych (przy użyciu SVG, płótna lub czegokolwiek), takich jak pamięć , fragmentacja pamięci itp.
• prosty sposób na wykonanie dowolnego wykresu 2D dowolnych danych ( poddział drzewa kd ? pole potencjalne? lub nawet zmienna wartość zmiennej? itd.)
• umożliwia logowanie na odległość (przy użyciu innego komputera w przeglądarce)
• za pomocą html5 w pamięci przeglądarki można przechowywać parametry sesji dziennika (bieżące filtry dziennika itp., a nawet notatki na każdym z nich)
• bardzo proste tworzenie raportu o błędach lub linkowanie biletów śledzenia jednym kliknięciem
• możliwość łatwego przewijania dziennika za pomocą GUI na osi czasu

i wiele innych zadań poza rejestrowaniem:

• pozwala na informacje o profilerze (wykresy ...)
• może nawet służyć jako konsola (wysłać polecenie z przeglądarki) lub nawet z szybkim graficznym interfejsem użytkownika za pomocą HTML lub nawet interfejsu flash
• różnice obrazów w przeglądarce (wysyłanie obrazu za pomocą gniazda i porównywanie w przeglądarce za pomocą funkcji pikseli obrazu na płótnie)
• itp...

(prawie wszystkie powyższe czynności można wykonać przy użyciu gniazd flash, zapisz możliwości bazy danych)

Teraz wiem, że konfiguracja wydaje się trochę długa. Ale tak naprawdę to zysk czasu na długi projekt, z trudną sytuacją debugowania (np. W grach). Jest to najpotężniejsza rzecz, z której korzystałem od czasów debuggerów ...

Uwaga 1: jedynym minusem => efekt podwójnej kontroli podczas debugowania kodu sieciowego gry (wpływ na rozmiar bufora gniazda, opóźnienie, przepustowość itp.)

Uwaga 2: niektóre przeglądarki domyślnie wyłączają websocket ze względów bezpieczeństwa, sprawdź about: config, aby upewnić się, że jest włączony.

Jeśli chodzi o wydajność, uważam, że templog jest praktycznie nie do pokonania . Używa szablonów wyrażeń w celu odroczenia oceny instrukcji rejestrowania, dopóki nie zostanie ustalone, że informacje zostaną w ogóle zarejestrowane. Ponieważ można również częściowo wyłączyć rejestrowanie (w zależności od istotności, pochodzenia i grupy docelowej komunikatu dziennika), niektóre z tych instrukcji rejestrowania mogą zostać wyeliminowane przez kompilator do zerowego kodu dla kompilacji wersji. (Rzeczywiście widziałem, jak to się dzieje z VC.)

Biblioteka niewiele ostatnio zrobiła w bibliotece, a inni w SO zauważyli, że pod pewnymi względami brakuje bagażnika, ale w firmie, w której kiedyś pracowałem, zauważyliśmy, że facet był dość responsywny, a jeden z moich ówczesnych krów robotników nawet dostałem dostęp do zatwierdzenia i dodałem do niego trochę kodu, więc może się okazać, że warto spróbować.

Aby wymienić swoje wymagania:

występ

Najlepsze, jakie znalazłem. Szczególnie atrakcyjna była jego zdolność do wykluczania komunikatów dziennika w czasie kompilacji i całkowitego wyeliminowania ich przez kompilator.

łatwość użycia (zezwalaj na przesyłanie strumieniowe lub formowanie itp.)

Gdy robisz coś złego, pojawiają się klasyczne okropne komunikaty o błędach kompilatora szablonów-meta, ale jeśli chodzi o łatwość użycia, to

TEMPLOG_LOG(my_logger,sev_error,aud_support) << "logged in as " << user_name;

jest trudny do pokonania.
Jednak może być konieczne utworzenie własnych ujść dziennika (tam, gdzie idą komunikaty dziennika), ponieważ kilka wstępnie zapakowanych (stderr, plik, rejestrowanie w systemie Windows itp.) Nie jest aż tak skomplikowanych. Ponieważ głównym celem jest wydajność, istotność całości jest nieco skomplikowana (podobnie jak formatory komunikatów dziennika są dość zaplątane w pochłaniacze dziennika), ale udało nam się to opanować (pamiętam, jak przechodziłem przez to w debugerze, który w tym pomógł) i raz zrozumiałem, że nie było tak trudno napisać własne formaty wiadomości lub logi.

niezawodny (nie wyciekaj i nie upaść!

Wykorzystaliśmy go, nie znajdując żadnych tak poważnych problemów. Nie ma tam praktycznie dynamicznej alokacji pamięci, więc trudno sobie nawet wyobrazić, że robi coś złego. Oczywiście testowaliśmy je tylko w jednym produkcie.

wieloplatformowy (przynajmniej Windows, MacOSX, Linux / Ubuntu)

Kiedy go używaliśmy, używaliśmy go w Win32, OSX i kilku różnych dystrybucjach Linuksa, w tym Ubuntu.

Co do wielowątkowości: nie korzystaliśmy z tego, ale z tego, co pamiętam z architektury biblioteki lib, wydaje się, że wystarczyło by to obsłużyć w zlewach logów. ICBWT.

Możesz rozważyć bibliotekę logów na stronie http://www.logog.org , która moim zdaniem może spełniać twoje wymagania. Zastrzeżenie: Napisałem to.

Zobacz także odpowiedzi innych osób na /programming/696321/best-logging-framework-for-native-c .

Zestaw narzędzi Baical może Cię zainteresować :

• Biblioteka Open Source i wieloplatformowa (Win, Linux, x86 / x64) dla dzienników, śladów i telemetrii - P7
• Niezwykle szybki (zaprojektowany dla urządzeń wbudowanych) - 3 miliony logów na sekundę do sieci, 5 milionów do archiwizacji na nowoczesnym procesorze. Nie znam żadnej innej biblioteki do rejestrowania, która zapewnia taką szybkość i tak szczegółowe informacje dla każdego komunikatu dziennika.
• Wątek bezpieczny
• Każda wiadomość śledzenia zawiera:
  • wiadomość tekstowa
  • poziom
  • dokładny czas (100ns)
  • plik źródłowy, nazwa funkcji i linia
  • identyfikator modułu i nazwa modułu
  • identyfikator wątku i nazwa wątku
  • indeks rdzenia procesora
• Aplikacja serwera do odbierania i przeglądania dzienników i danych telemetrycznych
• Możesz zbierać, analizować, wyszukiwać, filtrować dzienniki z wielu źródeł w czasie rzeczywistym