Keskustelu: Ohjelmointiputka: Kilpailut

Moni varmaan kaipaisi putkaan taas jonkin sortin kilpailuja, onkohan niitä odotettavissa?

Oma ehdotukseni olisi kilpailu, jossa osallistujan tekevät oman ohjelmointikielen / tulkin jollekin kielelle.

Juhko kirjoitti:

Oma ehdotukseni olisi kilpailu, jossa osallistujan tekevät oman ohjelmointikielen / tulkin jollekin kielelle.

Ja voittoon tarvittavat kriteerit olis...?

Käyttäjät testaavat tulkkeja ja äänestävät. Monipuolisin ja paras tulkki olisi voittaja.

Voisihan sitä myös määrätä kielen etukäteen, (esim. BASIC tai C), niin äänestäminen olisi helpompaa.

Itsekin mielelläni jonkinlaisen kilpailun putkassa näkisin, kun en ole täällä vielä noiden edellisten aikoihin pyörinyt. Itseäni ei kuitenkaan hirveästi minkään tulkin teko innosta, jos ei sitten jotain erityistä koukkua siihen keksitä.

Mieluummin ottaisin osaa vaikka jonkinlaiseen tekoälykisaan, jossa sitten osallistujien suorituksia voi helposti testata peluuttamalla niitä vastakkain. Ei sitten tarvitse kenenkään olla mitään taiteellisia ansioitakaan arvostelemassa. Pelillä ei niin väliä olisi, vaikka olisi sitten se perinenteinen kivi-paperi-sakset (muistelen jossakin törmänneeni tuollaiseenkin). Voihan sääntöihin aina keksiä jotain lisämuutoksia tai porsaanreikiä, jotka tekevät kisasta ihan omanlaisensa.

Miten kivi-paperi-sakset pelissä voi tehdä tekoälypelaajan? Satunnaisesti arpomalla päästään 50% voitto-osuuteen. Ainoa keino päästä parempaan on pelata jotain sellaista huonosti toteutettua pelaajaa vastaan, joka ei pelaa satunnaisesti ja analysoida sen pelityyliä löytääkseen toistuvia kuvioita. KPS ei ole mikään taitopeli, vaan idealtaan puhtaasti arvonta.

Ihmispelaajien kesken voi sentään käyttää psykologisia keinoja.

Siis tuon kps:n heitin vain tuohon, eikä ollut mikään vakava ehdotus. Tosihan on, että kovin monipuolisia tekoälyjä siihen tuskin kannattaa kehitellä jos on toisia tekoälyjä vastaan tarkoitus pelailla. Pelkkä satunnaislukufunkio riittää. Sinällään huono heitto siis.

Täytyy pohtia, jos ihan jonkun vakavamman ehdotuksen aiheesta keksisi vielä.

Othello (reversi) voisi olla mukava, koska se on ainakin mielestäni hiukan monipuolisempi, kuin perinteinen risti-nolla. Kohtuullisen tekoälyn saa aikaan aika nopeastikin, jolla saa aina sille hetkelle parhaan siirron laskettua.

Tunnetuissa peleissä (othello, go, shakki) ongelma on että niihin on kehitetty jo paljon hyviä algoritmeja (ja toteutuksia)... Sinänsä ikävä jos voittaja on pelkkä copy-paste.

Joskus itse olen miettinyt että olisi mielenkiintoista antaa kilpailulle aiheeksi jokin mille on oikea kysyntä, jokin hyötysovellus yksinkertaiseen ongelmaan vaikka. Voittaja voitaisiin sitten vaikka äänestää (tai valita raati), ja arvionnissa käytettäisiin kriteereinä mm. käytettävyyttä ja teknistä laatua. Osallistua voisi sitten joko yksin tai ryhmissä.

Grez kirjoitti:

Miten kivi-paperi-sakset pelissä voi tehdä tekoälypelaajan? Satunnaisesti arpomalla päästään 50% voitto-osuuteen. Ainoa keino päästä parempaan on pelata jotain sellaista huonosti toteutettua pelaajaa vastaan, joka ei pelaa satunnaisesti ja analysoida sen pelityyliä löytääkseen toistuvia kuvioita. KPS ei ole mikään taitopeli, vaan idealtaan puhtaasti arvonta.

Ihmispelaajien kesken voi sentään käyttää psykologisia keinoja.

http://www.cs.ualberta.ca/~darse/rsb-results1.html

KPS on oikeasti vaikea ongelma tekoälyille. Siinä pitää yrittää analysoida vastustajan kuvioita ja samalla yrittää itse välttää mahdollisimman paljon omaa arvattavuutta. Triviaalinen täysin satunnaisesti toimiva teköäly voi päästä vain 50% voittosuhteeseen, joten nämä sijoittuvat kps kilpailuissa aina suunnilleen puoleen väliin.

No joo, onhan tuokin totta. Saahan tuosta tosiaan ihan mielenkiintoisen kisan, varsinkin kun tehdään juuri noin kuin tuolla, että pistetään 10 dummybottia mukaan. Näin voi olla lähes varma että pääsee parempaan kuin 50% tulokseen jos yrittää havaita kuvioita ja reagoida.

Normaalisti putkan kisoissa ei ole saatu vastustajista paljon infoa. Tällä kertaa olisi kiva jos saisi tallentaa omiin tiedostoihin tavaraa pelien aikana ja kerätä näin vastustajista mahdollisimman paljon infoa. Näin saataisiin vähän lisää haastetta kehiin. Tällöin paremmin voisi pärjätä jos tekee 2 tai 3 algoritmia joita vaihtelee satunnaisesti pelin aikana, jotta toiset tekoälyt eivät pääsisi perille siirroistasi.

Jos kilpailussa tarkoituksena on valmistaa tekoäly, ehdotan että peli olisi jokin kilpailua varten tehty. Tämä siitä syystä, että lähes kaikkiin nykyisiin matalamman tason peleihin on jo olemassa lähes täydelliset tekoälyt. Peli voisi toki olla myös variaatio tai yhdistelmä joistakin peleistä.

Ohjelmalle voitaisiin myös asettaa suorittamisaika, jolloin koodin optimoinnilla saisi parempaa tulosta aikaan.

Idea vastustajan antamien ifojen lukemisesta on varsin mainio. Vastustajien lukutaitohan on lähes tärkein taito, jos vähänkin alkaa tosissaan harjoittelemaan jonkin pelin pelaamista pitää osata vastata erilaisten pelityylien edustajien siirtoihin.

Vaihtelua näihin perinteisiin älypeliälyihin voisi tuoda tekoäly muun tyyppiseen peliin. (Loogista, eikö?) Luulenpa, että jokin tietokonepeliä muistuttava kiinnostaisi monia sellaisia aloittelijoita, joille liian sofistikoituneet pelit ovat ylivoimainen ongelma. Älypelejä pääsee tutkimaan hyvin myös OP:n ulkopuolella, kun taas muihin peleihin törmää yleensä vain, jos niitä itse kehittää. Ei-triviaaleissa älypeliongelmissa vaaditaan sekä runsaasti älliä että hyvät algoritmiset ohjelmointitaidot, siis aika paljon. Minusta sivuston ajatukseen kuuluu, että jokaisella pitäisi olla mahdollisuus päästä nauttimaan ohjelmoinnista, vaikkei oma ratkaisu voittoon yltäisikään.

Miten olisi hippa?

Metabolix kirjoitti:

Miten olisi hippa?

Se olisi ainakin "erikoisempi" tällaisissa kilpailuissa, mutta jotenkin tuntuu siltä, että sitä pitäisi vähän monimutkaistaa: jos yksi on hippa, sen vältteleminen on todella helppoa (siis mikäli ymmärsin että tämä toteutettaisiin niin, että pelialue on ruudukko, yhteen ruutuun mahtuu yhden tekoälyn ohjaama hahmo ja liikutaan yksi ruutu kerrallaan). Eri asia on, jos on useampi hippa; Tässä tapauksessa tarvitsisi karkuun menijöiden oikeasti miettiä liikkumisiaan pitkälle eteenpäin. Eli kannatan hippaa, ja jos tehtäisiin juuri niin, että ohjelmalle suodaan yksi lokitiedosto mihin se saa tallentaa haluamiaan tietojaan haluamassaan formaatissa ja lukea sitä milloin haluaa, ja lisäksi tämä lokitiedosto erikseen annettaisiin tekoälyn kehittäjälle. Näin saataisiin kätevästi jatkuvia turnauksia, joihin saisi kehittää omaa tekoälyään paremmaksi.

Miten olisi hipasta sellainen variaatio, jossa toimittaisiin joukkueina ja tarkoituksena olisi "koskettaa" vastuttajaa selkään. Tekoälyillä olisi tietty määrä pelaajia hallinnassa ja pelaajat "kuolisi" aina kun sitä kosketettaisiin "selkään". Kun toisella tekoälyllä ei olisi enään yhtään tai vain z kpl pelaajia jäljellä, peli loppuisi ja selviytyjä olisi voittaja.
Pelaajat olisivat yksinkertaisia palloja, joilla olisi menosuunta ja takana pieni sektori johon tulisi koskettaa. Pelialueena olisi X kertaa Y alue, jossa ei olisi seiniä, jottei niistä otettaisi turvaa. Toisten pelaajien läpi ei tietenkään oli mahdollista mennä. Mielestäni tämä voisi olla sopivan haastava, niin aloittelijoille kuin kokeneillekin. Pelissä pärjäisi jokseenkin sillä, että yrittäisi vain väistellä vastustajia, ja sitä hallitsisi hyvällä taktiikalla ja tiimipelillä.

Vähän sekavasti ehkä selitetty.

petrinm:n ehdotus näin äkkiseltään vaatii melkoisen speksaamisen, miten hahmot liikkuvat yms. yms. yms.
Jos "peli" on "ruutupohjainen" pelkällä paikallaan pyörimisellä voi väistellä suhteellisen helposti muutamaa hippaa.

Jos taas pelissä voi liikkua vapaasti, niin tuossa tarvisi tietää kaikki, kuinka nopeasti pelaajat voivat kääntyillä ja liikkua.

Hyvin speksattuna hippa tosiaan voisi olla erittäin hyvä ja ainakin originelli kisa-aihe.

Ruutupohjaiset pelit on tietty helppoja toteuttaa eikä tarvitse huolehtia kääntäjien eroista kun lasketaan sinillä ja cosinilla (mikäli niitä edes on ollenkaan?). Mutta ruututyyliset laskemiset suosii tuttuja reitinhakualgoritmeja eikä tuollainen hippa olisi ongelma eikä mikään saada kiinni, ainakaan jos liikkuminen viistottain sallitaan. Jos taas ei sallita niin pelaajat saattaa jäädä ikuiseen silmukkaan ennakoimaan vasemmalle ja oikealle jne, eikä kiinni saisi ennen umpikujaa.

Eli itse antaisin botille kulman asteina ja koordinaatit, kumpikin kuitenkin kokonaislukuina.

Joku voisi ensin tehdä verkkopohjaisesti toimivan Ufohippa3:n ( eli modernisoidun version ufohippa2:sta http://www.suomipelit.com/index.php?c­=peliarvostelu&id=129 ) ja sitten vaan tekoälykilpailussa rakentamaan "botteja" siihen.

Lebe80 kirjoitti:

petrinm:n ehdotus näin äkkiseltään vaatii melkoisen speksaamisen, miten hahmot liikkuvat yms. yms. yms.
Jos "peli" on "ruutupohjainen" pelkällä paikallaan pyörimisellä voi väistellä suhteellisen helposti muutamaa hippaa.

Jos taas pelissä voi liikkua vapaasti, niin tuossa tarvisi tietää kaikki, kuinka nopeasti pelaajat voivat kääntyillä ja liikkua.

Tarkoitan juurikin tälläistä vapaata liikkumista, missä olisi tietysti rajoitettu tietysti kääntymis- ja liikkumisnopeus. (En vain jaksanut kirjoittaa sitä edelliseen viestiin.)
Mielestäni valttia tässä pelissä olisi nopeus. Tekoälylle ei annettaisi kuin muutama sekuntti miettimisaikaa, jolloin pelistä tulisi sujuvampi ihmissilmälle.
Pyöriminen ei tulisi onnistumaan, jos asettaa rajoituksen kääntymisnopeuteen tai vastassa on kaksi tai useampi vastustaja.

User137 kirjoitti:

Ruutupohjaiset pelit on tietty helppoja toteuttaa eikä tarvitse huolehtia kääntäjien eroista kun lasketaan sinillä ja cosinilla (mikäli niitä edes on ollenkaan?).

Kaikki kulman laskut tekevät tästä juuri vähän haastavamman. Tämä voi tietenkin karsia ja karsii joitain aloittelijoita, mutta onhan putkassa sentään tähän liittyvä hyvä opas.

User137 kirjoitti:

Mutta ruututyyliset laskemiset suosii tuttuja reitinhakualgoritmeja eikä tuollainen hippa olisi ongelma eikä mikään saada kiinni, ainakaan jos liikkuminen viistottain sallitaan. Jos taas ei sallita niin pelaajat saattaa jäädä ikuiseen silmukkaan ennakoimaan vasemmalle ja oikealle jne, eikä kiinni saisi ennen umpikujaa.

Reitinhakualgoritmeja ei tarvita jos alueella ei ole esteitä. (jos ei sitten kierrä vastustaja hyöjkkäyksen seläntaakse) Ne aiheuttavat vain päänvaivaa, jos tarkoitukena on tehdä toimiva tiimi ja taktiikka.
Suosisin muutekin ympyröitä, koska niiden törmäystarkistus on helpoin heti ruutujen jälkeen.

User137 kirjoitti:

Eli itse antaisin botille kulman asteina ja koordinaatit, kumpikin kuitenkin kokonaislukuina.

Juurikin jotakin tälläistä. Tekoälylle annetaan alueen koko, liikumis rajoitukset ja omien ja vastustajien pelaajien sijainnit. Pelaajan sijainti sisältäisi kulman johon pelaaja katsoo ja xy-kordinaatit.
Tekoäly pelauttaisi sitten omien pelaajien liikkeet eli z-asteen käännös x-pistettä eteenpäin.

Kaiken lisäksi peli voisi toimia niin "realiaikaisena" kuin vuoropohjaisena ja kentälle voitaisiin mahduttaa useampia pelaajia, mutta turhiin monimutkaisuuksiin ei ole syytä sortua. Yksikin lisäominaisuus vaikeuttaa tekoälyn tekemistä!

Ongelmia pelissä syntyy varmaan reulusti. Muun muassa pattitilanteet ovat hyvin todennäköisiä, jos taistelu on kutistuntu yksi vastaan yksi taisteluksi. Ehdotuksi?

Nyt seuraa toteutusehdotus.

Pelin säännöt:

Pelialue on ruudukko, jossa ruutu on lattiaa tai seinää. Liikkuminen tapahtuu aina suoraan viereiseen ruutuun, ja kiinni jää, kun joutuu samaan ruutuun hipan kanssa. Muissa tilanteissa nappulat eivät voi liikkua toistensa läpi. Kaikki nappulat liikkuvat samaan aikaan.

Kilpailujärjestely:

Tekoälyt pelaavat kaksittain. Kummallakin tekoälyllä on muutama nappula ohjattavanaan, esimerkiksi kolme. Toinen älyistä on hippa, ja pelissä lasketaan, montako siirtoa kuluu kaikkien vastustajan nappuloiden kiinni saamiseen. (Pelille asetetaan myös jokin maksimipituus.) Joka ottelusta saa pisteitä sitä enemmän, mitä nopeammin ja mitä enemmän vastustajia nappasi. Samat älyt pelaavat aina muutaman ottelun, esimerkiksi kolme, ja tänä aikana kerätyt tiedot ovat tekoälyn käytössä joka vuorolla.

Kilpailusta voi tehdä perinteisen, jossa joka siirtoa saa miettiä sekunnin tai pari, tai reaaliaikaisen. Reaaliaikaisessa versiossa ohjelma voisi vaikkapa lukea syötetiedostoa, johon hallinnointiohjelma kirjoittaa uuden pelitilanteen aina, kun se muuttuu. Tekoälyn nappulat jatkaisivat liikettään aina samaan suuntaan, kunnes tekoäly kirjoittaisi tulostetiedostoonsa uuden liikesuunnan. Voisi siis käydä myös niin, että älyn miettiessä kuluisi useampi pelikierros, eli älyn pitäisi älytä lukea tiedostosta kaikki sinne ilmestyneet uudet syötteet. (TCP/IP ei ole lainkaan välttämätön toteutustapa reaaliaikaiselle systeemille.)

Jos Antti on liian kiireinen järjestämään kilpailua, voin ehkä itse lupautua järjestäjäksi. Vaatimuksena tosin olisi tällöin, että tekoälyn pitäisi toimia suhteellisen vaivattomasti Linuxilla, mikä sinänsä ei liene kovin paljon vaadittu mutta voi joidenkin Microsoftin kielten kanssa aiheuttaa ongelmia.

Metabolix kirjoitti:

Nyt seuraa toteutusehdotus.

Kannatan tällaisia sääntöjä, mutta silti, mitä jos se toteutettaisiin tcp/ip:llä? Silloin reaaliaikainen toteutus olisi todennäköisesti varmemmin toimivaa. Tämä tehtäisiin niin, että yhden siirron aika on esim. sekunti, joka alkaa kun molemmille ohjelmille "pelinjohtajana" toimiva ohjelma on ilmoittanut tiedot nappuloiden sijainnista, ja päättyy tasan sekunti sen jälkeen. Tässä ajassa pelaavien ohjelmien on täytynyt ilmoittaa toimintansa, tai ohjelman tulkitaan olevansa haluamaton siirtoihin. Sen jälkeen "pelinjohtaja" laskee siirrot, katsoo mitä tapahtuu, ja uusi siirtokierros alkaa alusta.

No en kyllä näe, miten tcp/ip toteutus olisi "varmemmin toimivaa" mutta olisihan se elegantimpaa jos eri softia ajetaan eri koneilla. Jos taas samalla koneella niin eikö olisi järkevämpää käyttää vaikka nimettyjä putkia kuin tiedostoja.

Grez kirjoitti:

No en kyllä näe, miten tcp/ip toteutus olisi "varmemmin toimivaa" mutta olisihan se elegantimpaa jos eri softia ajetaan eri koneilla. Jos taas samalla koneella niin eikö olisi järkevämpää käyttää vaikka nimettyjä putkia kuin tiedostoja.

No joo, ei se ehkä kovin varmempaa olekaan, mutta jotenkin tuntuu siltä että parempi olisi tcp/ip:llä, sillä en toki täydellistä estettä itsekään tiedostojen käyttämiselle näe.

ei tuo tcp/ip vaakuuta, sillä jos oletetaan että se sekunti lasketaan siitä kun keskusäly kirjoittaa uuden pelitilanteen, niin sekunti on jo kulunut kun vastustaja saa tiedon..
ja sitten kun netti alkaa pätkiä, niin homma vähän niinkus kaatunee. kai. tai sit tajusin väärin.

No kyllä ainakin lokaalikoneella tcp-paketit viuhahtelee aika paljon nopeammin. (Testasin pienellä VB6 softalla jossa oli kaksi softaa jotka lähettelivät vuorotellen paketteja toisilleen, eli kun toinen sai viestin toiselta, se lähetti viestin takaisin jne. 2*10000 pakettia viuhahti vähän vajaassa 3 sekunnissa.)

Mutta en silti tajua (jos on tarkoitus ajaa samalla koneella, kuten tuo tiedoston käyttö viittaisi) että miksei käytettäisi nimettyjä putkia.

Ja jos ajetaan samalla koneella, niin täytyy varmaan huolehtia että molemmat prosessit saavat yhtäläisesti CPU-aikaa yms. resursseja.

ByteMan kirjoitti:

ei tuo tcp/ip vaakuuta, sillä jos oletetaan että se sekunti lasketaan siitä kun keskusäly kirjoittaa uuden pelitilanteen, niin sekunti on jo kulunut kun vastustaja saa tiedon..
ja sitten kun netti alkaa pätkiä, niin homma vähän niinkus kaatunee. kai. tai sit tajusin väärin.

Nyt ymmärsit jotenkin väärin, ja tarkoitin nimenomaan että se tehtäisiin samalla koneella. Missä se sekunti menee että vastustaja saa tiedon? Niin, no kyllä sen ihan tiedostoillakin voi toteuttaa. :)

Jokainenko siis koodaisi kaksi tekoälyä, yhden hipalle ja toisen hippaa välttelevälle? Molemmille voisi ehkä jakaa sijat erikseen, ja osallistuja saisi päättää, osallistuuko vain yhteen vai molempiin ryhmiin. Mikä olisi pelialueen koko ja millä periaatteella seinät sijoitettaisiin?

ByteMan kirjoitti:

ei tuo tcp/ip vaakuuta, sillä jos oletetaan että se sekunti lasketaan siitä kun keskusäly kirjoittaa uuden pelitilanteen, niin sekunti on jo kulunut kun vastustaja saa tiedon..

Mitäs ne first-person shooterit käyttääkään tiedonsiirtoon...?

Blaze kirjoitti:

ByteMan kirjoitti:

ei tuo tcp/ip vaakuuta, sillä jos oletetaan että se sekunti lasketaan siitä kun keskusäly kirjoittaa uuden pelitilanteen, niin sekunti on jo kulunut kun vastustaja saa tiedon..

Mitäs ne first-person shooterit käyttääkään tiedonsiirtoon...?

Yleensä UDP:tä mikäli olen ymmärtänyt oikein :).

Tosin ei TCP/IP:ssäkään mitään vikaa ole. TCP yhteyden muodostamiseen tarvittava molemminpuolinen kättely saattaa tosin viedä varsin kauan, jos latenssi on 100 ms luokkaa. Tämän tyyppisessä tilanteessa kuitenkin tcp-putki avataan jokaiseen tekoälyyn vain kerran, ja sen jälkeen keskustelu on aivan riittävän nopeaa lokaalikoneella, kun yhteyksiä pidetään jatkuvasti auki.

FooBat kirjoitti:

Blaze kirjoitti:

ByteMan kirjoitti:

ei tuo tcp/ip vaakuuta, sillä jos oletetaan että se sekunti lasketaan siitä kun keskusäly kirjoittaa uuden pelitilanteen, niin sekunti on jo kulunut kun vastustaja saa tiedon..

Mitäs ne first-person shooterit käyttääkään tiedonsiirtoon...?

Yleensä UDP:tä mikäli olen ymmärtänyt oikein :).

löytyykös tälle todisteita? Kaikki ne harvat netin yli pelattavat fps:t joita olen kokeillut, ovat toimineet. Tämä taas tarkoittaa sitä, että peli ei käytä ainakaan udp:tä, koska se ei meillä olevan natin takia toimi kuin ulospäin.

Jätkät, jätkät, nyt menee kyllä termit hieman sekaisin.

tgunner kirjoitti:

Jätkät, jätkät, nyt menee kyllä termit hieman sekaisin.

Älä sitten selvitä sotkua.

Harvinaisen natsi NAT jos ei tue lainkaan kaksisuuntaista UDP:tä.

Esimerkiksi Counter Strike vaatii mahdollisuuden UDP portteihin 27010, 7002 ja 27105 lähettyjen pakettien paluupaketteihin. Lisäksi NATin takana mahdollisesti oleville koneille pitää määrittää eri client-portit (27000, 27001 jne)

Grez kirjoitti:

Harvinaisen natsi NAT jos ei tue lainkaan kaksisuuntaista UDP:tä.

Esimerkiksi Counter Strike vaatii mahdollisuuden UDP portteihin 27010, 7002 ja 27105 lähettyjen pakettien paluupaketteihin. Lisäksi NATin takana mahdollisesti oleville koneille pitää määrittää eri client-portit (27000, 27001 jne)

hetkinen... Joko olen käsittänyt udp:n väärin tai sinä olet hakoteillä. Ei udp:ssä mitään paluupaketteja tcp:n tapaan ole! Siinä molemmat toimivat sekä clienttina että serverinä (olettaen että tietoa halutaan liikuttaa molempiin suuntiin). Tämä taas luonnollisesti aiheuttaa sen, että se ei toimi natilla muuta kuin ulospäin.

Jos lähetät portista 7654 UDP paketin koneen 123.45.67.89 porttiin 5678, niin sen jälkeen tietyn ajan kuluessa koneelta 123.45.67.89 portista 5678 porttiisi 7654 tulevien UDP-pakettien katsotaan yleensä olevan "paluupaketteja". Vaikka protokolla itsessään on tilaton, niin mikään ei estä palomuuria tai NATia pitämään kirjaa tuollaisista asioista.

Kannattaa tutustua aiheeseen.

Grez kirjoitti:

Jos lähetät portista 7654 UDP paketin koneen 123.45.67.89 porttiin 5678, niin sen jälkeen tietyn ajan kuluessa koneelta 123.45.67.89 portista 5678 porttiisi 7654 tulevien UDP-pakettien katsotaan yleensä olevan "paluupaketteja". Vaikka protokolla itsessään on tilaton, niin mikään ei estä palomuuria tai NATia pitämään kirjaa tuollaisista asioista.

Kannattaa tutustua aiheeseen.

Mitenkäs homma toimii sitten seuraavanlaisessa tilanteessa? Minulla on kaksi konetta natin takana ja kumpikin on "yhteydessä" natin ulkopuolella olevaan "serveriin" UDP-protokollan välityksellä ja sattumoisin kumpikin kone lähettää viestinsä serverille portista 4321 (ip on tietty kummallakin se sama(vaikka 123.45.67.89), joka näkyy natin ulkopuoliseen verkkoon). Nyt serverin pitäisi lähettää "paluupaketti" kummallekin. No, serveri lähettää ne, mutta kummankin osoite on 123.45.67.89:4321. Mistä natti pystyy päättelemään, kummalle kukin paketti pitäisi lähettää?

Kyllä se taitaa olla niin, että tiettyyn porttii osoitetut paketit pitää aina ohjata natilta tietylle koneelle. Toinen vaihtoehto on tietty ohjata kaikki natille tulevat viestit jollekin tietylle koneelle, mutta silloinhan tilanne on sama, kuin nattia ei olisikaan.

Edit; Yhtä kaikki, mielenkiintoinen kilpailuaihe! Tuohon täytyy osallistua, jos se saadaan järjestettyä ja aika riittää.

Siirtäkäähän tuo verkkokeskustelu jonnekin muualle, eikös? :)

TCP/IP vaatii eri kielillä erilaisia apukirjastoja, joiden käyttö ei ole aina yhtä suoraviivaista kuin tiedostojen. Tiedostot siis antavat kilpailussa paremmin tilaa itse aiheelle. Nimetty putki toimii Linuxissa samalla tavalla kuin tiedosto, mutta Windowissa se kai vaatii jotain erikoisempaa. Ongelmana taitaa myös olla, että datan lukeminen blokkaa ohjelman, kunnes dataa on saatavilla. Tämän voi toki kiertää mutta Linuxin ja Windowsin eroja ei. Oikaiskaa toki, jos Windowsillakin voi käyttää putkia normaaleilla tiedostofunktioilla.

Gaxx kirjoitti:

Kyllä se taitaa olla niin

Jep jep, mutulla on hyvä mennä.

Metabolix kirjoitti:

Siirtäkäähän tuo verkkokeskustelu jonnekin muualle, eikös? :)

Valitettavasti ei ole modaraattorin oikeuksia, enkä tiedä pystyykö tässä muutenkaan splittaamaan ketjua kahdeksi.

Metabolix kirjoitti:

Nimetty putki toimii Linuxissa samalla tavalla kuin tiedosto, mutta Windowissa se kai vaatii jotain erikoisempaa.

No etkös muutenkin sanonut, että jos sinä järjestäisit sen, niin kilpailusoftien pitäisi toimia Linuxilla? Eikä nuo nyt Windowsissakaan kyllä mitenkään ylivoimaisia ole käyttää.

Mutta joo, ainahan filet voidaan laittaa pyörimään ramdiskissä, ja muisti on nykyään halpaa, joten joku giga tilaa ramdiskillä ei ole mikään ongelma. Sikäli siis tiedostot voi olla myös ihan toimiva vaihtoehto "reaaliaikaisellekin" pelille.

Noh.. on se mahdollista vääntää toinen ohjelma joka luo yhteyden, käskee tekoälyn käynnistyä tarkkaillen ajastimella tietyn tiedoston olemassaoloa, ja kun se löytyy niin lukee siitä pelitiedon ja välittää TCP yli. Toisinsanoen mahdollistaisi TCP yhteyden tekoälyille jotka toimii tiedostopohjaisella systeemillä, henkilöille jotka eivät TCP:n päälle muuten ymmärrä tai halua tutustua.

Edit: Mutta toisaalta jos suurin osa käyttäisi tätä välitintä se tuhoaisi koko idean samalla koneella ajettavan testauksen eduista TCP:llä. Riippuu miten se kisa järjestetään ja onko halua/keinoja kontrolloida netin yli tapahtuvia kisoja.

Grez kirjoitti:

Gaxx kirjoitti:

Kyllä se taitaa olla niin

Jep jep, mutulla on hyvä mennä.

Mitäs sinun puheesi sitten ovat? :)

Mutta joo, kyllähän se putkillakin käy, aihe olisi hyvä, ja itse ainakin vääntäisin jonkinlaisen raakileen tällaiseen kilpailuun. :)
Edit: oho, olit vastannut tuohon ekaan kysymykseeni toisessa thredissa, eipä mitään.

Voisi sitä kyllä vaihteeksi tehdä kilpailun, jossa käytettäisiin TCP:tä tiedon siirtoon. Tämä myös nopeuttaisi ohjelmien ajoa ja sallisi ohjelmien pitää kirjaa edellisistä vuoroista, koska ohjelma olisi koko ajan päällä (tiedon liikuttaminen tcp:n yli käynnissä olevaan ohjelmaan on paljon nopeampaa kuin tiedostoon kirjoitus/ohjelman käytnnistys/tiedoston luku/vastauksen kirjoitus tiedostoon/ohjelman sammuminen/vastauksen lukeminen testiohjelmaan.). Niitä varten, jotka ovat harrastaneet vähemmän nettiohjemointia voitaisiin tietysti tehdä valmiiksi yksinkertainen ohjelmarunko, joka hoitaa vastausten lähetyksen ja muun verkkoliikenteen. Ohjelmarunkoja ei tietysti voida tehdä aivan kaikilla kielillä, mutta luulisin, että yleisimmät kielivaihtoehdot olisi mahdollista yhteistuumin toteuttaa.

FooBat kirjoitti:

Niitä varten, jotka ovat harrastaneet vähemmän nettiohjemointia voitaisiin tietysti tehdä valmiiksi yksinkertainen ohjelmarunko, joka hoitaa vastausten lähetyksen ja muun verkkoliikenteen. Ohjelmarunkoja ei tietysti voida tehdä aivan kaikilla kielillä, mutta luulisin, että yleisimmät kielivaihtoehdot olisi mahdollista yhteistuumin toteuttaa.

Tuollaiset kyllä varmasti madaltaisivat sitä rajaa osallistua, kun tarjotaan valmis runko, jotta ei tarvitse niitä socketteja vain yhtä kisaa varten alkaa opettelemaan. Tuollaisen valmiin rungon tekeminen olisi iso homma varmastikaan jollekin putkan osaajista. Joku pieni kirjasto/moduuli/mikähyvänäsä, joka tarjoillee kivoja lähetäVastaus, avaaPeli ja muita tarpeellisia funktioita.

Samoinhan voisi tehdä myös tiedostojen kanssa toimittaessa, että yleisimmille kielille tarjoillaan valmista koodia siihen tiedosto käpistelyyn pelin vaatimalla tavalla, jos jotain monimutkasempaa tulee.

Ainakin Linuxissa "verkkorajapinta" on helppo toteuttaa netcat-ohjelmalla. GNU netcat osaa ottaa TCP- tai UDP-yhteyden annettuun palvelimeen ja porttiin ja käynnistää sitten ohjelman niin, että sen standardivirrat on yhdistetty konsolin sijaan tähän verkkoyhteyteen. Ohjelma itse voi toimia kuin normaali komentoriviohjelma. Vastaavan ratkaisun voisi luultavasti kehittää myös Windowsille, ellei sellaista vielä ole. Näitä hienoja keksintöjä odotellessa ainakin seuraava kilpailu kuitenkin käyttää vielä tiedostoja.

Metabolix kirjoitti:

TCP/IP vaatii eri kielillä erilaisia apukirjastoja, joiden käyttö ei ole aina yhtä suoraviivaista kuin tiedostojen.

Socketit ja select ;) Lähes samanlainen, yksinkertainen, syntaxi sekä winsockille että posix socketeille, eikä pakko blokata.

Kirjoittaa Hello world mahdollisimman monella tavalla... voit itse päättää kielen jolla voi tehdä sen mahdollisimman monella tavalla

ruby esimerkki :

1.puts "Hello world"
2.A=hello
B=world
puts "hello world"

DancingDevil kirjoitti:

Kirjoittaa Hello world mahdollisimman monella tavalla... voit itse päättää kielen jolla voi tehdä sen mahdollisimman monella tavalla

ruby esimerkki :

1.puts "Hello world"
2.A=hello
B=world
puts "hello world"

Google ftw

DancingDevil kirjoitti:

ruby esimerkki :

1.puts "Hello world"
2.A=hello
B=world
puts "hello world"

Mikäs idea tässä 2. esimerkissä on? Tässä samalla tyylillä 3. esimerkki:

A=menen
B=paskalle
puts "hello world"

Aika älyttömän tuntuinen kilpailu, kun tuon voi kirjoittaa millä vaan kielellä äärettömän monella, toinen toistaan vähäjärkisemmällä tavalla. Tai siis, tietysti jos kilpaillaan eri tapojen esteettisyydestä, taiteellisuudesta, kekseliäisyydestä yms, niin sitten voi olla jotain järkeä toisin kuin ihan vaan määrästä kilpailussa.

Silti pitäisin järkevänä kilpailua jonka voittaja voitaisiin ratkaista ennalta määriteltyjen yksiselitteisten kriteerien perusteella.

Grez kirjoitti:

Aika älyttömän tuntuinen kilpailu, kun tuon voi kirjoittaa millä vaan kielellä äärettömän monella, toinen toistaan vähäjärkisemmällä tavalla. Tai siis, tietysti jos kilpaillaan eri tapojen esteettisyydestä, taiteellisuudesta, kekseliäisyydestä yms, niin sitten voi olla jotain järkeä toisin kuin ihan vaan määrästä kilpailussa.

Tällaisen kilpailun muistan nähneeni:

Kirjoita koodia joka toimii, mutta näyttää hyvältä. Tällaisen vääntelin esimerkiksi: http://sooda.dy.fi/paste/?9ai&plainpaste

ville-v kirjoitti:

Kirjoita koodia joka toimii, mutta näyttää hyvältä.

Törmäsin tollasiin joskus, aika hurjia: http://uguu.org/sources.html

Miten olisi kisa, jossa kaksi matoa pelaavat suorakulmiokentällä vastakkain, ja se voittaa, joka pakottaa toisen ensiksi törmäämään johonkin jo varattuun ruutuun? Vastaa esim. KDE:n KTron-peliä.

Itse tein joskus monta vuotta sitten sellaisen (kaksinpelinä) ja kaverini tykkäsivät siitä. :)

Itsekin olen semmosen tehnyt. Omassa versiossa pystyi napin painalluksella kiihdyttämään oman ja kaverin madon vauhtia.

Tämä voisi toimia pelinä. Jokainen saisi toimittaa myös kenttiä ja esineet ovat ennalta sovittuja. Tässä ei peritaatteesa riitä pelkkä reitinhakualgoritmi vaan on osattava ennakoida mitä toinen yrittää. Tämänhän ei tarvitse olla reaaliaikainen vaan ihan isolla ruudukolla toimii. Pelissä voisi olla myös erinlaista maastoa esim suo hidastaa ja asvaltti nopeuttaa. http://www.arcade.fi/peli/maze-stopper-2.html

Mites, onko tässä nyt jonkinlaista kilpailua syntymässä vai jääkö vain keskustelun tasolle? Ilmeisesti kuitenkin kiinnostuneita löytyisi, aihe näköjään taas pulmallinen.

Niin, itse en ole vielä täällä minkään kilpailun aikaan putkaviisuja lukuunottamatta pyörinyt. Yksi aihe olisi myöskin tuon älykkään ohjelman tekokilpailun uusi järjestäminen, sekin kiinnostaisi.

Kilpailu tulee, kunhan järjestelyt saadaan hoidettua ja säännöt hiottua kuntoon.

Mukava kuulla, että homma etenee ja löytyy henkilöitä järjestemään kisailua. Kiitos siitä.

Ja minä kun olen odottanut että tulisi joulupeli kilpailu.

efteri kirjoitti:

Ja minä kun olen odottanut että tulisi joulupeli kilpailu.

Paremminkin joulukoodi, kun ohjelmointiputkassa ollaan.

Metabolix kirjoitti:

Kilpailu tulee, kunhan järjestelyt saadaan hoidettua ja säännöt hiottua kuntoon.

Kauankohan tähän menee?

Ju ois kiva jos kilailu tulis... :P

Hoputtamalla ei yleensä saa mitään aikaan. Joitakin jatkuva hoputtaminen saattaa jopa ärsyttää ja motivaatio saattaa lopahtaa. Sääntöjen hiomisessa menee varmasti aikaa ja jos Metabolix on jotain luvannut järjestää, hän varmaan sen järjestää. Se tulee sitten kun on sen aika.

Juu, en mää ainakaan ole hoputtanut, eli sori jos ootte niin ymmärtäneet. :P

Arkistoidaan tämä ketju ja kilpailun päättymisen jälkeen nappastaan permbanni kaikille, jotka hoputti, eikä sitten osallistunu ;P

sainpa kumman ajatuksen:
kilpailu siitä, kuka tekee parhaan merkki/askiigrafiikkaa ainoastaan käyttävän demon =P
ainoa rajoitus siis olisi, et yksi- tai monivärisistä merkeistä koottas tarvittavat kuvat yms.
en sit tiiä, kommenttia

edit:: toi monivärisyys vähän niinku riippuu siitä et kuinka paljon sitä joustaa et pitääkö pyöriä konsolissa ymz

Tossa on selvä voittaja: http://www.asciimation.co.nz/ :D