Ontwerpen voor prestaties

Ontwerpen voor prestaties betekent het volgen van een handvol beste praktijken terwijl je je spel bouwt. In vergelijking met het vinden en oplossen van prestatieproblemen later in het ontwikkelingsproces, kan het vroeg ontwerpen voor prestaties je veel tijd en moeite besparen.

Apparaten met lage specificaties

Apparaten met lagere specificaties, met name mobiele apparaten, hebben ernstige geheugenbeperkingen en zijn gevoelig voor crashes door out of memory (OOM) fouten:

• Als je lagere-end apparaten wilt ondersteunen, kies dan ten minste één "basislijn" apparaat, test je spel op dit apparaat gedurende het ontwikkelingsproces, en let goed op de frame rate en het geheugengebruik. Terwijl je probleemgebieden in je spel vindt, gebruik je die gebieden om de limieten van je apparaat te identificeren.

  Bijvoorbeeld, je zou een spel kunnen testen met de Render (ShiftF2) en Samenvatting (ShiftF2) debugstatistieken ingeschakeld. Als de frame rate begint te dalen in een bijzonder rommelige omgeving, kun je de Draw (scene) cijfers bekijken en bepalen dat je onder de 1.000 draw calls en 1.000.000 driehoeken moet blijven om het spel goed te laten draaien op je basislijn apparaat.

  Of je zou de Developer Console (F9) kunnen bekijken en opmerken dat het geheugengebruik een beetje hoog is, tenzij je streaming inschakelt. Een duidelijk begrip van de apparaatlimieten kan je helpen om daaronder te blijven terwijl je verder bouwt aan je spel.

  

• De apparaatemulator in Roblox Studio is nuttig voor het controleren van de beeldverhouding en de bedieningselementen, maar is niet nauwkeurig voor geheugengebruik; wanneer je een spel in Studio test, draait het de server en de client, waardoor het geheugengebruik aanzienlijk hoger is.

Algemeen gesproken kan testen op verschillende apparaten je helpen te controleren of het spel overeenkomt met je visuele en prestatieverwachtingen op verschillende grafische kwaliteitsniveaus. Voor een veel gedetailleerder voorbeeld van hoe je zou kunnen nadenken over het optimaliseren van je spel voor apparaten met lage specificaties, zie Real World Building and Scripting Optimization.

Streaming en teleportatie

• Instance streaming stelt Roblox in staat om 3D-inhoud dynamisch te laden en te ontladen en is een geweldige optie voor de meeste plaatsen, vooral grotere. Streaming verbetert de join-tijden, vermindert de geheugendruk en verhoogt de frame rate.

  Bijvoorbeeld, wanneer je Workspace.EnableSLIMAvatars inschakelt en de LevelOfDetail eigenschap van je wereldmodellen instelt op SLIM, kun je werelden creëren met sociale ruimtes en drukke evenementen die visueel bevolkt blijven terwijl ze schalen over een breed scala aan apparaatspecificaties. Voor meer informatie, zie SLIM en Verbeter prestaties.

• Overweeg om grote plaatsen op te splitsen in meer beheersbare en gebruik teleportatie om spelers tussen hen te verplaatsen. Deze aanpak kan de initiële join-tijden verminderen, maar legt extra join-tijden op wanneer spelers van plaats naar plaats teleporteren. Voordelen voor geheugengebruik variëren afhankelijk van de grootte van de plaats en of je streaming hebt ingeschakeld.

  Zelfs zonder prestatieoverwegingen, kun je ontdekken dat het hebben van meerdere plaatsen het ontwikkelingsproces vereenvoudigt, vooral als je regelmatig nieuwe inhoud aan je spel toevoegt of deel uitmaakt van een groter team.

Materialen en duplicatie

• Standaardmaterialen gebruiken veel minder geheugen dan aangepaste texturen, maar passen mogelijk niet bij je artistieke visie. Probeer materialen te gebruiken wanneer mogelijk om het geheugengebruik voor de texturen die centraal staan in je spel te besparen.

• Terwijl je activa maakt, zet ze om in pakketten. Pakketten onderdeel maken van je workflow helpt om het veelvoorkomende probleem van dubbele activa met verschillende ID's te vermijden, wat de prestaties kan schaden.

• Wanneer je meshes en texturen toevoegt, gebruik en hergebruik ze in plaats van dubbele kopieën te importeren. Door te schalen, te roteren en te overlappen, kun je rijke, gevarieerde omgevingen creëren die zeer weinig draw calls vereisen. Voor meer informatie, zie Verwijder dubbele texturen.

Transparantie

• Vermijd transparantiewaarden anders dan 0 (zichtbaar) en 1 (onzichtbaar). Wanneer je gedeeltelijke transparantie gebruikt, wees dan vooral voorzichtig om hoge transparantie-overdraw te vermijden.

Scripting

• Schrijf waar mogelijk gebeurtenisgestuurde code in plaats van per-frame berekeningen. Bij 60 FPS is het totale budget voor elk frame 16,67 milliseconden (ms). Zelfs schijnbaar kleine per-frame berekeningen kunnen een aanzienlijk deel van dat budget gebruiken.

• Zoek manieren om langlopende code op te splitsen in beheersbare stukken. Als een stuk code 100 ms nodig heeft om uit te voeren en je het elke frame uitvoert, kan je spel slechts 10 FPS draaien. Als je besluit om de code slechts één keer per seconde uit te voeren in een spel dat anders op 60 FPS draait, komen 59 van je frames na 16,67 ms... en dan één na 100 ms, wat een schokkende hapering veroorzaakt.

  Onderzoek in plaats daarvan hoe je de code kunt opsplitsen. Misschien kun je 5 ms werk per frame uitvoeren, task.wait() gebruiken en de voltooide berekening elke 20 frames hebben terwijl je nog steeds 60 FPS behoudt. Multithreading kan ook helpen, soms Parallel Luau genoemd.

• Gebruik de RBXScriptConnection:Disconnect() methode om te voorkomen dat functies onnodig worden aangeroepen de volgende keer dat een gebeurtenis wordt geactiveerd.

• Roep niet dezelfde methode elke keer aan wanneer je een waarde nodig hebt. Roep de methode één keer aan, sla de waarde op en overschrijf deze later indien nodig.

• Sla niet alles op in ReplicatedStorage. De client laadt alles wat in deze container staat. Gebruik in plaats daarvan ServerStorage voor alles waar de client geen toegang toe nodig heeft.