Az MVP – Minimum Viable Product – egy projekt vagy ötlet legkisebb megvalóstott formáját jelenti, amely:

• felvállalható
• kipróbálható, visszaadja a termék “érzetét”
• releváns visszajelzések adhatóak róla

Ez a terminus nem csak játékok esetében él, hanem szinte bármilyen termék tervezési és fejlesztési folyamatára.

Mi az MVP játékoknál?

Az MVP nem egy “félig kész játék”. Az MVP nem egyenlő az összecsapottal. Az MVP lehet szép, átgondolt és élvezhető – de csak a lényeget tartalmazza.

Ez egy teljesen működőképes prototípus, ami már érdekes élményt nyújt. 
Például:

• Egy pálya egy tisztán érződő mechanikával
• Játékfigura mozgása, animációja
• Interakció, ami már “ránézésre” is játékélményt ad
• Hangulat, játékélmény átérződése

A csapda!

Az MVP egy amolyan módszertan, vagy inkább úgy mondanám, hogy egy másik szemléletmód, mint amivel a kezdő szellem rendelkezik.

Ugyanis pszichológiai alapbeállítás, hogy az ember belejön a tervezésbe, a projekt felfúvódik és egyre több idő és pénz megy bele annak ellenére, hogy még semmit nem tudunk arról, hogy bárki más számára használható, vagy élvezhető-e.

Ez a jelenség egy óriási csapda és figyelmet érdemel!

A játékfejlesztési projekt végére pedig súlyosbodik a helyzet, ugyanis a megrendelőnek kétségei támadnak, a projekt sikerét illetően, még ha nem is voltak komoly elvárásai. Ezért az ember hajlamos inkább továbbfejleszteni, mint túlesni a kiadási félelmeken.

Bekapcsolhat mindennek a tetejébe a “sunk cost fallacy” nevezetű másik pszichológiai jelenség, ami pedig azt jelenti, hogy az óriás költségeket felemésztett projektet már nem egyre nehezebben engedi el a megrendelő és egyre “könnyebben” költ rá további összegeket.

Ezt a szemléletet és a velejáró kidobott pénzt és időt hivatott megfékezni az MVP koncepciója.

Az előnyök

Ha megnézel random 10 sikeres indie fejlesztőt, abból 9 és fél biztos, hogy a korai verziózásra, vagy korai közösségi visszajelzésekre építette a fejlesztési folyamatot. Ez nem a véletlen műve.

1. Egyszerűség
   A projekt könnyen átlátható, mind a tervező, mind pedig a játékos részéről. Nem kell túl sok szabályt megemészteni egyszerre.
2. Korai visszajelzések
   Ha keveset költöttél még a projektre, és hamar kapsz visszajelzést, mondjuk egy kisebb közösségtől, akkor két dolog történhet:
   1. pozitívak a visszajelzések -> jó úton jársz -> erőt és kitartást kapsz
   2. negatívak -> egy tervvel kevesebb, de megspóroltál egy rakás pénzt.
      Pontosabban azt is lehet mondani, hogy kerestél egy csomó pénzt, amit másra költhetsz.

3. Proof of concept
   Ez azt jelenti, hogy kiderül, hogy ami fejben fergeteges ötlet, az kézben fogva is annak tűnik-e. Nem csak a visszajelzések alapján, hanem saját magad által megtapasztalva. Azt érzed-e, amit gondoltál, hogy érezni fogsz, mikor elkezdesz játszani a prototípussal.

4. Halogatás kiiktatása
   A publikálás előtt mindig vagy egy döccenő, a természetes (és egyben irreális) félelem attól, hogy amin hónapokat vagy éveket dolgoztál, arról mit fog mondani a “nagyközönség”. Ilyenkor halogatás és fölösleges fejlesztések beiktatása szokott fellépni.
   Az MVP ennek lehetőségét már az elején elvágja.

5. Hibázz gyorsan kicsiket
   Az elején nagyot hibázni nem lehet. A legrosszabb, ami megeshet, hogy nem működik a koncepció. Ilyenkor újratervezés, vagy pedig el kell engedni a játékprojektet ebben a formában.

6. Későbbiek
   Az MVP-n kívül eső, többi játékrészre érdemes update-ekként gondolni és így is közzétenni. Sokkal célszerűbb, mert a közönség gyakrabban kap frissítéseket, hírt a projekt fejlődéséről.
   Mindemellett a később következő funkciókról, a játék tervezett egészéről tudnia kell a játékfejlesztőnek, mert megfelelőbb döntéseket hozhat, ha ismeri a fejlesztés későbbi irányát.

Összefoglalva

Akármilyen tervezés-fejlesztésről is legyen szó, érdemesebb megközelíteni részfázisonként a munkát, nem pedig évekig fejleszteni egy “nagyot”, aminek a létjogosultságáról nincsen információ.

Köszi, hogy elolvastad, további cikkekkel hamarosan jelentkezem!