Fallout 76-spelers teleporteren per ongeluk naar onuitgebrachte vaults

Verschillende Fallout 76-spelers zijn tijdens het spelen in normaliter afgesloten vaults geraakt. Volgens een van de spelers ging dit onbewust. Ontwikkelaar Bethesda zegt dat de ruimtes nog in aanbouw zijn.

Redditgebruiker McStaken zegt Vault 63 in te zijn geteleporteerd tijdens een rad-rat horde-event, waarbij het de bedoeling is om grote ratten af te maken. Afbeeldingen die bij de post zijn geplaatst laten onder meer een nucleaire reactor, skelet en mijnschacht zien. Normaal gesproken is de vault ontoegankelijk. Ook andere redditors laten weten eerder de vault in te zijn geraakt en geven aan ook in de afgesloten Vaults 96 en 94 te zijn geweest. De enige manier om later nog de vaults uit te komen is door te fast travellen. Bethesda laat weten dat de vaults nog in aanbouw zijn.

Eerder werd bekend dat er een afgesloten ontwikkelaarsruimte in het spel zit, waar spelers alleen met 'illegale methoden' binnen kunnen komen. Spelers verkochten daarna nog onuitgebrachte spullen op eBay. Accounts van spelers die deze afgesloten ruimtes illegaal binnenkomen, krijgen een ban. McStaken was bang een permanente ban te krijgen vanwege het betreden van Vault 63 en nam daarom contact op met de ontwikkelaar. Het lijkt er niet op dat Bethesda de spelers gaat straffen voor het onbewust bezoeken van vaults.

Al voor de release van het online spel waarschuwde Bethesda voor 'spectaculaire' bugs, toen zei de gamestudio alle bugs af te werken. Volgens redditgebruiker Codkid036 zit de Vault 63-bug al twee maanden in het spel.

Screenshots van redditgebruiker McStaken

Reacties (75)

Kan iemand mij vertellen waarom zo’n ruimte in een live spel zit? Hebben ze geen ontwikkel omgeving?

Dit lijkt inderdaad het geval te zijn. Zulke situaties worden volledig voorkomen door OTAP (of varianten hiervan) omgevingen. In plaats van het Ontwikkel/Test/Acceptatie/Productie model, schijnt Bethesda het OPA model te hanteren.

Online Pleuren en Accepteer dat het niet anders is

Ook bij OTAP kan dit gewoon voorkomen. Als ze iteraties launchen kan het zijn dat er al het e.e.a. is gemaakt voor functionaliteit, dat later beschikbaar gaat komen. Anders moet je namelijk gaan uitsluiten wat er wel en niet in een iteratie uitgerold wordt; Dat vergt ontzettend veel meertijd m.b.t. versiebeheer. (Branching en Merging);
Stel je hebt een stuk code 'abcdefg'. In versie 1.00 staat hier het e.e.a. in. Vervolgens wordt er een branch getrokken en daar de code 'abcdefg' aangepast. Echter blijkt er een bug te zitten in het origineel, en wordt in de Trunk de code 'abcdefg' aangepast in versie 1.01...... Over x tijd blijkt de branch af te zijn en gaan ze die mergen met de trunk.... dan zit je dus met verschillen tussen 1.01 en de branch code die o.b.v. 1.00 was. Het samenvoegen hiervan kan een behoorlijke taak zijn.

Als ze gewoon hadden voorkomen dat je in de desbetreffende vault zou kunnen komen, was het geen probleem geweest.

Ik zag toevallig nog een voorbeeld bij Sea of Thieves, daar mist ineens een stuk van de railing aan de voorkant bij de boten. Hier staat echter nog niks, dus voor de community is het echt speculeren waarvoor het zal zijn.... fishing?.... front cannons?.....
Ook is er een cave die in een eerdere expansion is gebruikt nu compleet gerestyled.... voor waarschijnlijk een volgende update ergens.... de cave is al wel te bewonderen, de functionaliteit nog niet

Het is gewoon een keuze van de ontwikkelaar.

[Reactie gewijzigd door hoi3344 op 11 februari 2019 15:24]

Is het hele principe van iteratieve development niet dat je dingen uitrolt die "Done" zijn? Dan snap ik niet waarom onderdelen die deel uit maken van toekomstige updates uitrollen een verstandige developer keuze is zoals je dat benoemt.

Dat een cave te bewonderen is zonder functionaliteit kan ik nog begrijpen. De toegang en styling van de cave zal deel uit maken van een iteratie op zich. Een omgeving toevoegen aan de game die nog niet toegankelijk moet zijn is niet hetzelfde.

Dat er bij sea of thieves in eens een stukje railing mist, wat ter speculatie over laat waar deze voor zal dienen is dan toch ongewenst? waarom zou je het weg halen van dat stukje railing niet mee laten deployen in de daadwerkelijke iteratie waarin de functionaliteit er voor uit komt?

Sea of Thieves hoort eigenlijk niet in deze vergelijking. De devs letten erg goed op want in de builds voor de spelers zitten en deze wijziging is dan ook expres gedaan, puur om te teasen en mensen te laten speculeren.

Verder heb je wel gelijk, het hele punt van iteratieve development is dat je door developed tot het af is en dan uitbrengt.

Definieer dan 'done'. Zo kan de map al klaar zijn, maar de npc's nog niet.... of de functionaliteit niet...

Ik denk dat het uiteindelijk gewoon een 'kostenoverweging' is, zoals ik heb beschreven in mijn eerdere bericht. des te langer je wacht, des te meer tijd het kost om code samen te voegen.

Maargoed, ik ben verder niet zo bekend met Gaming Development. (meer bedrijfssoftware)

[Reactie gewijzigd door hoi3344 op 11 februari 2019 16:19]

Wat is dan het verschil tussen waterval en iteratief als je doorgaat tot alles 100% af en in steen staat voordat je released? Bij iteratief release je zodra er waarde voor 1 of meer stakeholders te halen is ipv. oppotten. In dit geval is de stakeholder level designer blijkbaar voorgetrokken (waarschijnlijk omdat een deel van het level design ingame gebeurt wat vrij gebruikelijk is).

maar het design dan op live laten plaatsvinden?

Ik snap het als ze stukken willen teasen maar unfinished scenery die unaccessible hoort te zijn hoort gewoon niet op live thuis... als ze willen weten waarom is het wachten tot de eerste casus "waarom anderen allang door schade en schande het anders zijn gaan doen".

Leuk en aardig maar goed leveldesign had ingehouden dat de spelers alsnog de unreachable area's niet in komen en dit is al de 3e situatie (laten we de meerdere instances als één incident zien) die aangeeft dat ze dat gewoon niet voldoende onder de knie hebben om via deze richting te willen werken. Ze voorkomen dan alleen dat ze in hen eigen handen snijden en het kost enkel een TestServer; wat zelfs toegankelijkheid tot de designers vergroot omdat die dan in nog een eerder stadium betrokken kunnen worden en minder kans op leaks geeft zodat teasers nog wat waard zijn; win-win.

[Reactie gewijzigd door Annihlator op 11 februari 2019 21:56]

maar het design dan op live laten plaatsvinden?

Bij een MMO vind bijna alle ontwikkeling in live plaats.
Puur omdat het spel nooit af is, en je toch continue veranderingen wilt toevoegen en je wilt ook gewoon direct de real-life veranderingen zien.

Het enige verschil tussen Bethesda en (zo ongeveer alle andere devvers) is dat Bethesda uitgegaan is van een Single-player engine die juist op jouw gewenste manier is gebouwd en waarbij er dus feitelijk geen verschil is tussen live-spul en dev-spul. Terwijl de andere devvers gewoon een engine opbouwen met keiharde muren zodat de dev-ruimtes gewoon niet binnen te komen is.

In een speciaal gebouwde engine is simpelweg bij elke movement-actie van een speler gedefinieerd dat die actie enkel binnen "live" omgeving mag plaatsvinden, je kan zelfs zo ver gaan dat je je texturen gaat taggen met live etc zodat een gewone speler die een ongewenste ruimte binnenkomt geen texturen ziet.
Alleen tja, bij een bestaande engine moet je dat allemaal achteraf gaan inbouwen en het is bijna zeker dat je dan gaten laat vallen (omdat een gebruiker iets doet wat jij niet verwacht)

Nope, er zijn zat stappen die tot en met testserver uitgevoerd worden en mogelijk de laatste minieme aanpassingen die geen kansgeeft op bugs zal niet per se zijn gedegen testtijd nodig hebben.

Zelf enkele jaren vrijwillig in zo'n testserver meegedraaid en daar steek je genoeg van op waarom dat de goede manier is.

volgens mij zijn het gewoon stukjes gecompileerde stukjes software van de makers zelf, en dus nog niet helemaal afgemaakt.
En per ongeluk gesaved in het spel met als resultaat dat je er naartoe kan gaan.
En misschien wel met opzet gedaan, gemaakt voor de gamer.Of een secret room met alles erop en eraan.Ik meen een paar dagen geleden dat ook al was met een andere room, met een hele hoop wapens op dat level.Volgens mij was dat op deze website ook al gepubliceerd.Maar kan het zo snel niet vinden.

Hoe definieer je done? In principe neem je op in je Definition of Done dat de feature die je uit wilt rollen waarde toevoegd. Als de waarde van deze feature is dat de level designers verder kunnen is er niets mis mee om dit uit te rollen.

"Als de waarde van deze feature is dat de level designers verder kunnen..."

exact...dat is een voorbeeld. Dit wordt dan als Done gemarkeerd, en wordt gemerged met de branch van de update, welke zal worden gemerged met de master branche als de complete update af is.

Nou nee. Nu ben je aan het watervallen: jij wil de game pas releasen als alles 100% klaar is voor de consument. Ik zeg dat je ook released als de feature klaar is voor een andere stakeholder (de level designer). Als de opzet van de infra zo is dat levels in de productie omgeving ontworpen worden met tools in de software zelf zul je toch echt moeten releasen met deze features (achter een vlag zodat niet iedere nitwit erbij kan). Oppotten (mergen/branchen etc.) is niet nodig en compliceert zaken alleen maar.

Inderdaad.
En in het geval van Fallout 76 is het nog vrij makkelijk ook aangezien de engine gewoon plugins ondersteunt.

Ze kunnen dus simpel gezegd de dev ruimtes gewoon in een plugin zetten welke niet met de gewone client word meegeleverd.

Het hoeft niet eens een apart gebuild te worden (dus geen extra dev branch nodig zelfs).

[Reactie gewijzigd door ErikRedbeard op 11 februari 2019 20:49]

Zelf als ontwikkelaar gebruiken we GIT met branches, waarbij elke verandering in een losse omgeving zit. En pas na een merge komen zaken pas weer "bij elkaar" en zouden ze na release in LIVE code terecht komen.

Voor data gerelateerde zaken delen we een database server, 1 voor debug 1 voor live.
Dus zaken komen pas door nadat ze handmatig zijn door gezet.

Ik vraag me af wat voor afscheiding je kunt toepassen bij spel ontwikkeling. Je zit er toch mee dat de wereld in de client zal moeten zitten dan wel in een soort verkapte database of in compileerde code, anders zul je elke keer de spelwereld moeten door streamen nadat je inlogt.

Maar klinkt ook als weer zo'n gevalletje van; er zijn er zoveel in de industrie die MMO's maken, en die zitten met hetzelfde probleem en daar oplossingen voor hebben, maar toch zit er weer een grote jongen tussen die denkt het anders te kunnen doen en nu met weer negatieve publiciteit zitten (er vanuit gaande dat dit niet de bedoeling was).

Dat is mijn hele punt. Die vault zit dan toch in die aparte branch, welke pas gemerged wordt wanneer de complete vault met functionaliteit en al voldoet aan de Definition Of Done?

Ligt een beetje aan de manier hoe je de productie omgeving ziet. Hedendaagse SaaS development heeft hier vele opties voor. Uiteindelijk is de productie de beste test omgeving. Het biedt zo enorm veel voordelen als je bijv een feature flag zet op een deur. Dan kan je elke dag meerdere stukjes achter die deur opleveren en kan alles per direct getest worden (zelfs op de drukste server). Het neemt wel weer ander soort risico's met zich mee maar dat is altijd het geval, jou voorstel is misschien nog wel gevaarlijker ... serieuze dingen kan je direct fixen.... tease bugs als deze kan je laten zitten vanwege het lage risico en eventueel goede publiciteit

[Reactie gewijzigd door Mellow Jack op 11 februari 2019 18:40]

Maar het mooie is dat de engine die ze gebruiken juist perfect is voor modulair te werk gaan.
Die test ruimte exploit van een tijdje terug waar men naartoe kon porten om allerlei wapens/gear te krijgen kan bijvoorbeeld perfect in een extra plugin welke niet meegeleverd word met de client en dus puur intern blijft.

De mods voor skyrim/fallout zijn heel goede voorbeelden van wat deze engine kan (ik praat dan niet over de Script Extender benodigde mods).

Als dat gedoe met fallout 76 komt bij mij voornamelijk over als niet nadenken en gewoon verdergaan zoals we altijd deden. Singleplayer development toepassen op multiplayer.

Nee het is typische SaaS ontwikkeling met 1 centrale codebase als uitgangspunt. Ik snap jou voorbeeld en ja, dat is ook een goede strategie maar het is tegenwoordig gewoon populair om dingen als CI/CD tot in de extreme te doen en mits goed uitgevoerd vind ik het de fijnste manier van werken omdat je zo min mogelijk big bangs hebt (ja een extensie enablen is ook een big bang).

Vermoedelijk is dit meer database vulling voor de levels. Die stop je dus niet in Git. Als je dan van O naar P wilt is het soms wel eens lastig als er niet alleen een code uitrol maar ook een data uitrol (waarbij je in P moet gaan zitten mergen). Ik snap hoe het kan ontstaan, maar het lijkt idd. meer op onervarenheid.

Ik snap hoe het kan ontstaan, maar het lijkt idd. meer op onervarenheid.

Het is pure onervarenheid + hergebruik van een Engine die er niet voor geschikt is.

Met een beetje ervaren persoon erachter kan je de data gewoon in P mergen omdat het een tag heeft dat het enkel voor dev is. Je tags houden dan gewoon de data uit elkaar.

Dit kan je niet oplossen met OTAP straat aangezien je aan de programmatuur (dat is je OTAP-straat) en aan de data zit te klooien en het gebeurt door 2 aparte teams die elk los releasen

Data heeft de nare eigenschap dat het in tegenstelling tot code niet los staat van de rest. Primaire sleutels moeten uniek zijn en de foreign keys moeten kloppen etc. Als je datamodel een zak records zou zijn kun je taggen en pushen. In de praktijk is dat vele malen lastiger en zou ik datasets niet zoals code behandelen

Aangezien dit ook Bethesda's eerste poging tot het ontwikkelen en uitbrengen van een online game (Elder Scrolsl Online is door een andere studio ontwikkeld) is, lijkt me dit helaas nog best realistisch ook.

Een "live" online game uitbrengen en onderhouden is toch een andere opgave dan iets wat hoofdzakelijk berust op een single-player ervaring met misschien een multilpayer-component, en ik kan me voorstellen dat hiertoe niet de juiste kennis aanwezig was in de studio.

Overigens had een studio als Bethesda misschien wel het vooruitzicht kunnen hebben om voldoende talent op dit gebied te vergaren voordat ze met FO76 live gingen, maar die launch is uiteraard een aparte discussie.

Mwa; dit concept heet gewoon feature toggles, alleen is het ze niet helemaal gelukt om het goed af te schermen voor alle gebruikers

Werken met feature toggles op productie is overigens wel gewoon een best-practice voor veel bedrijven (ook de facebook's en netflixen van deze wereld), uiteindelijk is namelijk niets zo representatief als productie dan productie zelf

De Bluehole manier. Ik geloof dat zij het tot een nieuwe kunst hebben verheven.

Dit lijkt inderdaad het geval te zijn. Zulke situaties worden volledig voorkomen door OTAP (of varianten hiervan) omgevingen. In plaats van het Ontwikkel/Test/Acceptatie/Productie model, schijnt Bethesda het OPA model te hanteren.

Online Pleuren en Accepteer dat het niet anders is

Ook wel bekend onder de geuzen-naam Developmestruction environment.

[Reactie gewijzigd door R4gnax op 11 februari 2019 21:55]

Dat hangt er helemaal van af hoe goed de testen zijn, en of het echt een probleem is dat deze ruimtes beschikbaar zijn. Het kan ook heel goed zijn dat men simpel weg gebruikmaakt van deze ruimte om bijvoorbeeld tests uit te voeren op een server waar mensen ook echt spelen. Je kunt nog zulke goede load generators hebben maar het is praktisch onmogelijk om (met een niet ongelimiteerd budget) de handelingen van enkele duizenden mensen te simuleren.

Daarnaast is een beleid waarbij men simpel weg dingen redelijk goed test en dan aan de gebruikers geeft om te zien wat men er mee doet helemaal zo'n slecht idee nog niet. Het is simpel weg een keuze om meer snelheid te hebben bij het uitproberen en uitrollen van features. En zo lang het geen game breaking changes zijn is er helemaal niets mis mee als mensen toevallig een ruimte bereiken die (nog) niet bedoeld was voor de spelers.

Het grootste probleem bij een MMO is dat je al snel op een punt bent waar je simpel weg niet kunt voorspellen hoe bepaalde dingen uitpakken. Kijk naar de plague bij WoW als een goed voorbeeld van goed getest en toch niet helemaal werkend zo als bedoeld. Zo als elke developer weet elke feature is fantastisch tot de gebruikers er mee aan de haal gaan... Zo als een producer van een andere MMO het eens omschreef een van zijn criteria voor nieuwe features is wat hij noemt: "the time to dick" of hoelang duurt het voor de spelers er een piemel van kunnen maken.
Dit soort dingen zijn heel moeilijk te testen omdat een tester simpel weg een bepaalde tijd heeft om alles te testen. En zij vaak (na 8h testen per dag) echt niet meer hele avonden de game willen spelen. Dus zij hebben gewoon de tijd niet om dit soort misbruik echt te testen tenzij er een budget voor gesteld is.

Waarschijnlijk te maken met iteratief bouwen van functionaliteit en meteen te leveren. Echter geloof ik niet dat dit een bug is.

met iteratief bouwen van functionaliteit en meteen te leveren

Waarom zou dat niet kunnen met een ontwikkelomgeving/testomgeving? Iteratief ontwikkelen en features pas leveren zodra de feature klaar is, is wat praktisch elk software ontwikkelend bedrijf doet. Dat is echt geen hogere wiskunde.

Iteratief ontwikkelen betekent ook iteratief leveren. A working piece of functionality. Echter maakt het deel uit van een groter onderdeel wat niet toegankelijk is voor spelers.

Dat ze een "bug" hiermee hebben waarbij men hierheen wordt geteleporteerd is een ander verhaal.

Kan je een functie wel "geleverd" noemen als deze in de regel nog ontoegankelijk is?

Ja, doorgaans stop je functionaliteit die je nog niet live wilt hebben voor de hele wereld achter een "feature toggle". Daarmee kan je dan de feature "aan" zetten wanneer je zelf wilt. Ik kan mij voorstellen dat dit bij Fallout betekend dat er een patch komt welke een "invisable wall" weghaalt of iets anders toevoegt zodat je er kan komen.

Iteratief ontwikkelen betekent ook iteratief leveren. A working piece of functionality.

Hangt een beetje van de definitie "werkend" af, of Bethesda in hun volledige bestaan dan ooit ook maar één degelijke titel afgevelerd heeft.

Waarschijnlijk moet QA het in een live omgeving testen. In een test omgeving kan je de server load van een echte game session moeilijk simuleren. Maar het is nog steeds slecht van Bethesda. Ze horen test spelers een flag of iets dergelijks te geven voor toegang tot de levels en elke speler die dat niet heeft er uit teleporteren.

bij een eerder bericht over dit soort ruimtes is ook wel een uitgebreide uitleg gegegen (alleen kan ik die weer niet terug vinden). Maar het komt er op neer dat sommige testen niet echt realistisch getest kunnen worden in een ontwikkel omgeving of een testomgeving en daarom worden die dan op een afgesloten live omgeving getest.

Je hebt altijd een ontwikkel-omgeving. Soms heb je ook een aparte omgeving voor productie :-)

Daar kunnen veel redenen voor zijn. Het komt bijvoorbeeld heel vaak voor dat grote delen van een nieuw deel van een spel al naar de clients worden gebracht om een grote update te voorkomen. In 't algemeen zit in snel ontwikkelende software vaak al "voorwerk" voor functies die nog in progress zijn.

Kan natuurlijk ook gewoon de doodsimpele rede zijn dat ze op release simpelweg de deur unlocken ipv dat iedereen zijn game moet afsluiten en een paar GB gaat zitten downloaden.

De meest simpele verklaring: dit zit er al vanaf het release moment in omdat het ooit wel het plan was om ze bij release af te hebben, maar dat is niet gelukt. Lijkt me niet dat de vaults afmaken op dit moment de prio heeft.

Je krijgt nul punten maar ik heb een gelijksoortige ervaring waar product owners focussen op features en waar technisch onderhoud wordt uitgesteld. Ik weet niet hoe het er bij Bethesda aan toegaat maar ze hebben nou niet bepaald een goed track record.

Die hele game is en blijft een trainwreck van ellende......

Nul hoop over voor Elder Scrolls 6.

Hoezo?

Volgens mij staan de bouwers van de twee games geheel los van elkaar?

als ze nog steeds in dezelfde engine blijven heb ik ook weinig hoop

als ze nog steeds in dezelfde engine blijven heb ik ook weinig hoop

Ik ook, het is een waardeloze engine, die ontzettend veel bugs heeft en problemen heeft, en vele jaren elke keer achter lopen op de rest van de engines en spellen, al helemaal qua beeld/grafische kwaliteit.

Het is een probleempje bedrijfscultuur en management, niet de schuld van individuele ontwikkelaars op een team. Dit is daarom ook door te trekken naar Elder Scrolls, wat ook ontwikkeld wordt door Bethesda.

niet de schuld van individuele ontwikkelaars op een team

Ik heb nog eens door flink wat van de Papyrus referentie-broncode voor de DLCs van Skyrim heengebladerd. I.h.b. hoe de events voor vampier-aanvallen inkopellen op de dag-/nacht-cyclus en hoe het stuk eeuwigdurende nacht geimplementeerd is.

Ik kan je vertellen: als dat het algemene kwaliteitsniveau is; dan zijn ook individuele ontwikkelaars een probleem.

Niet de schuld van het gebrek aan code review, quality assurance, enzovoorts?

Niet de schuld van het gebrek aan code review, quality assurance, enzovoorts?

Nee. Dat zag er echt uit als "baby's eerste programmeer-werkje."

Ik weet vrij zeker van niet, het word nog altijd ontwikkeld door bethesda die de boel in-house doet, dus er zal significante overlap zijn in het ontwikkelteam van de games.

Daarnaast is de creation engine inmiddels al een tikje outdated (2011), wat op zich niet zo'n punt is ware het niet dat het vanaf het begin al geen ideale engine is met een hele hoop quirks zoals het feit dat de physics by default gebonden zijn aan je framerate.

Als het technisch grondvest gammel blijft (en volgens mij is gammel nog een zwaar understatement als we het over de Creation Engine hebben) maakt het weinig uit welke ontwikkel-teams ermee aan de slag gaan.
Analogie: Verstappen kan nog zo'n goede coureur zijn, maar met een rijdende schroothoop zal hij ook geen enkele race kunnen winnen.

edit: Creation Engine, niet Gamebryo

[Reactie gewijzigd door w00t00w op 11 februari 2019 15:17]

edit: Creation Engine, niet Gamebryo

Allebei dezelfde troep.

Bethesda claimt dat het sinds Skyrim een complete rebuild van hun engine gedaan heeft, maar dat is dikke, dikke marketing-onzinpraat. Er zijn notabene nog bindings naar oude systemen uit Fallout 3 in Skyrim teruggevonden; nog altijd 'inert' aanwezig.

[Reactie gewijzigd door R4gnax op 11 februari 2019 21:52]

Hij is 15 euro nu en nog koop ik hem niet, zo slecht is deze game.
Hopelijk leren ze wat en is elder scrolls 6 wel een kraker.

[Reactie gewijzigd door D0gtag op 11 februari 2019 15:17]

Meh, vroeger (20 jaar geleden) waren dit soort hidden plekken van een map vet, nu is een game bij release zèlf nog steeds in aanbouw (ofwel gewoon niet af/alpha) dus zo nieuwswaardig lijkt me dit niet.

Ik lees best vaak het woord illegaal in een context waarvan ik denk dat deze onjuist is. Is het teleporteren naar een ruimte echt tegen de wet?

Laatst las ik ook zoiets over filmen in de bioscoop. Het leek me een reden om levenslang uit de bioscoop verbannen te worden. Nu blijkt daar een uitzondering voor gemaakt te zijn in de wet. Illegaal dus.

ik zal wel minnetjes krijgen maar wat is de nieuwswaarde ten opzichte van een willekeurige andere game wat ook wel eens zeer bijzondere bugs bevat?

Een Vault waar informatie voor DLC in verborgen is? Lijkt wel opzet zoiets. Allemaal speculatief van mij natuurlijk. Maar goed ik vind zelf dat dit lekker op reddit moet blijven zolang het geen grote impact op de algehele industrie kan hebben oid. Ofwel, boejueh, naar mijn idee zou Tweakers stampvol met dit nieuws moeten staan als alles "voor de een wel en ander niet relevant" moet zijn.

Oke ik stop met zeiken.

In andere games word je niet gebanned en de items worden (of kunnen) niet verkocht worden op eBay.

Daarnaast is het zo dat dit soort evenementen zich nu wel aan het ophopen zijn rond fallout 76, eerst met de canvas/nylon tassen van de collector's edition, en een aantal uitspraken van Bethesda topmensen die eufemistisch uitgedrukt "niet helemaal politiek correct" waren.

zolang je items aan elkaar door kan geven in de game, kun je ze ook verkopen op ebay.
Bij de meeste games wordt hier op gehunt en wordt je gewoon gebanned op het moment dat je dit doet.

In andere spellen wordt je volgens mij ook gewoon gebanned als je hack. Om in de dev room te komen moest je de console inschakelen (wat niet op een "legale" manier mogelijk is) en handmatig naar een specifieke locatie teleporteren.

Andere games 'bannen' niet meteen.

Mee eens. Ik durf ook bijna met zekerheid te zeggen dat de mensen die daadwerkelijk geïnteresseerd zijn in dit spel dit nieuws al elders gelezen hebben. Deze mensen zijn daarbij ook maar een heel klein percentage van de Tweakers userbase. Nutteloos artikel naar mijn mening. (ja toch geklikt met de hoop dat er een soortgelijke reactie erbij stond)

Waarom is dit uberhaupt nieuws op Tweakers? Fallout 76 is een zwaar en terecht geflopte game van een developer die het afgelopen jaar heeft bewezen op dit moment nul fucks te geven om ons als gamers.
Van de leugens omtrent de game zelf, de preorder bag tot de nuka rum, het is een groot debacle. Deze game zou m.i. Stelselmatig genegeerd moeten worden. Er zijn vast echte games om wat over te reporten.

Zodat we lekker kunnen zeiken over de flutgame Fallout 76.

"Al voor de release van het online spel waarschuwde Bethesda voor 'spectaculaire' bugs, toen zei de gamestudio alle bugs af te werken."

Nog een leugen, als er 1 ding is wat Bugthesda nooit doet is dit het wel.

"Al voor de release van het online spel waarschuwde Bethesda voor 'spectaculaire' bugs, toen zei de gamestudio alle bugs af te werken."

Nog een leugen, als er 1 ding is wat Bugthesda nooit doet is dit het wel.

Bugs afwerken zijn ze juist kampioen in. Hun titels zitten tjokvol met allerlei bugs; sommige zo complex en uitermate idioot dat het tot een soort kunst verheven zou kunnen worden.

Bugs oplossen daarentegen...

Als we het over een andere game hadden zou ik denken dat deze "bug" bewust is geïmplementeerd om in het nieuws te komen.

Ik hoop in ieder geval dat ze de mijnschacht nog wat verder afwerken; ik vindt het nogal lijken op graphics van pak 'm beet 15 jaar oud.

Precies, lijkt wel Half-life 2 uit 2004

Verschrikkelijk gedrocht, mijn slechtste 'game' aankoop ooit.

Had je kunnen weten. Ik was niet eens geïnteresseerd in deze game en zelfs ik kreeg mee wat voor een ramp deze game was voor en net na release.

Ik had het kunnen weten. Toch gekocht. Ondanks het slechte nieuws. De collectors edition zelfs. Heb de endgame niet eens gehaald. Rond level 35 was ik er compleet mee verveeld.Of de game overigens zo slecht is als het nieuws durf ik nog niet eens te zeggen. Ik speelde zelf op de PS4 en dat was voor mij zelf best goed te doen. Crashen deed het zeker. Maar niet minder vaak als ik van de voorgangers van Fallout ook wel gewend was. Daar hebben alle intersante events en characters me toch altijd daar weer heen kunnen trekken. Wat me hier vooral heeft laten stoppen is het absolute gebrek aan vermaak. Als statement nog wel een verzoek ingeschoten voor een vervangende canves tas. Maar ik laat de game voorlopig links liggen. Wie weet kijk ik er over een half jaar nog weer eens een keertje naar. Maar ik kan me eigelijk bijna niet voorstellen dat ze dit gebrek aan vermaak structureel kunnen oplossen. Mocht je je overigens wel vermaken met de game geniet er dan rustig van. Maar de game is helaas toch niet aan mij besteed.

“Game”