Seuraava versio tulee jäämään viimeiseksi

Olen ajatellut, että en tee enää tämän seuraavan version jälkeen uusia versioita tästä pelistä. Kuitenkin vielä tämän yhden version päätin tehdä, että pelissä olisi ainakin jonkin verran pelattavaa eikä se jäisi aivan pätkäksi.

Pääasiassa olen jättämässä tätä peliä sikseen, koska omasta mielestäni se on varsin huonosti ohjelmoitu. Tein peliä C++ kielellä, mutta koodi on kuitenkin hyvin C-mäistä eli en ole käyttänyt juuri ollenkaan C++ kielen uusia ominaisuuksia. Myöskin monet ohjelmoinnin kannalta tehdyt päätökset olisi voinut tehdä paremmin. Tämän takia peli ei ole ohjelmoitu niin, että siihen olisi todella helppo lisätä uusia ominaisuuksia, kuten uusia vihollisia, vaan aina jotakin uutta lisättäessä joutuu tekemään varsin paljon työtä. Olihan tämä toki ensimmäinen oikeasti iso projektini, joten tuskin on ihme, että koodista ei tullut vielä aivan laadukasta. Kuitenkin opin tästä hyvin paljon ja tulevaisuuden projekteista tulee varmasti paljon parempia.

Lisäksi olen alkanut myös hieman kyllästyä tämän pelin tekemiseen. Olisi kiva opettella taas jotain uutta ohjelmointiin liittyvää esimerkiksi OpenGL-grafiikkaa. Joten seuraavat projektit eivät varmasti tule käyttämään tätä samaa SDL-kirjastoa, vaan jotain muuta.

Vielä loppuun sanon, että ei hätä kuitenkaan ole tämän näköinen. Olen nimittäin päättänyt julkaista pelin lähdekoodit seuraavan version yhteydessä vaapaaseen käyttöön, joten kuka tahansa voi jatkaa pelin kehitystä, ja viedä sen niin loppuun kuin huvittaa. :)

Panosten törmääminen viholliseen

Nyt kerron, kuinka panosten ja vihollisten välinen törmäys on tässä pelissä toteutettu. Törmäystarkistuksiahan voi peleissä tehdä monilla eri tavoilla ja ympyröiden käyttämistä törmäystarkistukseen käytentään uskoakseni varsin paljon. Eli objektin ympärille kuvitellaan ympyrä ja katsotaan osuuko se toisen objektin ympärillä olevaan ympyrään. Periaatteessa se on sama, kuin testattaisiin näiden kahden kahden objektin keskipisteiden välinen etäisyys ja niin se myös käytännössä toteutetaan. Tämä seuraava kuva havainnollistaa hienosti kyseistä systeemiä:

Tässä systeemissä on kuitenkin yksi ongelma. Koska panokset liikkuvat nopeasti ja niitä voidaan liikuttaa vain framejen vaihtuessa, panokset ikään kuin pomppivat eteenpäin. Jos vihollinen on liian pieni, panos voi pompata tämän yli, vaikka näyttäisi, että se osuisi. Seuraava kuva yrittää havainnollistaa tätä tapahtumaa:

Niinpä tätä voidaan yrittää korjata tekemällä vihollisen ympärillä olevasta osuma-alueesta suurempi. Tässä tapauksessa syntyy kuitenkin toisenlainen ongelma. Nyt, vaikka panos menisi selvästi ohi vihollisesta, se voi silti osua, kuten seuraava kuva havainnollistaa:

Jotta tämä saataisiin korjattua, olen lisännyt tähän peliin vielä toisenlaisen tavan tarkistaa törmäys. Siinä kuvitellaan, että panoksen kulkema reitti synnyttää viivan ja sitten lasketaan vihollisen etäisyys tähän viivaan. Tämä oli varsin yksinkertaista toteuttaa, koska taulukkokirjasta löytyi valmis kaava tämän laskutoimituksen tekemiseen. Tämä törmäyssysteemi näyttäisi seuraavanlaiselta:

Kun nämä kaksi törmäystarkistusta yhdistetään saadaan aikaiseksi kyseinen systeemi törmäyksen tarkistamiselle. Siinä on saatu korjattua kaikki viat, paitsi yksi. Nyt panos näyttäisi osuvan viholliseen liian aikaisin, mutta se on helppo korjata. Piirretäänkin panos hieman edemmäs, kuin missä se todellisuudessa on.

Hiscoret valmiit

Nyt on siis hiscore-systeemi saatu kokonaan valmiiksi. Etukäteen vähän hirvitti sen tekeminen, koska siinä oli melko paljon tehtävää. Loppujen lopuksi tehtävää oli kuitenkin vähemmän, mitä odotin, mutta silti aika paljon.

Ensinnäkin piti tehdä systeemi, joka tulostaa tekstiä yksittäisistä kirjaimista, koska tähän mennessä kaikki pelissä esiintyvät tekstit olivat olleet kokonaisia kuvia. Päätin koodata tämän systeemin itse, vaikka tarjolla olisi ollut kirjastokin, joka olisi osannut tehdä tämän suoraan fonttitiedostolla. Kirjastoja on kuitenkin jo aika monta mukana, joten päätin säästää tässä asiassa. Sitten piti tehdä systeemi, joka lukee käyttäjän painamat näppäimet, jotta voitaisiin kysyä pelaajan nimi hiscoreihin. Näissä molemmissa systeemeissä oli luonnollisesti aika paljon tehtävää, koska kirjaimia on kuitenkin melko paljon.
Sitten enää puutuikin sivu, joka näyttää hiscoret, mutta se meni jo vähän nopeammin, koska tekstin tulostus oli jo hanskassa.

Pistesysteemi

On jo varmaan selvinnyt, että tässä pelissä ei mitään tehdä yksinkertaisesti, eipä siis pisteitäkään saa yksinkertaisesti. Parissa kuvassahan on jo vilahtanut pisteet siellä oikeassa palkissa ja ensinnäkin niistä huomaa, että siellä ei ole mitään ylimääräisiä nollia perässä. Joissakin ääripäänpeleissähän saattaa olla loppupisteet jopa 738000000, mutta minä en itse pidä ollenkaan noista nollista tuolla perässä. Niinpä tässä pelissä ei tule olemaan ollenkaan ylimääräisiä nollia pisteissä.

Sitten itse pisteiden antamiseen. Koska jokaisesta vihusta ei saa aina samaa määrä pisteitä, pisteiden pitää riippua jostakin, ja tässä pelissä ne riippuvat luonnollisesti expasta, koska expat ovat niin tärkeä ja iso juttu tässä pelissä. Joka tapon yhteydessä siis katsotaan paljonko mitäkin expaa sai, ja niiden perusteella annetaan pisteitä. Heti voi varmasti keksiä hienon systeemin tähän: lasketaan kaikki saadut expat yhteen ja lisätään ne pistesaaliiseen. No, ihan hyvä idea, mutta tässä pelissä se on kuitenkin paljon monimutkaisempi.

Ja nyt se selviää: aluksi kaikkien taitojen saadut expat kerrotaan yhteen, laitetaan ne neliöjuureen ja jaetaan kymmenellä. Nyt yhdestä vihusta voi saada 1-1000 pistettä ja pisteiden saanti riippuu enemmän taidoista, mutta miten?
Tässä seuraavaksi on piirretty hieno kuvaaja funktion f(x) = sqrt(x^4) / 10 mukaan, eli siinä oletetaan, että jokaisesta taidosta olisi aina saatu sama määrä (x-määrä) expaa:

Siitä siis muodostuu tuollainen nouseva käyrä (itseasiassa funktion f(x) = x² / 10 kuvaaja). Kuvaajasta voi esimerkiksi ottaa kohdan, jossa kaikista taidoistaa saa 50 expaa, jolloin pisteitä saa 250. Jos taas jokaisesta taidosta saisi 100 expaa, saisi pisteitä täydet 1000. Siis, expojen kasvaessa pisteet eivät kuitenkaan kasva samassa tahdissa vaan vasta saadessa huippuexpoja voi saada oikeasti suuria pisteitä.

Kappas, fps parani tähtitieteellisesti!

Opin tuossa, kuinka SDL:n Surfaceja eli kuvapintoja voi optimoida nopeampaa piirtoa varten ja niinpä fps parani varsin mukavasti. Pelissä fps nousi 100:sta 1000:een ja kaupassa 50:stä 5000:een, eli aika *lvetin paljon. Samoin pieneni muistin kulutus muutamalla megalla, mutta se ei kuitenkaan ollut kovin merkittävää. Tämän takia pelin latautumiseen kuluva aika kuitenkin kasvoi puolella sekuntilla, koska optimointiin menee jonkin aikaa, mutta eihän se haittaa, koska nyt tätä peliä voi pelata paljon vanhemmallakin raudalla.

Tuossa on vielä se mainio funktio, jolla tämä oli mahdollista:
kuville ilman alpha-kanavaa: SDL_DisplayFormat(kuvapinta)
ja kuville alpha-kanavan kanssa: SDL_DisplayFormatAlpha(kuvapinta)

Tähtäimen tarkkuus

Nyt siis selviää, kuinka tuo tähtäin tarkentuu... sillä sekään ei ole aivan yksinkertaisesti tehty tässä pelissä. On siis jo selvää, että tähtäin tarkentuu, kun sitä ei liikuta ja ei ammu. Tähtäin ei kuitenkaan tarkennu tasaista vauhtia, vaan sen tarkentuminen hidastuu, mitä tarkemmaksi se tulee. Päätin tehdä tällaisen systeemin, jotta tähtäimen saisi nopeasti vähän tarkemmaksi, mutta jos haluaa kriittisen ammuksen (eli, kun tähtäin on tullut täysin tarkaksi) saa odottaa paljon kauemmin. Tällainen tähtäin on saatu aikaan niin, että joka framessa kerrotaan tarkkuuden arvo tietyllä luvulla, kun taas sellainen tähtäin, joka pienenisi tasaista vauhtia, saataisiin aikaan vähentämällä tarkkuudesta joka framessa tietty luku.
Tämän lisäksi pelissä on taito tarkkuudelle, joka parantaa tarkkuutta pelin edetessä. Taidon karttuessa tähtäimen pieneneminen nopeutuu ja sen maksimikokokin pienenee.

Vihollis- ja karttasysteemi valmis

Nyt on siis vihollissysteemi valmis, eli mukana on nyt kolme erilaista vihollista, joiden ominaisuuksia voi muokata. Tällä hetkellä ainakin, vihollisina toimivat vielä kolme eri väristä palloa, sininen, vihreä ja punainen. Vihreä vihulainen on nopeampi ja punainen on kestävämpi. Sininen on siitä välistä. Saatan kuitenkin vielä tehdä myös joitakin muita vihollisia ensimmäiseen versioon.
Tämän lisäksi on myös karttasysteemi saatu valmiiksi eli kartat tehdään kirjoittamalla tekstitiedostoon juttuja ja sieltä peli sitten lataa pelattavan kartan. Ekaan versioon ei kuitenkaan tule kuin se yksi survival-kartta, mutta ainakin omien karttojen tekeminen on alusta asti mahdollista, jos sellainen kiinnostaa. Tämä systeemi tulee olemaan käytössä myös tulevaisuuden "uramoodissa".

Sitten vielä kerron millainen se kartta-tiedosto tulee olemaan. Jokaisella erilaisella vihollisella on oma spawneri, ja nämä spawnerit ovat kartta-tiedostossa peräkkäin. Yksi tällainen spawneri voisi näyttää esimerkiksi tältä:

spawner:
start           5
end             -1
rate            5
raterandom      50
minrate         1
progress        0.01
enemy:
type            -1
value           1
speed           0.4
speedrandom     75
size            2
health          1

Mutta eipä tuosta nyt vielä enempää. Kohta puoliin ajattelin taas näyttää yhden kuvat, jossa näkyy nyt hieman päivitetyt grafiikat ja niitä uusia vihollisia.

Jaa koodi tiedostoihin

Vielä vähän aikaa sitten, kaikki tämän pelin lähdekoodi oli yhdessä tiedostossa yhdessä pitkässä pötkössä. Kun koodirivejä alkoi olla jo yli 1500, alkoi käydä vaikeaksi löytää sieltä enää mitään nopeasti. Niinpä nyt tässä parin viimepäivän aikana opettelin, kuinka jakaa koodi eri tiedostoihin ja se on todellakin helpottanut hommaa. Siispä, jos joskus alat ohjelmoida, tämä kannattaa todellakin opetella.
Tämän ja muunkin pienen koodin optimoinnin takia ei ole ollut nyt hirveästi edistystä viimeaikoina.

Monen saman objektin luominen

Aikoinaan aina ihmettelin, miten koodaamalla olisi mahdollista saada luotua monta samaa objektia, jotka kaikki käyttäytyvät samalla tavalla. Esimerkiksi tässä minun peliprojektissani panokset ja viholliset. Jokaisella objektilla kun pitää olla aivan omat muuttujat ilmoittamaan kaikkia sen objektin ominaisuuksia, esimerkiksi koordinaatteja, missä se milläkin hetkellä sijaitsee. Aikoinaan, kun vähän CoolBasiciakin kokeilin ja joskus, kun vasta vähän tiesin C-kielestä, osasin alustaa vain yksittäisiä muuttujia. Pistää vaikka   int jotain;  niin saa alustettua yhden muuttujan. Pitäisikö siis alustaa pitkät litaniat muuttujia tarpeeksi monelle objektille ja sitte jotenkin kivasti numerojärjestyksessä laskea kaikki tarpeelliset laskut niillä läpi? No, ei tietenkään.
Itse käytän erästä menetelmää, joka on omasta mielestäni varsin hyvä ja yksinkertainen, vaikka en oikeasti tiedäkkään, tehdäänkö nämä asiat yleisesti näin. C-kielessä voi kätevästi tehdä "objektin" strucktin avulla ja sitten alustaa monta tällaista strucktia käyttämällä indeksiä: jokumuuttuja[joku luku]. Ei tarvitse käyttää mitään pitkiä muuttujalitanioita ja jokaisen noista saa myös helposti laskettua käymällä loopissa kaikki indeksit läpi.
Tässä on esimerkkinä kuinka olen vihollisen tehnyt pelissäni:

     //vihulainen
     struct vihustr {
            int elossa;
            int tyyppi;
            float nopeus;
            float koko;
            float x;
            float y;
            int energia;
     };
     struct vihustr vihu[256];

Tuossa siis aluksi määritellään millainen vihu on ja sitten alustetaan 256 tällaista vihua. Sitten kaikki nämä voi helposti laskea läpi yhdessä loopissa.

Käyttääkkö prossua vai muistia?

Sanoisin, että peleissä voi käyttää enemmän joko tietokoneen prosessoria tai muistia, ainakin joiltakin osin. Tässä projektissa on paljon kuvia, joita täytyy pyörittää tai skaalata, kuten tykin ampumat panokset. Tämän voi tehdä kesken pelin joka framessa aina silloin, kun sitä tarvitsee, mikä kuluttaa prosessoritehoja. Tai sitten sen voi tehdä pelin latautuessa, kun peli käynnistetään, ja tallentaa kaikki muistiin. Kun kaikki käännellyt ja skaalatut kuvat on kerran laitettu muistiin, ei niitä enää pelin aikana tarvitse luoda.
Tämän SDL kirjaston kohdalla kuvien kääntely ja skaalaus on varsin hidasta. Muutenkin, kun tämä kirjasto on melko hidas kaiken piirtämisessä, niin ei haluaisi enää enempää kuluttaa prossutehoja. Siispä tämän kirjaston kohdalla on lähes pakko tehdä kaikki etukäteen pelin latautuessa, minkä takia tämä peli tulee kuluttamaan melko paljon muistia. Siis tämä peli lataa kaikki kuvat ja kääntelee ne etukäteen muistiin pelin latautuessa.
Sitten voi vielä miettiä, että lataako kaiken heti aluksi muistiin vai vasta sitten kun tarvitsee. Esimerkiksi mentäessä menusta itse peliin, poistettaisiin kaikki menun tavara muistista ja ladattaisiin pelin tavarat sinne. Tämä on kuitenkin työläämpi tehdä, joten minä päätin vain ladata kaiken kerralla muistiin. Jos ei lataisi kaikkea kerralla, tulisi myös pieni lataustauko, aina kun siirtyisi pelin ja menun välillä.

Sitten vähän mitä olen viime aikoina saanut aikaiseksi muistin käytön osalta. Kuten tuossa edellisessä jutussa kerroin, peli kulutti huimat 244Mt muista ja latasi 2.7 sekuntia. Silloin esimerkiksi vihulaisten raadoista oli 360 eri kuvaa, jokaiseen mahdolliseen suunta, kaikki muistissa. Nyt vähensin niiden määrän kymmeneen, koska eihän niitä oikeasti tarvitse noin paljon olla. Siispä nyt muistin kulutus on paljon vähäisempää. Tällä hetkellä se on noin 150Mt ja pelikin latautuu nyt 1.9:ssä sekuntissa, ja tuossa on vielä mukana paljon enemmän tavaraa kuin viimeksi (kuten muutaman uuden vihun kuvat).
Sain myös yhden (ja luultavasti myös viimeisen) muistivuodon korjattua, mistä olen varsin iloinen.

Tähtäimen luominen

Nyt, kun kaikki peliin liittyvät perusasiat on saatu setvittyä läpi, niin ajattelin tähän väliin kertoa jostain vähän teknisemmästä asiasta. Niinpä kerron nyt kuinka tuo upea tähtäin on tehty.

Tuossa kuvassa on nyt kaksi erikokoista tähtäintä, mutta niitä on oikeasti 200 erikokoista. Oli siinä kyllä aikamoinen piirtourakka noissa... no ei nyt sentään. Mutta eihän se voi yksittäinen kuvakaan olla, jota olisi skaalattu, koska silloin eri kokoisilla tähtäimillä pitäisi olla eri paksuiset reunat. Siispä, noissa tähtäimissä ei ole käytetty yhtäkään valmista kuvaa vaan ne generoidaan tyhjästä joka kerta kun peli käynnistetään.
Tuo generointi tapahtuu niin, että aluksi tehdään tietyn kokoiselle tähtäimelle sopivan kokoinen kuva, sitten kuvan jokaisen pikselin kohdalla lasketaan kuinka kaukana se on kuvan keskipisteestä. Etäisyyden ollessa sopiva, piirretään siihen kohtaan punainen pikseli. Ja näin saatiin kätevästi kokoa vaihtava tähtäin, jonka reunan paksuus pysyy kuitenkin koko ajan samana.

Tuohon generointiin menee noin sekunti omalla koneellani, ja tällä hetkellä pelin kaikkien kuvien lataamiseen ja generointiin menee reilu kaksi ja puoli sekuntia.

Minkälainen peli on kyseessä?

Nyt vähän tietoa siitä, minkälainen tämä peli tulee olemaan:
Pelin genre tulee ainakin nyt aluksi olemaan vain arcadea. Saatan sitten myöhemmin vielä lisätä jotain muutakin kuin pelkän survivallin. Pelissä ammutaan ruudun alareunassa pysyvällä tykillä ruudun yläreunasta päälle vyöryviä vihulaisia, jotka muuten ovat kivoja pallukoita (grafiikasta sitten vielä myöhemmin lisää). Se mikä tässä pelissä on varsin omaperäistä, on skillisysteemi, jossa paremmin pelaamalla saa expaa, jolla tykin ominaisuudet paranevat. Siinä se sitten onkin aika tiivistettynä. Yksityiskohtia sitten satelee lisää pelin kehityksen edetessä.

Sitten vähän teknisempiä yksityiskohtia:
Pelin kehitys tapahtuu Dev C++ ohjelmalla, vaikka joidenkin mielestä sitä ei enää pitäisi käyttää, mutta kun sillä on nyt jotain jo tullut tehtyä, niin eiköhän sillä vielä yhden pelin saa tehdä.
Koska C-kielellä ei saa juuri mitään aikaan ilman kirjastoja, niin ainakin seuraavia kirjastoja tulen käyttämään:

• SDL - grafiikka ominaisuudet ja näppiksen ja hiiren lukeminen
  
• SDL_gfx - lisää grafiikka ominaisuuksia
  
• SDL_image - käyttää libpng:tä avaamaan png kuvia
  
• libpng - avamaan niitä png kuvia
  
• libjpeg - SDL_image tarvitsee tätä (vaikka minä en)
  
• zlib - SDL_image tarvitsee tätäkin johonkin
  
• SDL_mixer - soittamaan musiikkia

Ja ehkä vielä joitain muitakin, joita mahdollisesti tarvitsen myöhemmin, mutta näin alustavasti, ainakin nuo.

Sitten loppuun vielä sanon, että eilen sain jo vähän koodia kasaan, joten pelin kehitys alkoi siis virallisesti 05.10.09.