Indago ir Latvijas datorspēļu izstrādes konkurss, kas noris ik gadu. Programmētāji no marta līdz decembrim veido savus projektus un atskaitās konkursa lapā par savu progresu. Konkurss ir īpatnējs ar to, ka katru gadu līdz finišam nonāk tikai niecīgs procents spēļu, pie tam lielākoties tās ir nepabeigtas un zemas kvalitātes.
Gamez.lv autors Kamazs
mēģinājis salīdzināt Indago ar dev.gamez.lv rīkotajiem minikonkursiem, kur programmētājiem spēles jāizveido divu nedēļu laikā, ar šokējošiem rezultātiem: "Galvassāpes. Lūk, kas mani pārņēma pēc mini konkursa spēļu izmēģināšanas. Un šoreiz tās bija no patīkamā gala, kas saistīts ar mēģinājumu izprast šķietami paradoksālas un neloģiskas parādības. Proti, kādai burvestība ir vainojama tajā, ka mini konkursa dalībniekiem nedēļas laikā izdevās radīt divarpus baudāmas spēles. Tas ir par pus spēli vairāk kā 'īstajam' Indago konkursam, dārgie draugi!"
Kur slēpjas šī mistika, kāpēc divās nedēļās izdodas radīt labākas kvalitātes produktus nekā grūtniecības periodam pielīdzināmā deviņu mēnešu laika posmā? Mistikas nav, atbilde ir Kamaza mini konkursu definīcijā: "(Minikonkursos) dažu dienu laikā jāizstrādā maza, bet pilnībā funkcionāla spēlīte pēc diezgan stingri definētiem noteikumiem.". Ievērojam, ka minikonkurss uzliek stingrus laika un prasību ierobežojumus.
Atšķirībā no minikonkursiem, Indago spēles izstrādes termiņi ir šķietami bezgalīgi un nav pilnīgi nekādu prasību pret spēli. Un šeit arī rodas sarežģījumi. Atcerēsimies, ka Indago konkursos piedalās neatkarīgi, bieži vien profesionāli nepieredzējuši programmētāji, un es vēlētos uzsvērt vārdu programmētāji, pretstatā programminženieriem. Pašos programminženierijas pamatos tiek līdz apnikumam borēts, ka projektu nevar veiksmīgi izstrādāt ar "code and fix" paņēmienu, ko mēdz pielietot neprofesionāļi un jaunas firmas. Viss ir jādara pēc kārtas - virspirms prasības (ko taisīt), tad arhitektūra (kā taisīt) un tikai tad kods. Diemžēl Ingado konkursa dalībnieki tiek nepārtraukti atsviesti pirmajās divās fāzēs - tagad es pielikšu jaunu fīču, jo man liekas, ka citu spēļu izstrādātāju solījumi pārspēj manējos, vai tagad es nomainīšu programmēšanas valodu, jo lasīju, ka tā otra esot labāka.
Nākamais svarīgais faktors ir izstrādes grafiks un tā izpildes kontrole. Indago rīkotāji ir iedomājušies, ka "one size fits all" un visu apjomu un veidu spēlēm nolikuši, ka tik un tik drīz jābūt ekrānšāviņiem un vēl pēc tik nedēļām jābūt spēlējamam pirmajam līmenim. Kontroles mehānisms ir norealizēts caur obligātajām atskaitēm, kurās autori raksta "neko neesmu darījis, jo vasara prasa savu". Ekrānšāviņi parasti tiek vairāk vai mazāk speciāli šim mērķim uzģenerēti (nevis rodas kā blakusprodukti), kam nav pilnīgi nekāda sakara ar spēles reālo pabeigtību, turklāt programmētāji tādējādi tiek stimulēti veidot arhitektūru balstoties uz grafiku, nevis otrādi, un spēlējamais demo ir, nu, ne visai spēlējams.
Ja Indago rīkotāji pievērsīs uzmanību sekojošajām problēmām un piedāvās risinājumus, tad nākamo gadu konkursi varētu ne tikai izvērsties daudz kvalitatīvāki, bet arī dot reālu pieredzi programinženierijā jaunajiem programmētājiem. Es no sevis piedāvātu šādu risinājumu:
1. Izstrādātājam ir jāiekļaujas deviņos mēnešos.
2. Izstrādātājs konkursa pirmajās divās nedēļās izveido prasību specifikāciju, ko apstiprina Indago komisija. Prasībām jābūt pietiekami sīkām, lai tās būtu viegli testējamas un prasība skaitās izpildīta tikai tad, kad tā tāda tiešām ir, nevis 99% pabeigta.
3. Izstrādātājs izstrādā prasību specifikācijai atbilstošu projektējumu. Tam jābūt pietiekami sīkam, lai katru no punktiem varētu izstrādāt ilgākais nedēļas laikā.
4. Izstrādātājs pats izveido laika grafiku, ik pa mēnesim norādot, kas tieši no projektējuma tiks izpildīts attiecīgajā mēnesī. Katru mēnesi Indago komisijai ir tiesības pārbaudīt reāli padarītā atbilstību grafikam, par katru kavējumu dodot soda punktus. Grafikā jābūt ietvertām divām piegādnēm - demo versija un gala produkts.
5. Izstrādātājs drīkst mainīt prasību specifikāciju un projektējumu, saskaņojot ar komisiju, par katru ierosināto izmaiņu rakstot paskaidrojumu.
6. Projekta beigās spēle tiek vērtēta ņemot vērā spēles baudāmību, sakrātos soda punktus un tās atbilstību prasību specifikācijai.
Protams, tas viss izklausās sausi un garlaicīgi, bet, pirmkārt, patiesībā šādējādi ir pat interesantāk, un, otrkārt, tas ir vienīgais saprātīgais veids, kā pabeigt lielāku programmatūras projektu. Tikai veidojot projektējumu un liekot pretī katram punktam laiku, cik tas aizņems, programmētājam radīsies reāls priekšstats par tā apjomu un vai tas atbilst viņa spējām.
Lai nu kā, ceru uz interesanu Indago 2007!