Keskustelu: Ohjelmointikysymykset: C++: labyrintti-peli

Aloitin juuri ohjelmoimaan ja pelin teko himo on kova.
Olen tehnyt Paintilla labyrintin ja nyt se pitäisi
siirtää pelin pohjaksi. Onko se mahdollista

Aloita alkeista, tekstipohjaisista ohjelmista ja Putkan C-opassarjasta tai Pascal-opassarjasta, riippuen siitä, kumpaa kieltä haluat käyttää. En haluaisi olla tyly, mutta juuresta latvaan käy koodaajan tie. Älä kurkota liian korkealle, ettet masennu, kun et osaakaan.

Näin voi tehdä(joitakin kohtia voi tarvittaessa jättää poiskin)

Paintilla piirretty labyrintti -> SDL:llä(vaikka) pilkotaan tietyn kokoisiksi paloiksi -> taulukkoon -> ikkuna vaikka kuvan kokoseksi -> ja sitten ukkelin siirtokertoja ennen katellaan, että onkohan tässä x ja y kohtaa nyt sitten ruohopaalu vai ei.

Juu, ehkä kannattaa katella ja testailla ensin nuo konsolipohjaset systeemit ja perusteiden jälkeen voit vaikka tuon ymmärtääkkin

Labyrintti on hyvin pientä joten pystyykö sitä suurentamaan.

Pystyy.

www.libsdl.org

mä osaan ohjelmoida ja koodata labyrintti pelin.

Kiva kuulla. Mäkin osaan ohjelmoda kaikkea kivaa, mutta sanonko sitä täällä. :)

...... kirjoitti:

mä osaan ohjelmoida ja koodata labyrintti pelin.

Siltä vaikuttaa...

Valaisisitko muuten, mitä eroa on ohjelmoimisella ja koodaamisella? :)

mä tarvisin hieman apua tän pelin ohjelmoimisessa, nimittäin
sen SDL:n kanssa !!!!
ohjelmoiminen tarkoittaa ohjelman aukottoman suunnitelman keksimistä
(Esim. Vuokaavio )
koodaaminen muuttaa suunnitelman koneen ymmärtämälle muodolle (0,1,2)
Niin olishan toi helppoo jos ymmärtäis tosta jotain. Pitää vain
lukea hieman enemmän ohjelmoinnista. Sä voisit tehdä ton pelin jos haluut.

Arvaan, että SDL ei oo ennestään tuttu, jolloin sopiva alotuspaikka on tuolla: https://www.ohjelmointiputka.net/oppaat/opas.php?tunnus=sdl1

lainaus:

ohjelmoiminen tarkoittaa ohjelman aukottoman suunnitelman keksimistä

Niinkö tosiaan? Ei minusta.

lainaus:

koodaaminen muuttaa suunnitelman koneen ymmärtämälle muodolle (0,1,2)

Jaa? Missähän vaiheessa se ohjelmakoodi sitten kirjoitetaan? Ja kone ei mitään kakkosta ymmärrä (kuten ei mitään muutakaan, jos nyt tarkkoja ollaan). Kyllä se on kääntäminen se vaihe, kun koodista tehdään binääriä.

Heh heh... Saipas pitkästä aikaa hyvät naurut :) Tuli jotenkin mieleen ZeBe ja sen tyhmääkin tyhmemmät kysymykset :)

ajv kirjoitti:

Heh heh... Saipas pitkästä aikaa hyvät naurut :) Tuli jotenkin mieleen ZeBe ja sen tyhmääkin tyhmemmät kysymykset :)

Taitaa tämä ...... olla huumoriveikkoja. Tulee väkisinkin mieleen mureakuhan C++-foorumilta eräs nimeltämainitsematon C++-Quru.

Alkaa vaikuttaa tosiaan meidänkin puolestamme Mureakuhan tyyliltä.
Jospas lopetettaisiin naljailu ja neuvottaisiinkin kunnolla?

Ensin sinun on selvitettävä, hallitsetko taulukot, olio-ohjelmoinnin alkeet, funktiot, C/C++:n perusteet, hallitsetko riittävät taidot kirjastojen linkittämiseen(?) (vitaalia SDL:n asentamiselle).
Jos hallitset nämä, Heikki on kirjoittanut hyvän oppaan SDL:n alkeista, joka kannattaa lukea, jos kirjasto ei ole tuttu.
Jos taasen et hallitse, suosittelen lukemaan Antti Laaksosen C:n alkeisoppaan, joka valaisee muutamia perusasioita kielestä.
Molemmat oppaat löytyvät Ohjelmointiputkasta.

Kun olet oppaat lukenut ja ensimmäiset ohjelmat koodannut, voimme keskittyä taas labyrinttiongelmaan.

P.S. Onko mielestänne todellakin oikein, että aloittelija tyrmätään täällä meillä, kuten tehdään yllättävän usein Mureakuhassa. Aloittelijan kysymykset saattavat tuntua välillä tyhmiltä, mutta muistakaa, että aloittelijoita olette olleet itsekin.
Neuvotaan siis hyvä reitti ohjelmoimisen alkeisiin jokaiselle!

Vuokaavio haiskahtaa BASICilta. Tai sit se haiskahtaa muuten vaan. Hyppyjä sinne sun tänne. Vai käytetäänkö vuokaavioita myös C- ja C++-kieliseen ohjelmointiin?

No vuokaavio voi olla myös paperille piirretty suunnitelma, että miten ohjelman ajo etenee moduulista toiseen ja niiden vuorovaikutuksista.

Vuokaavion teon opettamista olen löytänyt useista kirjoista, jotka käsittelevät C++:aa, Pascalia ja Basic:eja. Se ei todellakaan ole mikään Basicin juttu (vaan juttu, joka pitäisi kirjoittajien mielestä tehdä joka ohjelmasta).

Joo, tiettyyn rajaan asti se on hyödyllinen joka ohjelmasta (ja kielellähän ei ole suunnittelun kannalta juurikaan merkitystä, jos tarvittavat ominaisuudet löytyvät), mutta en näe kerta kaikkiaan mitään järkeä tehdä kaaviota ihan niin matalalla tasolla kuin jokaisesta silmukasta, kuten oppaissa usein esitetään. Mieluummin ohitan ne silmukat toteamalla, että nyt tähdään X kaikille Y, jotka täyttävät ehdon Z. On sivuseikka, teenkö siitä while- vai for-silmukan vai kirjoitanko kaikki 240 taulukon alkiota erikseen. Ja vaikka jopa Tetriksen ohjelmoinnissa on apua valmiista suunnitelmasta, minä en ikipäivänä tekisi kaaviota esimerkiksi ohjelmasta, joka kysyy käyttäjältä operaation ja kaksi lukua ja suorittaa annetun operaation (+-*/) näille luvuille. Rajansa kaikella.

lainaus:

koodaaminen muuttaa suunnitelman koneen ymmärtämälle muodolle (0,1,2)

Mutta eikös kone käytä binääri-järjestelmää? (0, 1) (01010001001) (hyvät naurut)

Vuokaavio voi pahimmassa tapauksessa luoda tosi kimuranttia koodia, jos koodaaja ajattelee, että vuokaavio selittää koodin logiikan, jos koodi itsessään on liian takkuista. Vuokaavio voi tavallaan selventää koodia, mutta parempi tapa on kirjoittaa selkeää koodia kommentteineen. Tämä ei välttämättä onnistu jollain vanhalla basicilla (mbasic, gwbasic).

Vuokaaviot liittyvät sovelluksen määrittelyvaiheeseen, jonka pohjalta lopullinen koodi tuotetaan.
Kultainen sääntöhän olisi että ohjelmistotuotannosta on 90% speksien tuottamista ja 10% itse ohjelmointia.

Turha on räplätä SDL'n kanssa, opettele mieluummin DirectX tai OpenGL

aWW kirjoitti:

Turha on räplätä SDL'n kanssa, opettele mieluummin DirectX tai OpenGL

Jaa? Aika haka jätkä olet jos pelin pelkällä OpenGL:llä saat aikaan.

DirectX on käyttöjärjestelmäriippuvainen, hankalampi ja sitäpaitsi Microsoftin tekemä. SDL on käyttöjärjestelmäriippumaton(hyvin pitkälti), helpompi ja ei ole Microsoftin tekemä. SDL+OpenGL yhdistelmällä saa aikaan helpommin yhtä hyvää grafiikkaa kuin Direct3D:llä.

Ps. Älkää hikeentykö tuosta Microsoft irvailusta. Huumorin kukka on se kaunehin kukka :).

remontti-reiska kirjoitti:

Aika haka jätkä olet jos pelin pelkällä OpenGL:llä saat aikaan.

Miksei peliä voisi saada pelkällä OpenGL:llä. Minullakin on OpenGL:llä tehtyjä pelinalkuja (joissa EI ole käytetty SDL:llää) yhtä pitkällä kuin ne pelinprojektin tyngät joita olen tehnyt SDL:llä. Mietin vain että mitä perusteluja sinulla on tuohon?

remontti-reiska yritti nyt varmaankin selittää, että OpenGL:lle pitää hoitaa ikkuna ja viestinkäsittely, kon SDL:ssä ne ovat valmiina.

Eikö kukaan teistä SDL:n käyttäjistä tosiaan tajua, että ihan sama koodi sieltä SDL:nkin lähdekoodista löytyy; se vain on käännetty valmiiksi DLL:ksi (tai vastaavaksi). Kun yhden kerran kirjoitat itse hyvän WinAPI-ikkunanluonnin ja WndProcin (tai vastaavasti X-ikkunanluonnin ja tapahtumankäsittelijän), voit kopioida ne jokaiseen ohjelmaasi ja muokata tarpeen mukaan, ei kaikkea ole pakko kirjoittaa aina alusta asti uudestaan. SDL:ssä taas ne toimivat juuri tietyllä tavalla (koska joku on ne sinne kirjoittanut), ja joukosta löytyy paljon myös aivan turhia ominaisuuksia (eli muistia ja tehoa käytetään aivan turhaan sellaisiin asioihin, joita ei projektissa kaivata). Kun olen kerran kirjoittanut sellaisen ikkunankäsittelyjärjestelmän, josta pidän, minun on paljon helpompi käyttää sitä kuin SDL:ää. Ei tarvitse hetkeäkään miettiä, mikä se funktio / muuttuja / jokin nyt olikaan, kun olen itse kaiken suunnitellut ja tiedän, miten systeemi toimii.

Pitäisiköhän tehdä seuraava projekti SDL:llä? Hmm.
1) Siinä on näppäimistön- ja hiirenkäsittelijät ja ikkunanluonti. Niin on minullakin.
2) Siinä on ajastin. Minulla on oma.
3) Siinä on mikseri. Sellaisen saa kyllä itsekin väsättyä (OpenAL, libvorbis)
4) Siinä on jotakin peliohjainten käsittelyyn ja CD-asemaan liittyen. Peliohjaimia en ole vielä tarvinnut (ja tuskin tarvitsenkaan), CD-aseman tiedostoista selvinnee ihan siinä missä muistakin tiedostoista.

Hyvän peliohjelmoijan tulee osata DirectX JA OpenGL

Quake & Doom on kirjoitettu kokonaan OpenGL'lla

Aika moni muukin peli on kirjoitettu "kokonaan OpenGL:llä", mikä siis tarkoittaa, että kaikki graafiset osat käyttävät OpenGL:ää. Esimerkiksi Neverwinter Nights. Graafinen puoli ei todellakaan ole peliohjelmoinnin vaikein osa; huomattavasti vaikeampaa on itse pelin toiminta, tehokkaat törmäystarkistukset ja systeemi, jolla tasot ja muut tallennetaan tiedostoon, ladataan ja säilytetään muistissa niin, että kaikki törmäystarkistukset voidaan tehdä mahdollisimman tehokkaasti. Sekä OpenGL että Direct3D kyllä piirtävät ruudulle mallin kuin mallin, eikä toinen ole merkittävästi toista hankalampi. OpenGL:ää voi suositella lähinnä siksi, että siinä ei tarvitse sählätä monella eri tietotyypillä ja objektilla ja se kääntyy muillekin kuin Windowsille. DirectX:n tietotyypit toisaalta saattavat helpottaa käyttöä, jos oikeasti tietää, mitä tekee (mutta useimmat eivät tiedä, ainakaan matriiseista puhuttaessa). Oikeastaan DirectX:n vahvin puoli on se, että siitä tosiaan löytyy kaikki se, mitä SDL:stäkin, ja vielä 3D kaupan päälle.

Hyvän peliohjelmoijan pitää DirectX:n ja OpenGL:n ohella osata aika pirun paljon muutakin, pelkällä grafiikkalla ei tehdä pelejä.

aWW voisi joskus perustella kantaansa.

Metabolix kirjoitti:

pelkällä grafiikkalla ei tehdä pelejä.

Ei niin, pelissä pitäisi olla kiinnostava tarina, hyvä fysiikka, matalat laitteisto-vaatimukset, mielenkiintoinen taustamusiikki, hyvät ääninäyttelijät jne, jne ja vielä kerran jne.

Minä sanoisin samaa kuin Metabolix.No, pitäähän toki olla grafikkaakin(jos ei muuta niin merkkigrafiikkaa).Minusta tärkeintä ei ole grafiikka.Huono grafiikaisesta pelistä pitäisi tulla hyvä kun lisätään hyvä grafiikka.

Olen täysin samaa mieltä, kuin Metabolix. Aluksi grafiikan piirtäminen voi tuntua hankalalta, mutta loppujen lopuksi se onkin melkein helpoin osa. Kannattaa aluksi varmaan keskittyä ihan muihin asioihin, kuten törmäys tarkistukseen ym. Kun ne on saatu tehtyä on grafiikkaa helppo lähteä kehittämään. Tietysti kannattaa miettiä heti aluksi mitä rajapintaa lähtee käyttämään, koska joskus rajapinnasta toiseen siirtyminen voi olla aika tuskallista.(Ei tietenkään aina, tämä oli oikeastaan vain oma kokemus)

Mazuli kirjoitti:

joskus rajapinnasta toiseen siirtyminen voi olla aika tuskallista.

Tuo saattaa riippua pitkälti myös pelin toteutuksesta ja tietenkin grafiikan mutkikkuudesta. Tuon takia suunnittelu pitää tehdä oikein, esimerkiksi luoda sopiva rajapinta, josta näkyy ulos vain muutama yksinkertainen funktio. Minullakin oli OpenGL ja DirectX rinnakkain (kunnes heivasin DirectX:n metsään) ulospäin täsmälleen samanlaisissa olioissa, jolloin saatoin vain tarkistaa, kumpi on oikeasti olemassa ja kutsua molemmista samoja funktioita (Init, Load, Draw, ...). Oikeastaan ei ollut järin suuri askel edes muuttaa 2D-pohjalta peliä vastaavaksi tilepohjaiseksi palikka-3D:ksi, ainakaan OpenGL:llä. DirectX:llä joutunee vähän enemmän säätämään aluksi. Joka tapauksessa, kun kaikki piirtokoodi on samassa paikassa niin, että lähistöltä ei löydy yhtään mitään muuta, se on tarvittaessa suhteellisen helppo kirjoittaa uudestaan, kun ei tarvitse erotella muita koodinpätkiä joukosta.

jaa enpäs ole hoksannut tuota. se on kyllä totta että jos tekee omat functiot pirrtämiselle ym. niin on kyllä helpompaa siirtyä rajapinnasta toiseen, kun ei tarvitse muuttaa kuin yhtä functiota(jos se toimii samalla tavalla kuin edellinen),
eikä muutta tuhatta ja yhtä kohtaa koodissa. Täytyypä pitää mielessä :P

Kertokaa kaikki ihmeessä, miten oikein teette pelinne, jos piirtämiselle ei ole omaa funktiota? Ei kai kaikki ole mainin sisällä? Minä opin suunnilleen tällaisen perusperiaatteen heti ensimmäisessä C-pelissäni:

int main(int PC, char **PS)
{
  Alustus();

  while (KasitteleSyotteet() != LOPETA)
    Toiminta();

  Sammutus();

  return 0;
}

Ohjelmaa on helpompi käsitellä, kun se on pienissä osissa. Toiminta-funktio sisältää sen, että lasketaan kulunut aika, tarkistetaan pause- tai menu-näppäinten painallukset ja kutsutaan sen mukaan eri funktioita (normaalisti Maailma-olion toimintafunktiota, menussa Menu-olion toimintaa jne.), eli kaikki on siististi jaoteltu. Pisimmät yhtenäiset funktiot ovat törmäystarkistus ja piirto (ja tavallaan myös ikkunanluonti, koska se on sekä WinAPIlla että X:llä ja sisältää pitkästi OpenGL:n määrityksiä).

Metabolix kirjoitti:

Kertokaa kaikki ihmeessä, miten oikein teette pelinne, jos piirtämiselle ei ole omaa funktiota? Ei kai kaikki ole mainin sisällä?

Teen oman grafiikkasysteemin. Tarvitsen siihen ainoastaaan koodin/funktion, jolla voin lähettää dataa näyttömuistiin. Koodin rakenne minulla on miltei sama kuin Metabolixilla.

* karistaa offtopicin pois aiheen päältä *

Tuon labyrinttipelin toteutukseen käyttäisin itse yksinkertaisesti kaksiulotteista taulukkoa. Kannattaa tutustua basicin pelioppaassa tehtyyn peliin, joka muistuttaa tätä jonkin verran. Koodi on helpohkoa muuttaa C/C++-kieleen.

Kysy toki, ......, jos tarvitset ohjeita. Siksihän täällä ollaan :)

Metabolix kirjoitti:

Kertokaa kaikki ihmeessä, miten oikein teette pelinne, jos piirtämiselle ei ole omaa funktiota?

Ei suoraan, sen takia yleensä tehdään oma moottori

Metabolix kirjoitti:

Ei kai kaikki ole mainin sisällä?

Ei tietenkään, teen pelini windowsiin, joten pelin keskus on WinMain, sinne laitetaan varsinainen pelisilmukka, jossa suoritetaan tekoäly, fysiikka, otetaan syöte ja lopuksi piirretään taustapuskuriin

Minä käytän LaMothen mallia, eli tässä tyypillinen WinMain-> (mod. pitkä koodi poistettu)

edit->
laitoin kyseisen koodin kotisivulleni:
http://www.stwasm.org/tiedostot2/WinMain.txt

siis tarkoitin että minulla on esim pelaaja luokka/tietue, joka sisältää piirto, alustus ja muut functiot, mutta sitten on esim ammus-luokka joka taas sisältää nämä functiot joten tavallaan pirtämiseen ei ole yhtä functiota. Olen nyt alkanut tehdä nämä kyllä ehkä hieman paremmmin, eli minulla on esim pelaaja-luokka ja ammusluokka, jotka molemmat sisältävät sprite-luokan, jossa on piirtofunctiot.

Olen tuota kokeillut, ja se vain ei toimi kunnolla. Jotakin pientä sillä vielä saa aikaan, mutta isommissa kannattaa ehdottomasti tehdä niin, että piirtämisellä ei ole suoraa yhteyttä tyyppiin itseensä. Silloin on helpointa huolehtia siitä, kenen näkökulmasta asiat piirretään, jos haluaa tehdä peliinsä jonkinlaisen spectator-systeemin tai vastaavan. Siis saahan sen piirtämisen tehdä toisessa metodissa, vaikka niin, että kutsuu tyypin piirtometodia, jolle kerrotaan syötteissä, mihin kohti sen pitää itsensä piirtää, mutta ongelma tulee, kun yrittää piirtää ruutua monessa eri vaiheessa vähän kerrallaan. Niin se vain ei toimi.

Minun ratkaisuni 2D:ssä oli tarkemmin eriteltynä sellainen, että pelaajat, objektit yms. sisältävät mahdollisimman yksinkertaisen tiedon, eli sijainnin ja asteluvun sekä yhden luvun, joka ilmoitti, monesko "kuvaston kuva" piirretään (animaation edetessä tarvitsi siis muuttaa vain yhtä lukua). "Kuvaston kuvat" taas sisälsivät tilekartan numeron ja käytettävän kuvan sijainnin tilekartalla. Itse renderöijäolioon oli aluksi kyseiset tilekartat ladattu, ja piirtofunktiossa sitten käytiin kaikki pelaajat läpi, katsottiin, mikä kuva oli meneillään, ja piirrettiin se. Hyvä puoli järjestelmässä oli juuri se, että sain käännettyä ohjelman sisältämään sekä OpenGL:n että DirectX:n niin, että alussa sai valita, kumpaa käytetään. Irrallisilla funktioilla se ei olisi oikein onnistunut.

Ja aWW:n on ihan turha saivarrella :) main tai WinMain, ihan sama, lähinnä tarkoitin, että ei kai kaikkea ole tungettu samaan paikkaan (kuten tämän ketjun kyselijällä).

jaa kaipa tuo on totta, mutta eihän sitä kaikkea voi valmiiksi osata :P, että täytyy painaa noi vinkit mieleen metebolix :P

Voi teitä. Aloittelevan ohjelmoijan tyrmääminen on pahinta, mitä voi tapahtua. Mikään ei onnistu, kaikki gurut nauravat räkäisesti päälle ja morkkaavat. Kukaan ei ole ollut suoraan guru. Kaikki ovat olleet aloittelijoita joskus ammoisina aikoina. Nykypäivän putkan asenne aloittelijoihin on todella karu. Asenteen tulisi olla lämminhenkinen ja ystävällinen, jonka itse muistan putkassa olleen kyllä joskus, kun putka oli juuri avattu. Miellyttävää olisi, ettei putkaa muutettaisi mureakuhaksi (mureakuhassa kaikki ohjelmoijat ovat ammattilaisia ja aloittelijoita ei suvaita yhteisöön).

Eihän täällä ole alkuperäisestä aiheesta enää aikoihin puhuttu, ja alkuperäiseen aiheeseen annettiin jo aluksi ihan asiallinen neuvo, eli alkeet kannattaa ensin opetella. ...... on itse poistunut keskustelusta jo kauan sitten, kun Blaze yhtävällisesti hänet ohjasi SDL-oppaan luokse. Ja itsehän hän tuolla sanoo osaavansa kyseisen pelin "ohjelmoida ja koodata", eli ilmeisesti hän ei lopultakaan tarvitse apua.

On kahdenlaisia aloittelijoita: Niitä, jotka haluavat oppia, ja niitä, jotka haluavat tehdä. Ensimmäistä tyyppiä on mukavampi neuvoa, ja jälkimmäinen taas saa tuskin mitään aikaan ja päätyy usein lopulta pelinteko-ohjelmiin, ellei riitä kiinnostusta astua opettelijoiden puolelle.

TeeVee kirjoitti:

mureakuhassa kaikki ohjelmoijat ovat ammattilaisia ja aloittelijoita ei suvaita yhteisöön.

Olen huomannut saman