Share
In ons inleidende stuk over incrementele spellen hebben we de geschiedenis van het genre bekeken en bekeken wat deze spellen uniek maakt, maar we hebben ons niet te diep verdiept in hun daadwerkelijke ontwerp. Hoewel incrementele games eenvoudig kunnen lijken, onthult hun ontwerp een complexe en bedachtzame bedoeling van hun makers. Door naar enkele succesvolle voorbeelden van het genre te kijken, kunnen we de functies van deze spellen beter waarderen en beter begrijpen hoe we onze eigen ontwerpen kunnen ontwerpen.
Voordat ik in het wiskundig kader duik, zijn er drie gemakkelijk over het hoofd geziene maar belangrijke gebieden van ontwerp die ik wil benadrukken: de kwaliteit van exploratie en ontdekking, het verschil tussen 'inactieve' en 'clicker'-uitdrukkingen van het genre, en het belang van samenhangend thema en kunst.
Een van de belangrijkste vectoren van 'plezier' in een oplopende game is die van ontdekking. Veel van deze spellen beginnen met een zeer eenvoudige beginconfiguratie, maar de complexiteit neemt toe naarmate de speler verder komt. Het proces van het blootleggen van deze complexiteit maakt gebruik van de aangeboren aantrekkingskracht van het ontdekken van nieuwe en verborgen functies. Snoepdoos, kan bijvoorbeeld worden opgevat als een spel dat voornamelijk gaat over het verkennen van het systeem, en de 'ophogen' suikerscore is eenvoudigweg het mechanisme om meer inhoud te ontsluiten.
Dus, de meeste incrementele spellen maken het geheel van het systeem niet vanaf het begin beschikbaar, maar in plaats daarvan "extra functies" tegen lagen van de primaire valuta. Deze inhoud kan een "bekende onbekende" zijn, zoals in Stationair draaien om de goden te besturen, wanneer bepaalde delen van het spel expliciet leeg zijn en specificeren hoe en wanneer ze kunnen worden ontgrendeld, of een "onbekend onbekend", waarbij de speler niet eens weet dat de functies bestaan totdat een bepaald niveau is bereikt, zoals bijna alle inhoud in Cookie klikker. Sommige spellen bevatten mogelijk elementen van beide: AdVenture Capitalist informeert de speler over veel van zijn inhoud die ze kunnen ontgrendelen, maar bevat talloze verborgen functies die tijdens het spelen naar voren komen.
Ik denk dat we nog een lange weg te gaan hebben.Ontdekking is een belangrijke functie om te overwegen bij het ontwerpen van een oplopende game, omdat het een oriënterend beloningssysteem biedt voor de speler terwijl ze leren over de kernmechanismen van de game. Door alles voorin te presenteren, zou niet alleen de toegangsbarrière voor het leren van het spel worden opgeheven, maar ook de vreugde worden weggenomen die het gevolg is van een geleidelijke kennismaking met een systeem.
Incrementele games hebben de neiging om zich te concentreren op twee overlappende, maar onderscheiden primaire mechanica:
Spellen die zich richten op de laatste zullen over het algemeen een letterlijke "klikkende" monteur hebben om groei te produceren, of een andere manier om actieve spelersparticipatie te vereisen, zoals opslagdoppen die veelvuldig spelersinterventie vereisen. In CivClicker, de speler moet bijvoorbeeld zijn stad voornamelijk actief beheren, met slechts korte periodes van niet-actieve groei. Omgekeerd kunnen games die zich richten op autonome groei een klikmechanisme bevatten, maar als dat het geval is, neemt het belang ervan geleidelijk af ten gunste van iets geautomatiseerds. In AdVenture Capitalist,despeler moet eerst actief klikken, maar ontgrendelt snel de mogelijkheid om het proces te automatiseren, en is dan grotendeels vrij van handmatig incrementeren.
Deze keuze is grotendeels een kwestie van voorkeur en nadruk op de doelen van het spel. Een spel dat actief beheer vereist, kan in een kort tijdsbestek aantrekkelijker zijn voor de speler, maar als het wordt geïmplementeerd op een manier die te veel betrokkenheid van spelers vereist, kan het in strijd zijn met de principes van ethisch en humaan spelontwerp. Omgekeerd kan een meer autonome of inactieve benadering minder betrokkenheid van de speler in een bepaalde spelsessie vereisen, maar kan het een meer langdurige inzet voor het spel opleveren, wat verklaart waarom "inactieve" spellen op Kongregate zo'n hoge retentiegraad hebben. AdVenture Capitalist informeert de speler zelfs nuttig wat er tijdens zijn afwezigheid is gebeurd, met de nadruk dat het niet je voortdurende aandacht vereist:
Incrementele games profiteren nog vaak van een verhalend thema waarop de monteurs zitten (hoewel dit gemakkelijk over het hoofd te zien is omdat deze mechanica zo minimaal zijn.)
Een verstandig thema kan helpen de context te geven aan de anders abstracte oefening van toenemend aantal. hetzelfde, allemaal games profiteren van goede richting en ontwerp van de art, en incrementele vormen zijn geen uitzondering. Consistente esthetiek helpt het spel als een verenigde ervaring te voelen, en een schone interface verlaagt de mentale kosten van het navigeren door het spel, zodat de speler zich kan concentreren op het spel zelf, in plaats van slechte elementen van de gebruikersinterface te interpreteren.
Het bovenstaande voorbeeld van AdVenture Capitalist is hier een goede illustratie van. Het thema is bedrijfsmanagement en kapitalistische expansie (wat bij de gameplay van steeds grotere aantallen past) en het maakt gebruik van een Googie-esthetiek uit de jaren vijftig voor zijn richting van kunst. Dit wordt consequent (en met humor) gebruikt, zodat zelfs de menu's en tutorials "in karakter" zijn en het visuele en narratieve thema versterken.
De behoefte van incrementele games aan graphics en schrijven is misschien wat schaars in vergelijking met games van andere genres, maar het is belangrijk om niet te denken aan een lage behoefte aan Nee nodig hebben.
De meest bepalende mechanica van incrementele spellen is het toenemende aantal. We hebben deze laatste keer gedefinieerd als:
Het is dat derde item dat grotendeels het gevoel van het spel beïnvloedt, en dat is het moeilijkst om goed te ontwerpen. Omdat het een bijzonder eenvoudig voorbeeld is, laten we eens kijken naar Aantal door Tyler Glaiel. Het heeft de drie belangrijkste definitiepunten en bijna niets anders: een getal stijgt en je kunt dat aantal uitgeven om het sneller te laten stijgen.
Wanneer het spel begint, is de "inkomstenratio" van het aantal toenemend 0,1 per seconde. De hoeveelheid opgeslagen 'nummer' kan worden besteed om het sneller te laten stijgen. Dit zijn de eerste vijf aankopen, met hun kosten in de eerste kolom en het nieuwe "aantal per seconde" -tarief in de tweede:
| Kosten | Inkomenspercentage |
|---|---|
| 1.0 | 0.2 |
| 1.2 | 0.4 |
| 1.4 | 0.7 |
| 1.7 | 1.2 |
| 2.2 | 1.8 |
Zelfs met een handvol waarnemingen, kunnen we hier enkele kenmerken van incrementeel ontwerp identificeren. Een daarvan is de niet-lineaire verhogingen kosten en baten: er is meer en meer aantal nodig om relatief minder incrementele verbeteringen te krijgen.
Dit is logisch vanuit praktisch oogpunt: als de kosten / batenverhouding hetzelfde bleef (bijvoorbeeld als het altijd 1 nummer kostte om een 0,2 toename van het inkomenspercentage te kopen), dan zou er helemaal geen variabiliteit zijn in het resultaat en het inkomen. de tariefverhoging zou in een regelmatig en voorspelbaar tempo stijgen. Dit zou heel snel saai worden!
In plaats daarvan zien de kosten (in blauw) en inkomenspercentage (in oranje) voor de eerste twintig aankopen er zo uit:
Blauw: kosten van de x-de upgrade. Oranje: inkomsten per seconde gegenereerd uit x aankopen. De tiende aankoop kost bijvoorbeeld 7 cijfers en resulteert in een inkomstenratio van 7,6 cijfers per seconde.(U kunt een XLSX downloaden van de gegevens die zijn gebruikt om deze grafieken te genereren met deze GitHub-repo of een equivalent van Google Spreadsheets bekijken.)
We kunnen hier heel duidelijk zien dat deze functies niet-lineair zijn (zelfs de kostenformule-sprong negeren bij de 12th iteratie) en dat de kostenstijgingen sneller stijgen dan de inkomensstijgingen. Dat is een belangrijk aspect van het ontwerp, omdat het betekent dat de wachttijd om de volgende upgrade te betalen exponentieel groeit naarmate het spel langer duurt. Dus het spel vordert vrij snel in het begin, waarbij de speler slechts periodiek hoeft te wachten om genoeg op te sparen voor de volgende aankoop, maar geleidelijk vertraagt.
De meeste incrementele spellen hebben meerdere bronnen van inkomstenverhoging om te upgraden, in plaats van slechts één Aantal doet. Dit is een belangrijke bron van de ontdekking en strategie van incrementele games, omdat het hebben van meerdere verbeteringsvectoren waarvan de kosten toenemen, niet-lineair interessante optimalisatiemogelijkheden voor de speler introduceert. Als de speler ervoor kiest om zwaar te investeren in een enkel gebouw of een upgrade, betekent de exponentieel stijgende kost op enig moment dat andere opties relatief goedkoper worden, zelfs als ze aanvankelijk zeer hoog geprijsd waren. Dit betekent dat de speler een scala aan opties tot zijn beschikking heeft, maar ze moeten constant opnieuw worden geëvalueerd, omdat de relatieve waarde voor de speler voortdurend verschuift.
exponentiële kosten schaalvergroting is gunstig voor de steeds groter wordende middelen- en tijdinvestering die ze vereisen, maar de meeste games gebruiken geen exponentiële functies inkomen toeneemt. Waarom niet?
In de grafiek van het laatste gedeelte is het de kloof tussen de twee lijnen die ons de altijd groeiende kosten-batenverhouding geven. Om dat te bereiken, eisen we eigenlijk alleen dat de kosten (in oranje) exponentieel (of polynoom) stijgen; de inkomensratio zou lineair kunnen stijgen en de kloof tussen de lijnen zou nog steeds groter worden.
Bijvoorbeeld in Clicker Heroes, een van de eerste geautomatiseerde bronnen voor het vergroten van het aantal is van een "held" genaamd Treebeard. In eerste instantie kost het 50, en krijg je een inkomenstarief van 5 per seconde. Het tweede niveau kost 53,5, maar geeft nog steeds slechts een extra tariefverhoging van 5. De eerste vijftig aankopen zien er als volgt uit, opnieuw met de kosten in blauw en de inkomenskoers in oranje:
Houd er rekening mee dat we voor de eenvoud nog een aantal andere kosten / tariefmechanismen negeren Clicker Heroes.De functie "inkomenspercentage" is hier slechts een rechte lijn, omdat elke aankoop het bedrag met 5 verhoogt, dus de formule hiervoor is heel eenvoudig: het totale tarief per seconde is slechts het aantal in eigendom vermenigvuldigd met 5 (dus, \ (y = 5 x \)).
De kosten stijgen echter in een steeds hoger tempo. De incrementele kosten van elk extra niveau zijn in eerste instantie minimaal; in de grafiek die we kunnen zien voor de eerste twintig is de kloof tussen beide vrijwel constant. Maar dan breekt het dramatisch af, wat meer en meer vereist voor elke volgende upgrade.
De formule voor de kostenfunctie is hier eigenlijk een die veel wordt gebruikt in veel incrementele spellen:
\ [Prijs = BaseCost \ maal Multiplier ^ (\ # \: Eigendom) \]
Voor ons Treebeard-voorbeeld zijn de basiskosten 50 en de variabele "Multiplier" 1,07, dus het tweede niveau kost \ (50 \ keer 1,07 ^ 1 = 53,5 \), de derde kosten \ (50 \ keer 1,07 ^ 2 = 57.245 \), enzovoort. De waarde van de vermenigvuldiger bepaalt de kromming van de lijn, waarbij hogere waarden steilere kostencurven betekenen. (Een waarde van 1 zou een lineaire kostenregel geven.)
Clicker Heroes gebruikt 1.07 als de vermenigvuldigingsfactor voor alle 35 upgrade-helden en alle verschillende gebouwen van Cookie klikker gebruik een waarde van 1,15. Interessant is dat de 10 bedrijven van AdVenture Capitalist ze gebruiken allemaal een andere vermenigvuldiger, maar elk is tussen 1,07 en 1,15. Het verschijnen van dezelfde multiplicators in verschillende games suggereert dat de curven die tussen die grenzen worden geproduceerd, in balans en bevredigend zijn.
Sommige spellen verschillen echter van daar. Steam's multiplayer incrementeel spel Monster, een deel van hun 2015 zomerverkoopevenement gebruikt Multipliers zo hoog als 2,5, die erg steil toenemen.
Zoals eerder vermeld, heeft exponentiële kostencalculatie het voordeel van het balanceren van meerdere upgradepaden door ervoor te zorgen dat elk pad een weg van afnemende returns volgt. Dit maakt een deel van het tactische evenwicht inherent aan de kostenformule zelf, eerder dan iets dat de ontwerper expliciet moet kaderen. Want zelfs als een bepaalde bron soms of zelfs meestal 'beter' is, betekent de exponentieel stijgende kost dat deze niet exclusief kan worden geëxploiteerd.
Laten we eens kijken naar de lijst met uitbreidbare gebouwen in Cookie klikker als voorbeeld:
| Gebouw | Basiskosten | Basisinkomenspercentage |
|---|---|---|
| Cursor | 15 | 0.1 |
| grootmoeder | 100 | 0.5 |
| Farm | 500 | 4 |
| Fabriek | 3000 | 10 |
| De mijne | 10.000 | 40 |
| Verzending | 40.000 | 100 |
| Alchemy Lab | 200.000 | 400 |
| Portaal | 1.666.666 | 6666 |
| Tijd machine | 123.456.789 | 98.765 |
| Antimaterie condensator | 3999999999 | 999,999 |
| Prisma | 75000000000 | 10.000.000 |
We zien verschillende schijnbare patronen net uit deze tabel.
De eerste is dat de basiskosten van elke volgende upgrade bijna vijf keer hoger zijn dan de vorige (behalve de laatste paar). Deze stijgingen met een halve orde van grootte zorgen ervoor dat de speler voldoende tijd heeft om te genieten van elk nieuw ontgrendeld hulpmiddel; lagere verhogingen zouden betekenen dat de ontgrendelingen te snel zouden kunnen komen, maar dat het nog langer zou duren voordat de speler zich zou vervelen voordat de volgende ontgrendeling zou zijn bereikt.
De inkomensratio (cookies per seconde, voor deze game) groeit ondertussen slechts met ongeveer een derde voor elke extra laag, wat betekent dat terwijl de gebouwen steeds grotere numerieke bedragen toevoegen, ze in feite steeds minder efficiënt zijn in verhouding tot hun kosten.
Omdat elk gebouw dezelfde kostenverhogingsformule hanteert \ (Price = BaseCost \ times 1.15 ^ (\ # \: Owned) \), volgt elk gebouw echter eenzelfde patroon. De onderstaande grafiek toont een regel voor elk van de 11 gebouwen, waarbij hun eerste tweehonderd upgrades worden weergegeven, met logboekkosten langs de y-as en het log-inkomenspercentage op de x-as. (Aangezien dit exponentiële functies zijn, onthult een logaritmische schaal hun overeenkomst beter dan een lineaire.)
Deze Elke regel vertegenwoordigt een ander gebouw, met kosten op de y-as en inkomenspercentage op de x-as (beide logaritmische schalen). Dit is een visualisatie van de kosten die baat hebben bij kromming die we eerder hebben besprokenDus hoewel deze gebouwen erg verschillend lijken, omdat elke nominaal veel meer produceert en kost dan de vorige, produceren hun exponentiële kostenformules krommen die inherent vergelijkbaar zijn, terwijl ze toch een systeem creëren dat de speler kan optimaliseren.
Terwijl incrementele games oppervlakkig zijn over het laten stijgen van nummers, is het hoe ze omhoog kunnen gaan zo snel mogelijk dat zorgt voor speelplezier voor gepassioneerde spelers. De speler heeft altijd meerdere verbeteringsmogelijkheden tussen de verschillende upgradeable bronnen (meestal samen met een aantal extra functies die we later bespreken), en daagt de speler dus uit om deze keuzes te evalueren. Mocht u de goedkopere upgrade kopen die u zich nu kunt veroorloven, of opslaan totdat u de volgende laag kunt betalen?
Omdat we uiteindelijk alle upgrades willen kopen, is de meest efficiënte aanpak gewoon om de optimale volgorde te evalueren. Stel je een scenario voor waarin we momenteel 5 van ons aantal per seconde produceren (\ (nps = 5 \)), en we hebben de keuze tussen twee upgrades. De eerste kost 20 (\ (cost_a = 20 \)) en zal onze inkomsten met 1 (\ (syndicator = 1 \)) verhogen. De andere heeft \ (cost_b = 100 \), maar heeft ook \ (compsb = 10 \). De eerste is goedkoper, maar het is ook minder kostenefficiënt.
Laten we A dan B kopen:
Wat als we het tegenovergestelde deden?
Dus het lijkt erop dat je eerst A koopt en dan B efficiënter is, omdat \ (20/5 + 100 / (5 + 1) < 100/5+20/(5+10)\). We could generalize this example to get a formula like this:
\ [\ frac cost_a nps + \ frac cost_b (nps + syndicatora) < \frac cost_bnps + \fraccost_a(nps + rate_b) \]
Maar dit is alleen nuttig voor vergelijkingen tussen twee mogelijke upgrades, en dus is het niet zo nuttig als we veel keuzes hadden. We moeten de formule vereenvoudigen om de variabelen te isoleren voor slechts een enkele upgrade (waarvan de afleiding in detail wordt uitgelegd in dit fantastische artikel van Adam Babcock), wat dit oplevert:
\ [\ frac cost_a nps + \ frac cost_a (nps + syndicatora) \]
Nu kunnen we deze formule toepassen op elke mogelijke upgrade, en het laagste resultaat, vanwege de transitiviteit van de ongelijkheden, levert op wat we vervolgens moeten kopen (met enkele uitzonderingen die het niet waard zijn om voor dit niveau van analyse in aanmerking te komen). Dit vereenvoudigt het proces van het vinden van de meest efficiënte route naar optimalisatie enorm.
Dit is uiteraard relevant voor de speler, maar het is ook nuttig voor de ontwerper. Het meest efficiënt kennenhet gebruik van verschillende spelelementen kan het bestaan van onbedoelde pieken in de tijdvereisten identificeren en ervoor zorgen dat zelfs een optimaal spel vordert met een snelheid die is bedoeld door de maker.
Door af te leiden van optimale speelscenario's kunnen we ook verschillende incrementele spellen vergelijken, omdat we de ongelijksoortige variabelen kunnen reduceren tot precies de tijd die nodig is om een bepaald aantal niveaus per seconde te bereiken. Onderstaande grafiek geeft de tijd weer die nodig is om een gegeven inkomenspercentage per seconde te bereiken AdVenture Capitalist (in groen) en Cookie klikker (in bruin), als je gebouwen op de meest efficiënte manier koopt (andere spelaspecten negeren voor de eenvoud):
X-as: tijd, y-as: inkomenspercentage (log-schaal); groen: AdVenture Capitalist, brown: Cookie Clicker.Opmerkelijk genoeg lijken de twee games hier erg op elkaar, wat resulteert in hogere snelheden van nps tegen een steeds toenemende hoeveelheid tijd. Beide groeien ongelooflijk snel in de eerste 8-10 uur (ongeveer 500 minuten), maar de snelheid van de toename is veel meer marginaal daarna. Ze worden uiteindelijk vlakker naarmate het aantal nieuwe gebouwen is uitgeput. Dientengevolge omvatten de meeste incrementele spellen andere verkrijgbare middelen naast de belangrijkste uitbreidbare gebouwen, een van de belangrijkste is de mogelijkheid om het spel opnieuw in te stellen, waardoor de speler deze curve helemaal opnieuw kan beklimmen.
De spiraalvormige complexiteit van upgrades in incrementele games kan hun ontwerp een ontmoedigend vooruitzicht geven. Maar de ontwerper hoeft niet elk element precies te kalibreren. De schoonheid van complexe niet-lineaire systemen betekent dat boeiende ladders van upgrades kunnen worden geproduceerd met alleen een hoog niveau van balancering van de ontwerper. Voor de speler is het moeilijk en leuk om door het systeem te navigeren om de optimale volgorde te vinden, terwijl het voor de ontwerper eenvoudig is om ervoor te zorgen dat er zo'n complex systeem is om te navigeren.
Met een "New Game +" -functie kan de speler zijn voortgang resetten in ruil voor een blijvende bonus. Alle gekochte gebouwen en andere bronnen kunnen dus worden teruggezet naar nul, maar bij het opnieuw beginnen wordt een vlakke multiplicatieve verhoging toegepast op alle onderstaande berekeningen per nummer..
Dit verandert niets aan de fundamentele formules van het spel; het betekent gewoon dat de speler het uiteindelijke asymptotische plateau sneller en sneller zal bereiken. In essentie werkt deze functie om het kernspel uit te breiden door het sneller te laten afspelen. Dit kan echter niet voor onbepaalde tijd worden aangehouden, dus uiteindelijk zullen spelers die al heel lang in de buurt zijn een soort 'eindspel' bereiken.
In Clicker Heroes, oplopend beloont de spelers met een nieuwe valuta om upgrades mee te kopen.Een andere veelvoorkomende functie voor het uitbreiden van het spel is simpelweg het vergroten van de complexiteit van de uitbreidbare gebouwen. Tot nu toe hebben we alleen de meest gebruikelijke methode voor incrementele upgrade bekeken, die de exponentiële kostenfunctie volgt. Daarnaast zijn dit meestal upgrades die ofwel een eenmalige, vlakke verbetering van het totale aantal per seconde opleveren, ofwel de onderliggende kosten- en inkoersvariabelen op een of andere manier wijzigen.
In Clicker Heroes,er zijn bijvoorbeeld upgrades die het basegetal per seconde verhogen voor een "held", evenals degenen die het basegetal per seconde verhogen voor allemaal "Helden". Hoewel deze en soortgelijke functies de onderliggende mechanica van een incrementeel spel niet veranderen, kunnen ze de mogelijkheid ruimte voor de speler om te verkennen vergroten, en hun vermogen om het spel te optimaliseren verder uitdagen. Bovendien, net als de monteur 'New Game +', kan het volume van upgrades ook werken om het spel te verlengen voordat het uiteindelijke plateau wordt geraakt.
Conspiracy Clicker heeft drie verschillende bomen van onderling gerelateerde upgrades.Hoewel dit geen uitputtend onderzoek naar incrementeel gameontwerp is, hebben we hun fundamentele aspecten grondig bekeken. Als een korte samenvatting voor aankomende ontwerpers en ontwikkelaars:
Als u meer wilt weten, is de subreddit voor incrementele games een geweldige community van ontwerpers en ontwikkelaars waar u terecht kunt voor advies en ideeën. Als je meteen een duik wilt nemen in het implementeren van enkele van je ideeën, de ontwikkelaar van Cookie klikker creëerde een online tool die gemakkelijk vergelijkbare games kan maken, en het is een geweldige manier om te experimenteren zonder zelf het hele fundament te leggen. Als je op zoek bent naar iets geavanceerder, de maker van CivClicker heeft een uitstekend stuk over de logica voor een HTML- en JavaScript-implementatie.
Ik hoop dat het kader dat we hier hebben onderzocht, dient als inspiratie voor het verkennen van je eigen uitdrukking van een incrementeel spel. Er is tenslotte nog veel onontgonnen ontwerpruimte om te ontdekken:
Hoewel het geen uitgebreide lijst is (hiervoor heeft de subreddit voor incrementele games een geweldige lijst), hier is een lijst met games die in ons eerste artikel of in deze zijn genoemd:
Let ook op: u kunt een XLSX downloaden van de gegevens die zijn gebruikt om de grafieken in dit artikel te genereren uit deze GitHub-repo of een Google-bladenequivalent bekijken.
Accentsconagua