Valve zaostrza zasady wydawania gier na Steamie, gdy rosną zaległości w zatwierdzaniu

Valve zaostrzyło zasady wydawania gier na Steamie, ponieważ deweloperzy mierzą się z weryfikacją buildów trwającą do 12 dni roboczych, co wywiera presję na zaplanowane premiery. Zmiany wymagają większej liczby kontroli przed zgłoszeniem, w tym faktycznego uruchomienia gry przez Steam. Wprowadzono je w obliczu obaw dotyczących gier generowanych przez AI, choć Valve nie określiło ilościowo wkładu AI w powstawanie zaległości.

Bezpośredni spór dotyczy dostępu do wspólnej kolejki weryfikacyjnej. Deweloperzy mogą starannie przygotować własne zgłoszenia, a mimo to czekać za grami wymagającymi ponownych inspekcji. Odpowiedź Valve przenosi na twórców większą odpowiedzialność za wychwytywanie podstawowych problemów, zanim napotkają je recenzenci.

Porównanie z itch.io pomaga wyjaśnić stawkę. Oba sklepy stają przed pytaniami o zarządzanie generowanymi treściami, lecz wymagania dotyczące testowania i ograniczenia masowego przesyłania materiałów rozwiązują różne problemy. Najnowsze działanie Valve skupia się na gotowości do wydania. Jego powodzenie zależy od tego, czy poprawi czas zatwierdzania bez tworzenia większej niepewności dla deweloperów, którzy już czekają.

Co Valve zmieniło w zasadach wydawania gier na Steamie

Valve prosi deweloperów o wykazanie podstawowej gotowości do wydania przed zgłoszeniem gier do weryfikacji.

Aktualizacja weryfikacji przedpremierowej z 3 listopada dodaje kontrole mające ograniczyć ponowne inspekcje. Deweloperzy muszą uruchomić grę przez Steam na co najmniej pięć minut. Valve wymaga też kontroli obejmujących wymagane komponenty oprogramowania, osiągnięcia, zapisy w chmurze i kategorie zrzutów ekranu.

Firma podaje, że standardowy docelowy czas weryfikacji builda wynosi od trzech do pięciu dni, podczas gdy obecne oczekiwanie sięga 12 dni roboczych. Przypisuje dużą część opóźnień ponownemu sprawdzaniu zgłoszeń po wykryciu problemów. Są to zatwierdzenia deweloperskie, odrębne od opinii klientów, które gracze wystawiają po zakupie gier.

Build to spakowana wersja gry zgłaszana do testów lub dystrybucji. Uruchomienie takiego pakietu bezpośrednio na komputerze dewelopera nie odtwarza każdego kroku, który wykonuje klient. Instalacja, ustawienia uruchamiania i oprogramowanie pomocnicze mogą zachowywać się inaczej, gdy grę dostarcza Steam.

To rozróżnienie wyjaśnia, dlaczego wymóg czasu gry ma większe znaczenie, niż sugeruje jego niewielki wymiar. Kontrola sprawdza, czy deweloper przetestował rzeczywistą ścieżkę dystrybucji. Ustanawia minimalny kontakt z produktem w formie, w jakiej jest dostarczany, zamiast uznawać działający lokalnie plik wykonywalny za wystarczający dowód.

Typowe redystrybucyjne komponenty to współdzielone elementy oprogramowania, których gra potrzebuje do działania, takie jak biblioteki DirectX lub Visual C++. Ich potwierdzenie pomaga rozwiązać podstawowy problem wdrożeniowy: komputer dewelopera może zawierać zależności, których brakuje na innym komputerze. Pomyślny test lokalny pozostawia więc ważne pytania bez odpowiedzi.

Steam Cloud, usługa synchronizująca obsługiwane zapisy gier, tworzy kolejny punkt, w którym znaczenie ma konfiguracja. Osiągnięcia i klasyfikacje zrzutów ekranu podobnie łączą zgłoszony produkt z reklamowanymi funkcjami. Łącznie te kontrole dotyczą tego, czy pakiet gry i jego prezentacja odpowiadają temu, co otrzymają gracze.

Istniejący proces weryfikacji już wymaga zatwierdzenia zarówno obecności gry w sklepie, jak i jej builda. Stanowi też, że reklamowane funkcje muszą istnieć w zgłoszonej wersji. Nowa lista kontrolna Valve dodaje wyraźne wymogi przygotowania wokół tej ustalonej bramki.

Znaczenie tej polityki wynika z tego, gdzie Valve umieszcza pracę. Deweloperzy muszą rozwiązać więcej rutynowych kwestii przed wejściem do kolejki, która — jak przyznaje firma — jest opóźniona. Podejście to traktuje możliwe do uniknięcia ponowne zgłoszenia jako problem, którym Valve może się zająć bez zmiany narzędzi deweloperskich używanych przez twórców.

Tworzy też jasny sprawdzian dla wyjaśnienia firmy. Jeśli podstawowe błędy zgłoszeń stanowią znaczną część pracy weryfikacyjnej, ich wcześniejsze wykrywanie powinno pomóc. Jeśli dominują inne ograniczenia, bardziej szczegółowa lista kontrolna w dużej mierze pozostawi główskie wąskie gardło bez zmian.

Deweloperzy indie ponoszą koszt niepewnej kolejki

Opóźnione zatwierdzenie może zakłócić premierę, nawet gdy sama gra jest gotowa do wydania.

Data premiery koordynuje więcej niż przesłanie pliku. Może zgrać ogłoszenia, materiały twórców, oczekiwania społeczności i dostępność współpracowników. Przesunięcie tej daty oznacza konieczność ponownego rozważenia zobowiązań, nad którymi deweloperzy nie mają pełnej kontroli, zwłaszcza gdy nie mogą z przekonaniem ogłosić nowego terminu.

Cubic Earth obrazuje tę presję. Deweloper structmira powiedział PC Gamer, że gra zgromadziła ponad 6 000 pozycji na listach życzeń, a jej zwiastun przekroczył 60 000 wyświetleń na YouTube. Według relacji na temat zaległości w weryfikacji buildów deweloper opisał narastające skargi graczy, podczas gdy zatwierdzenie pozostawało nierozstrzygnięte.

Te liczby wskazują na zainteresowanie odbiorców, a nie gwarantowaną sprzedaż. Mimo to wyjaśniają, dlaczego oczekiwanie może wydawać się istotne. Zespół już poprosił ludzi o uwagę, a nierozstrzygnięta decyzja platformy przerywa moment, w którym ta uwaga miała przełożyć się na dostęp.

Wheel Make It stanowi kolejny opisywany przykład. Jego wydawca, 2 Left Thumbs, obwinił opóźnienia w zatwierdzaniu za zakłócenie premiery. Według relacji o jego opóźnionej premierze gry aktualizacje dewelopera opisywały również nieudaną weryfikację dotyczącą dostępu kontrolerem do ustawienia rozdzielczości.

To połączenie komplikuje prostą narrację o deweloperach czekających na Valve. Zgłoszenie może zawierać rzeczywisty problem, a mimo to czas potrzebny na wyjaśnienie jego statusu nadal stwarza poważny kłopot. Wykrycie usterki i zakomunikowanie wiarygodnego harmonogramu weryfikacji to odrębne obowiązki.

Presja szczególnie mocno dotyka zespołów mających niewielkie możliwości reorganizacji pracy. Opóźnienie premiery może wydłużyć zarządzanie społecznością, jednocześnie odsuwając samo wydanie. Deweloperzy poświęcają wtedy czas na wyjaśnianie decyzji, której nie mogą podjąć, zamiast mówić o stworzonej przez siebie grze.

Istnieje też różnica między niekorzystną odpowiedzią a brakiem odpowiedzi. Jasne odrzucenie daje zespołowi konkretną sprawę do rozwiązania. Nierozstrzygnięte zgłoszenie pozostawia niepewność co do przyczyny, wymaganej reakcji i tego, czy kolejne publiczne zobowiązanie byłoby wiarygodne.

Zaległości w weryfikacji na Steamie generują więc koszt koordynacyjny wykraczający poza biurko recenzenta. Deweloperzy mogą tworzyć większe bufory w komunikatach, opóźniać zobowiązania promocyjne albo unikać obiecywania precyzyjnej dostępności. Reakcje te są zrozumiałe, lecz przenoszą niepewność na resztę harmonogramu produkcji.

Przygotowanie pozostaje użyteczne, nie gwarantując jednak ochrony. Dobrze przetestowane zgłoszenie powinno ograniczyć problemy, których można uniknąć, lecz nadal zależy od współdzielonej przepustowości platformy. Lista kontrolna Valve daje deweloperom większą kontrolę nad jakością zgłoszenia niż nad datą, w której ktoś zakończy jego analizę.

To rozróżnienie ma znaczenie dla uczciwej oceny aktualizacji. Deweloperzy powinni odpowiadać za błędy, które mogą wykryć przed zgłoszeniem. Valve nadal odpowiada za jasność i działanie własnego procesu zatwierdzania. Poprawa pierwszego nie rozstrzyga automatycznie obaw dotyczących drugiego.

Szybsze tworzenie gier napotyka wspólną bramkę zatwierdzania

Ograniczenie wysiłku potrzebnego do stworzenia gry nie usuwa pracy wymaganej, by odpowiedzialnie ją dystrybuować.

To centralne napięcie stojące za aktualizacją zasad wydawania gier na Steamie. Generatywna AI, czyli oprogramowanie tworzące nowe treści na podstawie poleceń lub innych danych wejściowych, może wspierać część prac deweloperskich. Powstałe zgłoszenie nadal wymaga działającej instalacji, zgodnej z prawdą prezentacji i osoby odpowiedzialnej za sprawdzenie obu tych kwestii.

Powoduje to rozbieżność między tworzeniem materiału a walidacją ukończonego produktu. Wygenerowanie obrazu lub napisanie kodu dotyczy pojedynczego zadania. Wydanie gry dotyczy tego, jak wiele elementów współdziała, gdy inna osoba ją instaluje i w nią gra.

Rozważmy przykładową grę, która działa po uruchomieniu z folderu deweloperskiego twórcy. Nie dowodzi to, że dystrybuowany pakiet zawiera wszystko, czego potrzebuje. Problem dotyczy dostarczania produktu, niezależnie od tego, czy odpowiedni kod napisał człowiek, czy asystent AI.

Minimalny wymóg czasu gry Valve bezpośrednio odpowiada na tę lukę. Wymaga od twórców przejścia od tworzenia czegoś, co można uruchomić, do testowania czegoś, co jest dystrybuowane. Rozróżnienie brzmi podstawowo, ponieważ takie jest, lecz współdzielony system zatwierdzania nie może zakładać, że każde zgłoszenie je spełniło.

Napięcie ekonomiczne jest proste. Deweloper, który pomija przygotowanie, oszczędza wysiłek lokalnie, pozostawiając innej stronie odkrycie pominięcia. Jeśli to odkrycie wywoła ponowne zgłoszenie, ten sam produkt pochłania dodatkową uwagę, zanim dotrze do graczy.

Starannej pracy deweloperzy ponoszą wtedy konsekwencje niedbałego przygotowania innych. Ich własne buildy mogą wymagać niewiele pracy naprawczej, lecz nadal zależą od tego samego systemu zatwierdzania. Dlatego spór wykracza poza pytanie, czy konkretna gra wspierana przez AI zasługuje na krytykę.

Lista kontrolna oparta na rezultatach ma tu uzasadnioną zaletę. Może stosować ten sam standard gotowości niezależnie od metody tworzenia. Gra stworzona z pomocą AI nadal powinna uruchamiać się prawidłowo, podczas gdy gra wykonana ręcznie nie powinna otrzymywać zwolnienia z tego samego wymogu.

Konkurencyjne podejście widać w wytycznych jakości treści itch.io. Wytyczne te wyraźnie odnoszą się do nadmiernej ilości automatycznie generowanych treści oraz masowo tworzonych stron produktów. Dopuszczają użyteczne materiały generowane, ostrzegając jednocześnie przed wykorzystywaniem automatyzacji do zalewania systemów odkrywania treści.

Podejścia te dotyczą różnych etapów problemu. Kontrole zgłoszeń pytają, czy pojedynczy produkt jest gotowy do inspekcji. Ograniczenia masowej produkcji pytają, czy zachowanie przy przesyłaniu treści przytłacza rynek. Sklep może potrzebować obu, nie traktując każdego twórcy korzystającego z AI jako spamera.

Dla czytelników użyteczne porównanie dotyczy tego, gdzie każda platforma wprowadza tarcie. Wcześniejsze kontrole mogą powstrzymać oczywiste błędy przed wejściem do kolejki. Limity powtarzalnych przesyłek mogą ograniczać skalę. Żadne z tych podejść samo w sobie nie ustala, czy gra jest oryginalna, przyjemna lub uczciwie promowana.

Valve wybrało wąską interwencję wobec bezpośredniego problemu z zatwierdzaniem. Daje to deweloperom konkretny standard, ale ogranicza też zakres tego, co aktualizacja może osiągnąć. Gotowość techniczna jest niezbędna do wydania, lecz obejmuje tylko część kontrowersji wokół gier generowanych przez AI.

Ujawnienie użycia AI nie ustala przyczyny opóźnienia

Dowody potwierdzają opóźniony proces weryfikacji, podczas gdy dokładny wkład gier generowanych przez AI pozostaje publicznie niezmierzony.

Wyjaśnienie Valve wskazuje ponowne weryfikacje jako istotne źródło opóźnień. Mówi to czytelnikom coś o pracy kumulującej się wewnątrz procesu. Nie ujawnia metod tworzenia stojących za nieudanymi zgłoszeniami ani nie ustala, jakie rodzaje gier pochłaniają najwięcej czasu weryfikatorów.

Ujawnienie wykorzystania AI odpowiada na inne pytanie. Informuje graczy o zadeklarowanym przez dewelopera użyciu generowanych treści w zakresie objętym polityką ujawnień. Nie stanowi kompleksowej miary jakości testów, oryginalności ani nakładu pracy włożonego w grę.

Ankieta dotycząca treści Valve zapewnia odpowiednie ramy polityki. Odczytywanie takich ujawnień wymaga uwagi wobec tego, co obejmują. Oznaczenie dotyczące wygenerowanych materiałów nie powinno przekształcać się w niepoparte twierdzenie, że cała gra została wyprodukowana automatycznie.

Ta sama ostrożność dotyczy gier bez takiego ujawnienia. Brak etykiety nie dowodzi sam w sobie starannego testowania. Ocena jakości zgłoszenia wymaga dowodów dotyczących przesłanego produktu, a nie założeń o narzędziach preferowanych przez dewelopera.

Za obecną debatą stoją różne wskaźniki. Wydane gry opisują, co skutecznie trafiło do sklepu. Zgłoszone gry opisują napływające zapotrzebowanie na weryfikację. Ponowne kontrole opisują dodatkową pracę w ramach tego zapotrzebowania. Traktowanie tych kategorii jako wymiennych tworzy silniejsze twierdzenie przyczynowe, niż pozwalają na to dowody.

Nawet wiarygodny wzrost liczby ujawnień AI pozostawiłby istotne pytania bez odpowiedzi. Nie pokazałby, jak często te gry nie przechodzą kontroli, ile czasu recenzenci na nie poświęcają ani czy niepowodzenia różnią się od innych zgłoszeń. To właśnie te pomiary są potrzebne, by wyjaśnić strukturę zaległości.

Nie oznacza to, że obawy deweloperów są nierozsądne. Ich skargi odzwierciedlają realne narażenie na niepewne decyzje zatwierdzające, a szybkie generowanie treści stanowi wiarygodne źródło dodatkowego obciążenia. Wiarygodność powinna jednak kierować dochodzeniem, a nie zastępować analizę, której Valve nie opublikowało.

Powiązany problem dotyczy terminu „AI slop”, skrótu określającego niskiej jakości generowane materiały. Skutecznie komunikuje frustrację, lecz łączy odmienne zarzuty. Wadliwa instalacja, powtarzalny projekt, wprowadzająca w błąd prezentacja oraz niechciana generowana grafika wymagają różnych dowodów i potencjalnie różnych reakcji.

Kontrola działania gry po uruchomieniu bezpośrednio odnosi się do pierwszego zarzutu. Mówi znacznie mniej o tym, czy gra kopiuje pomysł innego twórcy albo oferuje wartościową rozgrywkę. Przedstawianie listy kontrolnej jako odpowiedzi na wszelkie obawy związane z AI zawyżałoby jej zakres.

Najmocniejsza analiza rozdziela więc te twierdzenia. Valve przyznało, że występują opóźnienia, i wskazało ponowne kontrole jako ich przyczynę. Deweloperzy i reporterzy łączą te trudności z szerszym napływem treści wspomaganych przez AI. Publicznie dostępne dane nadal nie określają, w jakim stopniu ten napływ je wyjaśnia.

Ta luka w weryfikacji powinna pozostać widoczna w miarę rozwoju polityki. Czytelnicy mogą traktować problem operacyjny poważnie, nie przypisując każdej porażki AI. Deweloperzy mogą domagać się lepszej obsługi, nie musząc udowadniać jednego wyjaśnienia wszystkiego, co spowalnia kolejkę.

Lepsze kontrole pomagają, ale Valve nadal ma pracę do wykonania

Lista kontrolna może ograniczyć możliwe do uniknięcia błędy; nie może wykazać, że system zatwierdzania dysponuje wystarczającą przepustowością.

Podejście Valve ma oczywistą logikę operacyjną. Wykrycie brakującej zależności przed zgłoszeniem jest lepsze niż odkrycie jej podczas weryfikacji. Potwierdzenie reklamowanych funkcji daje też recenzentom bardziej uporządkowany produkt do oceny i ogranicza pole do sporów o to, co powinno być obecne.

Argument na rzecz tego rozwiązania opiera się na zapobieganiu. Jeśli twórca może zidentyfikować podstawowy problem lokalnie, niewielka jest wartość w tym, by platforma odkrywała go później. Jasne wymagania pomagają także niedoświadczonym deweloperom zrozumieć, że ukończenie gry i przygotowanie jej do dystrybucji to odrębne zadania.

Sceptyczne stanowisko zasługuje jednak na równie dużą uwagę. Zgłoszenie może spełniać widoczne punkty listy kontrolnej, a mimo to zawierać problemy wymagające inspekcji. Minimalny czas rozgrywki nie obejmie wszystkich warunków działania, a pole potwierdzenia nie dowodzi, że twórca rozumiał potwierdzaną funkcję.

Skuteczność polityki zależy od tego, czy jej kontrole odpowiadają częstym, możliwym do uniknięcia błędom weryfikacji. Jeśli tak, dodatkowa praca powinna przynieść użyteczny zwrot. Jeśli deweloperzy jedynie wypełniają pola bez lepszego przygotowania, proces zyskuje formalność, zachowując swoje wady.

Istnieje też wyzwanie komunikacyjne. Deweloperzy muszą odróżniać standardowy cel od bieżących warunków operacyjnych. Znany szacunek ma niewielką wartość planistyczną, gdy uznane opóźnienie sprawia, że jest niewiarygodny dla planowanej premiery.

Valve może poprawić tę sytuację bez gwarantowania dat zatwierdzenia. Jasne informacje o statusie i aktualne oczekiwania pomogłyby zespołom zdecydować, co mogą odpowiedzialnie obiecać. Wyjaśnienie, czego potrzebuje recenzent, podobnie ograniczyłoby niepewność, gdy zgłoszenie wymaga zmian.

Dla zespołów deweloperskich spójna dokumentacja staje się częścią gotowości do premiery. Notatki z testów, decyzje konfiguracyjne i wcześniejsze informacje zwrotne mogą pomóc współpracownikom zrozumieć, co zostało już sprawdzone. Przeszukiwalna baza wiedzy inżynieryjnej może wspierać ten rejestr, nie zastępując praktycznych testów.

Szersza kwestia dotyczy odpowiedzialności w ramach wspólnego systemu. Twórcy kontrolują przygotowanie i rzetelność swoich deklaracji. Valve kontroluje operacje weryfikacyjne, jasność wymagań oraz informacje, które deweloperzy otrzymują podczas oczekiwania. Obie strony mają zadania, których druga nie może wykonać za nie.

Gracze również są zainteresowani zachowaniem znaczących kontroli. Szybszy proces zatwierdzania daje ograniczone korzyści, jeśli przechodzą przez niego oczywiste problemy z instalacją. Z kolei skuteczna inspekcja traci wartość, gdy jej harmonogram uniemożliwia deweloperom planowanie wiarygodnej premiery.

To sprawia, że szybkość i niezawodność są wspólnymi celami. Valve potrzebuje zgłoszeń wymagających mniej możliwych do uniknięcia poprawek, a deweloperzy potrzebują procesu, którego działanie mogą zrozumieć. Nowe wymagania odnoszą się do części tej wymiany, ale sama ich obecność nie jest dowodem, że wymiana się poprawiła.

Uczciwym standardem są obserwowalne wyniki po wdrożeniu. Bardziej szczegółowy formularz jest interwencją. Mniej możliwych do uniknięcia błędów i bardziej przewidywalne zatwierdzenia byłyby rezultatami. Dopóki te rezultaty się nie pojawią, aktualizacja pozostaje rozsądną propozycją, której praktyczny efekt nadal nie został rozstrzygnięty.

Co obserwować po aktualizacji zasad publikacji na Steam

Kolejnym testem będzie to, czy deweloperzy napotkają mniej ponownych kontroli i bardziej przewidywalne decyzje dotyczące premiery.

Pierwszym sygnałem jest sam harmonogram weryfikacji. W nadchodzących miesiącach warto obserwować, czy bieżące oczekiwania Valve wracają do zwykłego celu. Relacje deweloperów mogą dostarczyć kontekstu, szczególnie gdy wyraźnie rozdzielają pierwotne zgłoszenie, wymagane zmiany i ostateczne zatwierdzenie.

Krótsze oczekiwanie wsparłoby argument, że możliwe do uniknięcia ponowne kontrole były praktycznym wąskim gardłem. Utrzymujące się opóźnienia osłabiłyby twierdzenie, że lista kontrolna była wystarczająca. Żaden z tych wyników sam w sobie nie ustaliłby, w jakim stopniu treści wygenerowane przez AI przyczyniły się do pierwotnego problemu.

Drugim sygnałem jest jakość pętli informacji zwrotnej. Warto obserwować bardziej szczegółową dokumentację, jaśniejsze komunikaty o statusie i wyjaśnienia pozwalające deweloperom rozwiązywać powiązane problemy jednocześnie. Takie zmiany wskazywałyby na uwagę poświęconą relacji między jakością zgłoszeń a efektywnością weryfikacji.

Powtarzające się doniesienia o nowo odkrywanych podstawowych wymaganiach wskazywałyby w przeciwnym kierunku. Jeśli deweloperzy nie potrafią określić, co oznacza gotowość przed zgłoszeniem, odpowiedzialność nadal trudno przypisać. Standard działa najlepiej, gdy twórcy mogą go zastosować, zanim recenzent wyjaśni, co przeoczyli.

Trzecim sygnałem będzie to, czy sklepy publikują dowody łączące wolumen treści z wynikami operacyjnymi. Bardziej użyteczne raportowanie rozróżniałoby napływające zgłoszenia od wydanych gier i identyfikowało rodzaje błędów powodujących ponowną pracę. To bezpośrednio wzmocniłoby albo podważyło wyjaśnienie związane z AI.

Działania konkurentów zasługują na uwagę w ramach tego pytania o pomiary. Ograniczenia dotyczące powtarzalnych przesyłanych materiałów oraz ulepszenia mechanizmów odkrywania odnoszą się do presji wykraczających poza bramkę zatwierdzania Steam. Ich wartość należy oceniać według tego, co poprawiają, a nie według tego, jak stanowczo platforma opisuje niepożądane treści.

Dla twórców produktów AI jest to również przypomnienie o tym, co stanowi ukończoną pracę. Wygenerowany projekt działający w jednym środowisku przeszedł tylko część drogi. Dystrybucja, integracja i weryfikacja pozostają obowiązkami produktowymi, nawet gdy tworzenie staje się łatwiejsze.

Dla graczy praktyczne pytanie brzmi, czy sklepy zachowują zaufanie, obsługując większą liczbę zgłoszeń. Rzetelna prezentacja i działająca instalacja pozostają rozsądnymi oczekiwaniami. Nie rozstrzygają one każdego sporu o AI, ale zapewniają konkretną podstawę do oceny polityki platformy.

Dla studiów przygotowujących premierę istotne jest przestrzeganie aktualnych wymagań i wiązanie obietnic z potwierdzonymi kamieniami milowymi. Należy zapisywać, co testowano, która wersja otrzymała informacje zwrotne i co pozostaje nierozstrzygnięte. Traktujcie harmonogram zatwierdzenia jako zależność wymagającą aktywnej uwagi, zwłaszcza przy koordynowaniu zewnętrznego zasięgu medialnego lub wydarzeń społeczności.

Następnie należy ponownie ocenić zasady publikacji na Steam na podstawie rzeczywistych wyników, a nie samego ogłoszenia. Czy kompletne zgłoszenia są rozpatrywane bardziej przewidywalnie? Czy recenzenci znajdują mniej możliwych do uniknięcia problemów? Czy Valve przekazuje deweloperom wystarczające informacje, by mogli uczciwie wyjaśniać opóźnienia? Śledźcie odpowiedzi na te pytania, zanim zdecydujecie, czy nowe kontrole znacząco poprawiły drogę od ukończonej gry do gry gotowej do uruchomienia.