Kā atrast finansējumu

Viss, kas saistīts ar spēļu izstrādi Latvijā: problēmas, baumas, norises, spēle kā komercprojekts u.tml.
Message
Author
persick
Posts: 8
Joined: 15 Oct 2012, 15:43

Kā atrast finansējumu

#1 Post by persick » 15 Oct 2012, 16:07

Labdien!

Ir tā, ka man ļoti interesē Computational geometry tēma un gribu savu karjeru veidot tajā virzienā. Man ir 5 gadu pieredze kā web programmētājam, taču skaidri zinu, ka web izstrāde nav priekš manis. Pusaudža gados aizrāvos ar grafikas programmēšanu un tas mani tiešām saista.

Pa šiem gadiem ļoti daudz esmu domājis, kāds būtu efektīvākais algoritms priekš space partitioning vai scenegraph, tie tādi vispārēji apzīmējumi. Vārdu sakot, tas efektīvi var izpildīt ģeometriskos vaicājumus. Pilnīgi dinamiska datu strukūra (piem. statiskie octree/quadtree neder manām prasībām - turklāt tie defaultā neņem vērā objektu laukumu) - kas ļauj veikt objektu resize, pārvietojumus, rotāciju un attiecīgi datu struktūra apdeitojas. Piemēram, tas efektīvi atrisina šādu uzdevumu: man ir objekts A , tas veido pārvietojumu virzienā +x,+y un es tagad gribu iegūt pirmo objektu, ar kuru tas sadursies, ņemot vērā, ka telpā ir miljons citu objektu. Vārdu sakot to var izmantot visdažādākajiem uzdevumiem, kur nepieciešama ģeometrijas datu apstrāde. Pielietojuma tēmas: robotika, path finding, simulācijas, ĢIS, etc..

Bet es gribu zināt, ko man tālāk darīt, lai ar to pelnītu naudu ? Ja es kādam tā vienkārši to pastāstu, tad viņiem var likties, ka runāju muļķības. Teiksim - man ir algoritms un es gribu atrast finansējumu. Kā to izdarīt ?

Viens, ko varu iedomāties - taisīt tehniskos demo. Vai tas būtu tas noteicošais ? Jāpiebilst, ka es neesmu vēl to ieimplementējis līdz galam, ir tikai iesākta 2D versija un galvā man viss saskan. Vēl ideja - ieimplementēt kā DLL un sadarboties ar kādu software izstrādātāju, lai tas integrē savos produktos bez maksas, tā varētu gūt atsauksmes un tā būtu vieglāk piesaistīt finansējumu. Patreizējā dižā problēma - lai ieimplementētu, vajag daudz laika, kura man gandrīz nav. Tiešām, vienīgā iespēja ir pēc dienas darba birojā pa vakariem veltīt 2-3 h un varbūt pēc gada vai diviem tehnisko varētu izspiest ?

p.s. Varat kritizēt mani, utt. Bet vairāk gaidu konstruktīvus ieteikumus, ko tiešām es no savas situācijas varētu tālāk darīt.

snake5
Posts: 361
Joined: 07 Dec 2010, 03:54
Contact:

Re: Kā atrast finansējumu

#2 Post by snake5 » 15 Oct 2012, 19:25

Bet es gribu zināt, ko man tālāk darīt, lai ar to pelnītu naudu ?
Ar vienu pašu scene query neko nenopelnīsi. Ja būtu zināšanas par dzinēju dizainu, zema līmeņa programmēšanu un 3D grafiku, tad varētu strādāt 3D dzinēja komandā kādā spēļu studijā un pelnīt ar to.
ir tikai iesākta 2D versija un galvā man viss saskan
Implementē līdz galam, izveido vispusīgu testa programmu. No mēnesi ilgas octree algoritma optimizēšanas pieredzes teikšu, ka ne viss ir tā, kā sākumā izskatās. Pat ja galvā "viss saskan", procesors un kompilētājs var domāt savādāk...

Tālāk sekos neliela sapņu jaukšana. Ceru, ka noderēs.
"Vai tas būtu tas noteicošais" - noteicošais ir gan tas, gan pirmie klienti, gan mērķauditorija. Pasaulē ir ne vairāk par 100 nopietniem spēļu dzinējiem, katram ir jau savs variants implementēts. Reāli tirgošanās atliek tikai ar kaut kādiem nezinīšiem, kas bakstās uz Ogre3D/XNA/u.tml.
"ideja - ieimplementēt kā DLL" - bīstama ideja. Parasti dzinējos scene query struktūras ir dziļi integrētas, lai varētu objektu testus implementēt pēc iespējas mazāk traucējoši citiem procesiem (instancing u.tml.).
"sadarboties ar kādu software izstrādātāju" - zini kādu, kuram Latvijā būtu vēlēšanās pēc kaut kā tāda?
"lai ieimplementētu, vajag daudz laika, kura man gandrīz nav" - nezinu tavu algoritmu, bet nevienam no pārbaudītajiem nevajag vairāk par dažām darba dienām (pārsvarā implementācija iekļaujas vienā).

"Pilnīgi dinamiska datu strukūra" - parasts masīvs. Nopietni. Mūsdienu procesori necieš kaut kādus ūberkokus ar kaut kādām dinamiskām pārstrukturēšanām. Un ņem vērā, ka pilnīgi dinamiski dati nozīmē pamatīgus ierobežojumus.
"turklāt tie defaultā neņem vērā objektu laukumu" - pirms mētājies ar apgalvojumiem, iesaku palasīt vairāk par pirmo tutoriāli Googlē. Nav nekāda defaulta, ir algoritmi ar dažādiem ievaddatiem. Tāpat arī octree ir dinamisks, ja implementē "remove-node" algoritmu.
"attiecīgi datu struktūra apdeitojas" - no pieredzes saku - šausmīga ideja. Tiklīdz kā kustīgo objektu skaits pieaugs, algoritms kļūs daudz lēnāks (iespējams, pat eksponenciāli).

Ja reiz vajag konstruktīvi, tad došu rakšanas virzienus: Bounding volume hierarchy, Sweep and prune, Dynamic AABB tree, un ja pārdomā par statiskumu - arī k-d tree.

P.S.
Man ir 5 gadu pieredze kā web programmētājam, taču skaidri zinu, ka web izstrāde nav priekš manis.
Man ir 5+ gadu pieredze spēļu izstrādē, bet web programmēšana arī nešķiet slikta. Go figure.

persick
Posts: 8
Joined: 15 Oct 2012, 15:43

Re: Kā atrast finansējumu

#3 Post by persick » 15 Oct 2012, 21:39

Ar vienu pašu scene query neko nenopelnīsi. Ja būtu zināšanas par dzinēju dizainu, zema līmeņa programmēšanu un 3D grafiku, tad varētu strādāt 3D dzinēja komandā kādā spēļu studijā un pelnīt ar to.
Protams, ka ar vienu pašu ne, bet tas, manuprāt, ir labs instruments, lai uz tā pamata radītu sarežģītākus risinājumus / programmproduktus.
Zema līmeņa programmēšanu saprotu - esmu sen atpakaļ x86 asm kodējis, kā arī sarakstījis software 3D rendereri. Rakstot šo rendereri, nonācu pie šīs high-level scenegraph problēmas.
Darbs pie 3D spēles vai dziņa - jā, zinu, ka tas būtu labi, bet Latvijā grūti atrast. Var vēl braukt uz ārzemēm - bet tas pēdējais variants.
Implementē līdz galam, izveido vispusīgu testa programmu. No mēnesi ilgas octree algoritma optimizēšanas pieredzes teikšu, ka ne viss ir tā, kā sākumā izskatās. Pat ja galvā "viss saskan", procesors un kompilētājs var domāt savādāk...
Ok - piekrītu. Protams, performance ir primārais, bet sekundārā fīča šim algo ir tas, ka tas atrisina daudz citas problēmas bonusā - piemēram, path finding algoritma gadījumā nepieciešams vēlamajā virzienā veikt brīvās telpas vaicājumus, kas vienā solī ir viena konveksa brīvās telpas šūna.
"Vai tas būtu tas noteicošais" - noteicošais ir gan tas, gan pirmie klienti, gan mērķauditorija. Pasaulē ir ne vairāk par 100 nopietniem spēļu dzinējiem, katram ir jau savs variants implementēts. Reāli tirgošanās atliek tikai ar kaut kādiem nezinīšiem, kas bakstās uz Ogre3D/XNA/u.tml.
Šo risinājumu nav obligāti spēļu dzinī jāizmanto, pielietojums ir plašs.
"ideja - ieimplementēt kā DLL" - bīstama ideja. Parasti dzinējos scene query struktūras ir dziļi integrētas, lai varētu objektu testus implementēt pēc iespējas mazāk traucējoši citiem procesiem (instancing u.tml.).
Ir doma, ka būs vienkāršs interfeiss. Performance problēmas neredzu. Bet labi - ja esi darbojies ar to un tā saki, lai tā būtu.. pats pārbaudīšu.
"sadarboties ar kādu software izstrādātāju" - zini kādu, kuram Latvijā būtu vēlēšanās pēc kaut kā tāda?
Latvijā, protams, tāda iespējamība ir maza. Var sadarboties ar ārzemju kompānijām.
"Pilnīgi dinamiska datu strukūra" - parasts masīvs. Nopietni. Mūsdienu procesori necieš kaut kādus ūberkokus ar kaut kādām dinamiskām pārstrukturēšanām. Un ņem vērā, ka pilnīgi dinamiski dati nozīmē pamatīgus ierobežojumus.
Ja man ir miljons objektu un es tagad gribu noskaidrot, kādi objekti ir kameras redzeslokā, tad tu iesaki veikt miljons redzamības pārbaužu ? Dinamiski dati man taisni otrādi - asociējas ar brīvību. Nesaprotu, par kādiem ierobežojumiem Tu runā..
"attiecīgi datu struktūra apdeitojas" - no pieredzes saku - šausmīga ideja. Tiklīdz kā kustīgo objektu skaits pieaugs, algoritms kļūs daudz lēnāks (iespējams, pat eksponenciāli).

Nu jā - ja izmanto kādu standart algoritmu, tā var gadīties. Tāpēc man tie statiskie octree, utt. nepatīk.
Ja reiz vajag konstruktīvi, tad došu rakšanas virzienus: Bounding volume hierarchy, Sweep and prune, Dynamic AABB tree, un ja pārdomā par statiskumu - arī k-d tree.
Dažus no šiem principiem izmantoju.
Man ir 5+ gadu pieredze spēļu izstrādē, bet web programmēšana arī nešķiet slikta. Go figure.
Easy. Katram savs.


----------

No taviem komentāriem izvilku to, ka tiešām vajag ieimplementēt līdz galam un veikt testus. Ok. Tas ir viens viedoklis.

bubu
Guru
Guru
Posts: 398
Joined: 07 Dec 2010, 11:54

Re: Kā atrast finansējumu

#4 Post by bubu » 15 Oct 2012, 21:51

Taisi demo versiju ar kaut kādiem limitējumiem. Uztaisi smuku mājaslapu un pārdod to.
Lai cilvēki var novilkt un pamēģināt.

Līdzīgi kā Chipmunk Physics dara: http://chipmunk-physics.net/
Bāzes versija - opensource, par maksu var nopirkt "Pro" variantu ar labākām optimizācijām (ARM Neon).

snake5
Posts: 361
Joined: 07 Dec 2010, 03:54
Contact:

Re: Kā atrast finansējumu

#5 Post by snake5 » 15 Oct 2012, 22:35

Šo risinājumu nav obligāti spēļu dzinī jāizmanto, pielietojums ir plašs.
Mmm, tā saka daudzi. Pats darbā pēdējā mēneša laikā esmu pētījis vienu "pielietojums ir plašs" rīku. Praksē gan tā lieta tik labi neaiziet un reāli prātīgāks virziens ir koncentrēties uz konkrētu un plašu pielietojuma nozari (var nebūt viena, bet svarīgs ir fokuss). Vai nu spēles, vai karšu dati, vai kaut kas cits. Ar visiem kopā tā lieta uz priekšu īpaši labi neies, kaut kas tiks aizmirsts un nenostrādāts, liekot pielietojumam zaudēt jēgu.
Var sadarboties ar ārzemju kompānijām.
Iemesls, kāpēc ārzemes pat neapsvēru, ir tāds, ka nopietnām tehnoloģijām vajadzēs personisku pieeju. Staigāt pa uzņēmumiem, prezentēt. Lai to darītu ārzemēs, tur arī ir jādzīvo.
Ja man ir miljons objektu un es tagad gribu noskaidrot, kādi objekti ir kameras redzeslokā, tad tu iesaki veikt miljons redzamības pārbaužu ? Dinamiski dati man taisni otrādi - asociējas ar brīvību.
Skaties uz to no šādas puses: cache miss laikā salīstu iekšā 10-100 bounding volume testi. Kamēr grozies apkārt pa savām fancy datu struktūrām, vari veikt tās ~50 pārbaudes. Turklāt masīva datus var izdalīt max. tik threadiem, cik ir elementu masīvā. Procesori daudz ātrāki nekļūs, tikai vairāk. Tāpat arī ja interesē izmantot GPU savā sistēmā, ar masīvu datiem tas tiks galā ātrāk un vienkāršāk. Iedomājies 1024x1024 bounding sphere tekstūru. Tas gan nenozīmē, ka uzreiz ir jāpadod miljons objektu un jāmet miers optimizācijai. Pie tam, ja ir miljons objektu, tavas galvenās problēmas būs nevis ar datu apstrādi, bet ar glabāšanu. Ja kaut ko no web developmenta var mācīties, tad tas ir tas, kā glabāt tāda apjoma datus. Līdzīgi ar spēļu izstrādi un procesoru jaudas pielietojumu. Un par ierobežojumiem - tie ir ierobežojumi tev. Statiskiem datiem var uzģenerēt pat vairākus kokus un masīvus un vēl nez ko, lai varētu lietot pēc vajadzības. Ar dinamiskiem datiem jālieto pēc iespējas mazāk algoritmu, cauri visiem algoritmiem jāexploito kustības pārtraukumi līdz brīdim, kad ātrāk ir vienkārši pārģenerēt datus no nulles, kā arī jāņem vērā, kuros momentos sistēma vienkārši nestrādās kā gribētos (jo tādi bez šaubām būs).
ja izmanto kādu standart algoritmu, tā var gadīties
Intriģējoši... negribi pastāstīt vairāk par savu algoritmu?

Bāzes versija - opensource, par maksu var nopirkt "Pro" variantu ar labākām optimizācijām (ARM Neon).
Hmm, Chipmunk jau labu laiku eksistē... atceros, ka īpaši labi negāja pirms vairākiem gadiem (~2008), t.i. Box2D bija daudz spējīgāks projekts. Tagad neesmu testējis, kā strādā. Jebkurā gadījumā, manuprāt tas ir uzmanības vērts fakts. Tā kā jāatceras, ka nauda ne viegli, ne ātri nenāks...

persick
Posts: 8
Joined: 15 Oct 2012, 15:43

Re: Kā atrast finansējumu

#6 Post by persick » 16 Oct 2012, 00:13

Taisi demo versiju ar kaut kādiem limitējumiem. Uztaisi smuku mājaslapu un pārdod to.
Lai cilvēki var novilkt un pamēģināt.
Jā, tas arī variants.
Mmm, tā saka daudzi. Pats darbā pēdējā mēneša laikā esmu pētījis vienu "pielietojums ir plašs" rīku. Praksē gan tā lieta tik labi neaiziet un reāli prātīgāks virziens ir koncentrēties uz konkrētu un plašu pielietojuma nozari (var nebūt viena, bet svarīgs ir fokuss). Vai nu spēles, vai karšu dati, vai kaut kas cits. Ar visiem kopā tā lieta uz priekšu īpaši labi neies, kaut kas tiks aizmirsts un nenostrādāts, liekot pielietojumam zaudēt jēgu.
Iespējams, bet sākumā ir jāapzinās iespējas un būs jāatrod īstā niša, tāpēc nevar atmest variantus.
Iemesls, kāpēc ārzemes pat neapsvēru, ir tāds, ka nopietnām tehnoloģijām vajadzēs personisku pieeju. Staigāt pa uzņēmumiem, prezentēt. Lai to darītu ārzemēs, tur arī ir jādzīvo.
Droši vien. Nu jā - tad vispirms kaut kas jāsadara tepat Latvijā.
Skaties uz to no šādas puses: cache miss laikā salīstu iekšā 10-100 bounding volume testi. Kamēr grozies apkārt pa savām fancy datu struktūrām, vari veikt tās ~50 pārbaudes. Turklāt masīva datus var izdalīt max. tik threadiem, cik ir elementu masīvā. Procesori daudz ātrāki nekļūs, tikai vairāk.
Nezinu spriest. Tā ir Tava pieredze. Pats saskaršos, tad domāšu. Gan jau manā fancy datu struktūrā arī var nodarbināt vairākas cores. Tiesa, es nezinu cik tas reāli, neesmu tik tālu domājis.
Intriģējoši... negribi pastāstīt vairāk par savu algoritmu?
Daudz nevaru stāstīt, jo pamatkoncepts ir diezgan vienkāršs (protams, zinātājiem par tēmu), pats biju par to pārsteigts, kad apjēdzu pēdējo versiju.
1. 2D implementācijā sarežģīti concave poligoni tiek saskaldīti convex gabalos, to sauc par Convex decomposition - ir pieejami algoritmu apraksti. Šeit arī veidojas saucamais Bounding volume hierarchy, var saukt arī par Convex hull hierarchy, jo mēs ar vienu convex hull varam nosegt vairākus children objektus + strukturizēt dobumus. Nu un ja man viss ir convex gabalos, tad daudzas ģeometriskas operācijas kļūst smieklīgi vienkāršas. Piemēram, ja es novelku taisnu līniju pār šo convex hull, tad ir garantija, ka tā var krustoties tikai 2 robežpunktos. Var viegli atrast kopējo laukumu priekš ģeometriskām Boolean operācijām. Kolīziju atrašana, un tā tālāk...
2. stūrakmens: redzamības linkošana. Katrai līnijai ir savs redzesloks, tas izskatās kā konuss ar nocirstu sākumgalu. 3D versijā sauc par frustum. Es tās saucu par "acīm". Ja es iespraužu konveksu poligonu 2D telpā, tad viss laukums apkārt kļūst "redzams". Piemēram, poligonam ir 8 līnijas, tātad visu laukumu apkārt 360 grādos sadalam uz katru līniju ar savu redzesloku. Un katrai šai līnijai pielinkojam vismaz vienu objektu, kas šajā redzeslokā ir redzams - vēlams - vistuvāko.

Tagad, lai veiktu objekta pārvietošanu, man pietiks apdeitot visas "acis" , gan ar kurām objekts redz, gan citas, kuras redz šo objektu.

Tur ir vēl miljons nianses kā esmu to iedomājies, bet šie ir tie divi vaļi.

snake5
Posts: 361
Joined: 07 Dec 2010, 03:54
Contact:

Re: Kā atrast finansējumu

#7 Post by snake5 » 16 Oct 2012, 13:50

2D implementācijā sarežģīti concave poligoni tiek saskaldīti convex gabalos
No kurienes rodas šie concave daudzstūri? Un ņemot vērā, ka 3D variantā nav saprātīgi aprakstāmu concave polyhedron figūru (triangle mesh'i nav saprātīgi), kas tie būs algoritma 3D versijā?
Otro stūrakmeni nesapratu. Grūti iedomāties, kā ar to linkošanu var noteikt redzamību katram objektam.

Ir šaubas par to, vai mainīga izmēra dati ir labākais bounding volume aprakstīšanas veids... AABB/OBB/sphere objektus izvēlas tāpēc, ka tie ir statiski, vienveidīgi, paredzami dati, kuri netaisīs liekus atmiņas pieprasījumus. Convex daudzstūri un it īpaši polyhedron'i būs pavisam kaut kas cits un visticamāk dubultos prasības pret sistēmai nepieciešamo atmiņu visos veidos. Tā gan nebūtu tik liela problēma, ja atmet spēles kā potenciālo klientu.

persick
Posts: 8
Joined: 15 Oct 2012, 15:43

Re: Kā atrast finansējumu

#8 Post by persick » 16 Oct 2012, 14:41

No kurienes rodas šie concave daudzstūri?
Tā ir 2D analoģija 3D meshiem. Un 3D meshi var būt sarežģīti, gan concave, gan ar caurumiem.
Un ņemot vērā, ka 3D variantā nav saprātīgi aprakstāmu concave polyhedron figūru (triangle mesh'i nav saprātīgi), kas tie būs algoritma 3D versijā?
Nu arī iekš 3D tie polyhedron nebūs concave, bet gan sadalīti kā convex hierarhija. Teiksim, 3D kubs ar 6 virsmām arī var būt convex mesh. Čaulas jeb hull precizitāti varam likt kādu gribam - ņemam par pamatu oriģinālo convex hull no 3D modeļa, lai cik poligoni/trijstūri tam arī nebūtu, un vienkāršojam, teiksim uz 12 vai 18 poligoniem. Uztveram to kā nosedzošu čaulu, iekš kuras ir jau precīzāka 3D modeļa versija.
Otro stūrakmeni nesapratu. Grūti iedomāties, kā ar to linkošanu var noteikt redzamību katram objektam.
Varbūt vēlāk uzzīmēšu, tad būs skaidrāks.
Ir šaubas par to, vai mainīga izmēra dati ir labākais bounding volume aprakstīšanas veids... AABB/OBB/sphere objektus izvēlas tāpēc, ka tie ir statiski, vienveidīgi, paredzami dati, kuri netaisīs liekus atmiņas pieprasījumus. Convex daudzstūri un it īpaši polyhedron'i būs pavisam kaut kas cits un visticamāk dubultos prasības pret sistēmai nepieciešamo atmiņu visos veidos. Tā gan nebūtu tik liela problēma, ja atmet spēles kā potenciālo klientu.
Ok, es arī līdz galam nevaru pilnīgi galvot par performanci, tas ir jātestē. Bet visādi citādi šī struktūra atrisina daudzas ģeometriskas problēmas.

User avatar
rudis
Posts: 26
Joined: 11 Apr 2012, 13:55

Re: Kā atrast finansējumu

#9 Post by rudis » 16 Oct 2012, 16:04

Es tik domāju vai tu pārāk nesteidzies ar to nopelnīšanu ? Vēl jo vairāk ja lieta ir tik specifiska ? Mēs XNA pamuļķi esam izlaidušies tik tālu ka vajag uzreiz scene graph, physics , ai , utt., risinājumus , jo redz nelieši sapņojam pabeikt publicējamu spēli arī . Lielās zivis savukārt nodarbina tik daudz zinīšus ka viņiem kaut ko pārdot , nez , man liekas neiespējami , tām viss ir . Tā kā es ieteiktu pagaidām turēties pie tā kas tev ir un lēnām kāpt pa karjeras kāpnēm , ja vēlme ir radīt tehnoloģijas . Apsver iespēju kontribūtēt lieliem open source projektiem . Tas ir labs veids kā pierādīt sevi un nonākt lielās kompānijās . Tur tad tu arī varēsi strādāt pie izgudrojumiem un tehnoloģijām , ja tas ir tas ko tu vēlies .

persick
Posts: 8
Joined: 15 Oct 2012, 15:43

Re: Kā atrast finansējumu

#10 Post by persick » 16 Oct 2012, 16:25

Es to vairāk daru, tāpēc ka man tas interesē, kā izaicinājums. Ne naudas dēļ, vai lai pabeigtu spēli. Es ilgi ar to varētu nodarboties bez naudas iegūšanas. Tikai kā jau minēju - man trūkst laika. Bet laiku var mēģināt "nopirkt" ja mans projekts ienes augļus. Tāpēc tā orientējos uz šī risinājuma pārdošanu.

Nu iespējams, ka esmu mazliet mākoņos ielidojis par agru, bet toties man būs sirdsmiers tikai tāpēc, ka es kaut ko mēģināju. Tas ir galvenais.

Un galvenā doma nebija jau pārdot pašu algo / moduli - tikai kā variants. To var kā pamatu izmantot, lai radītu kādas konkrētas aplikācijas vai rikus, kuras tad varētu tirgot.
Apsver iespēju kontribūtēt lieliem open source projektiem . Tas ir labs veids kā pierādīt sevi un nonākt lielās kompānijās . Tur tad tu arī varēsi strādāt pie izgudrojumiem un tehnoloģijām , ja tas ir tas ko tu vēlies .
O rly? Mani tas vienmēr ir interesējis, no kurienes open source darboņi rauj piķi sevis uzturēšanai ? Ok, pieņemu, ka opensource seniori prot ar to pelnīt, bet iesācēji ? Pie mammītes mājas pagrabā ? Jūs teiksiet pēc darba dienas vēl vakaros kodēt ? Tā var kļūt par no liferi un turklāt tas grauj veselību, tik ilgi pie kompja sēdēt.

Post Reply

Return to “Spēļu izstrāde Latvijā / Game development in Latvia”