Hoe ontwerp je previews voor meubelplaatsing die botsingen en verkeerde plaatsing voorkomen
In een decoratiespel moet een meubelpreview drie vragen beantwoorden voordat de speler bevestigt: waar komt het meubel te staan, is die plek toegestaan en wat gebeurt er als de speler het draait of annuleert? Gebruik een live ‘spookweergave’ van het meubel, controleer de voetafdruk op de huidige positie en in de huidige rotatie, en geef duidelijk aan waarom plaatsing wordt geblokkeerd. Houd de preview zichtbaar totdat de speler bevestigt en zorg dat annuleren de speler terugbrengt naar de kamer zonder iets te plaatsen. Deze gids richt zich op het ontwerpen van die plaatsingsinteractie voor gameontwikkelaars.
Wat moet de preview duidelijk maken?
Behandel de preview als een tijdelijke versie van het uiteindelijke meubel, niet alleen als een cursorindicator. De preview moet de grootte en oriëntatie van het meubel tonen, evenals het contactpunt met de vloer of het draagvlak en de plaatsingsstatus. In de ontwerpaanbevelingen voor ARCore raadt Google aan het bestemmingspunt met het object of de schaduw ervan weer te geven en tijdig feedback te geven wanneer een oppervlak is gedetecteerd. Hoewel plaatsing in AR andere beperkingen kent dan in een decoratiespel, geldt hetzelfde principe: spelers moeten zien waar een meubel terechtkomt voordat ze de plaatsing bevestigen. Google’s richtlijnen voor contentplaatsing in ARCore
Een bruikbare preview heeft drie goed te onderscheiden statussen: geldig, ongeldig en onbepaald. Geldig betekent dat de voorgestelde plaatsing aan de spelregels voldoet. Ongeldig betekent dat een bekende regel wordt overtreden, bijvoorbeeld doordat het meubel een ander object overlapt of op een oppervlak staat dat het niet kan dragen. Onbepaald betekent dat het spel nog geen geldig doel kan bepalen, bijvoorbeeld omdat de cursor op een muur staat terwijl de speler een meubel op de vloer probeert te plaatsen. Geef onbepaald niet weer als geldig alleen omdat de botsingscontrole niets heeft gevonden: ‘geen botsing gedetecteerd’ en ‘kan hier worden geplaatst’ zijn niet hetzelfde.
Welk verschil is er tussen geldigheid en botsingsdetectie?
Botsingen zijn slechts één onderdeel van de geldigheid van een plaatsing. Een bank kan een ander object niet raken en toch buiten de kamer staan, boven de vloer zweven, in een onbruikbare richting wijzen of volgens de spelregels een deuropening blokkeren. Definieer geldigheid als een lijst met voorwaarden per meubelcategorie: toegestaan draagvlak, kamergrenzen, botsingen, oriëntatiebeperkingen en eventuele vrije ruimte voor toegang of interactie die het spel vereist.
Houd harde regels en voorkeuren uit elkaar. Een botsing of een ongeschikt oppervlak kan bevestiging verhinderen. Een smalle doorgang kan een zachte waarschuwing zijn als het spel plaatsing toestaat. Zo lijkt een decoratieve suggestie niet op een harde fout en begrijpen spelers welke voorwaarden ze desgewenst kunnen accepteren. Onderzoek naar systemen voor meubelindelingen houdt er ook rekening mee dat indelingen door meerdere regels worden bepaald, niet alleen door geometrie. Het gepubliceerde systeem van Stanford verwerkte richtlijnen voor interieurontwerp en liet deelnemers voorgestelde indelingen beoordelen. Dit is een reden om meer dan alleen botsingen mee te wegen, maar schrijft geen specifieke spelinterface voor. Onderzoek van Stanford naar interactieve meubelindelingen
De technische controle moet overeenkomen met de getransformeerde voetafdruk in de preview. De overlap-API van Unreal Engine beschrijft hoe je een opgegeven botsingsvorm controleert op een bepaalde positie en in een bepaalde rotatie. Unity 6’s Physics.OverlapBox accepteert een middelpunt, halve afmetingen, oriëntatie, laagmasker en instelling voor triggergedrag. Deze API’s laten zien waarom een wijziging in de rotatie een nieuwe controle met de gedraaide vorm moet activeren. Gedrag van game-engines en API-details verschillen per versie; raadpleeg de documentatie voor de engineversie en botsingsinstellingen waarmee de game daadwerkelijk wordt uitgebracht. De overlap-API van Unreal Engine en Unity 6 Physics.OverlapBox
Hoe moeten geldige en ongeldige posities eruitzien?
Combineer het uiterlijk met een extra, duidelijke aanwijzing. Verander bijvoorbeeld de tint en omtrek van de spookweergave en toon een korte status zoals ‘Klaar om te plaatsen’ of ‘Overlapt tafel’. Alleen op kleur vertrouwen kan lastig zijn, vooral op vloeren met verschillende kleuren of bij wisselende belichting. Houd het silhouet van het meubel in beide statussen zichtbaar, zodat de speler de positie en rotatie nog steeds kan beoordelen. Als een specifieke collider de blokkering veroorzaakt, kan het helpen die te benoemen. Maak de preview niet te vol met technische details als één begrijpelijke reden volstaat.
Werk de status bij terwijl het meubel beweegt, niet pas nadat de speler op de bevestigingsknop drukt. Plaats het meubel na bevestiging alleen als de huidige status geldig is en geef kort aan dat de actie is gelukt. Is de plaatsing ongeldig, laat de preview dan actief en vermeld de reden, zodat de speler de positie kan aanpassen zonder de interactie opnieuw te starten. Dit is een ontwerpaanbeveling die is afgeleid van het doel om onbedoelde plaatsing te voorkomen en van Google’s advies om fouten duidelijk te melden en een bruikbare manier aan te bieden om ze op te lossen. Google’s richtlijnen voor foutstatussen
Vertrouw niet op één drempelwaarde die de hele spookweergave zonder uitleg van geldig naar ongeldig laat omslaan. Als een stoel bijvoorbeeld te dicht bij een muur staat, moet de speler de werkelijke voetafdruk zien en een specifieke aanwijzing krijgen, zoals ‘Buiten de kamer’ of ‘Overlapt muur’. Is de regel alleen een voorkeur, vermeld dan dat het om een waarschuwing gaat en laat bevestiging toe als dat past bij het ontwerp van de game.
Welke feedback moet het draaien geven?
Houd de preview tijdens het draaien gekoppeld aan de invoer van de speler en controleer de plaatsing opnieuw bij de nieuwe hoek. De voetafdruk kan een object in de buurt raken, ook als het middelpunt van het meubel nauwelijks beweegt. De draaibediening moet bovendien duidelijk maken welke verandering de speler kan verwachten: een zichtbare draaihint, een duidelijke stapgrootte bij stapsgewijs draaien of een indicator voor doorlopend draaien kan laten zien wat de invoer doet.
Werk na het draaien zowel de spookweergave als elke oriëntatieaanwijzing bij. Een kleine pijl op de vloer, een markering aan de voorkant of een zichtbare voorrand kan duidelijk maken welke kant van een bank of bureau naar voren wijst. Als het meubel op een raster of vaste stappen wordt uitgelijnd, toon dan het uitgelijnde resultaat in de preview en niet alleen de onafgeronde cursorpositie. Zo kan de speler de plaatsing beoordelen die daadwerkelijk wordt bevestigd.
Hoe moeten annuleren en herstellen werken?
Maak annuleren beschikbaar via een vaste, zichtbare bediening zolang de speler een meubel vasthoudt. Annuleren moet de spookweergave verwijderen en de vorige staat van de kamer herstellen, zonder meubels ongemerkt te plaatsen, verwijderen of verplaatsen. Als de speler een bestaand meubel verplaatst, moet annuleren het terugzetten op de oorspronkelijke plek. Dit is een aanbevolen interactieregel, geen gedrag dat door een engine-API wordt gegarandeerd.
Geef bevestigen en annuleren verschillende labels of pictogrammen en laat de preview staan totdat de speler een van beide kiest. Toon bij een geblokkeerde plaatsing een kleine aanwijzing voor de volgende stap, zoals verplaatsen, draaien of annuleren, in plaats van de speler te laten raden. Ook in de plaatsingsrichtlijnen van Google worden duidelijke foutmeldingen en een oplossing aanbevolen. Google merkt daarbij op dat gebruikers soms uitleg nodig hebben voordat ze een sleepbeweging gebruiken. Toon in games de relevante bediening wanneer het meubel wordt opgepakt, niet alleen op een apart hulpscherm. Google’s richtlijnen voor handmatige plaatsing
Een uitgewerkt voorbeeld: een boekenkast plaatsen
Stel je voor dat een speler een boekenkast naast een muur probeert te zetten. De preview vindt eerst een doel op de vloer en schuift de boekenkast tegen de muur. De voetafdruk overlapt een bijzettafel, dus de spookweergave toont een ongeldige status met de melding ‘Overlapt bijzettafel’. De speler draait de boekenkast; de voetafdruk wordt opnieuw berekend met de nieuwe hoek en past nu zonder overlap. Een markering aan de voorkant bevestigt welke kant naar de kamer wijst. De speler ziet ‘Klaar om te plaatsen’, bevestigt en het meubel verschijnt op de plek die de spookweergave liet zien.
Komt de boekenkast deels buiten de kamergrens terecht, dan moet het spel die beperking aangeven, ook als er geen objectbotsing is. Kan het doeloppervlak niet worden bepaald, toon dan een neutrale aanwijzing dat de plaatsing onbepaald is, zoals ‘Plaats op de vloer’, en sta bevestiging niet toe. Deze meldingen zijn voorbeelden ter illustratie en geen uitspraken over functies van Metlivi of gemeten gebruiksvriendelijkheid.
Een praktische ontwerpchecklist
Schrijf vóór de implementatie de plaatsingsregels per meubeltype op en bepaal welke regels plaatsing blokkeren en welke alleen een waarschuwing geven. Controleer vervolgens of de preview dezelfde voetafdruk, rotatie, uitlijning en steunpunt gebruikt als het geplaatste object. Controleer de interactie bij muurranden, hoeken en smalle openingen, en na het draaien; zorg ervoor dat de spookweergave geen positie geldig verklaart die bij het uiteindelijke plaatsen wordt afgewezen. Test tot slot de volledige interactie: oppakken, verplaatsen, draaien, herstellen vanaf een ongeldige plek, plaatsen en annuleren, ook wanneer je bestaand meubilair verplaatst.
De beslisregel is eenvoudig: toon het exacte voorgestelde resultaat, maak onderscheid tussen geldige, ongeldige en onbepaalde statussen, leg de nuttigste reden voor een blokkering uit en bied een voorspelbare manier om te draaien, aan te passen, te bevestigen of te annuleren. Zo wordt de plaatsingspreview een praktisch hulpmiddel bij het kiezen, in plaats van een waarschuwing op het laatste moment.
