Tai rekisteröidy jo tänään!
Näytä kirjoitukset
Tässä osiossa voit tarkastella kaikkia tämän jäsenen viestejä. Huomaa, että näet viestit vain niiltä alueilta, joihin sinulla on pääsy.
  Viestit   Aiheet   Liitteet  

Aiheet - Woffelson

Sivuja: [1] 2 3
1
Valmiit pelit / Hazard #32
« : 19. Toukokuu 2019, 19:23 »
Hazard #32

Tämä Metroidvania-tyyppinen peli väsättiin siis tiimivoimin yliopiston game project kurssilla. Tälle GameMaker projektille oli suurin piirtein kuukausi aikaa. (Kahden kuukauden Unity-projektiksi yritettiin myös vääntää peliä sillä Final Boss ideallani, mutta useiden vastoinkäymisten johdosta kyseinen tuotos jäi käytännössä lähtökuoppiin.) Tässä Hazard-projektissa olin siis itse pääkoodarina, vastasin musiikista ja autoin muillakin osa-alueilla muuta tiimiä, jolle GM oli vieraampi. Sinänsä tämä on ollut siis aikamoinen saavutus, kun en ole ennen päässyt kokopitkää Metroidvaniaa tekemään vaikka se on ollut yksi vuosia kestänyt haaveeni pelidevaamisessa. Monta uuttakin asiaa tuli opittua matkan varrella ja erinäiset rajoitteet toi oman haasteensa. Näistä syistä esimerkiksi pelin optimointi jäi aika heikolle tasolle ja se saattaa joskus kaatua...

Peliä voi tosiaan speedrunnata pelin omankin ajastimen voimin (olettaen, että pelimekaniikan oppii ylipäätään hallitsemaan). Oma ennätykseni on 10:27  ;)

Kontrollit:
    WASD – move
    Space – jump, interaction
    Shift – run
    Mouse left – "weapon" (when unlocked)
    Enter – pause game
    Esc – quit game
    Backspace – main menu

LATAA (itch.io)

En nyt ihan kaikkea tietoa tänne rustaa: latauslinkki löytyy itchistä, jossa muutkin tarkemmat tiedot löytyät.

2
Tekstikäyttöliittymässä on sellainen ongelma, että kun pilkon katkelmaa osiin, teksti ei enää kirjoita typewriter tyyliin jälkimmäistä osaa. Yksi katkelma on siis muotoa katkelma[n]="wall of text"; Kun sillä tulee tekstiboxin raja vastaan, se aloittaa kirjoittamisen alusta siitä mihin jäi. Olen soveltanut tätä examplea, lisäämällä esim. tuon checkpoint muuttujan cp. Alla koodi siitä osasta, missä pilkkominen tehdään:

if (characters < message_length)
{ //if current character count is less than the amount in current message
    hold = keyboard_check(vk_enter); //hold is true or false if we hold or not
    if string_height_ext(message_draw,line,hlimit) < vlimit
    {
    characters += increase * (1 + hold*2); //increase speed based on hold
    message_draw = string_copy(message[message_current],cp,characters); //copy string to current character
    }
    else if keyboard_check_pressed(vk_enter)
    {
        cp = characters;
        message_draw = "";
    }
}


Examplesta poiketen piirrän tekstin näin: draw_text_ext(view_xview[0]+64,view_yview[0],message_draw,line,hlimit);

Jos joku haluaa oikeasti ajaa koodin, niin tässä lisäämäni muuttujat ja stepin loppuosa (joka lähes sama kuin examplessa):
Spoiler
hlimit = 128; //horizontal area for text
vlimit = 64; //vertical area
line = 16; //pixels between lines (vertical)
cp = 0;

else
{ //if current character is more than the amount in the current message
    cp = 0;
    if (keyboard_check_pressed(vk_enter))
    {
        if (message_current < message_end)
        { //if there are more messages left to show
            message_current += 1; //increase the message by 1
            message_length = string_length(message[message_current]); //get the new character length for message
            characters = 0; //set the characters back to 0
            message_draw = ""; //clear the drawn text
        }
        else
        { //if our messages are done (we reach end)...
            message_current = 0;
            message_draw = "";
        }
    }
}

3
Pelinkehityslogit / Laskettelu peli
« : 18. Elokuu 2018, 17:31 »
Vaikka Moduksen aiheessa lievästi jo manailinkin, ettei devailuille jäisi edelleenkään aikaa, niin ainakin nyt vielä ennen opiskelujen alkua innostuin vaihteen vuoksi suunnittelemaan vähän kevyempää laskettelupeliä. Siitä tulisi varmaan vähän samantyyppinen kuin se klassinen Dosin SkiFree, mutta tietenkin astetta nykyaikaisempi ja vaikka epärealistisestikin paljon nopeatempoisempi. (Viime aikoina on tullut taas pelailtua F-Zero GX:ää, mikä selittänee vauhtipuremani.)

Pähkäilin alkuun erään keskeisen pulman parissa, missä päädyin jo tosin ratkaisuun. Johtopäätös on vaan vielä käytännössä toteuttamatta. Käyty pohdinta alla:
Spoiler
Vaikka olenkin saanut aikaan tarkan ja realistisesti toteutettavissa olevan suunnitelman kasaan, yksi keskeinen kysymys on vielä ratkaisematta. Pohjautuisiko pelimoottori normaaliin vai old school arcade -mekaniikkaan? Moni varmaan saa kiinni, mitä jälkimmäisellä tarkoitan. Eli käytännössä pelaaja pysyy fiksatusti paikoillaan, samalla kun moottori kelaa ympäristöä eteenpäin. Normaalissa olisi tietenkin tähän nähden kopernikaanisempi käänne, eli pelaaja liikkuu objektina muiden joukossa eikä ole mitenkään maailman keskipisteenä.

Kuten voi arvata, näillä molemmilla malleilla on hyvät ja huonot puolensa, minkä takia en ole vielä päättänyt, millä menen. Molempiakin olisi toki mahdollista toteuttaa, mutta sitten joutuisin koodaamaan käytännössä kaksi eri moottoria. Niistä olisi vaikea saada yhdenmukaisia, jolloin niistä tulisi väistämättä kaksi eri peliä. Tällaiselta turhalta työltä haluaisin välttyä ja saada kaiken sujuvasti yhteen pakettiin.

Normaali:
+ Tarvittaessa tekoälylaskettelijat ja moninpeli olisi helppoja toteuttaa
+ Mäkiä pystyisi suunnittelemaan yksityiskohtaisesti aika helposti esim. GM:n room editorissa (joka tosin on kämäinen, kun edelleen "käytän" Studio 1:tä)

- Varsinkin nopeista mäistä tulisi helposti niin pitkiä, että niistä tulisi raskaita sekä suunnitella että laskennassa suorittaa
- Loputon random -generointi olisi tarvittaessa vaikea ellei mahdoton toteuttaa

Old school arcade:
+ Pitemmän päälle mäet olisivat koodissa helpompi käsitellä ja generoida vaikka loputtomiksikin
+ Peliin saisi rutkasti vauhdin tuntua, kun varsinaisia huone- yms. rajoituksia ei juuri olisi

- Mäkidesign ei ole mahdotonta, mutta saattaisi jäädä koodin varassa tönkön näköiseksi, ellen sitten loisi oman mäkieditorin...
- Tekoälyn ja moninpelin toteuttaminen olisi haastavampaa
Tulin siis pohdinnasta johtopäätökseen, että voin tehdä hybridimallin. Normaalin huoneen mekaniikkaa peli noudattaisi siinä määrin kuin kilpailijoiden välille tarvitaan välimatkaa, muttei yhtään sen enempää. Minua askarrutti, että miten saisin pelin kulkemaan niillä, ketkä jäisivät huoneen ulkopuolelle, mutta tajusin heistä huolehtimisen turhaksi: jos eivät pysy nopeimman vauhdissa, peli on heidän osalta sillä selvä! Tällä tavoin pelin ydinmekaniikka voisi jopa kehittyä tämän suhteellisen matkan voittamiseen eikä obsessoitua liikaa joistain tietyistä radoista. Niitäkin voisi toki tehdä ja silleen, mutta välimatka voisi olla niin sanotusti pelin koukku. (Moninpelin lisäksi pitäisi varmaan laskijatekoälykin koodata...)

Teknisesti laskijoiden nopeutta voisi laskea yhtäältä suhteellisena nopeutena nopeimmasta, joka asettaa pelin absoluuttisen nopeuden. Toisaalta nopeuden toinen osatekijä muodostuisi old school arcade -kelauksesta, jolla mäkeä generoidaan matkalla alaspäin. Sen nopeus määrittyy jälleen nopeimmasta laskijasta. Yksityiskohtiin en osaa vielä mennä, mutta trial and errorilla idea varmaan toteuttaessa hioutuisi näköisekseen. Riskejä tähän ratkaisuun varmasti sisältyy ja nopeuden muutoksista voisi odottaa pahimpien bugien listimisurakkaa...

Pelin pohja toimii jo nyt yksinkertaisilla liukureilla ja enköhän talveksi saa jonkinlaisen pelattavan version kasaan. Voisin tällä avauksella ehkä haastaa forkkaakin jouluskabaan, jos sellaisen järjestymiseen vielä löytyisi jengiltä puhtia. ;)

4
GameDev Suomi / Keskusteluryhmä (virallinen?)
« : 08. Maaliskuu 2017, 19:51 »
Tällä hetkellä GDS:llä on siis epävirallinen ja kuolemaa tekevä Skyperyhmä ja yleisthreadissa onkin aiheesta tarkemmin keskustelua, joten heitän tässä vielä vaan oman fifty centin tähän huimat mittasuhteet saaneeseen SkypeGateen ( :roll:). Jos Gamedev Suomella olisi virallinen keskusteluryhmä esim. Discordissa, siihen voisi jollain tapaa viitata vaikka foorumin etusivulla, jolloin säästyisi iänikuisilta vastakkainasetteluilta foorumin ja keskusteluryhmän välillä. Yhtälön "GDS = foorumi - chat" voisi kääntää muotoon "GDS = foorumi + chat", kun molemmissa olisi institutionaalisesti julkilausuttu linkki toiseen. Samaten jengi voisi liikkua kätevästi siellä, missä kokee tarpeelliseksi/paremmaksi jne. Jokin ylälaidan välilehti tai banneri forkalla voisi olla kohdillaan, jos oikein virallisuus edellä puuhun mennään. Viittaamisesta käytännössä en osaa sen enempää sanoa, mitä mahdollisuuksia tässä olisi, mutta pallo on varmaan ylläpitäjillä. Ignon palopuhe perustelkoon tarkemmin myös puolestaan:

Official olis kyllä positiivinen asia kaikenkaikkiaan. Toki aina ollut vääntöä siitä että Skype syö foorumin aktiivisuutta, mutta en ole aivan samaa mieltä. Uskoisin virallisen chat-huoneen luovan foorumin sisäistä yhteishenkeä kun porukat oikeasti tutustuu toisiinsa ja tekee kontakteja joista myös syntyy tiimejä ja peliprojekteja. Hyviä peliprojekteja ei myöskään aikuistenoikeesti synny pelkästään foorumin kautta, viimeistään tiimin synnyttyä siirrytään johonkin muuhun viestintäpalveluun. Kuitenkin jos/kun Skypen (tai muun kanavan) käyttäjät saa projekteja aikaan ja jatkaa siinä ohella foorumeille postaamista niin asiat on suht okei foorumin kannalta. Maksimissaan kaikki offtopic siirtyy chattiin (jonne ne tbh on tarkotettukin) Sitäpaitsi itse en koe foorumin aktiivisuutta itseisarvona vaan sitä että on oikeasti hyvä kanava kommunikoida muiden devaajien kanssa (vaikka en siis usko että foorumi kärsisi virallisesta chatista).

Jos kanava olisi virallinen niin uskoisin sen pelkästään jo takaavan että siitä tulisi vähintään yhtä aktiivinen kuin nykyinen Skype-ryhmä. Itse antaisin ääneni Discordille, koska (kuten Telegram) toimii työpöydällä ja mobiililla, sekä vielä nettiselaimestakin ja on muutenkin helpommin hallinnoitavissa adminien toimesta jos oletetaan että sinne halutaan "virallisempi" adminporukka. Plussana myös useat erilliset chat-huoneet ja helpot ryhmäpuhelut

Onko foorumin ylijumalilla(/admineilla) mielipidettä?

5
Keskeneräiset pelit / Modus: Simulations (alpha 0.3)
« : 02. Syyskuu 2015, 01:12 »
Modus: Simulations
Modus: Simulations on kokeellinen strategiapeli, johon yhdistelin paljon omia ideoita ja otin hieman vaikutteita Miksamoon CQB Tacticsistakin. Pelissä on toistaiseksi vain taistelumoodi ja sandbox testailua varten. Tarkoituksena on vallata torneja rahaa saadakseen, jotta voi hommata unitteja (klikkaamalla vihreitä laatikoita).

Valikossa voi melko laajasti asettaa taistelun ominaisuuksia. En käy niitä tässä läpi, kokeilkaa itse. Peli on hyvin keskeneräinen. Esim. kaikki hahmoanimaatiot puuttuvat ja bugeja riittänee. Kenttäsuunnitteluunkaan ei jäänyt oikein aikaa. Ajattelin vielä lisäillä kaikenlaista, kuten kampanjan sekä joitain asetuksia yms. Kunnollinen HUD olisi myös kiva sekä lisäinformaatio pelaajalle siitä, mitä unitit tekevät ja mitä ominaisuuksia niillä on...

Kontrollit ovat tiivistettynä seuraavanlaiset:
Lainaus
-WASD liikkuu
-Hiirestä tähtää,
-Hiiren vasen klikkaus hyökkää (asetuksista riippuen voi hyökkäyksenä käyttää bumerangia/pelaajan vaihtoa, meleetä, pommia tai rangedia)
-Hiiren oikea komentaa (komentoja on: tyhjennys komennoista, lähettäminen, seuraaminen ja oman unitin tuhoaminen, josta ei liene mitään hyötyä...)
-Shift pohjassa voi valita komentoja rullalla (muuten valitsee hyökkäyksen rullalla).
-Enteristä pausettaa, jolloin voi hioa hyökkäysstrategioita ja komennella unitteja.
-R restarttaa ja escistä poistuu päävalikossa.
-Osa toiminnoista toimii vaihtoehtoisesti HUDista hiirellä räpläiltäessä

0.1 (vanhaa settiä):
Spoiler

Hiiri ei muuten vielä toimi alkuvalikossa btw, näppäilkäätten siis.
Skriinshøt:
Spoiler


Joitain jo tiedossani olevia bugeja:
-Unittimenun syvyys kusee yli 999 y-koordinaatilla.
-Jostain syystä tiettyjen unittien tyyppi ei aina täsmää (jotkin rangedit ei spawnaudu rangedeina jne.)
-Erään kunkkuhahmon iskusprite on jäänyt placeholderiksi.
-Jne. jne.
Lataileppa tästä.

0.2 (kuwakaappauxia):
Spoiler



Latoo: Modus: Simulations (alpha 0.3)

6
Keskeneräiset pelit / BackWatch (open sauce)
« : 06. Elokuu 2015, 13:41 »
Watch your back!

Eli, tämä on hyvin alkeellinen kyhäelmä taisteluun selkäkipujani vastaan. Tein softan sitä varten, jotta voisin paremmin tauottaa koneellaistumisaikaani t: fysioterapeutti. Enkä liene tällä nörttiforkalla ainut, kuka istuu liikaa... Joten tämä voi olla yleishyödyllinen muillekin. En siis löytänyt mistään vastaavaa softaa, joka ajastaisi tiettyjen aikojen välein ilman herätyksen uudelleenasettamista joka kerta. Tässä on siis simppelisti kolme asetusta, joita voi sivunuolilla vaihtaa: puoli tuntia, tunti ja kaksi tuntia. Minun pitäisi siis parin tunnin välein tehdä tiettyjä venytyksiä, mutta jo pelkästä puolen tunnin välein noususta kroppa sanoo tack så mycket. Enteristä laittaa ajastimen päälle, jolloin kuuluu myös hälytysääni. Se on oletuksella sitten ihan vaan virtuaalianalogisyntsalla simuloitu kissan maukaisu. Pohjana on hieman käytetty jotain examplea gmc:stä enkä tiedä, onko ajastin ihan kaikista tarkin millisekunneissa jne. Pointtina on kuitenkin säännöllinen tauotus, joka toimii joka tapauksessa.

Ja kyllä, tämä on peli, jos haluat pelata terveydelläsi! Pelin voittaa se, jolla säilyy terve selkä ja pelissä häviää se, joka sairastuu tuki- ja liikuntaelin sairauksiin sekä halvaantuu ja kuolee. Any questions?

Ainakin toistaiseksi tämä on hyvin pelkistetty, mutta toimiipa jopa winen kautta Linuxilla, mikä on pääasia minulle. Siinä on esimerkiksi aika räikeä tausta (tosin tuskin kukaan koneella tunteja istuu BackWatch päällimmäisenä ikkunana). Laitoin kuitenkin projektitiedostonkin mukaan, jos haluaa viritellä oman kellon tältä pohjalta. Ei siis muuta kuin peba ylös penkistä.



LATAA EXE
LÄHDEKOODI (projektitiedosto)


Projektin rahoituksen ja propagandan tarjosi Terveyden ja hyvinvoinnin laitos

7
Apuosio / Kaksi toimintovalikkoa
« : 26. Heinäkuu 2015, 16:29 »
Ajattelin käyttää peliprojektissani kahta toimintovalikkoa. Yleensä peleissä voi hiiren rullalla valita yhden itemin tai jotain, mitä kerralla käyttää. Omassa systeemissäni voisi kerralla käyttää kahta eri toimintoa, joita voisi lennossa vaihtaa. Osaan varmasti homman jotenkin toteuttaa, mutta mietin mikä olisi käytännöllisin ratkaisu vai onko se ihan makuasia?

Valikolla 1valitaan käytännössä jokin ase ja valikolla 2 toiminto, jolla vaikutetaan muihin unitteihin tms. Vaihtoehtoja vaihdolle olen miettinyt seuraavanlaisia: A) Hiiren rulla ylös vaihtaa valikko 1:tä ja rulla alas 2:ta. B) Shift pohjassa rullalla voi valita valikko 2:n toimintoja. C) Shiftiä painaen voi näpytellä vuoron perään, kumpi valikko on käytössä.

Voi ehdottaa muutakin ratkaisua tai sanoa vaan, mikä mainituista olisi omasta mielestä paras.

8
Resurssit ja taide / Octabitium (chiptune-albumi)
« : 24. Heinäkuu 2015, 16:23 »
Noh, tein nyt oman aiheen tälle, ettei tule tuplapostia ääniaiheeseen ja varmaan ehkä tästä jutun juurtakin saa, kun näitä chiptuunaajia täältä gömssöstä löytyy. Julkaistiin siis kaverin kanssa tehty kokopitkä albumi kasibittistä surinaa progevivahteilla. Äänet olen itse syntetisoinut Korg R3 virtuaalianalogilla ja mm. käyttäen tätä väsäämääni rumpukonesysteemiä. Muuten olen ohjelmoinnissa hyödyntänyt MIDIä ja Linuxin softia. Eli vähän eri tekniikalla kuin Famitrackerilla (tai Game Boyn ohjelmointimenetelmillä, mitä jotkut hc-harrastajat tekevät). Virallisen julkaisun ajoitin 8.8. Sitä ennen tämä on vielä tällaisena pre-releasena siltä varalta, jos jotain tarvitsee vielä muuttaa ennen lopullista kaneettia.

Pidemmittä puheitta, kuunnelkaa (klikkaamalla) ja kommentoikaa toki, jos on jotain palautetta:

9
Koska saatan taas saada projektini pyörimään, niin miksenpä jakaisi niistä jotain sivutuotetta jo. Tämä on siis eräs jokin aika sitten kyhäämäni strategiaprojektini tekoälyskripti (mikrotasolla), jossa käytin pohjana erästä find_nearest skriptiä. Erityisesti tämä toimii siis reaaliaikaisessa strategiassa, miksei vuoropohjaisessakin. Kyseessä on siis kivi-paperi-sakset mekaniikalla toimiva skripti, joka etsii heikoimman vastustajan ja vertaa sitä sen etäisyyteen suhteessa muihin vastustajiin. Suhdeluvuista on vähän vaikea antaa suuntaa, mitä kannattaisi laittaa, koska se riippuu hyvin paljon tilanteesta. Koodia on toki mahdollista yksinkertaistaa ottamalla sieltä noita monimutkaisempia juttuja pois. Kommentit ovat enimmäkseen enkuksi, koska teen lopulliset sillä ja väliaikaiset sivuhuomiot suomeksi (vaikkakin todellisuudessa ne menevät aina ihan sekaisin).

Funktion muuttujat vielä lyhyesti:
-argument0 (object_index): tarkistettava objekti
-argument1 (side): objektien puolen/tiimin muuttuja
-argument2 (distance): tarkistettava etäisyys
-argument3 (health): tarkistettavan enkkamuuttuja
-argument4 (health_ratio): määrittää enkan ja tyypin suhteellisen painoarvon
-argument5 (type): tarkistettavan tyyppimuuttuja (kivi-paperi-sakset 0-1-2)
-argument6 (dist_ratio): määrittää etäisyyden ja heikkouden suhteellisen painoarvon

///instance_weakest(object_index,side,distance,health,health_ratio,type,dist_ratio)
{
    var ds1,ds2,weak,nearest,weakest;
    ds1 = ds_priority_create();
    ds2 = ds_priority_create();
    ds_priority_add(ds1,noone,100000000);
    ds_priority_add(ds2,noone,100000000);
    weak[0,2] = 1; //0 is stone and 2 (scissors) is its weak opponent
    weak[1,0] = 1; //paper's weak opponent is stone...
    weak[2,1] = 1; //GEDDIT?
    weak[0,1] = -1;
    weak[1,2] = -1; //avoid bad opponents using negative value
    weak[2,0] = -1;
    weak[0,0] = 0;
    weak[1,1] = 0; //same is lame
    weak[2,2] = 0;
    with (argument0) //object_index
    {
        if (argument1 != other.argument1 && id != other.id && //defines the enemy
            distance_to_object(other) < argument2)
        {
            ds_priority_add(ds1,id,point_distance(x,y,other.x,other.y)); //list near enemies
            ds_priority_add(ds2,id,(argument3 + (argument4 * (weak[argument5,other.argument5]))));
            //list weaklings (valittavalla kertoimella ottaa tarkistettavan enkankin huomioon)
        }
    }
    nearest = ds_priority_find_min(ds1); //nearest enemy
    weakest = ds_priority_find_min(ds2); //weakest enemy
    ds_priority_destroy(ds1);
    ds_priority_destroy(ds2);
    if (distance_to_point(weakest.x,weakest.y) - distance_to_point(nearest.x,nearest.y)) > argument6
    //compare the distance between nearest and weakest
    return nearest; //if weakest is too far, return nearest
    else
    return weakest; //if nearest is too far, return weakest
}

Puhtaaksi kirjoittaessani löysin vielä yhden virheen (koodissa argument3:n edessä oli other.) ja muitakin voi olla, joten palautetta ja kysymyksiä toki otetaan vastaan.

EDIT: Ai niin tosiaan, skriptiä saa käyttää, mutta ei ole pakko. Krediittiäkin saa antaa.

10
Pelisuunnittelu / Makrotekoäly
« : 07. Maaliskuu 2015, 02:17 »
Ei varmaan pitäisi tähän aikaan enää kirjoitella vaikeita kun väsyttää jo, mutta olen viime aikoina pohdiskellut aihetta omien koodailukokeilujenikin lomassa. Lähinnä strategiapeleissä yleensä kaiketi on eräänlaista makrotekoälyä. Tällä tarkoitan sitä, että tavanomaisten objektien ja näiden sisäisten tekoälyjen lisäksi on ylempi tekoäly, joka organisoi näitä yksiköitä spesifeihin tehtäviin. Yksinkertaisimmillaan ajatus voi toki pitää sisällään jonkin simppelin generoivan ajastussysteeminkin. Ihmetykseni koskee sitä, että millä eri tavoilla käytännössä makrotekoälyä voisi ja kannattaisi toteuttaa. Voi jakaa myös omia kokemuksiaan vastaavanlaisista toteutusviritelmistä yleensä, jos tuo makrotekoälyn kuvaukseni sopii keissiin.

Tällä hetkellä olen väsäillyt sellaisen tekoälyn kanssa, jossa se suuntaa kohti vastapuolen kingiä, ellei lähistöltä löydy heikompaa vastusta. Tämä ei ole kuitenkaan vielä bottitiimille kovin älykästä strategiointia ajatellen joukkojen kokoamista ja tiettyjen asemien puolustamista. Mitä jos vastapuolen joukoista suurin osa on oman kunkun kimpussa? Ei kai sitä voi pulaan jättää, mutta ei hylätä koko hyökkäystäkään, jos vastapuolelta yksi eksyy omille territorioille. Mitenpä siis analysoida joukkojen voimasuhteita? Pitäisikö tiettyjen alueiden välillä/sisällä laskea sen sisältävien instanssien suhteita? Entä onko alueiden instanssilaskutoimitukselle elegantimpia vaihtoehtoja?

11
Apuosio / Fakeroomin huoneaktivointi
« : 19. Joulukuu 2014, 11:41 »
Moni muistanee fakerooms-moottorini, jota olen monessa yhteydessä soveltanut. Haluaisin kehittää siihen uuden ominaisuuden, jossa deaktivointialue riippuisi sen hetkisen huoneen koosta. Olen rajannut huoneet obj_roomblockeilla, mutten tiedä, miten rajaisin aktivointialueen niiden sijaintiin määrittyneenä. Varmaan neljään suuntaan pitäisi tehdä jokin looppi, joka tarkistaa, tuleeko vastaan room_blockia ja asettaa sen perusteella rajat. Näin äkkiseltään se vaikuttaa itselleni aika isolta palalta enkä ole varma, missä kohdin aktivoinnit ja deaktivoinnit olisi parasta suorittaa, koska riskinä on ettei se toimi oikein tai koituu liian raskaaksi, jos kokonainen room on kovin iso. Thänks in ädvääns.

12
Resurssit ja taide / 8-bittirumpusetti Hydrogenille
« : 12. Joulukuu 2014, 02:17 »
No niin, sain julkaistua joskus jossain lupaamani 8-bittisen rumpusetin Hydrogen rumpukonesoftalle. Samplet on soitettu VA-syna Korg R3:lla. Tämä voi olla kätevä niille, ketkä eivät tee trackereillä, halua/jaksa ohjelmoida kohinaa, tai miettivät rumpusaundien soittamista MIDI-koskettimilla tms. Setti on paikoin aika karu vielä, että sitä voinee parannella, jos sampleihin kaipaa täydennystä tai jotain. Setti on myös GM-yhteensopiva (GENERAL MIDIÄ TARKOITAN), eli jos ohjelmoi Hydrogenin soittamaan MIDI-tiedostoa, niin rumpuäänet on perustavilta osin optimoitu. Jotkin äänet voi olla esim pitkiä kohinoita, joita voi dempata tietyllä nuotilla, jos haluaa itse päättää kohinan pituuden (siksi tuo pitkä kesto kyseisillä sampleilla).

LATAA TÄSTÄ!

13
Valmiit pelit / Spidernet
« : 02. Toukokuu 2014, 02:02 »
Spidernet on sandbox-tyyppisellä tavalla epämääräinen peli. Musiikeista vastaa Moons of Jupiter. Siinä kai yleisesti.

Kontrollit:
  • Voit liikkua W(ASD) napeista ja tähdätä suuntaa hiirellä.
  • Vasemmalla hiirellä voi tehdä positiivisia toimintoja. Etänä voi viestittää tai pitää pohjassa ollessa lähikontaktissa. Sama toimii toisinpäin oikealla hiirellä (negatiiviset toiminnot).

Pelissäkin on ohjeet ja selitykset, mutta seuraava vielä suomeksi:
Lainaus
Tehtävä: Olet hämähäkki ja kasvat isoksi. Sitten voit lisääntyä ja jatkaa uutena sukupolvena. Hämähäkkejä on kahdenlaisia. Puolulaisten kanssa on helppo lisääntyä. Vihollishämisten kanssa vähemmän, mutta sekin on mahdollista. Jos onnistut lisääntymään vihollisen kanssa, lapsi voi syntyä toiselle puolelle. Voit tappaa vihollishämähäkkejä ja mystisiä lataajia (jotka suojelevat sähköpihaa ötököiltä) saadaksessi kunnioitusta; mistä lienee apua lisääntymiseenkin. Jos synnyt androgyyninä, niin… Se voi hieman hankaloittaa asioita… Pidä hauskaa!

Skriinshöttejä, klikkaamalla kasvaa silmissä:


Pelissä on tosiaan aika rankasti randomia käytetty koodissa, joten voi vaikuttaa kaoottiselta. Lisääntyä voi siis vain vastakkaisen sukupuolen kanssa. Androgyynitkin teoriassa kykenevät, mutta huonolla todennäköisyydellä. Botitkin on androgyyneinä hieman vihamielisempiä misantrooppeja, araknofoobikkoja tai misaraknooppeja (mikä lie onkaan oikea termi). Alunperin minun piti kehittää moottori niin, että botit lisääntyisivät omavaraisesti, mutta toistaiseksi ne ovat niin autistisia, ettei kanta säily elossa ilman säännöllistä generointia.

Mutta joo, alphaahan tämä periaatteessa on, eli kehitysideaa voi antaa. Saa nähdä sitten, milloin vaa jaksaa ja kerkiää päivittämään.

LATAA

14
Apuosio / Periytymisominaisuus
« : 01. Maaliskuu 2014, 17:50 »
Yritän tehdä yhteen uuteen projektiini eräänlaista periytymistä, että kaksi samaa objektia luovat yhden uuden saman objektin, jolla olisi createssa tietyt arvot randomilla vanhempiensa arvojen ollessa raja-arvoina. Tuon randomin osaan varmaan itsekin säätää, mutta ongelmaksi on muodostunut, että miten viittaisin createssa vanhempiin, kun ne ovat samoja objekteja? Myös niiden idiä on vaikea alustaa. Ts. tiedän, miten luova objekti saisi idin luotavasta, mutten toisinpäin: miten luotu saisi idin luojastaan (varsinkin, kun luojia olisi vielä kaksikin)?

Hakemallakaan en oikein löytänyt lisätietoa tai sitten käytin vääriä hakusanoja, mutta jos jotain löytyy voi linkata, tai sitten suoraan keksiä jonkin hyvän metodin minulle avuksi. Kaikki vihjeet ja johtolangat on tervetulleita.

15
Ajattelin, josko kilpailutapahtumien rinnalle voisi tuoda vaikka jo seuraavan vuoden alusta virallisia yhteisöprojekteja, jossa ideana olisi tehdä peli tai muutama, johon mahdollisimman moni voisi osallistua kykyjensä, jaksamisensa ja aikansa puitteissa. Kilpailuissa kokonaisen pelin väkertäminen yksin rajallisessa ajassa on varmasti monille osallistujillekin iso homma puhumattakaan niistä, keille se on muutenkin liian iso pala purtavaksi. Nykyaikana muutenkaan on soolona hyvin vaikea saada mitään kovin kummoista aikaan. Yhteisöpelillä olisi siis monia synergisiä etuja:

Plussat:
Spoiler
+osallistua voisi ihan millä panoksella tahansa (esimerkiksi pientä grafiikkaa samaan tyyliin kuin pantterin Shield and Sword topicissa ovat kommentoijat tehneet)
+tarjoutuisi mahdollisuuksia myös niille, ketkä eivät osaa käyttää GameMakeria → Lisää potentiaalisia osallistujia.
+jos jollakulla esim. loppuu motivaatio, toinen paikkaa → Mitä enemmän osallistujia, sen epätodennäköisemmin projekti jäätyy.
+pelit saattaisivat joskus jopa valmistua
+lisäisi foorumiaktiivisuutta ja toisi mahdollisesti käyttäjiä laajemmalta osaamisalueelta
+yhteisöllisyys (niin kauan kun tekijät eivät riitaannu)

Toteuttamisella on varmasti myös monia haasteita, mutta seuraavista miinuksista suurin osa on vain kiinni onnistuneesta organisoinnista, missä lähestyisinkin erityisesti foorumin ylläpitäjiä asian mahdollistamisessa. Muutenkin seuraaviin seikkoihin voisi ehdotella ratkaisumalleja:

Miinukset:
Spoiler
-vaikeus saada porukka mukaan (itse esimerkiksi olen todella huono kasaamaan ihmisiä yhtään mihinkään)
-kilpailun kaltaisena tapahtumana palkintojen jako olisi hieman mutkikasta (jos ylipäätään palkitsemisjärjestelmää aiottaisiin tässä tapauksessa edes ylläpitää)
-tekijöiden täytyisi oppia nielemään kompromisseja (hey, that's life)
-haaste tasapainotella yhtenäisen taitotason kanssa
-jäsenten keskinäinen kommunikointi ja informaation kulku
-aloittamisen vaikeus

Sarjat:
Jos/kun pelejä olisi useampi kuin yksi, ne voisi jakaa joihinkin sarjoihin. Se voisi määrittyä taitotasosta, mutta itse en kannata ajatusta, koska se voisi luoda foorumille eräänlaista luokkajakoa eikä sitäpaitsi yksinkertainen pelimoottori poissulje taidokasta grafiikkaa ja toisinpäin. Järkevämpää lieneisi jako esim. GM-versioiden perusteella: GM8-, GM8.1 Lite/Pro, GM Studio...

Huomioitavaa järjestelyissä:
Spoiler
-peruste, jolla yhteisöprojektien yhtäaikainen määrä rajattaisiin
-projektien valinta ja devauksen aikaiset kehityspäätökset esim. jotenkin äänestämällä
-työnjako ”osaamis-statsien” perusteella

Statsit:
Selkeyden vuoksi pitäisi varmaan ylläpitää työnjakoa vaikka pohjautuen foorumin jäsenten erikoisosaamisalueisiin, etteivät kaikki tee sekaisin ihan kaikkea:
Spoiler
-Koodi: pro/noob (prot vastaisivat esim. moottorin keskeisistä moodeista, multiplayeristä yms. ja noobit ahertaisivat puolestaan törmäysinstanssien ym. perussälän kanssa)
-Grafiikka: sprite(animointi)/taustagrafiikka (HUDit jne.)
-Audio: efektit/taustamusiikki
-Muu: tasosuunnittelu/käsikirjoitus... u naym it!

Ehkä parhaassa tapauksessa pelistä saisi resursseiltaan dynaamisen paketin. Muistan, kun ennen varsinaista pelintekoharrastusta joskus lapsena tein Worms World Partyyn omia graffoja, äänipankkeja ja modauksia missioneja myöten vaikken koodauksesta tiennyt mitään. Se olisi oikeastaan aika ideaalitilanne, kun ajattelee kynnystä muiden osallistumiselle pelinteossa. Joka tapauksessa ideaani voi jalostaa eteenpäin, jos näkee sille jotain käyttöä. En tiedä, onko minusta tämän enempää valmistelemaan asiaa vaikka ajatuksesta olenkin innoissani. Onhan tässäkin toki jo jotain. (Yritin piilotella tekstiäkin spoilereihin, ettei wall-of-text pelottelisi heti karkuun.)

Eli, periaatteessa tämä on parannusehdotus ylläpidolle, mutta siihen aiheeseen ehkä turhan ylimittainen huomio, joten tein oman aiheen...

Sivuja: [1] 2 3
Powered by SMF 2.0.11 | SMF © 2006–2009, Simple Machines LLC