Enhet 1 / 11

Introduksjon til kunstig intelligens i spillutvikling: roller, grenser, verifisering, opphavsrett og etikk

Gevinster:

  • Å kunne skille hvor i spillets produksjonslinje (ide, utkast, iterasjon) kunstig intelligens sparer sanntid og hvor beslutninger som identiteten og originaliteten til spillet er overlatt til mennesket, i henhold til oppgavens risikonivå.
  • Evne til å bruke en disiplin som verifiserer hver AI-utgang gjennom trinnene med å koble den til kilden/motoren, kjøre og teste den, og sende den gjennom et smaks-/identitetsfilter.
  • For å forstå hvorfor opphavsrett og originalitet, datavern og sikkerhetsbruk til defensive formål bør tas i betraktning helt fra begynnelsen i spillproduksjon.

Du jobber i et spillstudio. På den ene siden er det en versjon som må ut, på den andre siden sluttbudsjettet; På den ene siden, forventningen om en spillbar prototype, på den andre siden, hundrevis av dialoglinjer som ennå ikke er skrevet, dusinvis av eiendeler som ikke er modellert (aktiva — hver visuelle, lyd- eller modellfil i spillet), en ubalansert økonomi. Spillutvikling; Det er et iboende tverrfaglig og iterativt håndverk som kombinerer design, kunst, kode, lyd, testing og publisering til én enkelt underholdningsopplevelse. Det er nettopp i denne overfloden av iterasjoner at kunstig intelligens (AI – programvare som kan trekke ut mønstre fra historiske data og produsere tekst, grafikk, lyd og kode) akselererer deg. Men selve begynnelsen av denne modulen er klar: AI er en assistent, utkastgenerator og idémultiplikator; Du er den som bestemmer ånden, originaliteten og den endelige avgjørelsen i spillet.

I denne første enheten vil vi fokusere på disiplin, ikke verktøyet. Du vil lære hvor AI sparer sanntid i spillets pipeline – kjeden av produksjonsstadier som en idé går gjennom til den blir spillbart innhold – hvor det er farlig, hvordan du verifiserer hver utgang, opphavsrett og originalitetsgrenser, og hvilke data du kan gi til hvilket verktøy. Uten å legge dette grunnlaget vil påfølgende enheter forbli i luften.

Hvor kommer AI til nytte på produksjonslinjen?

La oss dele jobbene innen spillutvikling i to store klynger. Første klynge: repeterende, reproduserbare, utkastbare oppgaver. Ti forskjellige variantsideer for en mekaniker, dialogutkast for en NPC (ikke-spillerkarakter), den innledende gråboksing-oppsettet til et nivå, retningseksperimenter for en konseptkunst, repeterende kodebiter (boilerplate), liste over hundrevis av testtilfeller. I disse oppgavene reduserer AI minutter til sekunder og blir ikke sliten.

Den andre klyngen: beslutninger som bestemmer identiteten, originaliteten og den kommersielle fremtiden til spillet. Hva kjernen i spillet vil være, hvilken art direction vil være merkevaren, den emosjonelle kjernen i historien, den ultimate balansen i økonomien, hvilke eiendeler vil gå inn i spillet, og om det er opphavsrettssikkert. Disse avgjørelsene krever visjon, smak, handleintuisjon og juridisk ansvar. AI multipliserer alternativer her, muliggjør rask prototyping - men du trykker på knappen.

La oss tydeliggjøre forskjellen i én setning: AI er sterk på spørsmål om "hva ville ti varianter av dette være og hvordan ville et første utkast se ut"; Avgjørelsen er din når det kommer til spørsmål som "hvilket er vårt spill og er dette innholdet lovlig vårt?"

Tips: Før du outsourcer en oppgave til en AI, spør: "Hva taper jeg hvis denne utgangen er feil eller middelmådig?" Hvis svaret er "noen minutter med iterasjon", delegere enkelt. Hvis svaret er "identiteten til spillet, en publiseringsblokk eller opphavsrettssøksmål", la AI produsere utkastet og du gir avgjørelsen og den siste touchen.

Verifikasjonsdisiplin: tre trinn

AI produserer flytende og selvsikkert; Dette betyr ikke at det er riktig eller brukbart. AI produserer av og til hallusinasjoner - det vil si at den presenterer en ikke-eksisterende API-funksjon, en ikke-fungerende kodelinje, en oppfunnet regel eller en ikke-eksisterende ressurs som ekte. I spillet fører en sammensatt Unity-funksjon til kode som ikke kompilerer, en ubalansert formel fører til en utnyttelse som bryter spillet. Så utvikle en tre-trinns refleks for å gjelde hver utgang:

  1. Koble til kilde og motor. Hver kodebit som AI-en returnerer bør være basert på API-en som faktisk eksisterer i den versjonen av motoren (Unity/Unreal) du bruker. "Hvilken versjon har denne funksjonen?" og match det med det offisielle dokumentet.
  2. Løp og test. Kompiler koden, spill mekanikken, simuler balansen. Ingenting AI produserer er "ok" før det er sett å fungere i spillet.
  3. Sett den gjennom filteret av smak og identitet. Føles utgangen som om den tilhører spillet ditt, eller er det generisk? Din kunstneriske og designmessige vurdering er det endelige filteret.
Oppmerksomhet: «AI produserte det på den måten» er ikke en begrunnelse. Hvis det er en feil, en ubalanse eller et brudd på opphavsretten, tilhører ansvaret personen som har lagt det utdataene inn i spillet uten å verifisere det, ikke AI. En ubekreftet AI-utgang er like risikabelt som en oppdatering som er utgitt uten testing.

Opphavsrett og originalitet: det du trenger å vite fra starten

Det mest sensitive aspektet ved AI i spillutvikling er opphavsrett og originalitet, fordi alle eiendeler du produserer er inkludert i et kommersielt produkt. Internaliser de tre reglene fra begynnelsen. For det første: hvis produksjonen av en generativ visuell/lydmodell gjenkjennelig imiterer et eksisterende opphavsrettsbeskyttet verk (en karakter, et merke, en kunstners signaturstil), risikerer du å bli krenket ved å bruke det resultatet i et kommersielt produkt. For det andre: vilkårene for bruk av verktøyet du bruker (kommersielle bruksrettigheter, om du eier utskriften) er forskjellige for hvert verktøy; Ikke bruk uten å lese. For det tredje: i noen land kan det hende at et verk skapt utelukkende av kunstig intelligens, uten menneskelig bidrag, ikke mottar opphavsrettslig beskyttelse - noe som betyr at andre kan kopiere det. Vi skal utdype disse tre punktene i 10. enhet; Men vet dette fra dag én: AI-utgang er et utgangspunkt, det bør ikke gå inn i produktet uten meningsfull menneskelig input og validering.

Data, personvern og forsvar

Studiodata er ofte forretningshemmeligheter: uutgitte designdokumenter, kildekode, karakterdesign, historie. Å stikke dem inn i et gratis offentlig verktøy betyr å risikere lekkasjer og konkurranse. Lag en enkel klassifisering: Åpne data (kunngjort, publisert) kan gå inn i hvilket som helst verktøy; interne data kun til institusjonsgodkjente kjøretøy; Konfidensielle data (ufrigitt kode, design, historie) går bare inn i kontraktsfestede verktøy, hvis data ikke går til modellopplæring. En merknad om IT og sikkerhet: Når du legger til AI-generert kode i spillet ditt, ikke aksepter blindt sikkerhetssårbarheter (for eksempel å stole på klienten og omgå serververifisering i et flerspillerspill); Bruk AI kun til forsvars- og verifiseringsformål, for å øke sikkerheten til ditt eget system, og aldri til uautoriserte formål som for eksempel uautorisert tilgang til andres system.

tre minisaker

Tilfelle 1 — Tidsbesparelse på rett sted. En designer for et indiestudio vil normalt bruke en dag på å tenke på 12 varianter for en puslespillmekaniker. Han ga AI en brief med klare begrensninger og utarbeidet 12 varianter på 20 minutter; Så valgte han 3 av dem etter sin egen smak og prototype dem. AI har spredt ideer; Valget og prototypen forble hos mennesket.

Tilfelle 2 – Validering fanget en feil. En programmerer ba AI om en inventarsystemkode. Koden så fin ut, men kompilerte ikke: AI hadde laget en funksjon som var i en eldre versjon av Unity, men ble fjernet i prosjektets versjon. "Kjør og test"-trinnet løste på 5 minutter det som kunne vært timer med forvirring.

Tilfelle 3 — Avkastning på opphavsrettsrisiko. En artist likte bildet av en helt han produserte med AI; men bildet hadde en tydelig likhet med en kjent tegneseriefigur. Art director grep inn: dette visuelle var en risiko for krenkelse i det kommersielle spillet. Bildet ble gjengitt på forespørsel for en unik silhuett og palett, og ble personliggjort med kunstnerens håndtegning.

Fire kopierbare maler

1) Arbeidsegnethetsvurdering:

Din rolle: senior spillprodusent. Jeg vil beskrive jobben nedenfor. Fortell meg (1) om dette arbeidet er utkast/duplisert arbeid som trygt kan delegeres til AI, eller en kritisk avgjørelse som bestemmer identiteten til spillet, (2) den potensielle kostnaden for feil/middelmådig produksjon, (3) verifiseringen jeg må gjøre før delegering. Jobb: [sett inn jobb her]

2) Forespørsel om kodebekreftelse:

Du skriver denne koden for [Unity 2022.3 / Unreal 5.3]. Oppgi at hver API du bruker finnes i denne versjonen. Merk "bekreft" der du ikke er sikker. Ikke lag opp noen ikke-eksisterende funksjoner; foreslå et alternativ.

3) Forhåndssjekk av opphavsrett/opprinnelse:

Jeg vil bruke følgende bilde/karakteridee i et kommersielt spill. Gi meg beskjed hvis denne ideen ligner et eksisterende opphavsrettsbeskyttet verk, varemerke eller kjent kunstnerstil; Hvis lignende, foreslå 3 konkrete endringer for å gjøre det unikt. Idé: [skriv her]

4) Maskering av konfidensiell data:

Teksten jeg vil gi deg kan inneholde upublisert design/kode. List først hvilke områder som er konfidensielle og må maskeres; Jeg vil maskere det og sende det igjen. Ikke analyser det som det er.

Svak forespørsel / Sterk forespørsel

Svak melding:

Gi meg en idé om spillmekaniker.

Denne forespørselen er kontekstfri: sjanger, målgruppe, plattform, begrensning er uklar. AI dumper generiske, kjente ideer.

Kraftig ledetekst:

Din rolle: erfaren spilldesigner. Mitt spill: mobil, spilt med én hånd, casual type, målgruppe 25-40 år. Kjernesyklus: 30 sekunders raske runder. Begrensning: ingen annonser, kjøpsvennlig, 10 sekunder å lære. Oppgave: gi 8 forskjellige kjernemekanikerideer; skrive en én-setnings oppsummering, styrker og mulige risikoer for hver. Klisje (kamp-3, uendelig løping) forslag.

Forskjellen er tydelig: begrensningen, publikummet, typen og "stereotype"-forespørselen gjør utdataene tilgjengelig.

Sammenligningsdiagram for rolle/oppgave

virksomhet

Rollen til AI

manns rolle

verifisering

Mekanisk idégenerering

Variasjonsutbredelse

utvalg, prototype

Gameplay test

NPC dialog

utkast til skriving

Tone, identitet, korreksjon

karakterkonsistens

kodebit

Boilerplate produksjon

Arkitektur, integrasjon

Bygg + test

visuell tilstedeværelse

Konsept/variasjon

Art direction, originalisering

Opphavsrettssjekk

Likevektsformel

kontoutkast

endelig innstilling

Simulering + spilletest

Vanlige feil

  • Misforstå AI-utgang som et ferdig produkt. Utgangen er alltid utkast; Den går ikke på lufta uten menneskelig innvirkning.
  • Be om en kode uten å spesifisere motor/versjon. Hvis du ikke sier versjon, vil AI produsere blandet eller utdatert API.
  • La opphavsretten ligge til slutten. Autentisitetskontroll gjøres på produksjonstidspunktet, ikke kvelden før sending.
  • Fester det hemmelige designet på det offentlige kjøretøyet. Hvis ikke-utgitt innhold lekker, kan det ikke hentes.
  • Spør uten kontekst, for eksempel "Gi en idé." Den ubegrensede forespørselen gir generiske resultater.

Oppsummert

AI er en kraftig assistent i spillutvikling: den multipliserer ideer, genererer utkast, akselererer iterasjon. Men identiteten, originaliteten, balansen og rettssikkerheten til spillet tilhører mennesker. Ha to-klyngeseparasjon (reproduserbare verk vs. identitetsbeslutninger), tre-trinns bekreftelse (lenke til kilde, kjøretest, smaksfilter), bevissthet om opphavsrett/originalitet og datavern som ryggraden i denne modulen.

Søknadsoppgave

List opp 6 jobber fra ditt eget (eller imaginære) spillprosjekt. Klassifiser hver som "AI-delegerbar blåkopi" eller "menneskelig beslutning." For en av de overførbare, bruk malen "Jobbegnethetsvurdering" ovenfor for å få svar fra AI og bruke tre-trinns bekreftelse.

sjekkliste

  • [ ] Jeg delte jobben i to partier (repliserbar / ID-avgjørelse).
  • [ ] Jeg implementerte tre-trinns bekreftelse (kilde, kjøre-test, nyt).
  • [ ] Jeg spesifiserte motoren og versjonen da jeg ba om koden.
  • [ ] Jeg gjorde den foreløpige opphavsretts-/originalitetskontrollen på produksjonstidspunktet.
  • [ ] Jeg har kun gitt konfidensielle data til verktøyet i en godkjent, maskert form.