Keskustelu: Ohjelmointiputka: Kilpailuista

Yli kolmen kuukauden jälkeen alkaa palikkapelikilpailu olla lopussa, ja kaikki kilpailuun osallistuneet pelit ovat kopioitavissa kilpailusivulla. Kärkikuusikon ulkopuolelle jäi monia mainioita pelejä, joiden kokeileminen on nyt siis mahdollista. Kiitokset kaikille kilpailun osanottajille sekä äänestäjille!

Nyt on myös hyvä tilaisuus puhua tulevista kilpailuista. Toinen suurempi, yhteinen kilpailu Suomipelit.comin kanssa on hyvin todennäköinen jossain vaiheessa, kenties kesällä. Tämän lisäksi olen kuitenkin ajatellut, että voisi olla hauskaa järjestää myös pienempiä kilpailuja esimerkiksi noin kuukauden välein. Joitakin aihe-ehdotuksia:

* Tietyyn aiheeseen liittyvä PHP-skripti
(https://www.ohjelmointiputka.net/keskustelu/4034-ohjelmoi-palikkascripti)

* QBasic-demo, joka täytyy toteuttaa QB:n omilla komennoilla ilman konekieltä tai apukirjastoja.

* Tekoäly johonkin peliin. Esimerkiksi ristinollakilpailu, jossa osallistuvat tekoälyt laitetaan pelaamaan toisiaan vastaan - kone vastaan kone!

* Algoritmitehtävä tyyliin Datatähti-kilpailut

Tällaisissa kilpailuissa etuna olisi se, että pieniä kilpailuja olisi usein, minkä vuoksi ei haittaisi, vaikka johonkin ei ehtisi mukaan tai aihe ei olisi mieluinen. Siksi erikoisemmatkin aiheet olisivat mahdollisia. Rahallisia palkintoja ei näihin pikkukilpailuihin ole tulossa, mutta en usko, että ne ovat onnistuneen kilpailun ehto.

Kertokaa toki, mitä olette mieltä edelläolevasta!

No kaikki muut ovat hyviä, mutta tuo viimeinen ei. Minun puolestani tälläinen kilpailu pitäisi järjestää pian sillä jäi todellakin närkästyttämään tuo palikkapeli.

Olisihan se mukavaa että pieniä kilpailuja järjestettäisi... koska kokoajan oppii jotain uutta niin ei haittaa jos joku kisa jää valistä

Qbasic demo voisi olla hyvä. kun muita kieliä en kunnolla osaa.

jotai pikkukisoja... ja helpohkoja tehtäviä et voisin mäkii osallistua :D

Mielenkiintoisiahan noi on, algoritmitehtävät myös. Esim. "Toteuta nopeimmalla mahdollisella algoritmillä tämä tehtävä.."
QB -demokisa vois olla myös ihan mielenkiintoisia, näkisi minkätasoinen QB-scene on :)

QB ja PHP... miksei joskus VB ja C++? Ainoat joihin noista voision osallistua on 2 viimeistä.

PHP:tä en osaa, mutta kolme viimeistä kävisivät hyvin. QB-demo on helppo toteuttaa, mutta eikö siinä pitäisi olla joku raja, että millaiset laitevaatimukset demoilla on? Ei muuten, mutta demon tasoa täytyy karsia aika paljon, jos sen täytyy toimia vaikka 400MHz koneella. Kilpailusta ei tulisi erityisen reilu, jos jotkut demot olisi sovitettu 3GHz koneille, kun toiset toimisivat jo alle Gigahertsin koneilla.

[PS] Olisi hyvä, jos kilpailusivuilla olisi screenshotit kaikista peleistä

lainaus:

QB ja PHP... miksei joskus VB ja C++?

Tuossa oli vain pari ehdotusta, muitakin aiheita saa toki ehdottaa. :)

Järjestäkää vaikka ensi viikolla tai huomenna jokin noista aiheista. Rahallisia palkintoja ei tarvitse olla. Maine ja kunnia riittää :D.

Voisin kokeilla ensimmäiseen osallistumista, ja toiseen voisin osallistua kunhan löydän jonkun tavan miten saan dos-ohjelmat toimimaan tällä koneella :P
Pitäisköhän asentaa MS-DOS tähän =D

Tämähän vasta olisi mukavaa, jos järjestettäisiin isompien kilpailujen ohella useita pieniä. :D
Joitain Data-tähden tyyppisiäkin voisi olla. Onnistuin ratkaisemaan viimekertaisen Data-tähden "mikropiirin tarkistan", mutta en voinut osallistua, kun en saanut toista valmiiksi, enkä tiennyt vastauksia muihin kysymyksiin, ja lisäksi koodasin QB:llä, joka ei ollut sallittua.

Jee! Asiaa! Olisi aika siistiä jos olisi tyyliin kuukauden välein jotain pikkukisoja...

lainaus:

QB -demokisa vois olla myös ihan mielenkiintoisia, näkisi minkätasoinen QB-scene on :)

Jees :P jos nyt qb:llä jotain tehokasta saa :D

lainaus:

Rahallisia palkintoja ei tarvitse olla. Maine ja kunnia riittää :D.

Nimenomaan :D
mikä toi datatähden idea nyt oli, olen kuullut siitä monesti mutten tiedä siitä suunnilleen yhtään?

ei lol, vähän nää nauruhymiöt(":D") näyttää hassulta :D

jos olisi vaikka kuukausittain kisa, jossa olisi ainakin viisi (5) sarjaa, vaikkapa kielet VB, QB, PHP, C++ (C++ ja C voisi olla samassa sarjassa) ja muut

ja sitten voisi vaikka joka kuukausi (tai joka toinen jne.) nimetä parhaiten tehdyn Kotisivun PHP-kielellä.

lainaus:

ei lol, vähän nää nauruhymiöt(":D") näyttää hassulta :D

Verdana fontilla näyttäisi paremmilta omasta mielestäni, ei olisi tommosia litteitä jos olis putkassa Verdana

ADD: Eikös kilpailulle voisi tehdä ihan oman keskustelualueen kun porukka näyttää olevan aika innokkaita kilpailuiden suhteen?

lainaus:

mikä toi datatähden idea nyt oli, olen kuullut siitä monesti mutten tiedä siitä suunnilleen yhtään?

Peruskoulun ja lukion ohjelmointikilpailu, tässä on tämän vuoden tehtävät:
http://www.cs.helsinki.fi/u/mnykanen/datatahti/DTtehtavat.html

lainaus:

Eikös kilpailulle voisi tehdä ihan oman keskustelualueen kun porukka näyttää olevan aika innokkaita kilpailuiden suhteen?

Ihan hyvä idea, jos kilpailuja alkaa tulla usein ja paljon niihin liittyviä viestejä.

Alue olisi kyllä ihan hyvä idea. Semmoinen voisi minun puolestani tulla :).

Joo kannatan samaten omaa aluetta kilpailuille.

Tuosta osoitteesta
http://www.cs.helsinki.fi/u/mnykanen/datatahti/DTtehtavat.html
minkä Antti laittoi, löytyy tosiaan vuoden tehtävät. Mutta se kilpailuaikahan oikeastaan päättyi jo. Ajattelin, että jos lukiossa sitten yrittäisin uudelleen. Riippuen tietysti tehtävistä. Se "mikropiirin testaaja" mikä oli yksi noista tehtävistä oli aika helppo, mutta sitä "Siperian lyhimmän tien etsijää" en saanut tehtyä.

Toivottavasti saadaan pian jonkinlainen kilpailu. Tuo QB-demo voisi olla aluksi hyvä.

Tietysti pitää asettaa säännöksi, ettei demoon saa kopioida toisten tekemiä koodivinkkejä, ja että se olisi hyvä aloittaa vasta sitten, kun/jos kilpailu alkaa.

Joku tekoälykilpa olis varmaa aika hauska jossain ristinollassa.
Mutta, miten tälläinen peli sitten toteutettaisiin? Tehdään ensin pelin runko, ja siihen jokainen saa tehdä oman tekoäly-scriptinsä?

lainaus:

ei lol, vähän nää nauruhymiöt(":D") näyttää hassulta :D

Vetäny sienii taas vai..? :)

Kannatetaan aluetta. Mutta voisko olla myös joku aloittelija-sarja jonne laitettas jotakin tyyliin: peli aiheena (ei palikka koska sehän oli just) vaikka roolipeli. Ja palkintoja ei tarvitte. Pääasiahan on, että on kivaa ja oppii koodaamaan!

Aloittelija sarja ja muitakii ku pelejä...

Jeps kukkuu. Huomenna alkaa maaliskuu, joten ehdottaisin kilpailun aloittamista silloin, niin olisi koko kuukausi aikaa tehdä sitä demopelidatatähtiphpskripti juttua loppuun. Jonkin äänestyksen voisi laittaa. Tai sitten järjestetän äänestys tässä.
Datatähti kilpailu: kirjoittakaa 1
QB demo: kirjoittakaaa 2
PHP skripti: kirjoittakaa 3
Teköäly: kirjoittakaa 4

123(4).

lainaus:

Vetäny sienii taas vai..? :)

en, puolukoita kylläkin... xD

Sooda: Valitse yksi!

Njääh :D no yksi(1) :P

php scripti-kilpailu olis ihan mukava ja tuo tekoaly, kunhan opin vb:tä ja c++:ssaa

2, 3

En nyt tiedä noista pikkukilpailuista mutta suurempia voisi järjestää jopa puolen vuoden välein että Putkaan tulisi vilskettä. Tätä edeltävä matopelikilpailu järjestettiin jo 2002 kesällä niin siinä on ehkä liian pitkä väli kilpailuille. Ei minulla mitään niitä pieniä kilpailuja vastaan ole mutta tuskin osallistun niihin.

Kieli pitäs olla vapaa ku teen vb:llä...
Tekoäly ois kiva mutten osais... :D

Hyvä oiskii jos huomenna alkas uus kilpailu ku ois aikaa tehäkkii lomalla...

Joillakin alkaa vasta hiihtoloma :(. Minulla se alkoi kaksi viikkoa sitten, mutta eiköhän sitä voi arkipäivisinkin säätää jotakin peliä. Itse valitsisin 3.

2 ja 4. Jos jompi kumpi pitää valita niin 2.

lainaus:

Mutta, miten tälläinen peli sitten toteutettaisiin? Tehdään ensin pelin runko, ja siihen jokainen saa tehdä oman tekoäly-scriptinsä?

Olen ajatellut asian näin: Kilpailuun osallistuva ohjelma lukee tiedostosta pelialueen koon ja sitten jokaisen ruudun tilan (tyhjä, risti tai nolla). Sitten ohjelma kirjoittaa toiseen tiedostoon sen ruudun koordinaatit, johon oma merkki laitetaan. Tämän lisäksi tarvitaan vielä ohjelma, joka turnauksen "järjestää"; varmistaa, että ohjelman tekemä merkintä on laillinen ja ilmoittaa kunkin pelin voittajan. Kaikki tämä on mahdollista automatisoida.

lainaus:

Huomenna alkaa maaliskuu, joten ehdottaisin kilpailun aloittamista silloin

No ei nyt sentään vielä huomenna ehdi mitään alkamaan. :)

Tuo ristinolla tekoäly kuullostaa mielenkiintoseltä tehdä. Ja kielihän tossa teko älyssä oli sitten vapaa vai kuinka.?
Taidampa alkaa pian varmuuden vuoksi tekemään :)

No ei ehkä juuri huomenna, mutta mieluiten viikon sisällä :).

Mitenköhän olisi jonkinlainen kilpailu, jossa tarkoituksena olisi väsätä jokin tietokannan tapainen viritys? (esim. kunnollinen vieraskirja, melko yksinkertainen foorumi, tietokanta eri artistien kappaleista hakutoiminnoilla, jne.)

Vapaa kieli!!!

Vapaa kieli, mutta ei peliteko-ohjelmia (kirjoitetaankohan se noin ;D). Minäkin aion osalistua Visual Basicilla, jos siihen tarkoitukseen kilpailu sattuu. PHP:llä sitten, jos on skripteistä kysymys.

lainaus:

Järjestäkää vaikka ensi viikolla tai huomenna jokin noista aiheista. Rahallisia palkintoja ei tarvitse olla. Maine ja kunnia riittää :D.

Esimerkiksi voittajan kotisivulle banneri putkan etusivulta?

Edit: Ristinollaan tekoäly voisi olla hyvä! Kieli vain vapaaksi..

Visual Basicilla mä teen.
Vois olla monta kilpailusarjaa helposta vaikeaan, et aloittelijatkii vois osallistua

Mää ainakin tekisin Visual Basicilla,(mutta en ällynnyt minkä tyypinen siis pelistä olisi tultava.

Ja eikö välillä voisi tehdää muutakin kuin "Pelejä"
Kuten ohjelmia.(jos nyt tehtäisiin ohjelma kilpailu itse ehdotaisin että sitä saisisi tehdä millä tahansa ohjelmointikielellä ja se saisi olla minkä tyypinen tahansa ohjelma, voitaja ohjelmana voisi olla minun milestä se ohjelma mikä olisi kaikisata "HYÖDYLISIN".)

tuukka miten määrittelisit taas että mikä ohjelmista on hyödyllisin jos kaikki kilpailuun osallistuneet ohjelmat esim ovat täysin erilaisia tyyliin: tietokantaa, oma tulkki, piiloohjelma, simulaattori, wav-editori jne...
kaikki ovat hyödyllisiä omilla osa-alueillaan
ennemmin niin että tee hyödyllisin office ohjelma eli supistetaan koko kilpailua jotta se olisi selkeempi ja sitten se että tarkasti määriteltäisiin että minkälainen ohjelma, siis että esim: multimedia ohjelma jossa kriteerit on seuraavat: luo ohjelma joka soittaa ääntä, liikuttaa kuvaa, ja toimii analogisesti tai dynaamisesti läpi prosessin jne... mutta tuokin on huono ehdotus koska esim mulla olisi jo valmiina siihen ohjelman runko jossa voi rakennella valmiista bpm kuvista animaation ja lisätä ääntä sekaan ja omia animaatioita voi katsoa sillä ohjelmalla jne... :)
mutta itse pitäytyisin peleissä jos kilpailuista on kyse ihan sen takia että se on paljon haastavampaa ja siinä näkee todelliset ohjelmointi-taidot (en väheksy ohjelmien tekijöitä huonoiksi koodaajiksi vaan sitä tarkoitan että peliä on vain yksinkertaisesti vaikeampi rakentaa ns. yhtä hyväksi kuin ohjelma) jne... mutta on se toisinkin päin josta pääsemme seuraavaan asiaan: miksi ei olisi kilpailua jossa olisi ideana rakentaa pelin ja ohjelman sekoitus? simulaatio? jokin josta on hyötyä mutta toimii graafisena sekä interaktiivisena kokonaisuutena?
itse kokeilin tuommoista, toi on vaikeaa mutta laskee kynnystä koodaamisesta jos on kyse mutta nostaa kynnystä jos on mielikuvituksesta kyse jne...
en jaksa selittää tulisi muutes paljonkin lisää tekstiä :)

lainaus:

Esimerkiksi voittajan kotisivulle banneri putkan etusivulta?

Hyi... 1. sija ja nikki siihen alle riittää mulle :) mitää karseita bannereita jaksa kukaan kattoa

Eipä jaksaisikaan,ja no loppujen lopuksi ehkä minunkin mielestä on parepi tehdä peli kisa kuin ohjelma.

!!mutta en ällynnyt minkä tyypinen siis pelistä olisi tultava.!!

ja tuli tässä vielä mieleen semmoinen että mitä jos jokin aihe olisi rakentaa pelimoottori?
pientä vinkkiä joku rpg moottori on iha legenda juttu ja aikas helppo toteuttaakin: esine-editori, hahmo-editori, mappi-editori, kauppa-editori, dialogi-editori jne...
ja kaikki laitetaan samaa pakettiin ja rakennetaan päälle kunnon "linkitetty-runko" ja vóla se on siinä :)

ja taas joku ylhäältäpäin kuvattu tappelu/ampuma-pelin moottori (tähän kannattaa ottaa mukaan directx:ää)
esim näin: tähänkin hahmoeditori, hahmon frame-editori, bottien älykkyys-editori sekä mappi-editori ja mappi-editoriin sitten bottien "wavepoint"-järjestelmä eli se että mitä rataa mikäkin botti liikkuu ja siitä voi karkaa huspoiskin eli että staattisen radan päälle dynaaminen rata jonka ohjelma ite luo jne...
ja sitten taas joku autopeli editori (taas ylhäältäpäin kuvattu 2d)
auto-editori, mappi-editori, osa-editori jne...

ja miksi kokoaika editorieita? miksei suoraan koodaa kaikkea? pieni vinkki taas: kokeilkaa rakentaa pieni peli aluksi koodista käsin suoraan ja sen jälkeen sama proggis omien editori-työkalujen avulla...
editorit on hyödyllisiä siinä esim tuossa autopeli-editorissa kun on auto-editori siinä määritellään eri asioita:
moottori = xxx
renkaat = xxx
pito = xxx
paino = xxx
jne...
ja sama taas osa editorissa määritellään sama jne...
näin se toimii ja tällä tavoin saadaan syvyyttäkin peliin ja säästetään aikaa... mutta kaikki tekee tyylillään
meni taas näköjää hurjasti offtopikin puoleen, sori :)
mutta mopo karkas kourasta ku oli kyse pelimoottoreista :)

vaihtelu virkistäis
justha oli kilpailun aiheena pelin tekeminen
nyt sais olla vuorostaa ohjelma

Perjaatteessahan se on aivan sama mikä on aihe/peli/ohjelma kuhan kaikki tekevät samasta aiheesta..

Ja toisaalta olisi ihan mukava tällainen "pienepi" kilpailu.. osallistuminen ei välttämättä vaatisi 3kk 24/7 koodaamista vaan se onnistuisi myös koulun jälkeen..

Oli hieman harmillista huomata että palikka kilpailuun ei ehtinyt millään kunnolla osallistua.. lukio vie liiaksi aikaa.

Kannatan ehkä sitten tuota ristinolla tekoälyä.
(offtopic: Onko kukaan koskaan kuullut puhuttavan jätkänshakista?)
Tuohan olisi kätevä systeemi, mitä Antti ehdotti, että jokainen tekoäly lukee tiedostosta ja tallentaa tiedostoon. Näin kahta tekoälyä ei tarvitse yhdistää yhdeksi ohjelmaksi. Siinähän voisi tulla vaikka minkälaisia ongelmia. Jos tällainen kilpailu tulee, täytyy tietysti erikseen kertoa, mikä merkki vastaa tyhjää, ristiä, ja nollaa, että saadaan peliruudukko yhteensopivaksi kaikkien tekoälyjen kanssa. Ja tietysti pitää ilmoittaa, missä järjestyksessä tiedot ovat tiedostossa, onko ensin leveys vai korkeus, mutta kyllähän Antti tietysti tällaiset asian itsekin tajuaa. Turhaan minä sitä rupean selittämään.

lainaus:

Ja tietysti pitää ilmoittaa, missä järjestyksessä tiedot ovat tiedostossa, onko ensin leveys vai korkeus, mutta kyllähän Antti tietysti tällaiset asian itsekin tajuaa. Turhaan minä sitä rupean selittämään.

Mutta eihän sitä leveyttä tarvi ilmoittaa jos laskee vain reippaasti sen ensimmäisen rivin pituuden...? :)

NO vaikka neljä

4

Eikös c++ssalla voisi skabba olla?

loppujen lopuksi tuossa ristinolla-tekoälyssä ei ole mitään ihmeellistä. Koska tulee Älyttömästi IF-lauseita, ja koska kukaan ei halua tehdä keskeneräistä tekoälyä, (ilman sitä tuskin tulee muuta kuin tasapelejä) niin sanoisin että tämä vaihtoehto on huono.

mutta toisaalta, eihän ristinolla ole ainoa peli jossa on tekoäly. Eli kyllä tekoäly on hyvä idea. Kannatan.
Mutta jos se tehdään monellakin eri kielellä?

Eihän sitä voi vain yhdellä tehdä. Kaikilla mahdollisilla ohjelmointikielillä, kuten palikkapelissäkin, mutta ei pelinteko-ohjelmia (ääh... :D). Moottorissa on se probleema, ettei sitä osaa tehdä kovinkaan moni, paitsi jos se jaetaan 2D ja 3D pelimoottoreihin..tai no omalla tavallaanhan ne ovat melkein yhtä vaikeita toteuttaa. No tekoäly olisi ihan mahtava idea. Ei liian vaikea eikä liian helppokaan ;D.

Jos tekisikin "paras kuvitus" kilpailun, pitäisi olla hyvä mielikuvitus (blaah mutta hyvä idea) eli sekä hyvät piirrokset että hyvä peli.

Siis tietenkin "paras kuvitus - peli" ja sillä ei olisi väliä olisiko se 2- vai 3ulotteinen. Mutta varmasti niitä suosii jotka 3-ulotteisen pystyvät tekemään.

lainaus:

Mutta eihän sitä leveyttä tarvi ilmoittaa jos laskee vain reippaasti sen ensimmäisen rivin pituuden...? :)

No joo, saishan sen niinkin, mutta on se nyt parempi ilmoittaa tiedostossa, turhaa sellainen kikkailu, kun joka tapauksessa on kyse pelkän tekoälyn teosta.

Tekoälykisa olisi ainakin kiinnostava, tosin ristinollan kanssa on mahdollista että kaksi hyvää tekoälyä päätyvät aina tasatulokseen. Tosin isot ruudukot saattavat auttaa.
Täytyyhän siihen tehdä kaikki estämiset, useiden yhtäaikaisten suorien yrittäminen jne... helppoa se ei olisi.

Algoritmikisa olisi myös kiinnostava, varsinkin jos otetaan joku hankala ongelma joka pitäisi ratkaista nopeasti. Ongelmana siinä on kuitenkin se, että vaikka QB:llä tekee millaisen algoritmin tahansa, huonohko C++-algoritmi voittaa nopeuskilpailun...

Tiettyyn aiheeseen liittyvä PHP-skripti: Kohtalainen idea...

QB-demo: kiinnostava aihe, näkisi kuinka QB:stä puristetaan viimeisetkin tehot irti...

Ja kun kilpailut ovat 'pikkukisoja', miksei kaikkia voisi pitää? Kuukausi koodausaikaa kilpailuun (uusi kilpailu julkistetaan joka kuun 1. päivä ja kilpailutyöt tuomaristolle kuukauden viimeiseen päivään mennessä).

Palkinnosta: Minusta varsinkin pikkukisoissa ei tarvita palkintoa ollenkaan, kyllähän se (ainakin minusta) on hyvä palkinto kun näkee nimensä listan kärjessä...

Ei tarviiskaa minkäälaista palkintoo...
Mutta olis paljo parempi vapaa kieli ku kaikki ei saata osata vaikka jotai PHP:tä tai QB:tä (esim. mä).

offtopic: laittoko kukaan lähdekoodia lavitykseen?

ois mukava nähdä miten nuo pelit kasaantuvat..

Ei tosiaan tarvita mitään palkintoja. Pääasia, että on hauskaa ja opitaan taas kaikki jotain uutta. Mietin itsekin tuota tasapeliasiaa, mutta jos vain pistetään niin hemmetin iso taulukko, ettei tasapelejä tule. Se voi tosin koitua ongelmaksi, miten ratkaistaan ottelu, jos molemmat tekoälyt voittavat, jos saavat aloittaa. Sinänsähän aloituksella ei ole paljon merkitystä, paitsi siinä suhteessa, ettei hävinnyt vastustaja saa antaa "tasoitusta", jolla molemmat voittaisivat.

lainaus:

mitää karseita bannereita jaksa kukaan kattoa

Tarviiko sen ollakkaan keskellä sivua, saatika että siinä ois 1/100 sekunnin välein vaihtuva, sekavan rasittava gif animaatio..

Joku pieni suhteellisen nätti tuohon ohjelmoi palikka-kilpailu linkin tilalle..

Jesh... Oon aina tuuminu etten tee pelejä mutta eilen se muuttu... Rupesin tekemään matopeliä vb:llä... on se ihan hauskaa sittenkii tehä pelejä jos vaa on tarpeeks helppo aihe

2

lainaus:

Ongelmana siinä on kuitenkin se, että vaikka QB:llä tekee millaisen algoritmin tahansa, huonohko C++-algoritmi voittaa nopeuskilpailun...

Tämä ei kokonaan pidä paikkansa, hyvän ja huonon algoritmin välillä nopeusero voi olla käsittämättömän suuri. Kuitenkin on selvää, että jos algoritmin nopeutta mitataan, niin eri kielien käyttäjät ovat eriarvoisessa asemassa. Siksi täytynee sopia yksi yhteinen kieli, jota kaikki käyttävät. Todennäköisesti se on tässä tapauksessa (algoritmitehtävä) C / C++.

lainaus:

Se voi tosin koitua ongelmaksi, miten ratkaistaan ottelu, jos molemmat tekoälyt voittavat, jos saavat aloittaa.

Onkohan mahdollista tehdä ristinollatekoälyä, joka voittaa jokaisen aloittamansa pelin ruudukon koosta riippumatta? Joka tapauksessa tasapeleistä ei mielestäni ole haittaa - voihan lopputuloksissakin olla jaettuja sijoja. Esim. koitos voitaisiin järjestää niin, että kaikki tekoälyt pelaavat toisiaan vastaan. Voitosta saa tietyn verran pisteitä, tasapelistä vähemmän. Sitten lopuksi kaikki pisteet lasketaan yhteen.

Banneripalkintoa ei ole näillä näkymin tulossa.

Eli kaikki tekoälyt kamppailevat toisiaan vastaa? No siinähän on se ongelma, että toiset tekoälyt eivät ehkä tunnista toista tekoälyä ja muutenkin, mutta minulle se on aivan sama, kunhan edes joku kilpailu tulee joka kuukausi.

Voisiko kilpailuja laittaa pääosin loma aikoihin. Että ei tarttis tehä läksyi samaan aikaan kun miettii koodiprojektia.

No eihän sitä tavitse osallistua näihin pienimpiin kilpailuihin :). Kesälomalla varmasti pidetään taas Suomipelit.comin kanssa joku hieman isompikin kilpailu.

lainaus:

No siinähän on se ongelma, että toiset tekoälyt eivät ehkä tunnista toista tekoälyä ja muutenkin

Ei ole ongelmaa, koska tekoälyt pitävät yhteyttä tiedostojen kautta, joiden muoto taas on määrätty. Lue toki aiempi viestini.

Hmm. no sitten. Eiköhän se sitten ole mahdollista :).

Onhan se toki mahdollista. Tiedosto toimii ikään kuin tulkkina, jonka kieltä molemmat tekoälyt ymmärtävät.

Häh, siis eihän siinä tiedostossa ole kuin merkkejä, esim:

000
0x0
000

Ja tosta sitten jokainen scripti päättelee mitä kannattaa tehdä.

Ristinollatekoälykilpailu kuulostaa tosi hauskalta idealta! Siihen voisi jopa osallistua! :) Joskus tosi kauan sitten Finnishgames.com järjesti tällaisen kisan ja sitä oli kyllä hauskaa pähkäillä. Valitettavasti silloin en saanut mitään järkevää aikaiseksi. Harmittaa vieläkin ;)

Ja tosiaan - eiköhän me jotain isoa tehdä taas sitten kesän lähestyessä :)

Ja pidetään sitten myös :D. Viime vuonna kilpailun oli tarkoitus ajoittua kesälomalle, mutta se pidettiinkin vasta talven alussa.

Tuo mahdollisuus, että tekoälyt pelaavat toisiaan vastaan kuulostaa tosi kivalta!
Voitaisiin varmaan toteutaa niin, että yleisimmille kielille tahdään linkkiyhteys ohjelma, joka on yhteensopiva kommunikaation osalta. Sitten vaan koneet pelaamaan!

Kaikkien peli en pitäisi olla Ihminen vastaan tietokone jolloin ihminen toimisi välikätenä kahden tietokone ohjelman kanssa.

Ristinollatekoäly tuntuisi mukavalta kisalta :) Pelialueesta voi muuten tehdä dynaamisen näin: pelialueen keskipiste 0,0 ja siitä yksi vasemmalle alaspäin olisi -1,-1 ja oikealle ylöspäin 1,1. Tietokoneiden pelaaminen keskenään kyllä onnistuu ihan hyvin, verkon kautta keskusteleminen onnistuu kunhan ensin suunnittelee, missä muodossa tieto kulkee ja tekee client- ja serverohjelmat. Ehkäpä joku serveri pystyyn tätä varten (tai vanhan käyttö)..

Mureakuhassa keskusteltiin samanlaisesta kisasta, mutta se sitten jäi tekemättä. Tässä osoite threadiin: http://mureakuha.com/dpBB/thread.php?page=1&threadid=3310

ristinollakisasta tulisi kyllä pirun vaikea... vain tosileetgurut voisi osallistua, enpäs tiiä osaanko ite tehdä edes vuodessa sellaista :P

Kuten petrinm jo totesikin lyhyesti, kannattaa pitää homma riittävän yksinkertaisena. (eli tollaset jv_windyn ehdottmat verkko-liikenne jutut voi jättää ihan suosilla, miten sellasta teet vaikka qbasicilla)

Tuollainen TXT tiedostosysteemi toki voi toimia, mutta jos vaikka sovitaan että lauta on 100*100 kokoinen ja 2 ohjelmaa toimii erikseen niin että ihminen asettaa siirrot toiseen ohjelmaan niin ihan hyvin se menee. (eli molemmat ohjelmat luulee pelaavansa ihmistä vastaan) Sama homma toimii niin sakissa tai laivanupotuksessa. Ei siis ole mitään väliä vaikka toinen ohjelma ois tehty qbasicilla ja toinen vaikka perlillä.

Ainoa ongelmahan on että jos ollistujia on enemmän, saattaa kisaamisessa mennä hetki aikaa.

lainaus:

Kaikkien peli en pitäisi olla Ihminen vastaan tietokone jolloin ihminen toimisi välikätenä kahden tietokone ohjelman kanssa.

Miksi? Hommahan menee pirun hitaaksi jos joku ajaa koneellaan kahta softaa ja kun tekoäly antaa siirtonsa, näpyttelee sen toiseen ohjelmaa.

Ajattele jos pelialue on suuri (vaikkapa 100*100) tai dynaaminen, niin kahden hyvä tekoälyn kilpailussa dynaamisella alueella menisi vuosia. Tiedoston/verkkokommunikoinnin avulla homma sujuisi nopeasti suuriakin alueita käyttäen.

Suuret alueet ovat sitäpaitsi välttämättömiä, sillä muutoin pelit päättyvät liian helposti tasapeliin.

Ps: yhdys sana virhe

Tervetuloa Ohjelmointiputkaa Meitzi!

sooda: Eikös ristinolla ole ihan helppo tehdä. Ainakin 3*3 :D kyllähän ne muutkin, mutta ne veisivät enemmän aikaa tehdä.

Pikaisella etsinnällä löytyy sivuja sivuja joiden mukaan QBasic:lläkin on teorissa mahdollista käyttää TCP/IP:tä, valmiista kirjastoista en tiedä. Tuli mieleen vielä tällainen pöhkö ajatus: qbasic:stä kutsutaan telnet 80 server.com:n http-pyynnöillä (hyvin helppoa) ja php-skripti käsittelee tiedot. Ei taidakaan olla hyvä idea, koska http on yhteydetön protokollla, mutta tulipa mieleen..

Staattinentaulukko olisi tietenkin yksikertaisempaa tehdä kuin dynaaminen, mutta tämä olisi huono tallennus-tapa: Pelikentäksi pitäisi varata varmuuden vuoksi tosi iso alue, kuitenkin vain murto-osa tästä tultaisiin useimmissa peleissä käyttämään.

Jos kisaamisessa menee aikaa (päätetään vähän pidempi aika / siirto), ainakin minua kiinnostaisi katsoa pelejä reaaliaikaisesti netin kautta ;)

Jos tehdään tekoäly-kilpailu (kuten ristinolla), siihen osallistuvat ovat varmaan ihan ihan hyviä koodereita. Jos tämä kilpailu olisi tehty vaikka 10v sitten, niin olisin ymmärtänyt miksei internet:ä kannata käyttää tähän (hitaat verkot, tosin tämäkin aiheuttaa tosi vähän liikennettä), mutta kyllä nykyään on täysin mahdollista esittämäni skenaario tietokoneiden välisestä pelistä internetin välityksellä.

Ja ristinolla on muuten paljon yksinkertaisempi ja helpompi peli kuin vaikka shakki tai go.

Heikki: samaa mieltä..

lainaus:

Tuli mieleen vielä tällainen pöhkö ajatus: qbasic:stä kutsutaan telnet 80 server.com:n http-pyynnöillä (hyvin helppoa) ja php-skripti käsittelee tiedot. Ei taidakaan olla hyvä idea, koska http on yhteydetön protokollla, mutta tulipa mieleen..

Ja mikäs siitä tekee yhteydettömän protokalaan? Sehän käyttää tcp :tä, joka on juuri yhteydellinen (vrt. udp).
Siihen ei kuitenkaan kannattaisi käyttää telnettiä, joka on graafinen ohjelma ainakin minulla (Win95), siihen kun on aika hankala syöttää mitään muuta kuin servu QBasicista. Itse ehdottaisin käytettäväksi ehkä wgettiä, jolla voisi hakea myös vastauksen siirtoon netistä.

Eli onko tämä ristinolla jokin netissä pelattava?

Niin täällä jotkut näkyvät luulevan, tai sitten että tekoälyt pelaisivat toisiaan vastaan muka verkkoyhteyden välityksellä. Eikö nyt ole sanomattakin selvä, ettei mitään nettisähellystä tarvita, vaan ohjelmat yksinkertaisesti lähetetään Laaksoselle, joka testaa ne toisiaan vastaan? Eikä mitään ihmisvälikäsiä, tai mitään linkkiyhteysohjelmia, vaan ihan yksinkertaisesti jokainen pistää tekoälyynsä sellaisen, että tiettyjen sääntöjen mukaan kirjoittaa ja tallentaa tiedostoon omat siirtonsa. Tämä on kaikista yksinkertaisin tapa ja helpoin toteuttaa. Lisätietoa siitä, mikä merkki tarkoittaa mitäkin, tulee tietysti sitten, jos kilpailu tulee.

Toivottavasti nyt saadaan tämä. Kerran tein tekoälyn, joka melkein voitti itseni. Taisi olla se aika hyvä. (tai sitten minä olin riittävän huono häviämään omalle tekoälylleni :D) No joo... se oli kauan sitten, mutta jos tämä kilpailu tulee, sitä voisi alkaa uudistaa ja parantaa.

Edit: Tuossa 3*3 on sitten niin mitätön määrä eri mahdollisuuksia, että jokaisen niistä voisi melkeimpä tallentaa erikseen tekoälyn muistiin ja lisäksi vastaavan siirron, joka kussakin tilanteessa tehdään. Siitä ei teoriassa syntyisi mitään muuta kuin tasapelejä. Kyllä se sellainen viidensuora pitää olla.

Olen samaa mieltä vohvelin kanssa. Mitään verkko hömpötyksiä ei tarvita, koska se on aivan turhaa.

lainaus:

sooda: Eikös ristinolla ole ihan helppo tehdä. Ainakin 3*3 :D kyllähän ne muutkin, mutta ne veisivät enemmän aikaa tehdä.

niin mutta se tekoäly siihen sitte :P ja tollaseen 100x100 pitää vähän miettiä :P

Kiitos remontti-reiska, yritän olla kiltisti.

Mutta mielestäni tuolla tiedostohommalla ei saada juurikaan etuja siihen hommaan. Vai ajattelitteko että ohjelmissa vaan painetaan "valmis" ja "aloita" ja 2 sekunnin kuluttua peli on ohi? Jos peliä "pelataan" vuoro kerraalaan taitaa mennä ihan yhtä kauan jos ne siirrot sitten tehdään käsin ja silloin toinen ohjelma saa olla tehty vaikka linuxille tai kahvinkeittimelle eikä se aiheuta isompia ongelmia.

Tietysti riippumatta siitä millä tavalla ohjelmat kommunikoisivat olisi hienoa pystyä seuraamaan peliä netin välityksellä reaaliaikaisesti... selotuksen kanssa tietty ;)

Olisipa muuten kiva jos ristinollakilpailuun voisi osallistua php-skriptillä (kun en muita kieliä erityisemmin osaa :)

lainaus:

Olisipa muuten kiva jos ristinollakilpailuun voisi osallistua php-skriptillä (kun en muita kieliä erityisemmin osaa :)

Varmasti voikin.

Hei Meitzi! Joo tervettuloo putkaan vaan. Kohta muuten ei erota kuka puhuu kun on jo monta melkein samanlaista nimee. Esim. Antti Laaksonen < > Antti (Mä ainaki aina sekotan antin ja a.laaksosen), Meitsi(siis minä tietenkin!) < > Meitzi, Minä, Me tms.

joo o kukaan ei näköjään nyt osaa keksiä omaperäistä nimeä P:

Nuo on muuten minun nimikirjaimeni, pistin kun en parempaakaan keksinyt...

Siis ME tarkoititko että ME == Meitzi. Siis onko sulla kaks tunnusta? (Kysyn vaan ettei sekota porukkaa)

Ei ole, viittasin vaan tohon ja soodan kommenttiin:

lainaus:

...Meitsi(siis minä tietenkin!) < > Meitzi, Minä, Me tms.

Tämäkin viestiketju on paisunut jo hiukan liikaa, olisikohan aika saada se kilpailuaiheinen alue pystyyn?

EDIT: Tai ainakin saada viestiketjuihin sivutus. On ärsyttävää odotella 100+ -viestiä sisältävien ketjujen latausta.

lainaus:

joo o kukaan ei näköjään nyt osaa keksiä omaperäistä nimeä P:

Duke Nukem 3D:tä kun aikoinaan pelasin netissä niin tuli tämä nick valittua, ei mikään kovin hyvä nick mutta en ole ainakaan niitä jotka jatkuvasti vaihtelee.

Petrinm
Toi nimi on vaan joskus nopeasti keksitty lyhenne nimestäni, koska se on nopea kirjoittaa.

Omaperäisistä nimistä puheenollen, tunnettekos montakin, jonka tunnus on Hunajavohveli? :D

Joo sooda, tuota justiin tarkoitinkin, että minustakin tekoälyn pitää voida käsitellä tuollaista 100*100 ruudun ruudukkoa, tai teoriassa niin suurta ruudukkoa kuin tarvis on. 3*3 olisi ihan liian yksinkertainen. Eihän ohjelmaan voi tietenkään tallentaa jokaista mahdollista tilannetta. Sehän veisi tuhottomasti tilaa. Tuossa 3*3:ssa se onnistuisi, muttei missään 100*100.

Niin ja ei sitten mennä ihan mahdottomuuksiin niiden ruutujen kanssa. Loppuu pian QB:n taulukkomuisti. :D

Niin ja sitten: Tämä tekoälykilpailu on tietysti PC:lle tarkoitettu, että sellaiset omat järjestelmät, kuten kahvinkeittimet luultavasti diskataan. Ja miksei tämä muka olisi Windows/Linux-yhteensopiva? Eihän tiedostot ole käyttiksissä erilaisia.

Tekstitiedostoissa on kyllä ero rivinvaihtona käytetyn merkin välillä, Unixeissa \n, Windowsissa \r\n.

lainaus:

joo o kukaan ei näköjään nyt osaa keksiä omaperäistä nimeä P:

Eikö? ;)

lainaus:

Niin ja ei sitten mennä ihan mahdottomuuksiin niiden ruutujen kanssa. Loppuu pian QB:n taulukkomuisti. :D

Onko se muka pakko tehdä taulukoilla? Itse en ehkä tekisi... (Mutten kyllä käytäkään QB:ta)

lainaus:

lainaus:

Tuli mieleen vielä tällainen pöhkö ajatus: qbasic:stä kutsutaan telnet 80 server.com:n http-pyynnöillä (hyvin helppoa) ja php-skripti käsittelee tiedot. Ei taidakaan olla hyvä idea, koska http on yhteydetön protokollla, mutta tulipa mieleen..

Ja mikäs siitä tekee yhteydettömän protokalaan? Sehän käyttää tcp :tä, joka on juuri yhteydellinen (vrt. udp).
Siihen ei kuitenkaan kannattaisi käyttää telnettiä, joka on graafinen ohjelma ainakin minulla (Win95), siihen kun on aika hankala syöttää mitään muuta kuin servu QBasicista. Itse ehdottaisin käytettäväksi ehkä wgettiä, jolla voisi hakea myös vastauksen siirtoon netistä.

Mikä tekee TCP yhteydellisen protokollan? Sehän IP:tä, joka on yhteydetön.. No joo, yksinkertaistettuna HTTP-protokolla on yhteydetön, koska yhteys on auki vain sivua ladattaessa, aina kun ladataan uusi sivu, pitää avata ja jälleen sulkea yhteys.

Ilmaisia teksti-pohjaisia telnet-ohjelmia varmasti löytyy ja ehkäpä kirjastokin qbasic:lle. Tämä telnet-juttu oli vain nopeasti keksitty päässä, tarkoitus oli osoittaa, että homma toimii. Itse asiassa wget (kääntyy myös windowsille ja valmiit binarytkin löytyy) voisi olla hyvä ajatus. HTTP-protokollassa on kuitenkin vaikeaa keksiä varmaa tapaa tunnistaa käyttäjä (kuten kaikessa). Tai voittehan te itsekin näpytellä siirrot web-liittymän kautta katsottuanne ensin mitä tekoälynne keksi tehdä.

No, katsotaan mitä mieltä vaikka Laaksonen tästä on. Pitäisitkö siitä, että jokainen lähettää sinulle pelisi ja autat ohjelmia niiden jokaisessa siirrossa?

Monien idea näyttää olevan tekstitiedosto. Mikä teidän ideanne täsmälleen ottaen olisi ja miten se käytännössä toimisi? Jos koko pelialue olisi tekstitiedostossa, se olisi tosi suuri. Ja tämä koko tiedosto pitäisi joka ikisen siirron välissä tutkia uudestaan. Jos tekoälyjen välikappaleena on vain tämä tekstitiedosto (muoto ruudukkona), pitää aina tutkia uudestaan pelialue, mihin esim. laitettiin äsken vastustajan merkki. Tietenkin voitte ehdottaa, että tekstitiedoston loppuun pistetään ylös, mihin viimeksi laitettiin. Mutta tällöin olisi järkevää kokonaan siirtyä ohjelmien väliseen viestintään, jossa vain kerrotaan, mihin ruutuun viimeksi laitettiin. Ja tällöin voitaisiin käyttää esim. Windows:n API:ja ohjelmien väliseen keskusteluun tai nettiä, jonka pitäisi myös onnistua QBasic:llä, mutta API:t taas eivät onnistu sillä (vai tiedättekö että onnistuisi?). Toki voi olla muitakin vaihtoehtoja, kertokaa ehdotuksianne.

Siirtojen ajasta vielä. Jokin aikaraja on pakko tehdä (jotta ei voi miettiä ikuisuuden), mutta siirtojen kestot eivät kuitenkaan ole yhtään esim. shakin luokkaa. Kun pelejä katsellaan myöhemmin vaikka netissä, voidaan peli ajastaa halutunlaiseksi (tai kelata edestakaisin).

lainaus:

Siirtojen ajasta vielä. Jokin aikaraja on pakko tehdä (jotta ei voi miettiä ikuisuuden), mutta siirtojen kestot eivät kuitenkaan ole yhtään esim. shakin luokkaa. Kun pelejä katsellaan myöhemmin vaikka netissä, voidaan peli ajastaa halutunlaiseksi (tai kelata edestakaisin).

Nyt meni yli. Mielestäni ohjelma saa laskea siirtoa niin pitkään kuin on tarpeen. Kukaan tuskin pystyy tekemään ojhelmaa jolla miettimiseen menee nykykoneella yli sekunti.

Yksitapahan on tietysti kertoa tekstitiedostossa vain että mihin pistetään, eli F56. Jos siis todella halutaan automaattista systeemiä.

Vielä kerran tuosta jätkänshakki ohjelmasta, vapailla markkinoilla on aika paljon lähdekoodia ihan toimivista ohjelmista, esim Go-Moku. Varsinkin aloitteleville ohjelmoijille olisi houkuttelevaa vähäm lainata, ko koodia. Millä voitaisiin tarkistaa että koodia ei ole lainattu? Ehdottaisin vaikka mieluummin vaikka korttipeliä, jonka toteutus ja aihepiiri olisi vapaa.. Ettei tule 100kpl Solitaireja ;)

Eikö se nyt ole selvää, ettei ruveta lainaamaan toisilta koodeja? Tuskin aloittelevat ohjelmoijat niin tyhmiä ovat, että suoraan kopioimaan rupeisivat. Ajatelkaas, jos joku käskisi vaikka selittämään, mitä koodi tekee, eikä sitten sen kopioinut "ohjelmoija" tietäisikään koodista yhtään mitään. Johan siinä nyt maine menisi kaikkien Ohjelmointiputkan jäsenten edessä, jos paljastuisi, että koodi on kopioitu.

Joresoft: No onhan joku muukin sentään kuullut puhuttavan jätkänshakista! :) Olen sen sillä nimellä alunperin oppinut, mutta kaikki muut ovat aina puhuneet ristinollasta.

Niin ja sitten, kyllä ajattelin, että taulukkoon se tilanne pitää kopioida, että käsittely tulee helpommaksi. Ei tarvitse jatkuvaa tiedostosta lukemista. Vai olisiko tähän jokin muukin konsti?

Ovathan nämä kaksi aivan eri pelejä...
Perinteinen risti-nolla pelataan aina 3*3 taulukossa, mutta jätkänshakki, niin että saadaan viisi omaa merkkiä peräkkäin...

JoreSoft:
Eikös se ole niinpäin, että jätkänshakki on 3*3 taulukossa ja tavallinen ristinolla äärettömän kokoisella alueella ja 5 merkkiä peräkkäin.

Kyllä minun tietääkseni jätkänshakki on nimenomaan tuo 3x3-peli.

Ristinolla-kilvasta sen verran että minun mielestäni järkevin systeemi olisi se, että tiedoston muuttamiset pidettäisiin minimissä. Eli sinne esimerkiksi tallennettaisiin vain muutettavan ruudun koordinaatit. Hostaavan ohjelman tulisi tietysti tarkistaa kaikki siirrot ja tarvittaessa hylätä toinen kilpailijoista. Hostaava ohjelma voisi myös tallettaa kaikki siirrot toiseen tiedostoon myöhempää tarkastelua varten.

Tuo kopiointiongelma on tietysti olemassa. Voitaisiinkin vaatia lähdekoodin julkaisemista ja suhteellisen kattavaa kommentointia. Mikään ei tietysti silloinkaan estä algoritmien kopioimista.

Jos minulta kysytään (mutta kun ei kysytä) Mikä on jätkänshakki ja mikä ristinolla voisin lainata pätkän kirjasta pelien parhaat:
"Jätkänshakissa pelilautana toimii koko paperi ja yhtenä ruutuna yksi paperiin painettu ruutu. Kumpikin pelaaja piirtää oman merkkinsä (ristin tai nollan) Johonkin paperin ruuduista. Pelin voittaa se pelaaja, joka ensimmäisenä saa muodostetuksi viisi omaa merkkiään joko vaaka-, pysty- tai viistosuuntaan.

Eli, jos se oikein kirjaan on rustattu, niin kaipa se sitten niin menee :).

Joo, ja perinteinen ristinolla on sitten se 3*3 niin kuin Maailman Ympäri-ohjelmassakin toisella kierroksella pelataan ristinollaa ja siinä on 3*3. Eli tuo teoriassa loputon määrä ruutuja on jätkänshakki.

lainaus:

Maailman Ympäri-ohjelmassakin toisella kierroksella pelataan ristinollaa

Lol.

lainaus:

lainaus:

Maailman Ympäri-ohjelmassakin toisella kierroksella pelataan ristinollaa

Lol.

Aurinko on hyvin kaunis eläin.

En voinut olla sanomatta, mutta mietitäänkö kerran ja sitten vasta vastataan(tai sitten ei vastata)? :)

Minä(kin) olen kyllä aina luullut, että jätkänšakki on 3x3 ja ristinolla rajattomalla ruudukolla, mutta jos se toisin oikein kirjassa lukee, niin joutunee tuota sitten korjaamaan käsitystään.

lainaus:

Aurinko on hyvin kaunis eläin.

En voinut olla sanomatta, mutta mietitäänkö kerran ja sitten vasta vastataan(tai sitten ei vastata)? :)

Ei nyt kyllä justiin aukene, mitä tuo oli tarkoittavinaan. :)

Minä pitäisin parhaana vaihtoehtona tiedostoa, johon kirjoitetaan vain siirto. Sitten pääohjelma tulkitsee ne ja katsoo milloin jompikumpi häviää.
Tuleeko tätä kilpailua nyt vaiko ei, ja kuka tekee sen pääohjelman?

Eikai pääohjelma ole paha, jos se ajaa vain vuorotellen eri ohjelmia, ja tarkistaa onko jompikumpi voittanut (jonka myös tekoäly voi tehdä).

Ja tekijä on luultavastikkin Antti...

Ensinnäkin tämän aiheen kunniaksi on keskustelussa nyt sivutus 50 viestin välein!

Pelialueen koko
Etukäteen on vaikea ennustaa, kuinka tasavertaisia tekoälyt tulevat olemaan. Kilpailussa voidaan toki käyttää monia erikokoisia ruudukoita. Tasapeli kahden tekoälyn välillä ei kai kuitenkaan haittaa, siitä voisivat molemmat saada jonkun verran pisteitä. Dynaaminen pelialue olisi muuten mainio, mutta samalla tekoälyn ohjelmointi vaikeutuisi huomattavasti.

Kilpailun toteutus
Tekstitiedosto on siksi hyvä, että tiedoston lukeminen ja kirjoittaminen onnistuu varmasti ongelmitta kaikilla ohjelmointikielillä. Syöte voisi olla koko ruudukon sisältö ja tulostus sen ruudun koordinaatit, johon oma merkki laitetaan. Ulkopuolinen ohjelma huolehtii tiedonsiirrosta tekoälyjen välillä. Huonona puolena on se, että tekoälyn pitää joka siirrolla ruveta alusta miettimään koko tilannetta. Mutta onko tämä sittenkään huono puoli?

Pelien esittäminen Internetissä on hyvä idea, ja näin tulee tapahtumaan. Tuskin kuitenkaan reaaliaikaisena, mutta jokaisen pelin jokaisen siirron voi myöhemmin katsoa.

Yhden siirron sallittu aika
Yksi siirto ei saa kestää kovin kauan, korkeintaan joitakin sekunteja. Tietokoneet ovat nopeita nykyisin, mutta eivät missään tapauksessa niin nopeita, että minkälainen tahansa algoritmi tuottaisi tuloksen silmänräpäyksessä. En kuitenkaan usko, että nopeudesta tulee ongelmaa ristinollatekoälyn kanssa.

Toisen tekemän koodin käyttö
Tämä ei tietenkään ole sallittua, moisen havaitseminen on vain valitettavasti vaikeaa. Mutta kilpailun aiheesta johtuen en usko, että kukaan yrittää huijata ja käyttää toisen tekemää koodia. Sillä eihän oman tekoälyn menestyminen tuntuisi miltään, jos se ei olisikaan itse tehty.

lainaus:

Toisen tekemän koodin käyttö
Tämä ei tietenkään ole sallittua, moisen havaitseminen on vain valitettavasti vaikeaa. Mutta kilpailun aiheesta johtuen en usko, että kukaan yrittää huijata ja käyttää toisen tekemää koodia. Sillä eihän oman tekoälyn menestyminen tuntuisi miltään, jos se ei olisikaan itse tehty.

Eiköhän se ole jo nähty monta kertaa kun toiset tekevät koodivinkkejä joiden koodi on 50-100% kopioitu toisista koodivinkeistä

Aina löytyy yksi peelo joka haluaa pilata jonkin hyvän asian rikkomalla sääntöjä tietoisesti.

PS: Viestien sivutus olikin hyvä uudistus pitkästä aikaa. Toivoisin kyllä että aiheen ensimmäinen viesti näkyisi myös jokaisella sivulla. Jos tätä ei voi kaikki sietää, niin ainahan siitäkin voi tehdä vaihtoehtoisen asetuksen profiiliin :P

lainaus:

Ensinnäkin tämän aiheen kunniaksi on keskustelussa nyt sivutus 50 viestin välein!

Wow, tap tap tap, yleisön raikuvat aploodit.

lainaus:

Etukäteen on vaikea ennustaa, kuinka tasavertaisia tekoälyt tulevat olemaan. Kilpailussa voidaan toki käyttää monia erikokoisia ruudukoita. Tasapeli kahden tekoälyn välillä ei kai kuitenkaan haittaa, siitä voisivat molemmat saada jonkun verran pisteitä. Dynaaminen pelialue olisi muuten mainio, mutta samalla tekoälyn ohjelmointi vaikeutuisi huomattavasti.

Ja dynaaminen pelialue voisi aiheuttaa myös sen että kaksi tyhmää/vähemmän tyhmää konetta pelaa loputtomasti. Minusta "pakotetulle" pelialueelle on selkeät peruusteet, eihän se ruutupaperi todellisuudessakaan jatku loputtomiin. ;)

lainaus:

Syöte voisi olla koko ruudukon sisältö ja tulostus sen ruudun koordinaatit, johon oma merkki laitetaan. Ulkopuolinen ohjelma huolehtii tiedonsiirrosta tekoälyjen välillä. Huonona puolena on se, että tekoälyn pitää joka siirrolla ruveta alusta miettimään koko tilannetta. Mutta onko tämä sittenkään huono puoli?

Miksei syötekkin ole vain vastapuolen siirto?

Olet oikeassa että tekoälyn kannalta ei ole mitään väliä mihin vihollinen tai mihin itse ollaan viimeksi siirretty, kokonaistilanne on aina se millä päätetään.

lainaus:

Ja dynaaminen pelialue voisi aiheuttaa myös sen että kaksi tyhmää/vähemmän tyhmää konetta pelaa loputtomasti.

Tuo taitaa olla mahdotonta, koska tietyn ajan päästä tulee vähintäänkin vahingossa eteen tilanne, jonka ansiosta jompikumpi voittaa. Ellei nuo ohjelmat sitten ole niin tyhmiä etteivät ne edes tiedä miten voi voittaa :P

Pisteiden lasku olisi hyvä suhteuttaa mahdolliseen tilanne järjestelyyn jo pelin aikana.

Meillä oli yhdeksännen luokan shakki-kurssilla pisteiden lasku ja sijoitukset niin että, kaikille annettiin aluksi 1200 pistettä. Sitten jonkun kaavan avulla laskettiin siitä että jos kaveri jolla oli vaikka 1800 pojoa, haastoi jonkun jolla oli esm 600 pistettä. Jos haastaja voitti, hän sai hieman pisteitä ja häviäjä menetti vähän, jos haastaja hävisi, hän menetti paljon ja haastettu sai paljon pisteitä..

Tajusikohan tuosta kukaan mitään? ;) Mutta joka tapauksessa.. Tuossa molempien pelaajien pistemäärän erolla oli merkitystä.

Tässä ristinolla kilpailussa se tarkoittaisi sitä että, jos joku tekoäly joka on tähän asti voittanut lähes kaikki pelinsä, sattuukin häviämään tekoälylle joka on menestyny ns huonosti, niin hyvä menettää häviöstä paljon, huono saa pisteitä voitosta runsaasti. (tämä siksi että hyvässäkään älyssä ei välttämättä ole ajateltu juuri sitä tilannetta mikä ehkä ns huonommassa älyssä on ajateltuna.)

Tietääkö joku tuota pisteiden lasku tapaa? Voisi vähän selventää, kun tuo taitaa olla aika huonosti kerrottu ;)

Tiedän tuon. chessworld.net:issä käytetään tuota tapaa. Alussa on muistaakseni 1200 tai 1400 pistettä jne... En osaa kyllä selittää tuon paremmin tuota.

Mihin tyyliin kirjoitetaan tiedostoon ne siirrot? Se kannattaisi päättää niin päästäis jo koodaamaan sitä tekoälyä...
Käykö sellainen että 0,0 on vasen ylänurkka...
sitten vaan kasvatetaan aina esim. 20,34 ja se voisi olla loputon.
Ja sitten tekoälyille voisi olla raja siirroille (esim. 500 siirtoa ja jos se menee ohi niin draw) joka sitten estäisi sen että tyhmät tekoälyt pelaisivat loputtomiin.

Tietenkään ei ole mitään väliä, mitä on viimeksi siirretty, vaan siirtopäätös tehdään ainoastaan sen hetkisestä tilanteesta, eli totta kai tekoäly alkaa aina miettiä uudestaan tilannetta.
Eikö olisi parempi, että olisi tekstitiedosto, josta nykyisen tilanteen voisi suoraan lukea? Tällaiseen tiedostoon olisi kuitenkin vaikea tallentaa, ja tehdä muutoksia, joten tekoäly voisi tallentaa siirtonsa toiseen tiedostoon, minkä perusteella "ulkopuolinen ohjelma" osaisi muuttaa sitä tiedostoa, johon on tallennettu nykyinen tilanne. Siis ruudukku, jossa vaikka 0 tarkoittaa tyhjää, 1 risti, 2 nollaa.

lainaus:

Mihin tyyliin kirjoitetaan tiedostoon ne siirrot? Se kannattaisi päättää niin päästäis jo koodaamaan sitä tekoälyä...
Käykö sellainen että 0,0 on vasen ylänurkka...
sitten vaan kasvatetaan aina esim. 20,34 ja se voisi olla loputon.
Ja sitten tekoälyille voisi olla raja siirroille (esim. 500 siirtoa ja jos se menee ohi niin draw) joka sitten estäisi sen että tyhmät tekoälyt pelaisivat loputtomiin.

Eihän sinun vielä tarvitse tuosta siirtohommasta välittää mitään, kyllä sen tekoalyn voi tehdä täysin valmiiksi jo. Jos meillä on vasen ylänurkka pitää olla myös alanurkka, muuten ainakin minä aloittaisim pelaamaan ruudusta 10milj,10milj ja saisin qbasic ohjelmat nurin ;)

Ei mitään siirtorajaa, jos koko pelialue tulee täyteen niin sitten voidaan hyväksyä että tasapeli se on.

lainaus:

Tietenkään ei ole mitään väliä, mitä on viimeksi siirretty, vaan siirtopäätös tehdään ainoastaan sen hetkisestä tilanteesta, eli totta kai tekoäly alkaa aina miettiä uudestaan tilannetta.
Eikö olisi parempi, että olisi tekstitiedosto, josta nykyisen tilanteen voisi suoraan lukea?

Miksi sellainen tiedosto pitäisi olla? Varmastihan kaikissa ohjelmissa on pelitaulukko johon on nuo siirrot merkattu eli riittää kun sinne vain lisätään uusin siirto.
AINOA tilanne missä tuollaista voisi tarvita on se että ohjelma tai kone kaatuu. Eli kaatumisen jälkeen voidaan jatkaa ilman että peliä tarvitsee aloittaa alusta, mutta jos kaatuminen johtui ohjelmasta niin tod. näk. ohjelma kaatu samalla tavalla uudelelenkin mietittäessä.

[edit] hmm.. hieman tarkemmin mietittyäni tietysti jos halutaan suorittaa siirrot niin että
1) siirtovuorossa oleva ohjelma suoritetaan
2) ohjelma lukee koko tilanteen
3) ohjelma pähkäilee ja tekee siirron
4) ohjelma sammuu

Mutta entäs jos joku sittenkin haluaa tietää mihin on viimeksi siirretty? pitääkö siihen antaa mahdollisuus?

[edit2] Köh köh, ehkä pitäisi miettiä hieman tarkemmin ennekuin kirjoittaa ;)
Jos ohjelmalle annetaan mahdollisuus kirjoittaa temp tiedosto niin ei tuostakaan tule ongelmaa.

Ajattelin, että olisi kätevä, jos koko tilanteen saisi luettua suoraan tiedostosta, mutta kai sen voi noinkin toteuttaa.

Jos se on hirmu iso se ruudukko, se on hitaampaa... Ja jos se pelialue olisi dynaaminen, se olisi luultavasti helpointa kirjoittaa vain siirto.

Mutta ei pelialue käytännössä kuitenkaan loputon voi olla. Eihän muuten voi tietää, mistä kohtaa silmukat pitäisi aloittaa, jos ei ole mitään reunapisteitä. Minulle on ihan sama miten luetaan tiedostosta, mutta ei tiedostosta lukeminen paljoa aikaa vie. Sanoisin, että se on nopein osa.

Kyllähän dynaaminekin pelialue on mahdollista, mutta koska jokatapauksessa jotain rajoja on pakko olla niin ei siitä hyödytä. Vai miten pitäisi toimia kun ensimmäine laittaa merkin ruutuun 0,0 ja seuraava ruutuun 3.6789783621655157926926259847836e+39995,100000. (suom. aika kauas) Jos jollakin on tehty ohjelma niin että se tekee pelialueesta taulukon (aika järkevä tapa) niin saattaapa loppua muisti kesken.

Aika yksinkertaita määrittää että pelialue on vaikka 500*500 ja ensimmäinen merkki on PAKKO pistää ruutuun 250,250.

Jos QBasic halutaan mukaan, yksinkertaisinta voisi olla Meitzin ehdotus. Eli keskusohjelma kutsuu aina tekoälyohjelmaa, joka palauttaa siirtonsa johonkin tiettyyn ruutuun. Keskusohjelmalle voitaisiin jättää tiedostoon kirjoitus (varmempaa näin) aina siirron jälkeen. Niiden tulisi myös tarkistaa siirtojen laillisuus ja tarvittaessa hylätä tekoäly pois pelistä sääntöjen rikkomisen takia (ei laittanut tyhjään ruutuun, palautti siirron väärässä muodossa tai suoritusaika ylittyi) päättää peli. Koska tekoäly-ohjelmat sammuisivat aina välillä, niiden pitäisi tästä tiedostosta ladata aina pelialue muistiinsa uudestaan.

Ehdottaisin että tiedostoformaatti olisi suunnilleen tällainen:

G5
H6
H5
..

Tiedoston loppuun lisättäisiin aina viimeinen vuoro. Sen pystyy kirjoittamisen lisäksi myös lukemaan helposti, tässä tapauksessa luettaisiin vain 2 viimeistä tavua eli tiedoston koon ollessa 6 tavua aloittettaisiin tavusta 5 ja luettaisiin tavut 5 sekä 6. (En ottanut tässä huomioon rivinvaihtoja selkeyden vuoksi)

Kun tiedostosta luetaan pelitaulukko, pitäisi tietää missä siirrossa on laitettu risti ja missä nolla. Voitaisiin päättää että risti aloittaa ja tämän mukaan laskea ne. Aloitta tekoäly tietää aloittavansa, koska näkee tiedoston olevan tyhjä, ja tietää näin olevansa risti.

Pelitaulukko olisi mahdollista tehdä dynaamiseksi, jolloin rajoitukseksi voisi pistää siirtojen määrän tai x- ja y-akselien sallitut rajat. Origo siis 0,0 ja negatiiviset ja positiiviset arvot olisivat olemassa. Eräs helppo ratkaisu tämän toteuttamiseen voisi olla tällainen: Pelitaulukkoa ladatessa katsottaisiin ensin mitkä ovat raja-arvot (pelikentän senhetkinen koko voisi olla omassa kohdassaan tiedostossa), esim. -7,-5 ja 4,8. Tämän mukaan tehtäisiin tavallinen taulukko, johon nämä raja-arvot juuri mahtuisivat, tässä tapauksessa siis 12 vaakasuorassa ja 14 pystysuorassa.

Jos tämä tuntuu vaikealta (minusta ei) voidaan tietenkin sopia, että pelikentän koko olisi olisi enneltamäärätty. Riittäisiköhän 256*256?

Jos siis pelikentän yhden ulottuvuuden raja olisi 256, voitaisiin luku kirjoittaa ihan binäärimuodossa (tekstimuodossa hukattaisiin tilaa valtavasti, ainakin suhteessa). Yhdellä rivillä olisi siis aina 2 tavua (toinen vaakasuuntaan ja toinen pystysuuntaan). Rivivälinkin voisi oikeastaan poistaa turhana, koska tiedetään tallennusformaatti kuitenkin tarkkaan. Ehkäpä kuitenkin selkeyden vuoksi sen voisi sinne jättää.

Tuo keskusohjelman käyttäminen tekisi PHP-skriptien ja muilla ohjelmointikielillä tehtyjen tekoälyjen keskinäiset matsit vaikeiksi, ellei mahdottomiksi. On paljon yksinkertaisempaa, jos Antti vain ajaa tekoälyjä vuorotellen koneellaan.

lainaus:

Tuo keskusohjelman käyttäminen tekisi PHP-skriptien ja muilla ohjelmointikielillä tehtyjen tekoälyjen keskinäiset matsit vaikeiksi, ellei mahdottomiksi. On paljon yksinkertaisempaa, jos Antti vain ajaa tekoälyjä vuorotellen koneellaan.

Jos PHP:kin halutaan mukaan, vaaditte että Antti pitää koneellaan serveriä pystyssä. No se kovin vaikeaa ole, mutta miksi sitä pitäisi vaatia algoritmi-kilpailussa? Vai oliko ideana lähettää sekunnin välein koko pelikenttää netin kautta?

Jos osaat PHP:ta, osaat varmaan myös C:täkin (tai ainakin opit nopeasti), koska ne ovat sukulaiskieliä.

Antti kirjoitti jo aikaisemmin, että "Ulkopuolinen ohjelma huolehtii tiedonsiirrosta tekoälyjen välillä." Tuskin hän jaksaisi ajella manuaalisesti jokaisen tekoäly-ohjelmaa jokaikisellä siirrolla erikseen. En minä ainakaan.

Mitä tarkoitat muilla ohjelmointikielillä? Ohjelmien kommunikointihan tapahtuisi tiedostojen välityksellä (ja vielä keskusohjelma kontrolloimassa kaikkea), joka on kieliriippumatonta (kunhan vain tiedostojen käsittely löytyy).

lainaus:

Ehdottaisin että tiedostoformaatti olisi suunnilleen tällainen:
G5
H6
H5

Turhan monimutkainen tapa. Oikeastaan aika surkea ;)

lainaus:

Pelitaulukko olisi mahdollista tehdä dynaamiseksi, jolloin rajoitukseksi voisi pistää siirtojen määrän tai x- ja y-akselien sallitut rajat.

Mutta onko se edes enää dynaaminen jos kuitenkin rajat on? Eihän siinä ole kiinteään mitään muuta eroa kuin että origo on keskellä.

lainaus:

Jos siis pelikentän yhden ulottuvuuden raja olisi 256, voitaisiin luku kirjoittaa ihan binäärimuodossa

Niin, tuohan on aika simppeli ja onnistuu kyllä varmaan kaikilla kielillä. Tiedoston tutkimiseen käsin tosin tarvitaan joku HEX editori, mutta eiköhän sellainen kaikilta löydy.

lainaus:

Ehdottaisin että tiedostoformaatti olisi suunnilleen tällainen:

G5
H6
H5

Tuolloin pelialue olisi melko pieni. Aakkoset kun ei oikeen riitä... Muistathan kun siitä sanottiin, että tasavertaisten tekoälyjen peliin voi tarvita todella ison alueen.

lainaus:

Jos tämä tuntuu vaikealta (minusta ei) voidaan tietenkin sopia, että pelikentän koko olisi olisi enneltamäärätty. Riittäisiköhän 256*256?

Jos siis pelikentän yhden ulottuvuuden raja olisi 256, voitaisiin luku kirjoittaa ihan binäärimuodossa (tekstimuodossa hukattaisiin tilaa valtavasti, ainakin suhteessa). Yhdellä rivillä olisi siis aina 2 tavua (toinen vaakasuuntaan ja toinen pystysuuntaan). Rivivälinkin voisi oikeastaan poistaa turhana, koska tiedetään tallennusformaatti kuitenkin tarkkaan. Ehkäpä kuitenkin selkeyden vuoksi sen voisi sinne jättää.

Eikö olisi kaikkien kannalta (aloittelioita ajatellen) helpompi tehdä yksinkertaiset koordinaatit X,Y. Tietysti tuo ennalta määritetty kannattaa ehkä sittenkin olla =D. Hmm, missä vaiheessa esim. integer taulukon muisti loppuu QB:ssa? (En tunne QB:ta kovin koska aloitin VB:llä enkä halua siirtyä huonompaan ;)

Niin no, ehkei PHP:tä voi ajaa niin että "ohjelma sulkeutuu", mutta en vielä näe mitään ongelmaa miksei PHP voisi olla mukana vaikka käytettäisiinkin automaattista "tuomaria". Tuomariohjelma vain suorittaa joko
c:\kilpailu\meitzi\egoaly.exe tai
http://locahost/kilpailu/me/jallitus.php

ja molemmat antavat vastauksensa tiedostoon. Molempiin ohjelmiinhan on mahdollista antaa parametrejäkin jos tarvitsee.

lainaus:

Mitä tarkoitat muilla ohjelmointikielillä? Ohjelmien kommunikointihan tapahtuisi tiedostojen välityksellä (ja vielä keskusohjelma kontrolloimassa kaikkea), joka on kieliriippumatonta (kunhan vain tiedostojen käsittely löytyy).

En usko että on kovin helppoa saada keskusohjelma ajamaan PHP-skriptejä sekä muita ohjelmia. Se, että jaksaako niitä käsinkään ajaa, riippuu tietysti ihmisestä. Siihen tietysti auttaa pelialueen pitäminen pienenä.

PHP-skriptien osalta voisi tosin pitää reaaliaikaisesti netissä pelattavan matsin. Silloin voisi käyttää yhtä skriptiä ajamaan tekoälyjä, ja voisihan PHP:llä tietysti suorittaa ei-php-tekoälyjäkin, kunhan ne lataisi serverille.
Näin matseja voisi seurata livenä!

lainaus:

lainaus:

Ehdottaisin että tiedostoformaatti olisi suunnilleen tällainen:
G5
H6
H5

Turhan monimutkainen tapa. Oikeastaan aika surkea ;)

Tuo nyt oli hyvin yksinkertaittuna se mitä esitin myöhemmin tarkempana. Siis tallennusmuotona binääriluku 0.255 eli 1 tavu.

lainaus:

lainaus:

Pelitaulukko olisi mahdollista tehdä dynaamiseksi, jolloin rajoitukseksi voisi pistää siirtojen määrän tai x- ja y-akselien sallitut rajat.

Mutta onko se edes enää dynaaminen jos kuitenkin rajat on? Eihän siinä ole kiinteään mitään muuta eroa kuin että origo on keskellä.

Ihan oikeassa olet. Dynaamisessa ruudukossa ei olisi järkeä rajoittaa x- ja y-akseleita, koska tämä voitaisiin helpommin korvata siirtämällä origo keskeltä vasempaan ylänurkkaan. Dynaamisessa taulukossa voitaisiin ehkä ottaa siirtojen määrä tai peliaika rajaksi, jottei peli kestäisi mahdollisesti loputtomiin.

QB:n Integer päättyy tietysti 16 bittiin, eli 2^16=65536, eli 32768 negatiiviseen ja positiiviseen suuntaan.
Eikö tällainen olisi kätevä:

15,15,1
16,15,2
16,16,1

Jokaisen rivin ensimmäiset kaksi lukua ovat x ja y koordinaatit ja viimeinen luku on joko risti (1) tai nolla (2). Tyhjiä ei tietenkään merkitä, koska kaikki ruudut, joiden koordinaatteja ei tiedostosta löydy, ovat automaattisesti tyhjiä.

hunajavohveli: Mielestäni tuo on se helpoin tapa. Eli kannatan tuota.

Mutta annetaan kuitenkin Antti Laaksosen päättää!

lainaus:

lainaus:

Tuo keskusohjelman käyttäminen tekisi PHP-skriptien ja muilla ohjelmointikielillä tehtyjen tekoälyjen keskinäiset matsit vaikeiksi, ellei mahdottomiksi. On paljon yksinkertaisempaa, jos Antti vain ajaa tekoälyjä vuorotellen koneellaan.

Jos PHP:kin halutaan mukaan, vaaditte että Antti pitää koneellaan serveriä pystyssä. No se kovin vaikeaa ole, mutta miksi sitä pitäisi vaatia algoritmi-kilpailussa? Vai oliko ideana lähettää sekunnin välein koko pelikenttää netin kautta?

Voihan PHP-koodeja ajaa ilmankin serveriä. CLI-versiolla ajettuna PHP-ohjelma toimii kuten mikä tahansa muukin komentotilasta ajettava ohjelma.

Minkäänlaista live-seurantaa ei mielestäni näihin kannata alkaa tekemään. Matsit voi katsoa jälkikäteen, jos haluaa.

Minusta ruudukko voisi olla aluksi vaikkapa 10x10, mutta sen koko kasvaisi aina, kun johonkin äärilaidoista tulee merkintä. Kasvatuksesta ja koordinaattien mahdollisesta muunnoksesta huolehtisi siirtojen välillä kilpailun "järjestävä" ohjelma. Siis taulukko näkyisi ohjelmille staattisena, jolloin sen käsittely on helppoa, mutta oikeasti se kuitenkin olisikin dynaaminen (tiettyyn rajaan asti tietenkin).

Pisteenlasku voisi olla sellainen, että voitosta saa kolme pistettä, tasapelistä yhden ja häviöstä ei mitään. Minän mainitsema suhteutettu pisteenlasku (pisteiden muutos riippuu pelaajien tasoerosta) kuulostaa tosin myös hauskalta. Tietääkö kukaan, millä perusteella pisteet tarkalleen lasketaan? Onko pelien järjestyksellä vaikutusta lopputulokseen?

PHP:n käyttö tulee olemaan mahdollista. Tämä minun on helppo toteuttaa, koska PHP-skriptejä pystyy ajamaan kirjoittamalla komentorivillä "php skripti.php".

lainaus:

Minusta ruudukko voisi olla aluksi vaikkapa 10x10, mutta sen koko kasvaisi aina, kun johonkin äärilaidoista tulee merkintä. Kasvatuksesta ja koordinaattien mahdollisesta muunnoksesta huolehtisi siirtojen välillä kilpailun "järjestävä" ohjelma. Siis taulukko näkyisi ohjelmille staattisena, jolloin sen käsittely on helppoa, mutta oikeasti se kuitenkin olisikin dynaaminen (tiettyyn rajaan asti tietenkin).

Hmm, miten ajattelit päätellä tekoäly-ohjelmille näytettävän pelialueen, vaikkapa sen keskustan paikan (josta muu osa päätellään)? Muuten tämä voisi olla aika eräs aika hyvä vaihtoehto. Tekoälyohjelmille näytettävä pelikentän koko pitää olla sopivan kokoinen, ettet niiltä jää huomaamatta mikään sen hetkisen tilanteen tärkeä ruutu. Tämä olisi kyllä kilpailuun osallistuville yksinkertainen ratkaisu, mutta vaatii kilpailun järjestäjältä vähän enemmän vaivaa kuin staattinen pelitaulukko.

Tiedostoja olisi siis 2, toisessa pelikenttä (vaikka 10*10) (tekoälyohjelmien käyttöön) ja toisessa kaikki siirrot "dynaamisessa" taulukossa (keskusohjelman käyttöön ja pelin näyttämisen myöhemmin) vaikka 16 bitillä (tai 8 eli 1 tavu) kahden komplementilla (saadaan myös negatiiviset arvot keskeltä lähtien). Ohjelmointikielten kääntävät kyllä yleensä hoitavat tämän, esim. C:ssä short int on 16 bittinen erimerkillinen muuttujatyyppi, siis -32,768..+32,767 (yleensä myös pelkkä int on 16 bittinen, riippuu kääntäjästä), tarvitsee siis vain lukea tiedostosta tämän muuttujan kokoisen palan x- ja y-koordinaateille. Pelimerkin kertova bitti voidaan selkeyden vuoksi laittaa, jos halutaan, mutta tiedosto kuitenkin vie 7 bittiä lisää tilaa, koska tiedostot tallennetaan tavuittain. Mielestäni on tarpeeksi selkeää, että päätetään ristin aina aloittavan, ohjelma tietää tästä laskea pelimerkit vuorotellen, ihmiset eivät kuitenkaan lue ASCII-teksturilla int-muuttujia.

lainaus:

PHP:n käyttö tulee olemaan mahdollista. Tämä minun on helppo toteuttaa, koska PHP-skriptejä pystyy ajamaan kirjoittamalla komentorivillä "php skripti.php".

Antti ehti näköjään jo sanoa, että PHP:stä on tehty binary:täkin, esim. windowsille php.exe. CLI:n lisäksi on ennen ollut käytössä CGI:tä tähän. Alkuperäisellä PHP:n ehdottajalla ei varmaan ollut tätä mielessä (hänen teksteistään päätellen). Itsekään en heti muistanut, että valmiita binarykin on tehty (ja tämähän tyyli on ennen moduuleita ollut käytössä). PHP:n mukaanottaminen ei siis paljoa vaadi. Itse aion kyllä tehokkuuden takia tehdä algoritmin C:llä, koska sen koodi on jo käännetty eikä sitä enää tarvitse tulkata konekoodiksi sen ollessa jo valmiina sitä.

Suomipelit.com tulee varmaan myös mukaan (päätellen jalaine:n viestistä). Entä Mureakuha? Heiltäkin voisi kysyä, siellä oltiin ainakin ennen innokkaita järjestämään tällainen kilpailu ja näin ollen osallistujiakin löytyisi varmaan.

Kuulostaa ihan hyvältä, mutta entäs live-matsit? Säätäisi vaan pääohjelman/-skriptin teettämään siirrot vaikka puolen tunnin välein, ja näyttämään senhetkisen tilanteen netissä.

Tuo dynaaminen pelialue on mukava idea, mutta kenttää pitää laajentaa jo paljon ennen kuin reuna tulee vastaan, muutenhan tekoälyltä menee täysin pasmat sekaisin.

lainaus:

Kuulostaa ihan hyvältä, mutta entäs live-matsit? Säätäisi vaan pääohjelman/-skriptin teettämään siirrot vaikka puolen tunnin välein, ja näyttämään senhetkisen tilanteen netissä.

½ tuntia olisi aika pitkä aika, kilpailu kestäisiä päiviä..tosin hyvin pieni aika taas kuormittaisi liikaa palvelinta.

Ehkäpä voisi tehdä niin, että keskusohjelma lähettää välillä tietoja ohjelmointiputka.net:iin johonkin tiedostoon (tai se pyörisi samassa koneessa ja muokkaisi tätä tiedostoa), jota sivuilla oleva php-skripti lukee ja muodostaa tästä peliruudukon, näin kävijät voisivat seurata pelien kulkua melkein reaaliaikaisesti.. Tämäkin aiheuttaa liikennettä varmaan poikeukkellisen paljon (innokaita kävijöitä paljon näihin aikoihin ja sivujen päivitykset hyvin tiheitä (tätä voisi rajoittaa)), mutta moni muu reaaliaikasysteemi aiheuttaisi paljon enemmän kuormitusta (vaikka php-skriptien kamppailu eri servereiden välillä).

Miksi lainatessa ei näy kirjoittajan nimeä?

lainaus:

Antti Laaksonen: Minusta ruudukko voisi olla aluksi vaikkapa 10x10, mutta sen koko kasvaisi aina, kun johonkin äärilaidoista tulee merkintä. Kasvatuksesta ja koordinaattien mahdollisesta muunnoksesta huolehtisi siirtojen välillä kilpailun "järjestävä" ohjelma. Siis taulukko näkyisi ohjelmille staattisena, jolloin sen käsittely on helppoa, mutta oikeasti se kuitenkin olisikin dynaaminen (tiettyyn rajaan asti tietenkin).

Myönnät varmaan sen, että dynaaminen ruudukko on vaikeampi toteuttaa. (tässä tapauksessa vaikeus on enemmänkin "tuomarilla")

Siksi kysynkin, mitä etuja dynaamisella ruudukolla saavutetaan?

Myöskään en oikein keksi miksi koko ruudukko pitää olla tiedostossa, riittää aivan hyvin pelkkä tiedosto jossa on järjestyksessä tehdyt siirrot. Se on helppo ja nopea lukea ohjelmaan. Tiedosto toki voi kasvaa aika isoksikin mutta ei varmasti koskaan niin isoksi kuin koko pelikentän kuvaava tiedosto.

lainaus:

Pisteenlasku voisi olla sellainen, että voitosta saa kolme pistettä, tasapelistä yhden ja häviöstä ei mitään. Minän mainitsema suhteutettu pisteenlasku (pisteiden muutos riippuu pelaajien tasoerosta) kuulostaa tosin myös hauskalta. Tietääkö kukaan, millä perusteella pisteet tarkalleen lasketaan? Onko pelien järjestyksellä vaikutusta lopputulokseen?

Minäpä soitan kyseisen kurssin järjestäjälle. Uskon että sillä tavalla sen saisi helpoiten selville.

Niin alkaako se kilpailu vai eikö ala???

Eiköhän se tässä piakkoin pystyyn saada. Täytyyhän Antille antaa aikaa miettiä kaikkia näitä yli 100 viestin ehdotuksia ja huomautuksia, että saa niistä kasattua selkeät säännöt ja ohjeet.

Ei kai se kilpailu vain kovin pian ala? On kerrankin niin erinomaisia aiheita, että haluaisin osallistua, mutta yo-kirjoitukset alkavat kohta, ja niihinkin täytyy keskittyä. Ensi kuun alussa olisi esimerkiksi ihan hyvä aloitusajankohta.

lainaus:

jätkänshakki

Muistakaa sitten että jätkänshakki on se joka on _isommassa_ kuin 3x3 ruudukossa, se joka on 3x3 ruudukossa on ristinolla.

ADD: Mistä ihmeestä se muuten johtuu että ihmisillä on näinkin pienestä ja lähes täysin mihinkään vaikuttamattomasta asiasta niin monia eri mielipiteitä?

Mitä minun pelikirjani sanoo ristinollasta:

lainaus:

Tämä myllypelin muunnelma lienee kaikkein yksinkertaisin peleistä, joissa pyritään muodostamaan kolmen rivi.
...
Pelin aloittaja piirtää ristin johonkin yhdeksästä ruudusta

Ja jätkänshakista: Ei se sano siitä mitään :D

Jos jotain kiinnostaa että mikä kirja on kyseessä: Suuri pelikirja, kirjoittanut Tony Burrett ja Carla van Splunteren.

Parasta on tosiaan tallentaa tiedostoon ainoastaan ne ruudut, joissa on risti tai nolla. Tämän ansiosta ohjelma saa selville myös järjestyksen, jossa merkinnät on tehty. Minusta tiedosto kannattaa pitää tekstimuodossa, jolloin sitä voi tutkia tavallisella tekstieditorilla ja eri ohjelmointikielten välillä ei tule ongelmia.

Tavoite on se, että ohjelmoiminen tiedostomuotojen ym. kannalta on mahdollisimman helppoa. Kilpailun järjestävä ohjelma kasvattaa tarvittaessa ruudukon kokoa, tarkistaa siirron laillisuuden ja ilmoittaa pelin päättymisestä. Lisäksi teen varmaankin ohjelman, jolla tekoälyn voi testata toimivan oikein ennen kuin sen lähettää kilpailuun.

Pelien seuraamisesta Internetin kautta olen vieläkin vähän epävarma. Nimittäin "suorassa lähetyksessä" on se riski, että jotain menee mönkään - palvelimen, kilpailun järjestävän ohjelman tai tekoälyohjelmien toiminnassa. Pelien näyttäminen Internetissä edellyttäisi hyvin tiheää päivitystahtia, jottei kilpailu kestäisi loputtomiin.

lainaus:

Suomipelit.com tulee varmaan myös mukaan (päätellen jalaine:n viestistä). Entä Mureakuha? Heiltäkin voisi kysyä, siellä oltiin ainakin ennen innokkaita järjestämään tällainen kilpailu ja näin ollen osallistujiakin löytyisi varmaan.

Tämä "pikku"kilpailu on ainakin tällä haavaa tarkoitus järjestää yksin. Suomipelit.comin kanssa on varmastikin yhteistyötä myöhemmin jonkin suuremman kilpailun merkeissä.

Huhtikuun alku voisi olla ihan hyvä aloitushetki kilpailulle, jos saadaan kaikki sitä ennen päätettyä ja tehtyä.

lainaus:

Parasta on tosiaan tallentaa tiedostoon ainoastaan ne ruudut, joissa on risti tai nolla. Tämän ansiosta ohjelma saa selville myös järjestyksen, jossa merkinnät on tehty.

Mutta miten tekoäly silloin selvittää ruudukon koon? Keskusohjelman pitäisi kirjoittaa ruudukon koko erillisen tiedostoon, josta se sitten luettaisiin.

Live-pelien ei tarvitse olla kilpailun "virallisia" matseja, vaan ihan näytösluontoisia kokeiluja. Silloin ei haittaa, vaikka jotain menisi pieleen.

lainaus:

Mutta miten tekoäly silloin selvittää ruudukon koon? Keskusohjelman pitäisi kirjoittaa ruudukon koko erillisen tiedostoon, josta se sitten luettaisiin.

Koska jokatapauksessa määritetään peliauleen maksimikoko (onko se nyt sitten 50*50 vai 256*256) on ohjelmassa ihan sama käyttää kyseisen kokoista ruudukkoa aina. Ei ole juurikaan järkeä lähteä rajailemaan, koska ohjelman on kuitenkin kyettävä käsittelemään maksimikokoista ruudukkoa. Muistia se toki Antin koneelta kuluttaa vähä ylimääräistä ;)

Tosin "esittelyä" varten on hyvä ruudukolta rajata reunoja pois.

lainaus:

Mutta miten tekoäly silloin selvittää ruudukon koon? Keskusohjelman pitäisi kirjoittaa ruudukon koko erillisen tiedostoon, josta se sitten luettaisiin.

Ruudukon koko voisi lukea vaikkapa tiedoston ensimmäisellä rivillä, erillistä tiedostoa ei varmastikaan tarvita.

lainaus:

Koska jokatapauksessa määritetään peliauleen maksimikoko (onko se nyt sitten 50*50 vai 256*256) on ohjelmassa ihan sama käyttää kyseisen kokoista ruudukkoa aina.

Pienempää ruudukkoa on varmasti nopeampaa käsitellä ohjelmassa, eli se tuskin ainakaan vaikeuttaa ohjelmointia. Juuri tuon pelin myöhemmän seuraamisen kannalta sopivan kokoinen ruudukko on myös hyvä.

lainaus:

Ruudukon koko voisi lukea vaikkapa tiedoston ensimmäisellä rivillä, erillistä tiedostoa ei varmastikaan tarvita.

Jos ruudukon koko on määritelty vaikka niin että etsitään pelimerkit ja niiden reunoille lisätään 3 ruudun vyöhyke niin eikö tämä ruudun ulkopuolelle saa merkkiä asettaa? Jos saa niin ei "kerrotulla" koolla ole mitään merkitystä, se vain hankaloittaisi ohjelman tekemistä.

lainaus:

Pienempää ruudukkoa on varmasti nopeampaa käsitellä ohjelmassa, eli se tuskin ainakaan vaikeuttaa ohjelmointia. Juuri tuon pelin myöhemmän seuraamisen kannalta sopivan kokoinen ruudukko on myös hyvä.

Jokainenhan voi tehdä omaan koodiinsa optimointeja. Ja minusta tämä optimointi kuuluu jättää ohjelmalle eikä "tuomarille". Itse pelkään vain sitä, että jonkun osallistujan ohjelma kaatuu siksi että ruudukon käsittelystä on tehty liian monimutkaista.

Tietenkin koodi pitää tehdä niin, että se ei pistä merkkejä ruudukon ulkopuolelle. Ja lähetetäänkö tekoäly muuten koodina vai EXE:nä?

lainaus:

Tietenkin koodi pitää tehdä niin, että se ei pistä merkkejä ruudukon ulkopuolelle.

Et tainnut ihan ymmärtää mitä tarkoitin. Oletetaan että peliauleen maksimikooksi on määritelty vaikka 256*256. (eli tämä on MAKSIMIkoko)

Jos pelaaja1 aloittaa pelin pistämällä merkin X ruutuun 48,40 niin eikö pelaaja2 saa pistää 0 merkkiä ruutuun 10,10? Tai ruutuun 240,0? Mihin tarvitaan pelialueen arvoa joka kertoo peliauleen koon? eikös pelialue ole tuo 256*256?

Ai mihinkä tarvitaan tietoa pelialueen koosta? No tietenkin siihen, että tekoäly tietää mihkä saa pistää ja mihkä ei.

Eli siis toisin sanoen en ymmärtänyt vieläkään. :) (ei ole uutta)

Ajatellaan pelialue on dynaamisena keskusohjelman tiedossa, mutta se näyttää tekoälyohjelmalla vain esim. 50*50. Et voi laittaa vaikka pisteeseen 51,51, koska et voi tietää onko tässä ruudussa jo pelimerkki. Kuitenkin tekoälyohjelman pitää tietää, että pelialueen ulkopuolelle voi seuraavalla siirolla kenties jatkaa, joten reunaankin voi joskus kannattaa laittaa..

Ajatellaan myös pelin aloitusta. Ensin aloitetaan pelaaman vasempaan ylänurkkaan. Toinen pelaaja havaitsee olevansa tappiolla ja pistää oman merkkinsä taktisesti oikeaan alanuerkkaan. Tällöin keskusohjelman pitäisi päätellä järkevästi mikä 50*50 pelialue näytetään seuraavaksi. Sen ei kannattaisi siirtyä vähänkään oikealle alaviistoon, minne toinen pelaaja haluaisi jatkaa peliä, vaan sen pitäisi ehkä näyttää entinen pelialue kokonaisuudessaan, jotta toinen pelaaja voisi reilusti jatkaa peliään siinä peliryhmässä, johon peli keskittyi viimeksi. Tämäntyyppiset ongelmat voisi olla hieman hankalia hoitaa ainakin täydellisesti.

Tuli muuten sellainen mieleen, että aloittajalla on tosi suuri etu. Jos ymmärsin oikein erään sivun, niin sen mukaan on todistettu että tavallisessa viiden suora -pelissä aloittaja voittaa aina, jos pelaa täydellistä peliä. Tietokoneiden välisissä ammattilais-peleissä käytetään tasoituksena sääntöä, jonka mukaan aloittaja ei saa tehdä tiettyjä kuvioita.

Helpompi tapa voisi täsä meidän pikku kisassa olla, että pelattaisiin jokaisen tekoälyn välillä 2 peliä, aloitukset vuorotellen. Jos molemmat voittaisivat itse aloittavansa pelinsä, katsottaisiin että kumpi voitti pienemmellä siirtomäärällä. Jos tämäkin menee tasan, tekoälyt ovat kai sitten samanveroisia!

Itse kuitenkin taipuisin siihen, että pelialue määrättäisiin vaikka 256*256 ja vain pelisiirrot pistettäisiin tiedostoon ylös, ei koko pelialuetta..

Noista kahesta ekakappaalesta nyt ei ota erkkikää selvää mutta selvää on se että dynaaminen peliaule ei ainakaan tee pelistä liian helppoa. (se on sitten kokonaan toinen juttu miten pelialuetta rajataan itse "näytöksessä")

Jos nyt käsitin oikein, dynaaminen on sellainen, mikä jatkuu sitä mukaa kun siirtoja tehdään...? En kannata tällaista, menee liian mutkikkaaksi. Kysessähän oli pelkkä tekoäly, niin että ei ruveta änkemään lisäksi sellaista, mikä rajoittaisi niin osallistumista, jotka kuitenkin muuten osaisivat tekoälyn tehdä.

-> jv windy:
Ei se pelialueen dynaamisuus tarkoita sitä, että se vaihtaa näytettävän paikan, vaan että se laajenee pelin edetessä siten, että aina kaikki ristit ja nollat ovat näkyvissä ja vähän ylimääräistäkin.

hunajavohveli:

lainaus:

Jos nyt käsitin oikein, dynaaminen on sellainen, mikä jatkuu sitä mukaa kun siirtoja tehdään...? En kannata tällaista, menee liian mutkikkaaksi.

Jos pelialue ei ole dynaaminen, niin tekoäly joutuu ottamaan huomioon alueen laidat, mikä sekin on monimutkaista. (Tämä ei silti tarkoita, että olisin itse dynaamisen kannalla :-)

No totta hemmetissä laidat pitää voida ottaa huomioon. Pitäähän tekoälyn nyt tietää, miltä aluuelta mahdollinen siirto on valittava.

Eihän tällainen nyt käy:

FOR a = 1 to ääretön
FOR b = 1 to ääretön
NEXT b
NEXT a

Jos nyt QB-koodia esimerkkinä käytän. Vai oliko idea siinä, että silmukat ulottuvat tietyn määrän ruutuja niiden alueiden ulkopuolelle mihin kyseiseen tilanteeseen asti on tehty siirtoja? Toivottavasti osasin selittää niin että tajusitte.

Laaksonen:

lainaus:

Ruudukon koko voisi lukea vaikkapa tiedoston ensimmäisellä rivillä

Tämä olisi varmaan järkevää, tekoälyohjelmasta tulisi myös yleiskäyttöisempi, kun pelialue ei olisi sidottu ainostaan yhteen tiettyyn kokoon.

tn:

lainaus:

-> jv windy:
Ei se pelialueen dynaamisuus tarkoita sitä, että se vaihtaa näytettävän paikan, vaan että se laajenee pelin edetessä siten, että aina kaikki ristit ja nollat ovat näkyvissä ja vähän ylimääräistäkin.

En tätä tarkoittanutkaan. Kirjoitin:

lainaus:

Ajatellaan [että] pelialue on dynaamisena keskusohjelman tiedossa, mutta se näyttää tekoälyohjelmalla vain esim. 50*50.

Laaksonen kirjoitti aiemmin:

lainaus:

Taulukko näkyisi ohjelmille staattisena, jolloin sen käsittely on helppoa, mutta oikeasti se kuitenkin olisikin dynaaminen.

Yritin juuri osoittaa, että tällainen tapa johtaisi moneen ongelmaan..
Toki tietokoneen dynaamiselle muistinvarauksellekin on rajansa muuttujatyyppien mukaan tai oikeastaan viimeistään muistin loppuessa.

Hunajavohveli:

lainaus:

Jos nyt käsitin oikein, dynaaminen on sellainen, mikä jatkuu sitä mukaa kun siirtoja tehdään...? En kannata tällaista, menee liian mutkikkaaksi. Kysessähän oli pelkkä tekoäly, niin että ei ruveta änkemään lisäksi sellaista, mikä rajoittaisi niin osallistumista, jotka kuitenkin muuten osaisivat tekoälyn tehdä.

Ei dynaamisen taulukon käsittely periaatteessa ole sen vaikeampaa ole kuin staattisenkaan. Muistinvaraus pitää hoitaa eri tavalla (tietääkseni se onnistuu Q-Basic:ssä), mutta vaikkapa kaikkien ruutujen läpikäyminen ei muutu toimintaperiaatteeltaan. Loopissa asetetaan raja, että miten monta kertaa käyt sen läpi. Staattisessa taulukossa tämä on aina vakio, dynaamisessa tämä on ylhäällä vaikka muuttujassa. Luulisin, että kilpailussa pärjäävät osaavat kyllä dynaamisen muistinkäsittelyn, tai ainakin ymmärtävät sen toiminnan.

Jaa'a, toivotaan sitten, että minäkin nyt tajusin sen.

Ehkä muuttumattoman kokoinen ruudukko sittenkin on parempi, jotta vältytään turhilta epäselvyyksiltä ja vaikeuksilta. Ja pelejä voidaan toki järjestää eri kokoisilla ruudukoilla. Internet-sivuille on helppo karsia näkyville aina vain se peliruudukon osa, jossa on merkintöjä.

Olen kyllä samaten edelleen sillä kannalla, että ruudukoiden koko voi kyllä vaihdella, mutta se pitää olla luettavissa tiedoston ensimmäiseltä riviltä.

Ehkäpä se on yksinkertaisin ratkaisu (minä olisin kyllä alunperin halunnut pitänyt enemmän tehokkaammasta ja reaaliaikaisesta ratkaisusta).

Pelikentän koko, X ja Y on varmaan hyvä olla tiedostossa ylhäällä. Näin voidaan pelata myös isomman alueen pelejä, jos pienemmällä alueella tulee tasapeli. Tai ehkäpä pelialuetta voidaan laajentaa 64*64->128*128, jos entinen on jo liian täynnä, tämä vaatisi ruudukko-tiedoston muuttamista tuomariohjelmalta. Tekoälyohjelmathan eivät olisi yhtään tietoisia tästä, koska käynnistyvät aina uudestaan jokaisen oman vuoronsa kohdalla.

Pelitilanne olisi pienen pelin ollessa kyseessä tehokkaampaa ladata siirroittain, mutta varmaan yksinkertaisinta olisi muodostaa ruudukko siitä. Jos pelikentän lataaminen ei aiheuta paljon aikaa (mikä kuuluu myös siirrolle annettavaan aikaan), niin se olisi yksinkertaisinta tehdä varmaan sitten ASCII-muodossa. Ehkäpä näin:

####X
#XOX#
#OXX#
#XOOO
X#XO#

Ensin meinasin merkitä tyhjää nollalla, mutta sen sekottaisi helposti(ihmis-lukija), ellei sitten merkitse myös ristiä ja nollaa numeroilla, mutta ne eivät ole niin selkeitä lukea. Nyt tyhjä on siis ruutu.

Näitä olisi suhteellisen helppo lukea tekstimuodosta taulukko-muuttujaan. Pelkkiä siirtoja olisi vielä helpompi ladata. Mutta pidetään homma yksinkertaisena.

Onko ajateltu sitä miten vuoronjako olisi paras toteuttaa?

Oma mielipiteeni ruudukon koosta on että yhdenkokoinen ruudukko yhtä peliä kohden, jonka koko kerrotaan tiedoston ensimmäisellä rivillä ja seuraavaksi tulee merkkien paikat koordinaattimuodossa x,y:<merkki>;
====esimerkki 1=======
64x64
5,5:O;5,4:X;4,5:O;....
======================

====esimerkki 2=======
64x64
5,5:O
5,4:X
4,5:O
...
======================

Eli tuollanen tuli näin nopeasti mieleen.

Itse ehdotin aiemmin, että päätetään ristin aloittavan aina. Kun tämän kaikki tietää ei tule ongelmia, eikä tarvitse turhaan sitä kertoa jokaisella rivillä.

Mitä mieltä olette, kirjoitetaanko tiedostoon muuttujia binääri-muodossa vai ASCII-muodossa tekstinä?

Oletteko ajatelleet sitä, että aloittajalla on suuri etu? Kirjoitin tästä joitakin viestejä aiemmin.

Ehdottaisin binäärimuotoa nopeuden takia.

Ja tuon aloittaja-edun voi poistaa kahdella "erällä", niinkuin jossakin aiemmassa viestistä esitettiin.

Itse olen ASCII-muodon kannalla, koska tietojen lukeminen on nopeaa tallennustavasta riippumatta. ASCII-muodon etuina on se, että tiedostoja voi lukea tekstieditorilla ja kaikki ohjelmat pystyvät varmasti lukemaan samanlaisia tiedostoja.

Kuinkahan suuri aloittajan etu on? Ainakin omien havaintojeni perusteella ristinollassa taitavampi pelaaja tapaa voittaa aloittajasta riippumatta. Paras mahdollinen tekoäly kenties voittaa jokaisen aloittamansa pelin, mutta jos joku onnistuu sellaisen tekemään itse, niin silloin lienee kilpailun voittokin ansaittu. Joka tapauksessa aloittajan voisi ehkä arpoa aina ennen peliä.

Kyllä kaikilla yleisesti käytetyillä ohjelmointikielillä pystyy lukemaan binääri-muotoista dataa ihan niin kuin ASCII:takin (tai Unicodea). Vähän vaikeampaa se tosin on.

Itse olen havainnut (yläasteella pelattiin paljon ristinollaa erityisesti yhden tyypin kanssa), että aloituksella on todella merkitystä. Monesti otimme uusiksi pelin, koska aloittaja voitti, ja usein tällä toisella yrittämällä sillä kertaa aloittanut voitti jne. Ei tietenkkään aina, mutta tällaista muistelisin. Riippuu tietenkin pelaajien tasoeroista joskus aika paljonkin, minä ja kaverini olimme hyvin samantasoisia (mutta välttämättä samantyylisiä).

Löysin sivun, jossa ehkäpä vastaus aloittajan etuun. Tavallinen viiden-suora on englanniksi Go-Moku. Renju on tästä variaatio, joka sisältää aloittajaa rajoittavia sääntöjä. Renjusta löytyy tietoa osoitteesta http://renju.nu/. Sivulla kysytään "Why can black always win when you play without any rules" ja vastauksessa sanotaan "there is an advanced computer proof". Sitten viitataan sivuun http://www.cs.vu.nl/~victor/thesis.html. Täytyypä lukea kun on aikaa.

Tämä meidän kisamme ei kylläkään ole mikään maailmanmestaruuskisa, mutta jotta kukaan ei ole toista edullisemmassa asemassa, ehdottaisin että jokainen tekoälypari pelaisi 2 peliä. Jos molemmat voittaisivat omat pelinsä, katsottaisiin kumpi voitti nopeammin. Jos tämäkin menisi tasan, ratkaisu olisi tasapeli!

Oletetaan että 2 meidän kilpailuun osallistujaa tekee täydellisen tekoälyn. Edellä lainaamani mukaan aloittaja kuintenkin voittaa, eikä se ole reilua. Koska pelit voi automatisoida ja miksei koko kilpailun kaikkia pelejäkin, ei pelit varmaan kovin kauaa kestä.

Entä jos kumpikin on vuorollaan aloittaja sillain että jos aloittaja voittaa ensimmäisen erän, niin pelataan sitten toinen erä ja siinä häviäjä aloittaa. Jos nytkin voittaa aloittaja, niin tekoälyt ovat tasavertaisia.

-Grey-

Tuota juuri tarkoitin.

Mutta toisaalta, jos aloittaja häviää pelin, ei toista peliä tarvita vaan paremmuus on jo selvä.

On matemaattisesti todistettu, että ristinollassa aloittava pelaaja voittaa AINA ja POIKKEUKSETTA, jos osaa pelata oikein. Mutta kaikista tekoälyistähän ei voi millään tulla sellaisia huippupelaajia, joten on tässä kilpailussa sentään jotain mieltäkin.
Ja ASCII ehdottomasti. Pysytään aiheessa, eli ristinollassa. Kaikki muu on toisarvoista ja voidaan yksinkertaistaa niin, että jokainen pystyy ne ohjelmoimaan.
Laaksonen päättäköön luetaanko tiedostosta pelitilanne vai siirrot. Itse olen siirtojen kannalla, koska ihmistenkin keskeisessä pelissä kumpikin tietää mihin on siirretty ja missä järjestyksessä.

lainaus:

Tai ehkäpä pelialuetta voidaan laajentaa 64*64->128*128, jos entinen on jo liian täynnä, tämä vaatisi ruudukko-tiedoston muuttamista tuomariohjelmalta.

No haloo nyt! Miten tekoäly voi pelata jos se toteaa että tuossa on vihollisella neljän suora, mutta onneksi vihollinen ei voi jatkaa sitä, koska seinä tulee eteen. Sitten seuraavalla siirolla seinä on hävinnyt.

lainaus:

Pelkkiä siirtoja olisi vielä helpompi ladata. Mutta pidetään homma yksinkertaisena.

Aivan. Miksi sitten sanoit että "mutta varmaan yksinkertaisinta olisi muodostaa ruudukko siitä" jos se ei sitä sinunkaan mielestä ole.

Tuo sama laajenemisongelma kävi minullakin mielessä. Eiköhän ole jo paras antaa Laaksosen päättää, tuleeko ruudukosta dynaaminen vai ei. Itse kannatan ei.

lainaus:

lainaus:

Tai ehkäpä pelialuetta voidaan laajentaa 64*64->128*128, jos entinen on jo liian täynnä, tämä vaatisi ruudukko-tiedoston muuttamista tuomariohjelmalta.

No haloo nyt! Miten tekoäly voi pelata jos se toteaa että tuossa on vihollisella neljän suora, mutta onneksi vihollinen ei voi jatkaa sitä, koska seinä tulee eteen. Sitten seuraavalla siirolla seinä on hävinnyt.

Tämä kävi itselläkin mielessä. Siksi pistin sanan LIIAN täynnä. Pelikentässä pitäisi varmaan olla aina 5 ruutua tyhjää tilaa reunoilla joka suuntaan. Tosin joitakin usemman siirron suunnitelmia reuna kuitenkin häiritsee, ja tämä ongelma on aina (varatun tilan tai koko muistin loppuminen). Jos tämä kasvatus kesken peliä käy liian vaikeaksi, niin "pelejä voidaan toki järjestää eri kokoisilla ruudukoilla", kuten Laaksonen sanoi.

lainaus:

lainaus:

Pelkkiä siirtoja olisi vielä helpompi ladata. Mutta pidetään homma yksinkertaisena.

Aivan. Miksi sitten sanoit että "mutta varmaan yksinkertaisinta olisi muodostaa ruudukko siitä" jos se ei sitä sinunkaan mielestä ole.

Sanoin ehkä vähän hassusti. Tarkoitus oli ilmaista, että pelkkien siirtojen tallentaminen ja lataaminen on tehokkaampaa ja yksinkertaisempaa kuin ruudukon. Ruudukkoa on taas ihmisen helpompi katsella (hänen kannaltaan yksinkertaisempaa). Pelejä kuitenkin katsellaan netissä, jossa muodostetaan niitä varten kuva tai ruudukko, niin tätä ongelmaa ei ole. Kaikkia kuitenkin kiinnoistaisi siirtojen järjestys, joten ruudukko muoto olisi kyllä tällöin turha lisä siirtomuotoiselle tallentamiselle.

lainaus:

Hunajavohveli:Mutta kaikista tekoälyistähän ei voi millään tulla sellaisia huippupelaajia, joten on tässä kilpailussa sentään jotain mieltäkin.

Varmaan juuri siksi tämä kiinnostaa monia, koska ovat ajatelleet joskus tekevänsä ristinollatekoälyn, mutta idea tai toteutus on jäänyt kesken (kuten minulla). Olen edelleenkin sitä mieltä, että reiluinta olisi järjestää uusi peli, jos aloittaja voittaa ja päätellä seuraavan pelin perusteella voittaja (voitto viimeistään pienimmällä siirtojen määrällä aloitusvuorolla), tai että peli päättyi tasan. Useampaakin peliä voisi järjestää, koska tekoälyissäkin on varmaan useimmiten satunnaisuutta, ainakin symmetrisissä tilanteissa (pelataan vaihtelevasti hämäten vastustajaa). Yleensäkin eri tilanteisiin on monia eri tyylejä pelata, paras riippuu vastustajasta (jos sen pelitavan tuntisi hyvin). Edit: Unohtui: Mutta maksimissaan 2 peliä riittää varmaan aivan hyvin meidän kisaamme. Jos sattuu tulemaan todella hyviä tekoälyä, jotka pelaavat tasan, voidaan näiden kesken pelata pidempiä pelejä isomma alueella.

Ilman muuta tämä siksi juuri kiinnostaa. Ja olen itse juuri samaa mieltä, että jos molemmat tekoälyt voittavat aloittaessaan, järjestetään uusintoja tietyy määrä. Jos tasapeli pysyy edelleen, tulos on lopullinen tasapeli. Jos taas tekoäly ei aloita, mutta voittaa silti, se on voittaja.

Tuosta vastustajan pelitavasta: Voisihan kehittää toki tekoälyyn sellaisen, että sen muistissa on paljon eri tyylejä pelata. Sitten se katsoo, mitä niistä vastustaja käytää, ja siirtää sitä vastaan parhaalla mahdollisella tavalla. Tosin tällä tavalla ja satunnaisuudella ei voi koskaan saavutta tekoälyä, joka voittaisi aina sillä tavalla miten se matemaattisesti on todistettu, sillä täydellinen tekoäly tekisi aina samanlaiset siirrot juuri niihin paikkoihin, mihin pitää.

Tehdyt siirrot on varmasti parempi tallennustapa kuin kokonainen ruudukko, koska silloin tekoäly saa halutessaan tietää myös siirtojen järjestyksen. Internetissä pelejä tietenkin tarkastellaan ruudukkomuodossa (siirrot näkyvät siinä samalla).

Kaksi peliä tekoälyparia kohden on myös hyvä idea, molemmat saavat aloittaa vuorollaan.

Antti Laaksonen kirjoitti:

Tehdyt siirrot on varmasti parempi tallennustapa kuin kokonainen ruudukko, koska silloin tekoäly saa halutessaan tietää myös siirtojen järjestyksen. Internetissä pelejä tietenkin tarkastellaan ruudukkomuodossa (siirrot näkyvät siinä samalla).

Kaksi peliä tekoälyparia kohden on myös hyvä idea, molemmat saavat aloittaa vuorollaan.

Voitaisiinkohan nämä Laaksosen mainitsemat asiat lyödä nyt lukkoon, ettei tarvitsisi koko ajan niistä keskustella ja väitellä? Nämä ovat minustakin ehdottomasti parhaimmat vaihtoehdot.

hunajavohveli kirjoitti:

Voitaisiinkohan nämä Laaksosen mainitsemat asiat lyödä nyt lukkoon, ettei tarvitsisi koko ajan niistä keskustella ja väitellä? Nämä ovat minustakin ehdottomasti parhaimmat vaihtoehdot.

Sopii ainakin minulle. Nämä olivat myös minun viimeisin kantani.

Laaksonen varmaan tekee tämän tuomari-ohjelman? Itse teen joka tapauksessa sellaisen, koska haluan kokeilla eri tyylisiä ratkaisuja, kokeilla niiden pelaavan keskenään. En muuten usko, että ainakaan itse pystyn tekemään parempaa tekoälyä, kuin mitä minä olen :) Ellei sitten jotain tosi hyviä ideoita keksi, kuten monen siirron päähän ennustavaa kokeilua, jonka toteuttaisi järkevästi.. Oman tekoälynsä toiminnan ja puutteet tulee kuitenkin havaittua testatessa varmaan aika hyvin. No, saa nähdä mitä tästä tulee.

Joo, eiköhän ristinollakisaan liittyvät asiat ala olla pääpiirteissään sovittu. Koetan tässä lähiaikoina tehdä tarvittavat ohjelmat sekä kirjoittaa säännöt, niin kilpailu pääsee alkamaan.

Tuli tossa mieleen että mites satunnaisuuden kanssa, meinaan että jos satunnaisuus kielletään säännöissä niin silloin jokainen voisi ottaa revanssin matsista omalla koneella ja kahden tekoälyn välinen tulos on aina sama. (satunnaisuushan ei pitäisi kuulua älyyn)

Tokihan tämä voi joidenkin mielestä tuntua rajoitukselta jos haluaa pelata tuurilla.

Niin sitähän minä sanoinkin, että täydellinen äly tekee aina oikean siirron (joita on vain yksi kappale per tilanne) joten satunnaisuutta ei pitäisi olla. Mutta koska kaikki eivät osaa tehdä täydellistä älyä, voi heille olla satunnaisuudesta korvaavaa hyötyä, joten ei missään nimessä evätä tätä mahdollisuutta.

hunajavohveli kirjoitti:

Mutta koska kaikki eivät osaa tehdä täydellistä älyä, voi heille olla satunnaisuudesta korvaavaa hyötyä, joten ei missään nimessä evätä tätä mahdollisuutta.

Ei se nyt sentään ihan noin mene. Jos alussa toinen pistää merkin keskelle ruutua on aivan sama onko tekoäly täydellinen vai ei niin on ainakin 4 saman-arvoista paikkaa. Eli sovitaan vain että tälläisessa tilanteessa tekoälyn on vain päätettävä joku "suunta" mihin pistetään. Se voi toki "arpoa" vaikka siirtojen määrän perusteella kunhan se uudelleenpelattaessa tekee samoin. (tarkennus: eli jos siirtoja on tehty vain 1 niin suunta on tietty mutta jos samanlainen tilanne tulee siirrolla 11 niin suunta on joku toinen)

Tai oikeastaanhan riittäisi että tekoäly vain alustaa satunnaislukugeneraattorin siemenluvulla. (eikä käytä timeriä)

Mutta jos tälle nyt on vastustusta ihan vain periaatteesta niin en ala tappelemaan.

Miksi kummassa Timeria ei saisi käyttää? Siitä voidaan lähteä, että aloittava tekoäly pistää jokatapauksessa merkkinsä keskelle, koska aloituskohdalla ei ole pelin kannalta mitään merkitystä, mutta ohjelmointi helpottuu.
Mutta siitä eteenpäin pitää tietysti olla ihan vain kiinni tekoälyistä, mihin ne siirtävät, ja minusta siirtojen valinnan saa itse kukin koodata miten haluaa. Sitä ei ruveta rajoittamaan, sanon minä.

hunajavohveli kirjoitti:

Miksi kummassa Timeria ei saisi käyttää?

Siksi että se ei auta yhtään. Ja etuna olisi se että jokainen voisi myös jälestäpäin tutkia mikä omassa tekoälyssä oli huonoa/hyvää. Miksi tekoälyt pelasivat niinkuin pelasivat jne. Unload.me

No entä sitten vaikkei auttaisikaan? Sinua ei ehkä auta, mutta jota kuta toista voi hyvinkin auttaa, jos saa sen avulla edes jotenkin paremman tekoälyn, mikäli ei osaa täydellistä tehdä.
Ja jos haluaa tutkia, miksi tekoäly pelaa niin kuin pelaa, niin eikö siirron syyksi riitä, että äly teki satunnaisen siirron?

Taidanpa jättää asian tähän koska selittämiseen menisi vähän turha paljon aikaa/tilaa. Tietokone kun ei vaan osaa satunnaisuttaa, ei randomize timer oli mitään satunnaisuutta, ei se siirto ole satunnainen vaa se on juuri se tietty siirto tiettynä kellonaikana. Ohjelma tekee juuri samansiirron aina jos kello on yhtä paljon.

hunajavohveli kirjoitti:

Laaksonen mainitsi kyllä asian aikaisemmin, ellet huomannut.

En huomannut, tämä tapahtui viestissä nro?

Kyllä varmasti hyvät tekoälyt pistävät jonkin verran (näennäistä mutta tarpeeksi hyvää) satunnaisuutta mukaan symmetrisissä ja muissa tilanteissa, joissa on ihan sama, että mihin muutamasta samanlaiseen tilanteeseen johtavasta paikasta pistää. Näin voidaan hämätä vastustajaa :)

Varmaan Kasparov olisi periaatteessa voinut voittaa ei-satunnaisen ja muuttumattoman tietokonetekoälyn shakissa, jos olisi oletetun 1. voittonsa jälkeen pelannut aivan samalla tavalla seuraavat pelit. Luulisin, että hän muistaisi pelin kulun aika hyvin..

No voi, eikö se nyt mennyt poistamaan sen viestini, kun yritin muokata! Melkein ehdin pysäyttää, mutta en aivan. Niin joo, muistin kai väärin, se oli kai joku toinen, kun en löytänyt enää.
Edit: Itse asiassa se oli jv windy

jv_windy kirjoitti:

Kyllä varmasti hyvät tekoälyt pistävät jonkin verran (näennäistä mutta tarpeeksi hyvää) satunnaisuutta mukaan symmetrisissä ja muissa tilanteissa, joissa on ihan sama, että mihin muutamasta samanlaiseen tilanteeseen johtavasta paikasta pistää. Näin voidaan hämätä vastustajaa :)

Korjataan nyt senverran että tarkoitus ei ole poista satunnaisuutta, ainoastaan sen kytkeminen kelloon.

Onko siis ehdotuksia, miten tässä tapauksessa hoitaisit satunnaisuuden käyttämättä BIOSin kelloa? Ehkä jollain nopeustestillä tai vastaavalla, josta saisi seedin...? Nopeustesteissähän luvut vaihtelevat, paitsi että miten testata nopeus, jos Timeriä ei saa käyttää?

Joskus käytettiin sellaista tapaa, että seurattiin käyttäjän hiiren liikuttamista ja näppäimistön painalluksia. Ne eivät kyllä käy tähän.

Nopeustestitkin perustuvat aikaan. Itse olen satunnaisia lukua generoidessa käyttänyt yleensä aikaa, kyllä se on tarpeeksi satunnainen. Sähkön jännitteet ja virta vaihtelevat jonkun verran, pienet nopeuserot taitavat johtua tästä. Hyvä satunnaislukualgoritmi taitaa olla sellainen, jonka on syy-seuraus-suhde on mahdollisimman pitkä. Esim. tarkka aika on tällainen, tai jokin muu tietokoneen ulkopuolella oleva mitattava kohde.

Mutta itse kilpailusta: Tekoälyn tekeminen taitaakin olla vaikeampaa kuin aluksi luulin.. tai sitten koitan ajatella liian vaikeasti.

Mikäs on tämän kilpailun tilanne? En halua mitenkään hoputtaa, mutta kun tästä puhuttiin niin kovasti lähes pari kuukautta sitten, että rupesin ihmettelemään, miksi koko kilpailu on aivan unohdettu. En viitsisi ruveta kehittämään omaa tekoälyäni ennen varsinaista kilpailun avaamista. Eli mikähän mahtaa olla tilanne? Onko se kilpailun hoitava ohjelma tulossa piakkoin?

Minäkin ehin jo aikani kuluksi tehdä (ja formatoimalla tuhota) 3x3 ristinollan ja siihen vastustaja tekoälyn, kun kilpailusta ei mitään kuulunut.

[offtopic]
Teitkö rekursiolla, vai jollain muulla tekniikalla?
[/offtopic]
Kyllä tämän kilpailun voisi jo minunkin mielestäni kohta julistaa. Eikä siinä tarvitse välttämättä olla edes palkintoa.

Antti Laaksonen kirjoitti:

* QBasic-demo, joka täytyy toteuttaa QB:n omilla komennoilla ilman konekieltä tai apukirjastoja.

Tuollainen olisi ihan kiva kilpailu.

Olette oikeassa, kilpailun alku on viivästynyt enemmän kuin on ollut tarkoitus. Mutta kilpailu ei missään nimessä ole unohtunut tai peruuntunut! Kouluhommat alkavat pikku hiljaa helpottaa, ja teen parhaani asian suhteen.

Mie ehdottaisin jotain demokompoa tai vastaava nyt kesän aikana. Jokin rajoitus olisi kiva, esim. max 4kt lähdekoodi tms.

lainaus:

Teitkö rekursiolla, vai jollain muulla tekniikalla?

Mitäköhän sekin tarkoittaa?
Tein ihan vain if-lauseilla.

EDIT: Demoa kannatetaan. Tuo tekoäly alkoi mennä liian monimutkaiseksi.

demokompo olis ihan kiva. tosin minusta sorsien kokoa ei kannata rajoittaa. mieluummin vaikka 1-2Mb rajotus koko paketille, tai sitten ihan rehellinen minidemo, jossa koko paketti saa olla esim. 64Kb.

Antti Laaksonen kirjoitti:

Olette oikeassa, kilpailun alku on viivästynyt enemmän kuin on ollut tarkoitus. Mutta kilpailu ei missään nimessä ole unohtunut tai peruuntunut! Kouluhommat alkavat pikku hiljaa helpottaa, ja teen parhaani asian suhteen.

Hienoa, jos saadaan kesäksi tuo kilpailu. Aloin vain vähän huolestua. :)

Ja muut: Jospa puhuttaisiin niistä muista kilpailuista sitten myöhemmin, kun tämä ristinolla on jo kerran vakiintunut tälle aiheelle? Ikävä puhua näin ristiin kahdesta eri kilpailusta. Toivon kyllä tuota QB-demoakin, mutta jos puhuttaisiin siitä sitten tuon ristinollan jälkeen?

Hei muta ei mitää tekö äly kilpailuja vaan vaikka taso hyppely peli kilpailu!

Tuota 64 kilon demoa kannatetaan!!!
Onko sallittua käyttää asmia ja directX:ää?

Edit: Millä kielellä tämän demon saa ylipäätään toteuttaa(jos tämä demoidea menee läpi)?

Kilpailussa ei saisi olla minun mielestä teko älyä ellei halua.

Idea on hyvä mutta eikä tuo 64 kiloa ole hieman liian vähän?
Itse ehdottaisin 0.5 megaa johon pitäisi sisältyä kuvat , musiikit ja koodi.
Luulisin että kieli ei olisi vain yksi tietty vaan, voisi käyttää yleisempiä eli: visual basicia, qbasicia , c++ yms.

Yksi hyvä ideahan voisi olla että musiikkia saa tehdä mutta
kaikki grafiikat täytyisi piirtää koodilla ja koon rajoitus olisi suurin piiretein se 0.5 - 1 megaa!
Näin saataisiin ehkä hieman tavallisesta poikkevia pelejä ja
haastettakin riittäisi!

Laittakaa nyt kaikki omia mielipiteitänne tulemaan!

Mielestäni tuo 64 kiloa on ihan riittävä.
Grafiikathan voi pakata exeen tai luoda algoritmisesti reaaliajassa(perlin noisa/fault noise/metapallot/ray tracing)
Voihan kilpaulussa olla monta sarjaa:
4 kiloa tosi guruille(pelkkä asm siis)
64 kiloa keskivaikeaksi
sitten tuo 1 mega jos haluaa tehdä vähän helpomman demon.

Millä kielellä meinasit itse ohjelmoida?
Itse tarkoitin että tuossa aikaisemmassa viestissä että oltaisiin oltu tekemässä peliä mutta sinä kai tarkotit jotain muuta tuossa toisessa keskustelussa..
Selittäisitkö sen vielä vähän tarkemmin.

Siis ajattelin ihan perusdemoa.
Kieli olisi täysin vapaa.
Tai jos tämä tuottaa eripuraa(joidenkin mielestä c++ on epäreilua) niin voisihan eri kieliryhmille olla omat sarjat(c++ + delphi + pascal) ja (vb + qb).

Edit: Tosin on ehkä järkevämpää hoitaa ensin tämä ristinolla kilpailu pois alta, vaikka pidän tätä demoa mukavampana.
Edit2: ja eikös siitä ristinolla lyöty lukkoon jo vähän aikaa sitten?
Se ei siis varmaan voi enää vaihtua. :(

Minä kannatan tässä asiassa tuomasta

Ja minä taas en jos ei graffa saa itse piirtää niin on se aika tyhmää aloitelijat eivät voi osalistua kisaan kun eivät ole niin hyviä !

Demokompo olisi todella hyvä idea, osallistuisin paljon mieluummin kuin tuohon tekoälykisaan. Sarjojakin voisi tuossa demokisassa olla pari eritasoista esim. 64 kilon ja sitten vaikka 1 - 2 megan. Kaikki kielet kävisivät kilpailuun, mielestäni erillisiä sarjoja esim. C++:lle ja VB:lle ei tarvita.

peki kirjoitti:

Edit2: ja eikös siitä ristinolla lyöty lukkoon jo vähän aikaa sitten?
Se ei siis varmaan voi enää vaihtua. :(

Voihan molemmat järjestää :) Ne ketkä tykkäävät osallistuvat ristinollaan ja ne, jotka pitävät democompoon tekemisestä, osallistuvat siihen. Tai sitten molempiin, jos kiinnostusta ja aikaa riittää.

Ristinollakilpailun aloitus tosiaan venyi, mutta varmaan kesäkuussa se voitaisiin järjestää? Ehkäpä Democompo olisi tämän jälkeen? Tai yhtäaikaa, ellei tälle ole esteitä?

Näihin kilpailuihin näyttäisi olevan paljon innokkaita osallistujia, toivottavasti kaikki vielä jaksavat osallistua niihin, että hyvästä kokemuksesta näitä järjesttäisiin myöhemminkin lisääkin :)

Omasta mielestäni palkinnot eivät ole välttämättämiä näissä pikkukilpailuissa. Ristinollateköäly on jäänyt minulla tekemättä ja olisi muuten vain kivaa pistää tietokoneohjelmia kisaamaan keskenään ja katsomaan miten ne pärjäävät :)

Itselläni työkiireet luultavasti vain lisääntyvät kesällä, mutta aion silti hyvin varmasti koittaa osallistua ristinollakilpailuun.

Tuskin siitä muuten haittaa on, jos ryhtyisi jo etukäteen tekemään kilpailutekelettä, kunhan sen tekee sovittujen sääntöjen mukaan vain tätä kilpailua varten ja itsenäisesti kopioimatta muualta. Ristinollan kohdalla säännöthän sovittiin jo, democompo:ssa pitää kai sopia sääntöjä vielä paremmin.

Olen ihan samaa mieltä noissa asioissa, jotka jv windy mainitsi. Palkintoja ei mielestäni tarvita, ja molemmat kilpailut voidaan minun puolestani järjestää. On minullakin oikeastaan jo pohja valmiina tuohon ristinollaan, mutta rupean varsinaisesti kehittämään vasta, kun kilpailu avataan. Täytyyhän siihen ensin saada jonkinlaiset säännöt ja standardit, joita tekoälyn on noudatettava.

Kilpailussa olisi hyvä palkinto esim kääntäjä.

On varmaan hyvä idea järjestää molemmat kilpailut, tekoäly ja demo, niin mahdollisimman moni pääsee osallistumaan mieluisaan kilpailuun. Ei kuitenkaan yhtä aikaa, vaan toinen alkukesästä ja toinen loppukesästä. Otan tavoitteeksi, että ristinollakisa alkaa 1.6., demojuttua voidaan miettiä tarkemmin sen jälkeen.

Kiva kun kesällä jotain kilpailuja. Kouluaikoihin ei edes viikonloppuna jaksa kunnolla keskittyä koodaamiseen. Eikä palkinnoilla mitään väliä, pääasia että pääsee tekemään jotakin ja näkemään tulokset =)

~jc

Sitäpaitsi onhan voittajaan kohdistuva rispektin tulva jo riittävä palkinto.
XD XD LOL LOL

teksturi kirjoitti:

Kilpailussa olisi hyvä palkinto esim kääntäjä.

Joo, ja IDE ja grafiikkakirjasto. Esimerkiksi Mingw, Dev-C++ ja Allegro. :)

No noitahan saa netistäkin (osaa jopa laillisesti) ladattua.

niin muttei täys versioita.

Tämä nyt on vähän offtopic mutta voisitte opetella ne yhdyssanat edes joskus, on hyvin ärsyttävää lukea tekstiä kun huomaa että kaikki yhdyssanat on päin kuusta.

Ja offtopiccina pysyy:

Kaviaari kirjoitti:

Tämä nyt on vähän offtopic mutta voisitte opetella ne yhdyssanat edes joskus, on hyvin ärsyttävää lukea tekstiä kun huomaa että kaikki yhdyssanat on päin kuusta.

Minusta on hyvin ärsyttävää kun yhdyssanoista valitetaan aina. Täällä olisi paljon vähemmän turhia viestejä jos yhdyssanoista huomauttelu olisi jätetty pois. Katsos kun tällaiseen ärsyttävään huomautteluun pyritään vastaamaan (niinkuin juuri minäkin tein ;) ja offtopic vaan jatkuu. Tämä saa sitten olla viimeinen viestini joka koskee tätä asiaa.

Kilpailuihin ei ole tulossa varsinaisia palkintoja, mutta en usko sen haittaavan. Erityisesti ristinollakilpailussa kaikkein mielenkiintoisin osuus on tietenkin se, kun tekoälyt pannaan vastakkain. Siinä ei muuten tarvita kävijä-äänestystä ollenkaan.

Kaviaari kirjoitti:

Tämä nyt on vähän offtopic mutta voisitte opetella ne yhdyssanat edes joskus, on hyvin ärsyttävää lukea tekstiä kun huomaa että kaikki yhdyssanat on päin kuusta.

Jos valittaa tällaisesta asiasta, niin kannattaisi totisesti pitää huolta siitä, että se oma viesti on sitten oikein kirjoitettu. Melkein yhtä ikävää on näet lukea tekstiä, johon pilkut on siroteltu ihan miten sattuu.

Kun tuota kahden tekoälyn ottelua seurataan, niin onko mahdollista, että tästä ottelusta tehdään sellainen, että se on reaaliajassa nähtävissä?
Eli Java appletti, joka näyttää tämän kamppailun reaaliajassa.
Vai tehdäänkö tästä vain listat, joista selviää voittaja?
Olisi mielenkiintosta seurata otteluja selaimen ruudulta.
Jos Javalla on mahdotonta, niin ei olisi kovinkaan vaikeaa koodata ohjelmaa, joka winsocketilla hakee tilanteen koneelta, jossa peli pyörii ja sitten näyttäisi tilanteen ruudulta
Putkasta löytyisi varmasti vapaaehtoisia koodareita tämän tekemiseen!

Edit: Minä mukaanlukien ;D

Eli siis 1.6. alkaa ristinollakilpailu johon voi osallistua kuka vaan ja alustat ja kielet on vapaita, vai?
Itse tekisin pelin Windows9x alustalle VB4Pro:lla, onko mahdotonta? Entä minne valmiit tuotokset sitten upload:taan, jos mahdollista niin lähettäisin e-maililla kun ei ole itsellä kaistaa ja mitään ftp:tä...

Tuo reaaliajassa seuraaminen kuulostaa hyvältä idealta. Pitäis vaan kaikkien olla juuri silloin seuraamassa, mutta tokihan tulokset sitten myöhemminkin näkisi.

sami_jokimies kirjoitti:

Eli siis 1.6. alkaa ristinollakilpailu johon voi osallistua kuka vaan ja alustat ja kielet on vapaita, vai?

Lue aiempia viestejä.

sami_jokimies kirjoitti:

Itse tekisin pelin Windows9x alustalle VB4Pro:lla, onko mahdotonta?

Kyllä onnistuu VB4PRO:lla.

sami_jokimies kirjoitti:

Entä minne valmiit tuotokset sitten upload:taan, jos mahdollista niin lähettäisin e-maililla kun ei ole itsellä kaistaa ja mitään ftp:tä...

Varmaan sähköpostilla, kuten edellisessä palikkapelikilpailussakin (harmittaa muuten kun en itse ehtinyt osallistua).

Itse ehdotin aiemmin, että kilpailu käytäisiin eri osallistujien kesken reaaliaikaisesti, mutta tämä todettiin monen muun mielestä liian hankalaksi ja nostavan osallistumiskynnystä liikaa.

Mutta kilpailun käyminen yhdelläkin koneella reaaliaikaisesti ja pelisiirtojen näyttäminen esim. palvelinpään Javalla tai PHP:n kautta olisi tietenkin mahdollista. Mutta se vaatii taas paljon enemmän työtä kuin se, että pelit näytettäisiin vain jälkikäteen animoituina Myöskin kilpailun (automaattinen) tuomarointi kestäisi tällöin kauemmin. Keskitytään nyt ainakin ensin itse tekoälyjen tekemiseen ja annetaan Antti Laaksosen tehdä tuomariohjelma rauhassa.

Mitä mieltä olisitte, että jos joku tekisi pienen koodivinkin ristinollatekoälystä? Sen pitäisi tietenkin olla ihan perustekoäly, että se ei pystyisi voittamaan. Tai ainakin jonkunlainen pohja, minkä päälle voisi rakentaa tekoälyn.. Näin saataisiin luultavasti enemmän osallistujia. Vai mitä mieltä muut ovat, olisiko se turhaa vai voisiko sillä olla järkevää käyttöä?

Monet säännöt jo sovittiin, mutta miten siirron maksimiajan kanssa on? Onko ehdotuksia? Ei ikuisuuksia, muttei liian lyhyttäkään..

Lisäksi pitäisi päättää tarkat specifikaatiot siirtojen suorittamisesta/vanhojen lukemisesta. Mutta jos joku haluaa jo nyt suunnitella ristinollatekoälyään, voihan ensi hätään tehdä jonkin samalla periaatteella toimivan siirtojärjestelmän ja muuttaa myöhemmin tätä rajapintaa ohjelmassa. Omassa ohjelmassaan siirtoja voi tietenkin käsitellä miten haluaa, koska eri muotoiset siirtodatathan voidaan konvertoida.

Edit: Osallistuuhan Antti Laaksonen myös ristinollatekoälykisaan?? Tuomaroinin puolesta ei ole esteitä, koska se on automatisoitua. Hänen ajastaan en tiedä, mutta kesällä ainakin on lomaa ja hän sanoi keskittyvänsä Ohjelmointiputkan kehittämiseen silloin ja tämä liittyisi siihenkin. Haaste on heitetty :)

Niin ja osallistukaa kaikki vaan keitä vähänkin kiinnostaa! Saadaan mielenkiintoisia tekoälypelejä, joita voidaan analysoida myöhemmin ja vertailla miten kaverilla meni :) Ei haittaa vaikka tekoälystä ei mitään parasta tulisikaan, tuskin omastanikaan.

Olisiko mahdollista julkaista ristinolla-kiplailun voittajan koodi, toki kaikki muutkin koodit voisi julkaista (jos tekijä haluaa).

Tuskin ellei voittaja itse halua.
Moni ei varmastikaan haluaisi laittaa lähdekoodiaan levitykseen jos on tehnyt sitä suurella vaivalla.

Totta, vaikka voisin kyllä ehkä itse laittaa sillä ehdolla, että sitä ei saisi kopioida muuhun kun kokeilu- ja opiskelu käyttöön.
Ja vain silloin, jos koodi olisi erityisen hyvää ja esimerkillistä. :P

Tuohan on periaattessa ihan sama kun antaisit lähdekoodin vaapaksi levitykseen.
Koska eihän sitä käyttöä kukaan valvo.
Juuri tuon takia olisikin hyvä että koodi on levityksessä vain tekijän luvalla.

Kyllä mä ainakin olisin vaan ylpeä jos joku huolisi mun purkkaa projektiinsa :P

zigilii kirjoitti:

Olisiko mahdollista julkaista ristinolla-kiplailun voittajan koodi, toki kaikki muutkin koodit voisi julkaista (jos tekijä haluaa).

Eli voittajaa rankaistaisi. Jos joku haluaa julkaista koodinsa, niin voihan sen lähettää tänne.

Linkku kirjoitti:

Kyllä mä ainakin olisin vaan ylpeä jos joku huolisi mun purkkaa projektiinsa :P

Ei se ole purkkaa vaan sämpylää. XD

Jotenkin tuntuu siltä, että kilpailuun osallistuu paljon vähemmän porukkaa, kuin mitä täällä on ollut uhoamassa.

Tuo voi olla totta koska kaikki eivät tuota tekoälyä osaa rakentaa niin että se pelaisi toista vastaan..
Itse osaan kyllä tehdä jonkinlaisen tekoälyn mutta se ei todellakaan osaa pelata toista tekoälyä vastaan.
Asiaahan tietysti auttaisi kun saisi tietää säännöt sun muut.
Voisihan asiaa toteuttaa niin että Laaksonen tekisi koodin jonka päälle alettaisiin rakentamaan tuota tekoälyä.
Tarkoitan lähinnä koodin pätkää jolloin oma tekoäly tietäisi milloin on sen vuoro yms.

Codewalkerssissa oli joskus kilpailu, jossa piti tehdä ristinollan kaltaista peliä pelaava php-skripti ( http://codewalkers.com/contests/2003-05-05/ ) em. sivulta on ladattavissa myös "tuomariskripti" ja kilpailuun osallistuneet koodit.

Tekoälystä löytyy kovasti tarinoita kun vaivautuu kirjoittamaan googlen hakukenttää sanat: tic tac toe ai

Tuo tekoäly kilpailu alkaa sitten huomenna..
Kuinka moni aikoo näillä näkymin osallistua?
Itse osallistun ainakin tällä kertaa..viimeksi homma kaatui
siihen kun en osannut koodata vielä kovin hyvin.

Voisin periaatteessa osallistua mutta sen näkee vasta sitten kun rupeaa jotain vääntämään. Itse veikkaan ihan samaa kuin ezuli ("Jotenkin tuntuu siltä, että kilpailuun osallistuu paljon vähemmän porukkaa, kuin mitä täällä on ollut uhoamassa") koska kunnon tekoälyn vääntäminen ei oikeasti ole helppo homma.

tuomas kirjoitti:

Kuinka moni aikoo näillä näkymin osallistua?

No pitää nyt kattoo, jos sitä saa jotain julkasukelposta aikaseks. Sitä ei tosiaan tiedä, ennen kuin alkaa vääntämään jotain. Tekoälyt ei oo koskaan kuulunu omiin vahvoihin puoliin.

Ja veikkaan samaa, kuin ezuli ja fawkz.

Mä en ainakaan. Ihan liian hankala mulle :/

En mäkää. Liian helppoo :)

Enpä usko että osallistun, sillä "tekoälyni" olisi kuitenkin joku peittelytaktiikkaa käyttävä p*ska. Mutta seuraan kilpailua mielenkiinnolla.

Pois jään, koska kyllästyin. Ei taida jäädä paljoakaan seurattavaa.

Pakko kai se on sitten osallistua :) Osallistukaa muutkin vain rohkeasti ettei kilpailua aivan turhaan järjestetä :)

Kelpaako jos laitan emäntäni sellaisenaan... tosin ei se taida pärjätä :D

Aion osallistua ainakin jonkinlaisella tekeleellä, mitä ehdin töiden lomassa tehdä. (kesäkuu töitä).

Tuskin se varmaan niin älyttömän vaikea loppujen lopuksi on, moni asia on helpompaa kuin sen luulee ensiksi olevan. Kannattaa koittaa mitä saa aikaiseksi ja tehdä sellainen mitä saa aikaiseksi. Olisi hyvä, että tekoälyjä saataisin useampi, myös eritasoisia.

Antti Laaksonen taitaa myös osallistua, joten siinäkin 1 osallistuja.

Varmaan osallistujia tulee enemmänkin, kuin mitä täällä ilmoittaudutaan..

Kunhan siirtotavat on ilmoitettu, voidaan tekoälyjä alkaa toden teolla tekemään. Mitä mieltä olette, että tehtäisiin koodivinkiksi pieni tekoälyn alku, joka olisi ihan toimiva, mutta jolla ei kuitenkaan voitettaisi kisaa?

Voisihan sellaista ajatella..
jos vain kerkeäisi tehdä.

Haasteelliseksi kilpailun tekee jos tekoälyn oletetaan olevan oppiva.

Kun pelaat ristinollaa sitä vastaan se ei seuraavalla kerralla lankea samaan virheeseen kuin ensimmäisellä kerralla hävittyään vaan yrittää toisenlaista vastausta.

Saisko tästä ny jonkinlaisen lyhennelmän mitä tehdään.. en jaksa selata näitä ~250 viestiä. Ja olisihan se kaikkien mielestä selkeämpää? Osallistun tod.näk. jos selvät säännöt löytyypi.

Kuten varmaan olet huomannut (tai sitten et) täällä putkassa on tuolla oikeassa alareunassa sellainen pieni mainos jossa lukee seuraava "Ohjelmoi tekoäly, alkaa 1.6"
eli huomenna.
Huomenna myös siis ilmeisesti julkistetaan säännöt, kilpailusivu, sallitut kielet, tuomaristo,kilpailu aika yms.
Tuo ehdotus jossa sanottiin että tehdään jokin koodivinkki kilpailuun esimerkiksi ei ehkä sittenkään olisi kovin hyvä jos sallittuja kieliä olisi useampia.
Jollekin kielelle voisi olla esimerkki ja jollekin taas ei.
Sama aloituspiste kaikille!

Tuli vielä mieleen, että kun omaa tekoälyä tehdessä testaa sitä välillä, varmaan tulee tehtyä ohjelma, joka antaa ihmisen pelata tätä omaa tekoälyään vastaan.

Tämä olisi hyödyllinen jokaiselle, ehkäpä joku voisi tehdä tällaisen?

Ainahan voit kasata tekoälystä sellaisen, että se avaa testi-ikkunan ikkunan kun antaa tietyn parametrin ohjelmalle...

Tehkää joskus sellanen kisa että pitää koodata PHP:lla jotakin

Voi tuon tekoälyn tehdä PHP:llakin, kuten aiemmista keskusteluista käy ilmi.