Ohjelmointiputkassa alkaa tänään taas tekoälykilpailu. Aiheena on kahden pelaajan lautapeli, jossa yksi yrittää vallata laudalta mahdollisimman suuria yhtenäisiä alueita ja toinen yrittää estää tämän.
Osallistumisen helpottamiseksi on jälleen tarjolla esimerkkiohjelma muutamalla yleisimmällä kielellä sekä Javalla tehty testausohjelma, jolla voi pelata omaa tekoälyään vastaan. Aiemmista kilpailuista poiketen tällä kertaa saa myös osallistua useammalla eri tekoälyllä, kunhan niiden toimintaperiaatteet ovat selvästi erilaiset. Kilpailuaika päättyy sunnuntaina 13.1.2013 kello 18.00.
Tarkemmat kilpailuohjeet ovat kilpailusivulla. Onnea kilpailuun!
Näyttää mielenkiintoselta. Asettelin tuossa kaiken koodausta vaille valmiiks. Esimerkkiohjelma ja testaus toimii.
Vaikka satunnaislukujen käyttö on kielletty, oletan että edelleen tiedostoon valmiiksi tehtyjen taulujen käyttö on ok.
Kyllä, valmiita lukuja tai itse tehtyä, vakiosiemenellä alustettua generaattoria saa käyttää entiseen tapaan, eli pääasia on, ettei ohjelman lopputulos vaihtele. Säännön syy on tietenkin se, että voittaja on selvä ja että kuka tahansa voi periaatteessa varmistaa kilpailun tuloksen itse.
Hyvä, että testasit myös esimerkin ja testausohjelman, kun itse en paljon pystynyt testailemaan. :)
Kiinnostavan oloinen peli. Säännöt on varmaan ihan itse keksitty?
Kyhäisin JavaScript-toteutuksen, jossa voi pelailla itseään vastaan ja saada vähän intuitiota peliin: http://laire.fi/t/valtapeli/?size=8
Taitaa olla liian simppeli peli 'tekoälylle'. Uskoisin, että hyvinkin yksinkertainen algoritmi pärjää riittävästi tässä kilpailussa. Monimutkaisen tekoälyn toteuttaminen kyseiseen kilpailuun voi jopa huonontaa voitto-mahdollisuuksia.
Vaikuttaa kyllä mieluummin ongelmalta johon voi olla monimutkaisia ratkaisuja. Matemaattisesti ajateltuna paras lopputilanne on yksi mahdollisimman suuri yhtenäinen alue, kun taas monta pientä ei anna läheskään yhtä paljoa pisteitä. Siinä siis heti selviää että valloittajan ja häiritsijän taktiikat on aivan erilaisia. Eri lähestymistapoja on myös paljon.
Säännöt ovat simppelit, mutta minusta peli on yllättävän syvällinen ja monimutkainen. (Tämä on hyvän pelin merkki!) Pohdi huviksesi variaatiota, jossa pelkästään yhdestä suurimmasta alueesta saa pisteitä. Itse en keksinyt edes tähän mitään "hyvin yksinkertaista algoritmiä", ja kun kaikista alueista saa pisteitä, pelin monimutkaisuus nousee huomattavasti. Mutta koodaa toki oma yksinkertaisen algoritmisi ja katsotaan, kuka voittaa. :)
Peli on tosiaan itse keksitty. Lähtökohtana oli Carcassonne-lautapeli, mutta lopputulos taitaa muistuttaa melkeinpä enemmän go-peliä.
Sääntöjen on tarkoitus olla yksinkertaiset, mutta se ei tee pelistä helppoa. Muutenkin on outoa väittää, että jollain ratkaisulla pärjäisi "riittävän hyvin": vaikka kuinka hyvä ratkaisu voi hävitä koko kilpailun, jos muut ovat vielä parempia.
Ei silti ole mitenkään mahdotonta, että jollain yksinkertaisella idealla pärjäisi hyvin. Peliin on varmasti monta lähestymistapaa, ja toivonkin, että kilpailuun saadaan paljon luovia ratkaisuja eikä vain raakaa laskentaa. Itse teinkin jo yhden tekoälyn ja hävisin sille heti. :)
Hauskalta vaikuttaa. Ikävänä puolena että näemmä nimirajoitteet ovat tiukentuneet entisestään kun _ ja - on tiputettu pois. Eikö Putkan kisojenkin alkaisi olla korkea aika siirtyä Unicode-aikaan? ◕‿↼
Toinen huono puoli on, että maksimoidaan voittojen eikä kerättyjen kokonaispisteiden määrää. Ehdin jo innostua, kun luin että saa lähettää monta bottia, kun vaikutti että kisan voisi voittaa lähettämällä armeijallisen botteja jotka jakavat toisilleen täysiä pisteitä ja pelaavat muita vastaan edes kohtalaisesti.
Sisuaski kirjoitti:
Ikävänä puolena että näemmä nimirajoitteet ovat tiukentuneet entisestään kun _ ja - on tiputettu pois.
Nimirajoite tiukkeni sääntöjen yksinkertaistamiseksi ja tulosten selventämiseksi, kun aiemmissa kisoissa on nähty näitä ___-nimisiä ym. pelleilyä. Ties mitä Unicode-merkistöstä sitten löytyisi – vaikka jokin leveä non-breaking space. On enemmistön etu, että nimet ovat helppoja lukea ja kirjoittaa. Voit sitten pyytää IRC-kanavalla erikseen kilpailua hassuista Unicode-merkeistä.
Usealla tekoälyllä ei myöskään saa pelata vilpillisesti, vaan niiden pitää olla kunnolla kisassa mukana.
Mahdollisuuksia saada PL/I kilpailussa sallittujen ohjelmointikielten listalle? Linux alustalla toimiva kehitteillä oleva kääntäjä löytyypi ainakin täältä. Itsellä ajossa OS/2 versio ja ehkä jotakin toimivaa ehtisin kilpailuun saada aikaiseksi, pari ideaa jo olisi...
Ainakin Python-esimerkkipelaajan (esim.py) koodissa on indeksivirhe. Rivit 35-36 pitää olla:
x = int(x) - 1 y = int(y) - 1
Chiman, kiitos, korjasin Python-version sekä toisen virheen PHP-versiosta.
jalski, en ala asentaa, ei ole paketinhallinnassa ja et ehkä osallistu kuitenkaan. Sitä paitsi osaat niin monta tavallistakin kieltä, että olisi aika pöljää asentaa takiasi jokin ihan ihmeellinen. Jätetään uusien kielten mahdollisuus niille, joille todella ei ole listalla mitään sopivaa kieltä.
Testiohjelma taitaa käsitellä y-koordinaatin ennen x-koordinaattia virrassa?
Koordinaatistolla sinänsä ei ole mitään merkitystä, eikä siihen oteta kantaa säännöissä, mutta muutin nyt testiohjelmaa niin, että käyttöliittymässä on matemaattinen koordinaatisto ja x-koordinaatti "käsitellään ensin".
saisiko tuen Go-kielelle?
härmälä kirjoitti:
saisiko tuen Go-kielelle?
Tarvittaessa gccgo järjestyy.
testausohjelma ei toimi
Testausohjelma toimii oikein hyvin. Jos haluat apua ongelmaasi, sinun pitää kertoa paljon selvemmin, mitä olet tehnyt ja millä tavalla ohjelma "ei toimi".
Metabolix: olisiko mahdollista hieman laajentaa tuota testausohjelmaa siten, että pelilaudan koon voisi antaa parametrina? Olisi koodauksen alkuvaiheessa helpompi testata ja debugata omaa algoritmia hieman pienemmällä pelilaudalla.
Laudan koon muuttaminen olisi minusta hämäävä ominaisuus, koska kokoa ei kuitenkaan ilmoiteta tekoälylle. Voithan muuten vain jättää osan laudasta käyttämättä ja lisätä vaikka tekoälyn loppuun jonkin nukkumiskomennon, jotta ehdit keskeyttää pelin oikeassa välissä.
python 2 vai 3? (kummalla se ajetaan)
ja sitten... Tehdäänkö syöte ja luku samalla tavalla kuin esimerkissä???
Eikös tuolla kilpailusivulla lue :
"Python (2.7.3 ja 3.3.0)"
eli saa itse valita?
Kyllä.
Alkaa jo jännittää. Voitan tekoälyni enää about 300 pisteellä. Tämä peli tosin tuntuu intuitiivisesti helpolta ihmiselle pelata. Tietokoneelle vaikeampi havaita muotoja ja tilanteiden vaikutuksia toisiinsa. Sääli ettei voi jo nyt testata muita vastaan! :'(
Pieniä päivityksi testausohjelmaan: Kun tekoäly tekee virheen, tulostetaan nyt myös, monesko siirto oli menossa. Lisäksi tekoälyn tilalle tulevassa algoritmissa olivat indeksit väärin päin, nyt sekin toimii oikein.
hfcoder kirjoitti:
python 2 vai 3?
Molemmat ovat sallittuja. Jos olet oikein avulias, voit jo itse kirjoittaa tiedoston ensimmäiselle riville #!/usr/bin/python2 tai #!/usr/bin/python3.
hfcoder kirjoitti:
Tehdäänkö syöte ja luku samalla tavalla kuin esimerkissä???
Tietenkin tehdään, ja ohjeissakin lukee niin. Mitähän järkeä olisi tehdä esimerkkejä, jos niistä ei voisi edes ottaa mallia?
Weggo kirjoitti:
Uskoisin, että hyvinkin yksinkertainen algoritmi pärjää riittävästi tässä kilpailussa.
Mietin tätä asiaa lisää ja tuli mieleeni, että kilpailuhan olisi aivan erityisen onnistunut, jos sen voittaisi jollain ihan helpolla kaavalla. Samoin käy usein oikeassakin ohjelmoinnissa: ensin joku vääntää tuhat riviä bugista koodia, sitten joku muu heittää sen roskiin ja tekee paremmin ihan parilla koodirivillä.
Apodus kirjoitti:
Sääli ettei voi jo nyt testata muita vastaan! :'(
Kun lähetät ohjelmasi, voin kertoa, miten se pärjää omaa tekoälyäni vastaan. En aio itse jatkokehittää sitä enää. Tosin en tähtääkään huipulle vaan pyrin lyhyeen mutta kohtalaiseen ratkaisuun.
Apodus kirjoitti:
Tietokoneelle vaikeampi havaita muotoja ja tilanteiden vaikutuksia toisiinsa.
Omasta mielestäni tässä tehtävässä voisi kyllä hyvinkin yksinkertainen ohjelma pärjätä kohtuullisen hyvin käyttämällä reaaliaikaisista strategiapeleistä tuttuja menetelmiä.
Vinkkinä helppoon toteutukseen annettakoon, että miten sotapeli hahmottaisi helposti ja hyvin suoraviivaisesti joukkojen määrät ja vahvuudet pelialueella.
(EE) Virhe tekoälyjen kanssa: virhe nimen lukemisessa: ei syötettä!
Ei näytä testausohjelma toimivan edes sivulla annetun esimerkkiohjelman esim.c kanssa. Ympäristönä on Windows ja Cygwin, esimerkkiohjelmaa kyllä voi terminaalista käyttää.
eetu99, ohjelmaa ei sattumoisin ole testattu Cygwinissä. Toimiiko ylipäänsä Cygwin-ohjelman käynnistäminen vaikka tuplaklikkaamalla? Mitä tapahtuu, jos teet bat-tiedoston ohjelman ajamiseen ja syötät sen testiohjelmalle? Jos ongelma ei muuten selviä, etkö voisi vain käyttää tavallista MinGW-kääntäjää?
Timmmo, en ole tehnyt ohjelmaan mitään muutosta, joka vaikuttaisi tuohon. Ohjelma odottaa tekoälyn sammumista sekunnin ja sulkee sen sitten väkisin, ja ilmeisesti tekoälylläsi kestää jostain syystä liian kauan sulkeutua. Minulla testausohjelma toimii moitteettomasti, joten vika lienee joko sinun ohjelmassasi tai käyttöjärjestelmässä. Sinänsä asialla ei ole mitään vaikutusta pelin tulokseen, kunhan kaikki siirrot rekisteröityvät oikein.
Hei, onko liian myöhäistä pyytää testausohjelmaan vaihtoehtoiseksi vastustajaksi vaikka Metabolix sinun tekemäsi tekoäly? Joku versio vain, ei välttämättä tarvitse olla se final.
Tällä tavalla saisi jonkilaisen käsityksen oman tekoälyn tasosta ja sitä voisi viilata ennen kisoja?
Onhan: 'ini_set('xdebug.max_nesting_level', 128);' sallittu.
Kiitos.
ps.
Tein yhden version jolle häviän joka kerta. Onko se sitten tekemäni tekoälyn hyvyys vai oma tyhmyys.. Paradoksi.
Millaisia pisteitä olette muuten saaneet pelissä?
Minulla tulee ~1300 tekoälyä vastaan,
ja tekoäly saa sen ~1000 minua vastaan.
Itseään vastaan pelatessa tekoäly tekee ~1100 pistettä.
qeijo: Testausohjelmaa en aio muuttaa, ja minun tekoälyäni vastaan ei luultavasti saa mitään käsitystä oman tekoälynsä tasosta, koska en edes yritä pärjätä hyvin vaan panostan pisteisiin per koodirivi. ini_set-rivisi ei tee mitään, koska minulla ei ole koko xdebugia. Kuitenkin epäilen, että noin syvä rekursio joko vie liikaa aikaa tai on ainakin hitaampi kuin vastaava ratkaisu silmukalla toteutettuna.
Metabolix kirjoitti:
Kuitenkin epäilen, että noin syvä rekursio joko vie liikaa aikaa tai on ainakin hitaampi kuin vastaava ratkaisu silmukalla toteutettuna.
Ei vie, tämä skenaario on todella harvinainen mutta mahdollinen.
Eli toisin sanoen ei ole rajaa PHP:n rekursiossa?
qeijo kirjoitti:
Eli toisin sanoen ei ole rajaa PHP:n rekursiossa?
Aina se johonkin tökkää. Suosittelen toteuttamaan algoritmin toisin, jos rekursiosyvyys huolettaa. Käytä vaikka taulukkoa pinona eri laskentatasojen tilojen tallentamiseen.
Chiman kirjoitti:
qeijo kirjoitti:
Eli toisin sanoen ei ole rajaa PHP:n rekursiossa?
Aina se johonkin tökkää. Suosittelen toteuttamaan algoritmin toisin, jos rekursiosyvyys huolettaa. Käytä vaikka taulukkoa pinona eri laskentatasojen tilojen tallentamiseen.
Tökkää tökkää, mutta ei vielä tuossa vaiheessa jos vain PHP sen vain suorittaa.
Suurin teoreettinen rekursiosyvyys on: 16 * 16 / 2 - 1.
<?php
function laske($x, $y) {
global $n, $kentta;
if (ehto) {
$n += 1;
laske($x, $y);
}
}Monesti rekursiolle ennetaan parametri josta voi päätellä ollaanko jo syvimmässä mahdollisessa sopukassa. En tiedä php:stä, mutta jos sun "globaali" muuttuja kenttä (tarkottaa siis 16x16 taulukkoa?) on määritelty funktion sisällä, se ei ole sama kaikissa rekursiofunktion instansseissa?
qeijo kirjoitti:
...koodia...
Sama ilman rekursiota:
<?php
function laske($x, $y) {
global $n, $kentta;
while (ehto) {
$n += 1;
}
}Tosin luultavasti yksinkertaistit koodiasi sen verran, ettei tuo malli toimi suoraan sinulle.
Chiman kirjoitti:
Tosin luultavasti yksinkertaistit koodiasi sen verran, ettei tuo malli toimi suoraan sinulle.
Jep.
Tein "flood fill" tyyppisen ratkaisun joka on itse asiassa hieman hitaampi.
Apodus kirjoitti:
Millaisia pisteitä olette muuten saaneet pelissä?
Minulla tulee ~1300 tekoälyä vastaan,
ja tekoäly saa sen ~1000 minua vastaan.
Itseään vastaan pelatessa tekoäly tekee ~1100 pistettä.
Kuulostaa aika kovalta tekoälyltä. Annatko sille paljonkin aikaa? Kilpailukonehan on skrubu ja 30 sekuntia sillä on vähemmän kuin voisi toivoa.
Metabolix, saisitkos kompromissina Fortranin kilpailussa sallittujen kielten listalle? GFortran pakettien luulisi löytyvän useimpien jakelujen paketinhallinnasta ja eikö olisi sääli, jos niinkin perinteinen ohjelmointikieli olisi suljettu kilpailun ulkopuolelle? ;-)
Osallistun tällä kertaa varmasti, jos tuo on mahdollista (ideaa testattu jo MiniBASIC kääntäjällä)...
Huomio! Kannattaa lähettää tekoälystä jokin versio jo hyvissä ajoin, jotta on aikaa korjata siitä virheet. Tähän mennessä kaikissa tekoälyissä on ollut ongelmia kuten kaatumisia tai virheellisiä siirtoja.
Optimointivinkki: viimeisellä siirrolla on turha laskea mitään, vastustajan siirron voi vaikka jättää lukematta ja omaksi siirroksi voi valita laudalta ainoan vapaan ruudun.
qeijo kirjoitti:
Tein "flood fill" tyyppisen ratkaisun joka on itse asiassa hieman hitaampi.
Senkin voi toteuttaa monella tavalla. Pinolla järkevästi toteutettuna se toimii hyvinkin nopeasti:
function rekursio($x) {
// koodia
rekursio($y);
rekursio($z);
}
function iteraatio($x) {
$pino = array($x);
while (!empty($pino)) {
$x = array_pop($pino);
// koodia
array_push($z);
array_push($y);
}
}MakeGho kirjoitti:
Kilpailukonehan on skrubu ja 30 sekuntia sillä on vähemmän kuin voisi toivoa.
Itse taas ajattelin tuossa, että olisi sittenkin pitänyt laittaa aikarajaksi vaikka 3 sekuntia. Minusta on tylsää, jos kisaan väännetään vain tunnettuja huippualgoritmeja. Onneksi 30 sekunnin raja pakottaa jo vähän luovempiin ratkaisuihin.
Sitä paitsi eivät ne uusimmatkaan (tavallisille kuluttajille suunnatut) nykyprosessorit ole merkittävästi nopeampia kuin kilpailukoneessa, joten turha valittaa. Ihme hifistelijä.
jalski kirjoitti:
Metabolix, saisitkos kompromissina Fortranin kilpailussa sallittujen kielten listalle?
GCC:n Fortran-kääntäjä järjestyy vaivatta.
MakeGho:
Käytin liikaa aikaa noihin tuloksiin. Kaiketi noin 90s kisakoneella (toivottavasti en nyt pahasti valehtele). Skaalasin hommaa vähän alaspäin, nyt ottelu itseään vastaan kestää kokonaisuudessaan kisakoneella about 30s, eli 15s käytetty aikaa per AI.
Tässä vielä numerot vanhempaa versiota vastaan pelatuista peleistä.
Nopeutettu puolustajana: 1048
Nopeutettu hyökkääjänä: 1080
Ilmeisesti en juurikaan saanut lisäinformaatiota ylimääräisella ajankäytöllä.
Tuon testausohjelman saa siis myös ladattua kotikoneelle. Sivun lähdekoodista tempasin tuommosen linkin java-ohjelmaan:
https://www.ohjelmointiputka.net/valtapeli/
Tietysti sivun kautta testaamalla on aina käytössä uusin versio, mutta ainakin itsellä saattaa internetin saatavuus olla rajoitettu muutaman päivän ajan.
Metabolix kirjoitti:
MakeGho kirjoitti:
Kilpailukonehan on skrubu ja 30 sekuntia sillä on vähemmän kuin voisi toivoa.
Itse taas ajattelin tuossa, että olisi sittenkin pitänyt laittaa aikarajaksi vaikka 3 sekuntia. Minusta on tylsää, jos kisaan väännetään vain tunnettuja huippualgoritmeja. Onneksi 30 sekunnin raja pakottaa jo vähän luovempiin ratkaisuihin.
Sitä paitsi eivät ne uusimmatkaan (tavallisille kuluttajille suunnatut) nykyprosessorit ole merkittävästi nopeampia kuin kilpailukoneessa, joten turha valittaa. Ihme hifistelijä.
Pieni aikaraja ei sulje pois ainoastaan hyväksi havaittuja tunnettuja algoritmeja vaan ylipäätään lähes kaikki haut. Pelin luonteesta (valtava määrä siirtovaihtoehtoja) seuraa jo muutenkin haasteita monien standardialgoritmien kanssa, joten en näe tarpeelliseksi rajoittaa hakuja enempää luovuuden esiin kaivamiseksi - sitä tarvitaan joka tapauksessa. Hyvä kuitenkin ettet kolmeen sekuntiin päätynyt, ehkä siirtoihin voidaan saada jotain järkeäkin.
Tehoeron merkittävyyteen voisi kuitata, että esimerkiksi Jimmsin tavalliselle käyttäjälle suunnattu surffilauta on varustettu noin neljä kertaa tehokkaammalla prosessorilla. :-)
Apodus kirjoitti:
Tässä vielä numerot vanhempaa versiota vastaan pelatuista peleistä.
Nopeutettu puolustajana: 1048
Nopeutettu hyökkääjänä: 1080
Hyökkääjänä saan samankaltaisia lukemia, mutta tekoälylläni on jonkin verran ongelmia puolustuksen kanssa fiksua vastustajaa vastaan. Yritän paikkailla asiaa, mutta haasteita riittää.
MakeGho kirjoitti:
Tehoeron merkittävyyteen voisi kuitata, että esimerkiksi [640 euron pöytäkone] on varustettu noin neljä kertaa tehokkaammalla prosessorilla [Intel Core i3-2100 @ 3.10GHz]. :-)
Minusta ero on siis melko pieni ja erityisesti yllättävän pieni siihen nähden, että kilpailukone on liki 5 vuotta vanha 500 euron kannettava.
30 sekuntia laskuaikaa pitäisi riittää kaikille, koska 30 sekuntia on todella paljon aikaa. Minusta on hyvä, että tekoäly tekee siirrot nopeasti ja soveltuu ihmistä vastaan pelaajaksi.
Metabolix kirjoitti:
kilpailukone on liki 5 vuotta vanha 500 euron kannettava.
No eikö "skrubu" sitten kuvaa sitä hyvin, mitä sitä vänkäämään vastaan?
Grez kirjoitti:
No eikö "skrubu" sitten kuvaa sitä hyvin, mitä sitä vänkäämään vastaan?
En väitä vastaan koneen huonoudesta. Pointtini on, että väite "huono kone, ei ehdi laskea mitään" ei ole järkevä, koska uudellakaan koneella ei saa paljon enempää laskettua ja, kuten Apodus sanoi, laskennan vähentäminen vastaavassa suhteessa ei näytä kauheasti vaikuttavan tekoälyn tuloksiin.
Tulevaisuudessa ehkä kisaamme Raspberry Pi -koneella. ;)
Antti Laaksonen kirjoitti:
30 sekuntia laskuaikaa pitäisi riittää kaikille, koska 30 sekuntia on todella paljon aikaa. Minusta on hyvä, että tekoäly tekee siirrot nopeasti ja soveltuu ihmistä vastaan pelaajaksi.
On parempi jos tekoäly käyttää suunnilleen saman verran aikaa kuin sitä vastaan pelaava ihminen. Nopeasti pelaava tekoäly saa ihmisenkin hakkaamaan siirtoja ajattelematta.
Metabolix kirjoitti:
En väitä vastaan koneen huonoudesta. Pointtini on, että väite "huono kone, ei ehdi laskea mitään" ei ole järkevä, koska uudellakaan koneella ei saa paljon enempää laskettua ja, kuten Apodus sanoi, laskennan vähentäminen vastaavassa suhteessa ei näytä kauheasti vaikuttavan tekoälyn tuloksiin.
Tuo Apoduksen kommentti toki koski vain kyseistä tekoälyä. Omalle tekoälylleni kriittinen laskentakapasiteetti ei vielä ylity läppärilläsi keskimäärin kymmenesosasekuntin laskenta-ajoilla. Laskenta-ajan tuplaus tai nelinkertaistus sen sijaan parantaa siirtojen laatua huomattavasti.
Tämä toki tuo oman mielenkiintoisen aspektinsa kilpailuun, mutta väite laskenta-ajan riittävyydestä tai lisäkapasiteetin merkityksettömyydestä on perätön.
MakeGho kirjoitti:
On parempi jos tekoäly käyttää suunnilleen saman verran aikaa kuin sitä vastaan pelaava ihminen. Nopeasti pelaava tekoäly saa ihmisenkin hakkaamaan siirtoja ajattelematta.
Tämä ei ole järkevä perustelu, koska nopean tekoälyn saa tarvittaessa hitaaksi laittamalla siihen viivettä. Sen sijaan hidasta tekoälyä ei saa mitenkään nopeaksi. Algoritmin hitautta ei voi mitenkään laskea algoritmin ansioksi.
MakeGho kirjoitti:
Tämä toki tuo oman mielenkiintoisen aspektinsa kilpailuun, mutta väite laskenta-ajan riittävyydestä tai lisäkapasiteetin merkityksettömyydestä on perätön.
Tietenkin näillä asioilla on merkitystä. Jos tekoäly saisi laskea vuoden supertietokoneella, se olisi vielä paljon parempi. Kuitenkin myös Metabolixin laitteistolla ehtii laskea vaikka mitä 30 sekunnissa.
Antti Laaksonen kirjoitti:
30 sekuntia laskuaikaa pitäisi riittää kaikille, koska 30 sekuntia on todella paljon aikaa. Minusta on hyvä, että tekoäly tekee siirrot nopeasti ja soveltuu ihmistä vastaan pelaajaksi.
MakeGho kirjoitti:
On parempi jos tekoäly käyttää suunnilleen saman verran aikaa kuin sitä vastaan pelaava ihminen. Nopeasti pelaava tekoäly saa ihmisenkin hakkaamaan siirtoja ajattelematta.
Antti Laaksonen kirjoitti:
Tämä ei ole järkevä perustelu, koska nopean tekoälyn saa tarvittaessa hitaaksi laittamalla siihen viivettä. Sen sijaan hidasta tekoälyä ei saa mitenkään nopeaksi. Algoritmin hitautta ei voi mitenkään laskea algoritmin ansioksi.
Tässä oli kyse siitä, että tekoälyllä ei ole niin kiire, että kaikki siirrot pitäisi saada tehtyä 30 sekunnissa, koska tuo vauhti pakottaisi pitkiä sleeppejä joka vuorolle. Järkevällä tempolla pelatessa aikaa on huomattavasti enemmän kuin 0,2 sekuntia per siirto ja silti tekoäly soveltuu vähintään yhtä hyvin ihmistä vastaan pelaajaksi.
Algoritmin prosessorin säästämisestä ja turhasta odottelusta johtuvaa huonoutta ei voi mitenkään laskea algoritmin ansioksi.
MakeGho kirjoitti:
Algoritmin prosessorin säästämisestä ja turhasta odottelusta johtuvaa huonoutta ei voi mitenkään laskea algoritmin ansioksi.
Ei ei ei, eikö kpzpt opettanu teille mitään!
Innostuin tämän kilpailun ansiosta piiitkästä aikaan koodailemaan myös vapaa-ajalla ja sainkin tuossa jo rungon valmiiksi. Motivaattorina toimii
- pelin säännöt: haastava, mutta silti helposti saa jotain aikaiseksi
- tutustuminen uuteen kieleen (C#)
- tutustuminen juuri näihin em. tunnettuihin algoritmeihin.
Täytyy yrittää keksiä jotain piristystä noihin "tylsiin" laskentamenetelmiin :)
Metabolix kirjoitti:
qeijo: Testausohjelmaa en aio muuttaa, ja minun tekoälyäni vastaan ei luultavasti saa mitään käsitystä oman tekoälynsä tasosta, koska en edes yritä pärjätä hyvin vaan panostan pisteisiin per koodirivi.
Tästä tulikin mieleeni, että kilpailun sisällä voisi olla kaksi epävirallista "osakilpailua":
1) Pisteet / koodirivi (vai olisiko kooditiedostojen koko parempi?)
2) Pisteet / käytetty suoritusaika. Samat pisteet lyhyemmässä ajassa = parempi algoritmi.
Lisäys:
Metabolix kirjoitti:
Optimointivinkki: viimeisellä siirrolla on turha laskea mitään, vastustajan siirron voi vaikka jättää lukematta ja omaksi siirroksi voi valita laudalta ainoan vapaan ruudun.
Tämä on hyvä vinkki, mutta itse kilpailussa, kierroksen lopputuloksen kannalta, ei ole haitallista, vaikka aika loppuisi kesken, sillä ajan loppuessa esimerkkiohjelma astuu puikkoihin, ja suorittaa tuon viimeisen siirron.
Omasta mielestäni varsinkin tämä pisteet/koodirivit on hullu ajatus, koska eri kielissä pystyy koodirivien määrän kikkailemaan aikalailla sellaiseksi kuin haluaa. Sama asia pätee myös tuohon pisteet/tiedoston koko -juttuun. Miksi jokin algoritmi/koodi olisi huonompi esim sen vuoksi että se on kunnolla kommentoitu/sisennetty/käytetty sulkuja/jne...
Ja varsinkin tässä tehtävässä, jossa ratkaisun voi jättää eri kielillä, niin en ymmärrä miksi esim C-koodaajia pitäisi rangaista siitä että muuttujat pitää aluksi esitellä verrattuna johonkin php-koodiin.
Muutenkin tuntuu että vallalla on käsitys että mitä pienempään tilaan kaiken maailman kikkailuilla jonkun koodin saa, niin sitä parempaa koodia. Tämä näkyi hyvin esim aikoinaan php-haasteen yhteydessä. Tietenkin hyvä koodi ei rönsyile eikä siinä ole mitään turhaa, ja se on kompaktisti ja hyvin suunniteltu, mutta koodin pituus ei mielestäni ole kovinkaan suuri peruste koodin hyvyydelle.
Osallistuinpa nyt sitten tällä kertaa kilpailuun ja lähetin äsken oman kilpailuohjelmani.
Jos joku haluaa kokeilla tekoälyään 15 minuutissa kirjoitettua, reilusti alle kolme sekuntia käyttävää tuotosta vastaan niin Windows binääri löytyy täältä ;-)
jalski kirjoitti:
Jos joku haluaa kokeilla tekoälyään 15 minuutissa kirjoitettua, reilusti alle kolme sekuntia käyttävää tuotosta vastaan
(II) Peli alkaa.
(II) P1: php C:\Users\qeijo\Desktop\Valtapeli\saga\saga.php
(II) P2: C:\Users\qeijo\Desktop\Valtapeli\FU2.exe
(II) Peli päättyi. Tulos: 5766
(II) Peli alkaa.
(II) P1: C:\Users\qeijo\Desktop\Valtapeli\FU2.exe
(II) P2: php C:\Users\qeijo\Desktop\Valtapeli\saga\saga.php
(II) Peli päättyi. Tulos: 1382
qeijo kirjoitti:
(II) Peli alkaa.
(II) P1: php C:\Users\qeijo\Desktop\Valtapeli\saga\saga.php
(II) P2: C:\Users\qeijo\Desktop\Valtapeli\FU2.exe
(II) Peli päättyi. Tulos: 5766(II) Peli alkaa.
(II) P1: C:\Users\qeijo\Desktop\Valtapeli\FU2.exe
(II) P2: php C:\Users\qeijo\Desktop\Valtapeli\saga\saga.php
(II) Peli päättyi. Tulos: 1382
Kakkospelaajana ohjelmani pelaa tällä hetkellä aika huonosti. Ykköspelaajana ohjelma pärjää kohtuullisen hyvin suhteutettuna sen yksinkertaiseen toteutukseen.
Täytyy ehkä hiukan vielä hioa kakkospelaajan strategiaa ja kokeilla tehdä muutoksia valmiiksi laskettuihin arvoihin. Tuossahan voisi vaikka kokeilla GA:lla hakea optimaalisia arvoja valmiiksi laskettuihin taulukoihin.
jalski kirjoitti:
Kakkospelaajana ohjelmani pelaa tällä hetkellä aika huonosti.
Olet oikeassa. Oma älyni sai 16130 FU2:sta vastaan, joka on lähes maksimi (= 16384).
Anaatti kirjoitti:
Olet oikeassa. Oma älyni sai 16130 FU2:sta vastaan, joka on lähes maksimi (= 16384).
Entäs FU2 ykköspelaajana?
Kakkospelaajassa on pieni ajatusvirhe, korjailen tuon kun pääsen oman koneeni ääreen...
jalski kirjoitti:
Anaatti kirjoitti:
Olet oikeassa. Oma älyni sai 16130 FU2:sta vastaan, joka on lähes maksimi (= 16384).
Entäs FU2 ykköspelaajana?
Noh, tässä vähän lisää tilastoja:
esim hyökkää: 570
FU2 hyökkää: 852
tekoäly itseään vastaan: 2994
Korjailin hiukan tuota ohjelmaani ja päivitin aiemmin linkittämäni paketin.
Esimerkkiohjelmaa vastaan en tuota ole päässyt kokeilemaan, kun testausohjelma jostain syystä antaa esimerkkiohjelmalle (C-kielinen versio) virheilmoituksen:
(EE) Virhe tekoälyjen kanssa: virhe nimen lukemisessa: ei syötettä!
jalski kirjoitti:
Korjailin hiukan tuota ohjelmaani ja päivitin aiemmin linkittämäni paketin.
(II) Peli alkaa.
(II) P1: php C:\Users\qeijo\Desktop\Valtapeli\saga\saga.php
(II) P2: C:\Users\qeijo\Desktop\Valtapeli\FU2.exe
(II) Peli päättyi. Tulos: 7268
(II) Peli alkaa.
(II) P1: C:\Users\qeijo\Desktop\Valtapeli\FU2.exe
(II) P2: php C:\Users\qeijo\Desktop\Valtapeli\saga\saga.php
(II) Peli päättyi. Tulos: 938
qeijo kirjoitti:
(II) Peli alkaa.
(II) P1: php C:\Users\qeijo\Desktop\Valtapeli\saga\saga.php
(II) P2: C:\Users\qeijo\Desktop\Valtapeli\FU2.exe
(II) Peli päättyi. Tulos: 7268
Edelleen ohjelmani puolustaa ala-arvoisesti. Sain äsken kahvipöydässä idean ja kirjoittelen tuon puolustustajan kokonaan uusiksi. Hyökkääjään tuskin teen enää isompia muutoksia.
jalski kirjoitti:
Testausohjelma jostain syystä antaa esimerkkiohjelmalle (C-kielinen versio) virheilmoituksen: – –
Kumma juttu. Millä järjestelmällä, miten käännettynä ja millä ajokomennolla?
Voisiko testausohjelmaan saada pikanappulan jolla pystyy vaihtamaan tekoälyjen rooleja. Siis hyökkääjä=>puolustaja, puolustaja=>hyökkääjä.
Metabolix kirjoitti:
Kumma juttu. Millä järjestelmällä, miten käännettynä ja millä ajokomennolla?
Windows 7 ja Silverfrost C++. Jännä juttu on, että komentokehotteesta käsin kokeiltuna tuntuu toimivan OK, mutta testausohjelma saa syötteestä vain numeron ja herjaa virhettä ohjelman nimen lukemisessa.
Sain nyt tuon esimerkkiohjelman kuitenkin toimimaan kääntämällä sen OpenWatcom C:llä.
jalski kirjoitti:
Jännä juttu on, että komentokehotteesta käsin kokeiltuna tuntuu toimivan OK, mutta testausohjelma saa syötteestä vain numeron ja herjaa virhettä ohjelman nimen lukemisessa.
Yksi mahdollinen selitys on, että kääntäjäsi käyttää väkisin jotain omaa kirjastoaan eikä osaa tehdä tavallisia, putkille sopivia ohjelmia.
ajv kirjoitti:
Voisiko testausohjelmaan saada pikanappulan jolla pystyy vaihtamaan tekoälyjen rooleja.
Nyt pelaajien paikat voi vaihtaa. Lisäsin samalla karkean arvion tekoälyn käyttämästä ajasta, mutta siinä saattaa olla suuriakin heittoja useasta syystä, joten jos asiasta on epäilyksiä, kannattaa lähettää ohjelma ajoissa testattavaksi.
Huh. Hyvä että tuli testattua FU2:sta vastaan. Sitä vastaan pelatessa tilanne pysyi jatkuvasti juuri sen verran monipuolisena, että ohjelmani halusi käyttää hyökätessään runsaasti aikaa jokaiselle siirrolle, ja ylitti käytettävissä olevan aikarajan merkittävästi.
Tulokset:
FU2 puolustajana: 11792
FU2 hyökkääjänä: 756
Apodus kirjoitti:
Hyvä että tuli testattua FU2:sta vastaan. Sitä vastaan pelatessa tilanne pysyi jatkuvasti juuri sen verran monipuolisena, että ohjelmani halusi käyttää hyökätessään runsaasti aikaa jokaiselle siirrolle, ja ylitti käytettävissä olevan aikarajan merkittävästi.
Koska FU2 saa turpiinsa testeissä muita tekoälyjä vastaan, niin päätin nyt vielä hiukan kokeilla parannella sitä yrittäen silti säilyttää sen yksinkertaisen rakenteen ja pitää siirtonopeuden hurjana.
Koska varsinkin puolustaessa tulee tietyissä tilanteissa tehtyä huonoja siirtoja, niiin päätin yksinkertaisena jippona rajoittaa parhaan siirron valitsemisen pelkästään optimaaliselle alueelle pelialuetta. Eri kokoisten alueiden vahvuuksiahan saa yksinkertaisesti ja nopeasti laskettua vakioajassa käyttämällä summataulua (Summed area table, integral image). Lisäilen tuon, kun tässä oikeilta töiltäni kerkiän ja katsotaan tuleeko tuloksiin muutosta. :-)
Onpas tullut joululoman aikana koodattua tätä ennätysmäärä - ja vielä enemmän on mennyt aikaa suunnitteluun, teorian lukemiseen ja testaamiseen.
Vaikea arvioida miten se pelaa muita vastaan ja koodirivejäkin on varmaan 100-kertainen määrä nokkelampiin ohjelmiin verrattuna, mutta sanotaan näin että tavoite on jo tässä vaiheessa täyttynyt: uuden kielen perussyntaksi alkaa olla painunut mieleen ja tekoälyalgoritmimen teoriastakin ymmärtää jo vähäsen :)
Onko sallittua käyttää scipyä?
Teen sillä ainakin itselleni testausohjelman.
makumaku kirjoitti:
Koodin pituus ei mielestäni ole kovinkaan suuri peruste koodin hyvyydelle.
Tietenkin on typerää lyhentää koodia turhalla kikkailulla, muuttujien nimiä vaihtamalla tai muuten sotkemalla, ja itse en ehdottanutkaan mitään kilpailua asiasta. Minusta koodin pituus on kuitenkin hyvä mittari silloin, kun koodeissa ei ole muuta vertailtavaa eli kun koodit ovat yhtä siistit ja toimivat yhtä hyvin. Yleensä silloin lyhyempi koodi on paremmin suunniteltu ja helpompi hahmottaa. Onhan esimerkiksi parempi käyttää funktioita kuin kopioida samaa koodia, vaikka molemmat tavat toimivat aivan oikein.
Mielestäni on hienompaa saada kohtalainen tulos nopeasti lisäämällä esimerkkiin pari riviä kuin päästä kärkikahinoihin tuhannen rivin koodilla aikarajat paukkuen. Noudatan samaa mallia monessa muussakin asiassa.
Joonazan kirjoitti:
Onko sallittua käyttää scipyä?
Voit käyttää scipy-kirjastoa, vaikka en näe sille montakaan hyvää sovellusta ongelmassa.
Metabolix kirjoitti:
Mielestäni on hienompaa saada kohtalainen tulos nopeasti lisäämällä esimerkkiin pari riviä kuin päästä kärkikahinoihin tuhannen rivin koodilla aikarajat paukkuen. Noudatan samaa mallia monessa muussakin asiassa.
Mielestäni on kuitenkin tehtävän hengen mukaista pyrkiä saavuttamaan mahdollisimman hyvä tulos. Muutoin termi "kilpailu" on kyseenalainen valinta. Se, onko annetut resurssit (30s aikaa, ja 10 000 riviä koodia) käytetty vai ei, ei ole minusta missään määrin merkityksellinen seikka. Vähän kuin olisi korkeushypyssä hienompaa saada vähän vasurilla läpällä ponnistaen keskinkertainen tulos, kuin ottaa se kultamitali kotiin annettuaan kaikkensa suoritukselle. Tai kokkikisassa 50e budjetilla ostaa vitosella banaaneja tarkoituksella säästellen, ja rutistaa niistä satunnaisen tortun, jonka ihminen kykenee nielemään. Onhan siinäkin omat meriittinsä, mutta niiden esille nostaminen kilpailun kontekstissa on minusta omituista.
Itse katson tämän kaltaisen kilpailun hienoimmaksi puoleksi sen tarjoaman mahdollisuuden tutustua nimenomaan niihin tunnettuihin algoritmeihin, jotka nyt on pyritty aikarajalla sulkemaan pois. Kannustaisinkin ennemmin osallistujia kokeilemaan mahdollisimman monipuolisesti eri lähestymisiä ja sitä kautta oppimaan eri menetelmien rajoitteita. Kuten MakeGho jo aiemmin totesi, on tämä peli vaikea perinteisille menetelmille joka tapauksessa, johtuen korkeasta haarautumiskertoimesta ja keskeneräisen aseman arvottamisen vaikeudesta. Tämä taas johtaa kaikilla aika-asetuksilla ratkaisuihin, jotka eivät ole niitä tyypillisimpiä.
Mikäli valitun hakumenetelmän aiheuttamat erot halutaan kilpailusta pois, ei aikaraja ole tehokas menettely (hyvät algoritmit tuppaavat olemaan hyviä suhteessa käytettyyn aikaan, vaikka aikaraja olisikin tiukka). Hakualgoritmin voisi sen sijaan asettaa kilpailun järjestäjä, ja pyytää osallistujaa tarjoamaan ainoastaan lehtisolmun arvottavan algoritmin. Täsmääkö se osuus keskustelussa haettuun "luovaan ratkaisuun"?
Apodus kirjoitti:
Mielestäni on kuitenkin tehtävän hengen mukaista pyrkiä saavuttamaan mahdollisimman hyvä tulos.
Toki, enkä ole kieltänyt ketään tavoittelemasta voittoa. Kerroin vain, mistä itse pidän. Osasyy valintaani on myös se, että järjestäjänä olen tavallaan jäävi osallistumaan.
Apodus kirjoitti:
Itse katson tämän kaltaisen kilpailun hienoimmaksi puoleksi sen tarjoaman mahdollisuuden tutustua nimenomaan niihin tunnettuihin algoritmeihin, jotka nyt on pyritty aikarajalla sulkemaan pois.
Toisaalta niitä algoritmeja on jo käytetty monessa kisassa, ja minusta kilpailun pitäisi tuoda jotain uutta edellisiin nähden. Lisäksi ainakin minulla on vaikutelma, että aika harva päätyy kilpailun takia etsimään ja opettelemaan tunnettuja algoritmeja; yleensä niitä on käyttänyt vain yksi tai pari kärkipään kilpailijaa, joille kilpailu luultavasti ei ole ollut kovinkaan tärkeä oppimisen kannalta.
Minusta kilpailun juttu on, että kaikki pääsevät vähän kokeilemaan, mitä osaavat ja miten pärjäävät muille, ja reippaimmat voivat lopuksi katsoa, mitä algoritmeja parhaat käyttivät eli mihin voisi ehkä jatkossa tutustua.
Apodus kirjoitti:
Mikäli valitun hakumenetelmän aiheuttamat erot halutaan kilpailusta pois, ei aikaraja ole tehokas menettely (hyvät algoritmit tuppaavat olemaan hyviä suhteessa käytettyyn aikaan, vaikka aikaraja olisikin tiukka). Hakualgoritmin voisi sen sijaan asettaa kilpailun järjestäjä, ja pyytää osallistujaa tarjoamaan ainoastaan lehtisolmun arvottavan algoritmin. Täsmääkö se osuus keskustelussa haettuun "luovaan ratkaisuun"?
Kilpailusta ei ole tarkoitus poistaa hakualgoritmin merkitystä. On totta, että aikaraja vaikuttaa kaikenlaisiin hakualgoritmeihin, ja tähän sopeutuminen on osa luovuutta. Kuitenkin yleensä suuri osa kilpailijoista tekee erittäin nopean ohjelman, joka ei käytä ollenkaan varsinaisia hakualgoritmeja vaan valitsee siirron suoraan nykytilanteen perusteella jollain omatekoisella kaavalla, ja silloin aikaraja ei juurikaan vaikuta. Niinpä tiukka aikaraja kaventaa näiden lähestymistapojen välistä kuilua.
Ehkä hait ehdotuksessasi jotain sarkasmia, en tiedä. Joka tapauksessa ideasi tuntuu olevan kaikin puolin luovuuden vastainen: enää ei voi valita hakualgoritmia, ja enää ei voi tehdä tekoälyä ilman hakualgoritmia pelkästään epämääräisellä kasalla ehtolauseita. Tai toisaalta, jos linja ei ole tiukka, joku voi edelleen käyttää pisteytykseen vaikkapa minmax-algoritmia.
Metabolix kirjoitti:
Joka tapauksessa ideasi tuntuu olevan kaikin puolin luovuuden vastainen: enää ei voi valita hakualgoritmia, ja enää ei voi tehdä tekoälyä ilman hakualgoritmia pelkästään epämääräisellä kasalla ehtolauseita.
Tarkoituksena oli luoda tilanne, jossa nimeomaan epämääräinen kasa ehtolauseita riittäisi antamaan vahvasti pelaavan tekoälyn. Ja se kenen ehtolauseet sattuvat parhaimmin kuvaamaan eri tilanteiden keskinäistä hyvyysjärjestystä voittaisi kisan.
On toki totta, että mikäli sääntöjä ei ole tarkemmin speksattu, olisi minmaxin jatkaminen itse toteutetulla vänkäreellä mahdollista.
Metabolix kirjoitti:
Kuitenkin yleensä suuri osa kilpailijoista tekee erittäin nopean ohjelman, joka ei käytä ollenkaan varsinaisia hakualgoritmeja vaan valitsee siirron suoraan nykytilanteen perusteella jollain omatekoisella kaavalla, ja silloin aikaraja ei juurikaan vaikuta.
Juuri näin teen tälläkin kertaa: hyvin nopea ja melko yksinkertainen siirron valinta ilman siirtojen laskemista eteenpäin. Koska kyse on huvista, luon mieluiten itse jotain uutta ja selkeää, jolla toivon sijoittuvani tulosluettelon parempaan puoliskoon. Terävimpään kärkeen en tule yltämään.
Hämmästyn jos tuleva kärkikolmikko päätyy keskenään samantapaisiin algoritmeihin. Arvaan kahden kolmesta laskevan siirtoja tehokkaasti eteenpäin haaroja karsien ja yksi tekee jotain muuta.
Hmm...
Säännöt kirjoitti:
Kellonaika ja tietokoneen nopeus eivät saa vaikuttaa tekoälyn toimintaan.
Mites tämä oikein täytisi tulkita. Jos ohjelmaa ajetaan todella hitaalla koneella, tulee aikaraja täyteen ja ohjelma pelaa erilailla, kun nopealla koneella.
Toisin sanoen: saako ohjelma tutkia kulutettua aikaa ja tehdä muutoksia toimintaansa sen perusteella?
ajv, sääntö tarkoittaa nimenomaan sitä, että ohjelman ei pidä tutkia aikaa vaan sen pitää tehdä samat laskut välittämättä siitä, onko aika loppunut. Näin kuka tahansa voi jälkikäteen ajaa saman ottelun ja tarkistaa tuloksen, vaikka siihen menisi vuosi. Aikaraja ei liity tuohon sääntöön, koska rajan ylittyminen ei vaikuta millään tavalla ohjelman toimintaan vaan pelkästään kilpailussa käyttämieni skriptien toimintaan.
Ok, kiitos, tämä selvensi asian!
Kisa päättyy sunnuntaina kello 18, muistakaa osallistua (mieluiten ajoissa)! Osallistujia on nyt suunnilleen 10, ja taso vaihtelee laidasta laitaan.
Saa myös ehdottaa jotain yksinkertaista mutta kiinnostavaa graafista "tilastoa" tulossivulle. Plussaa kilpailusähköpostiin lähetetystä PHP-funktiosta, jolla kuvan voi tuottaa. Ainakin alueiden kokojakauma on tulossa.
Jos suoritusaikoja mitataan, voisi loppusijoitus-suoritusaika-asteikon kuvaaja olla kiinnostava.
Kilpailu lähestyy loppuaan. Mukana on jo kaikkiaan 20 tekoälyä, toivottavasti vielä joku ilmoittautuu. :) Jos joku ei ole vielä saanut kuittausta lähetyksestään, kannattaa ottaa pikaisesti yhteyttä.
Chiman kirjoitti:
Jos suoritusaikoja mitataan, voisi loppusijoitus-suoritusaika-asteikon kuvaaja olla kiinnostava.
Väkersin vihdoin myös varsinaisen ajanoton, ja ajattelin ilmoittaa keskimääräiset ajat lukuina tulostaulukossa – erot ovat aika kiinnostavia.
Itseäni kiinnostaa että mikä on paras strategia hyökkäykseen. Yksinkertaisinta on aloittaa keskeltä pelikenttää, ja koittaa laajentaa yhtä yhtenäistä aluetta kunnes se ei ole enää mahdollista, ja sitten aloittaa kasvattamaan seuraavaa aluetta.
Toinen vaihtoehto on hajauttaa siirtojaan ympäri pelikenttää, ja myöhemmässä vaiheessa koettaa yhdistää ne suuriksi alueiksi. Oma älyni käyttää ensimmäistä menetelmää, ja on melko simppeli.
msdos464 kirjoitti:
Oma älyni käyttää ensimmäistä menetelmää, ja on melko simppeli.
Sitä minunkin käyttää, ja on suht simppeli, vaikka rivejä muutama sata kertyikin.
Olin jo rakentamassa parannettua puolustusta hajautettujen alueiden yhdistämistä vastaan, mutta sen tasapainoinen lisääminen koodiin alkoi maistua puulta, joten päätin jättää tuon heikkouden jäljelle. Saa nähdä harmittaako.
Kilpailu on ohi, ja nyt seuraavat tulokset. Voittaja on Apodus tekoälyllään DrAter, onneksi olkoon! Kiitos muillekin hyvästä kilpailusta.
Toisin kuin Chiman ennusti, kärkikolmikosta jopa kaksi tekoälyä käyttää heuristiikkoja ilman varsinaista hakualgoritmia. Voitto meni kuitenkin taas kerran tyylikkäälle minmax-sovellukselle. Toisaalta erilaisia minmaxeja on ripoteltu pitkin listaa useampikin; tällä kertaa pisteytykseen käytettävä kaava oli aivan erityisen tärkeä, koska minmaxilla pystyi laskemaan vain pari siirtoa eteenpäin.
weggo oli siis tavallaan oikeassa uhotessaan pelin yksinkertaisuudesta, mutta hän jäi kuitenkin itse listan puoliväliin.
Ajankäytöllisesti taisin vetää itse pisimmän korren: kolmas sija ja pienin mitattavissa oleva aika. ;)
Kovin ihmeellistä tulosgrafiikkaa en tähän hätään saanut kasaan, jotenkin ei ollut siihen inspiroiva peli. Ihmetelkää nyt sitten logaritmista graafia, jossa ei ole edes asteikkoa.
Kiitos kilpailun järjestämisestä Metabolixille. Peli yksinkertaisine sääntöineen sopi hyvin tähän kisaan. Onnittelut kärkikolmikolle!
Pärjäsin hieman odotuksiani paremmin. Olin onnekas, ettei puolustukseni heikkouksia paljastaneet muut kuin Kuutti, jonka satuin voittamaan lukemin 6364-5434.
Suuret kiitokset Metabolixilille hyvin järjestetystä mielenkiintoisesta kilpailusta!
Oma sijoitus joukon keskellä (10.) oli juuri se mitä realistisesti arvioin. Jos lasketaan kulutettu aika suhteessa sijoitukseen tai koodirivit suhteessa sijoitukseen ja käännetään tuloslista ympäri, niin sitten olen vahvoilla! :)
Ei nyt kerenny/jaksanu itse koodailla, mietin kyllä suosikkialgoritmit. Ei kyllä olis kärkisijoille yltänyt, luulisin.
Hyökkäys:
- Lähde keskeltä laajentamaan eri suuntiin.
- Vähäinen prioriteetti laajennussuunnilla joista voi enää jatkaa vain yhden ruudun verran. Näin luotaisiin ensin runkoa yhtenäiselle alueelle, ja sitten lopuksi vasta lisätään nuo irtopisteet.
- Korkea prioriteetti ruuduilla joiden lähellä ei ole omaa väriä. Tuosta voi tehdä pienen arvokartan.
Puolustus:
- Diagonaalisesti puolittaa ruudukon pienempiin ja pienempiin osiin.
- Säästää siirtomääriä, kun samalla käyttää vaikka vain parittomia ruutuja pelkästään.
- Ei millään tavoin riipu hyökkääjän tekemistä siirroista, joten tarkoitus olisi yllättää se tilanteella jossa on yksinkertaisesti mahdotonta lopettaa peliä isoilla alueilla.
- Fiksu hyökkääjä pystyisi ennalta tekemään "reikiä" viivoihin, joista yhdistää alueet, mutta moisen todennäköisyys olisi kai pieni.
175 riviä koodia, siistimällä voisin saada vielä 30 riviä pois.
Lopputuloksena 7. sija, olen kyllä tyytyväinen.
Ylpeänä ainoa PHP edustaja.. :)
Positiivisena yllätyksenä saatiinkin paljon enemmän osallistujia kuin neljässä aikaisemmassa kilpailussa. :)
Oma tekoälyni näytti olevan hitain puolustaja, ja sen kyllä uskoo. Sellaista purkkaa tuli kirjoitettua.
Testailin vielä huvikseni pelkän aloitussiirron vaikutusta tekoälyni pistesaaliiseen hyökätessä 2. ja 3. sijoittuneita tekoälyjä vastaan.
Kilpailussa tekoälyni aloitti keskeltä eli pisteestä (9, 9). Tällöin tekoälyni pistesaalis oli:
Floydia vastaan 1528 (Floyd hyökkäsi minua vastaan 1668)
LightOnia vastaan 1368 (LightOn hyökkäsi minua vastaan 1790)
Aloittamalla pisteestä (11, 12) tekoälyni hyökkäyspistesaalis on:
Floydia vastaan 2060
LightOnia vastaan 2008
Aloittamalla pisteestä (10, 12) tekoälyni hyökkäyspistesaalis on:
Floydia vastaan 1490
LightOnia vastaan 2098
Aloittamalla pisteestä (10, 10) tekoälyni hyökkäyspistesaalis on:
Floydia vastaan 2282
LightOnia vastaan 1406
Yli puolella testaamistani aloitussiirtovaihtoehdoista hävisin molemmille, joten lopputulos ei harmita, mutta pistesaalis muuttuu yllättävän paljon pelkän aloitussiirron perusteella.
Tein vielä tarkemman kartoituksen pelkän aloitussiirron vaikutuksesta tekoälyni pistesaaliiseen hyökätessä 2. ja 3. sijoittuneita tekoälyjä vastaan. Pelejä pelattiin 256 kappaletta eli yksi per aloitusruutu 16x16-laudalla.
Vastustaja Floyd: cimple voitti 31 peliä 256:sta, pistekeskiarvo kaikissa peleissä 1382 (976..2282)
Vastustaja LightOn: cimple voitti 109 peliä 256:sta, pistekeskiarvo kaikissa peleissä 1756 (1018..3192)
cimple hävisi molemmille: 126/256
cimple voitti yhden, hävisi toiselle: 120/256
cimple voitti molemmat: 10/256
Lopuksi pelilauta, jossa aloitusruutukohtaisesti cimplellä 0, 1 tai 2 voittoa mainitusta vastustajaparista.
0000101010000000
1111111101010101
1111110000001100
1101111100000000
0111111101011010
0111111000000010
1110111000100000
0111111010000010
0211110000001100
0111100001100111
2221010000101110
0211000011210010
0020110010011111
0122110000001110
1110210101111100
1100001100101000
Chiman, kiinnostavia testejä. Ilmeisesti et kuitenkaan ole saanut esiin mitään ihan mullistavia virheitä, ja keskimäärin sekä pisteiden että lopputulosten mukaan sijoituksesi oli oikea. :)
LightOn-tekoälyni ei perustu kovin tarkkaan suunnitelmaan, vaan kirjoitin useimmat säännöt muutaman oman kokeiluni perusteella ja paikkailin sitten vain pahimpia aukkoja, joita kokeilemalla löysin. Hyökkäystä en tainnut testata ollenkaan (paitsi tietenkin ohjelmalla itseään vastaan), koska idea tuntui uskottavalta eikä ollut parempaakaan.
LightOn piti tehdä, kun kilpailuun ei osallistunutkaan odottamaani määrää aloittelijoita ja Metapallo jäi liian heikoille. ;)
Aloitussiirto on ilmeisesti aika olennainen. Floyd aloittaa hyökkäyksen aina Stetson-Harrison-metodilla lasketusta ruudusta (6,6). Logiikka oli se, että vaikka isoimman mahdollisen alueen saisi aloituksessa todennäköisimmin aikaiseksi aloittamalla keskeltä, heikentää iso möykky keskellä pelikenttää mahdollisuuksia uusien suurien alueiden rakentamiseen merkittävästi verrattuna siihen, että ensimmäinen alue olisi vähän sivussa.
Metabolix kirjoitti:
Chiman, kiinnostavia testejä. Ilmeisesti et kuitenkaan ole saanut esiin mitään ihan mullistavia virheitä, ja keskimäärin sekä pisteiden että lopputulosten mukaan sijoituksesi oli oikea. :)
Mitään virhettä en ole epäillyt missään vaiheessa, jos kisan järjestelyjä tarkoitat. Omassa tekoälyssänikään en huomannut nyt kisan jälkeen mitään piilevää bugia, mutta testaillessani pieniä muutoksia huomasin avaussiirrolla olevan odottamattoman ison vaikutuksen pisteisiin. Se on lähinnä pelimekaniikan kannalta kiinnostavaa; en olisi voinut valita alkusiirtoa kilpailuun paremmin, koska käytössäni ei ollut kisavastustajia.
Sijoitukseni meni aivan oikein. Olin jopa onnekas, koska kukaan ei käyttänyt erillisten alueiden hyökkäystä tekoälylleni tuhoisalla tavalla.
os kirjoitti:
Logiikka oli se, että vaikka isoimman mahdollisen alueen saisi aloituksessa todennäköisimmin aikaiseksi aloittamalla keskeltä, heikentää iso möykky keskellä pelikenttää mahdollisuuksia uusien suurien alueiden rakentamiseen merkittävästi verrattuna siihen, että ensimmäinen alue olisi vähän sivussa.
Samaa mietin itsekin, testailin ja olin kahden vaiheilla aloitusruudun valinnassa kilpailuun. Päädyin kuitenkin keskustaan, koska nopea motitus siellä jättäisi vastaavan kokoisille alueille tilaa reunoilla. En myöskään saanut testeissä johdonmukaista eroa vaihtoehtojen välille. Toinen harkitsemani aloitusvaihtoehto olisi muuten sekin tuottanut tappiot Floydia ja LightOnia vastaan.
Chiman kirjoitti:
Mitään virhettä en ole epäillyt missään vaiheessa, jos kisan järjestelyjä tarkoitat.
Tarkoitin virheitä tekoälyissä. Esimerkiksi LightOn arvotti aluksi hyvin korkealle tilanteen, jossa omia ruutuja ei ole lähellä ja vastustajan ruutu on kulmittain. Silloin sain noin 8000 pistettä jatkamalla aluetta aina vain kulmittain ja yhdistämällä ketjun lopuksi. Epäilen, että vastaavia voittotaktiikoita löytyy yhä; ainakin kärkikaksikkoa vastaan näyttää olevan monta tilannetta, joissa voisi tehdä toisin, mutta eri asia on, miten hyvin ne istuvat ehtolauseisiini.
Kisan aikana näin monta kertaa, miten jokin pieni päivitys heitti tekoälyn tulokset yhdessä pelissä monta tuhatta paremmiksi ja samalla toisessa yhtä paljon huonommiksi. Ilmeisesti siis monessakin tekoälyssä on vikoja, jotka ilmenevät valtavina tappioina, kun vastustaja tekee tiettyjä hieman poikkeuksellisia siirtoja.
Metabolix kirjoitti:
Tarkoitin virheitä tekoälyissä.
LightOnin puolustuksessa on sellainen virhe, ettei se alueen sulkemisen jälkeen osallistu alueen täyttämiseen, vaan jättää hyökkääjän keräämään maksimipinnat rajatulta alueelta. Muita yhtä selkeitä virheitä en bongannut.
Virhe näkyy esim. tässä siirrosta 50 alkaen:
https://www.ohjelmointiputka.net/valtapeli/
Aaaarrrghhh...unohdin lähettää tekoälyni kilpailuun. Täytyy kaiketi tyytyä vertailemaan epävirallisesti lähdekoodien avulla.
Chiman kirjoitti:
LightOnin puolustuksessa on sellainen virhe, ettei se alueen sulkemisen jälkeen osallistu alueen täyttämiseen, vaan jättää hyökkääjän keräämään maksimipinnat rajatulta alueelta.
Se kuuluu suunnitelmaan. Voi toki olla, että arvioin saavutettavan hyödyn väärin.
Metabolix kirjoitti:
Se kuuluu suunnitelmaan. Voi toki olla, että arvioin saavutettavan hyödyn väärin.
No sitten ei näkynyt virheitä :) Ne alueiden viimeisimmät laajennusruudut ovat kaikkein arvokkaimpia, joten ajattelin täyttämisen olevan tärkeää, mutten ole tehnyt mitään tarkempaa analyysiä.
Metabolix kirjoitti:
Chiman kirjoitti:
LightOnin puolustuksessa on sellainen virhe, ettei se alueen sulkemisen jälkeen osallistu alueen täyttämiseen, vaan jättää hyökkääjän keräämään maksimipinnat rajatulta alueelta.
Se kuuluu suunnitelmaan. Voi toki olla, että arvioin saavutettavan hyödyn väärin.
Aika hassu suunnitelma.
Chiman kirjoitti:
Ne alueiden viimeisimmät laajennusruudut ovat kaikkein arvokkaimpia, joten ajattelin täyttämisen olevan tärkeää, mutten ole tehnyt mitään tarkempaa analyysiä.
Kokeilinpa lisätä säännön noiden täyttämistä varten. Erot tuloksissa eivät ole merkittävät, alla joitakin uusia puolustustuloksia:
DrAt Floy Ligh cimp Aero powe Saga walt Snip AIka lier rxa LightOn 1860 1750 1168 1368 1704 1486 2122 1016 1678 1702 1044 1318 LightOn2 1812 1750 1262 1424 1710 1512 2118 968 1558 1540 1032 1468
Erityisesti nyt cimple sai vähän aiempaa paremmat pisteet. Tässä on vielä ottelu cimple vs. muokattu LightOn.
Ilmeisesti arvioni oli siis ihan kohtalainen: ympäriinsä sirotelluista tekoälyni ympäriinsä sirottelemat siirrot maksavat itsensä aika hyvin takaisin myöhemmässä puolustuksessa. Ei ollut ollenkaan hassumpi suunnitelma, qeijokin voi olla ihan hiljaa. ;)
Joo, jäi mullakin oma tekemättä loppuu ja siksi lähettämättä...
Mutta pelasiko kenenkään tekoäly seuraavasti (mitä kikkaa ajattelin käyttää).
Jos tilanne on tämä (X hyökkää):
_______________ | | | | X | O |
Niin pelataan ilman kontaktia:
_______________ | | | X | X | O |
Tämä on mahdollista sillä, kontakti saadaan aina muodostettua. Esim:
_______________ | | | OX | X | O | _______________ | | | OX | XX | O |
Idea on sekä hieman hämätä puolustavaa tekoälyä että (mahdollisesti) saada vallattua enemmän aluetta. ("mahdollisesti" siksi että testaus puuttuu.)
JaskaP, kyllä ainakin Kuutti teki välillä tuollaisia siirtoja (Kuutti–LightOn). Taktiikka ei ole erityisen edullinen, jos puolustaja tekee jotain muuta kuin tuon esittämäsi vastasiirron.
Metabolix kirjoitti:
Kokeilinpa lisätä säännön noiden täyttämistä varten.
Hyvä. Arvioin täytön vaikutuksen väärin.
No, niin näköjään Kuutti tekee, mutta ei heti alussa kuten pitäisi.
Metabolix kirjoitti:
Taktiikka ei ole erityisen edullinen, jos puolustaja tekee jotain muuta kuin tuon esittämäsi vastasiirron.
En väittänytkään että se on hyvä siirto, vain demosin että alue saadaan pysymään yhtenäisenä. Paras puolustus ko. tilanteessa eittämättä on:
_______________ | | O | X | X | O |
Ja jatkuisi:
('diagonaalisiirto' ei nyt käy koska puolustaja
saisi ketjun poikki.)
_______________
|
| O
| X
| XX
| O O
|
Nyt taas 'diagonaalisiirto' olisi mahdollinen
_______________
|
| X O
| X
| XX
| O O
|Metabolix kirjoitti:
.. Ei ollut ollenkaan hassumpi suunnitelma, qeijokin voi olla ihan hiljaa. ..
Jos ei lähdetä täyttämään ympäröityä aluetta, siitä voisi seurata suuremmat tappiot kun mainitsemasi ennakoivat siirrot pystyisivät saavuttamaan.
Useimmissa tapauksissa täyttämisellä ei saavuteta suurta hyötyä, mutta yksittäisissä tapauksessa täyttämättä jättämisellä voidaan ratkaista koko peli.
Tietyissä tilanteissa, varsinkin viimeisillä siirroilla tasaisissa peleissä, täyttämättä jättäminen voi olla ratkaiseva tekijä.
Se ettei sellaista tilannetta ilmennyt, ei puhu mielestäni kummankaan puolesta, pelejä ja vastustajia oli niin pieni erä.
Loppujen lopulta saavutettava hyöty tai menetys hän on kiinni myös vastustajan logiikasta.
No äkkiseltään tuntuisi että puolustuksessa olisi tärkeintä saada lohkottua isoja alueita pienemminksi ja toiseksi tärkeintä saada täytettyä lohkottuja alueita ja näissä tietysti ensisijaisesti sitä lohkoa, jossa on eniten ruutuja hyökkääjällä + tyhjänä.
Eli jos nyt oikein ymmärsin niin Metabolixin strategina oli, että ei täytetä niitä pienempiä alueita, jos isompia yhtenäisiä on vielä jäljelä. Mielestäni ei ole mitenkään itsestäänselvää, että tämä olisi "hassu suunnitelma".
qeijo kirjoitti:
Tietyissä tilanteissa, varsinkin viimeisillä siirroilla tasaisissa peleissä, täyttämättä jättäminen voi olla ratkaiseva tekijä.
Jotain aluettahan siinä joka tapauksessa täytetään joka vuorolla. "Täyttämättä jättäminen" ei ole pelin sääntöjen ja toiminnan puitteissa edes mahdollista.
Ja nimenomaan viimeisillä siirroilla, jos on selvää ettei pysty jakamaan mitään isohkoa aluetta osiin, pitäisi täyttää niitä ruutuja, joista hyökkääjä saisi eniten pisteitä, ei esim. viimeksi muodostetun yhtenäisen alueen sisältöä.
Grez kirjoitti:
Jotain aluettahan siinä joka tapauksessa täytetään joka vuorolla. "Täyttämättä jättäminen" ei ole pelin sääntöjen ja toiminnan puitteissa edes mahdollista.
Varmaan ymmärsit että takoitin ympäröityjen alueiden "Täyttämättä jättäminen"..
Grez kirjoitti:
No äkkiseltään tuntuisi että puolustuksessa olisi tärkeintä saada lohkottua isoja alueita pienemminksi ja toiseksi tärkeintä saada täytettyä lohkottuja alueita ja näissä tietysti ensisijaisesti sitä lohkoa, jossa on eniten ruutuja hyökkääjällä + tyhjänä. Ja nimenomaan viimeisillä siirroilla, jos on selvää ettei pysty jakamaan mitään isohkoa aluetta osiin, pitäisi täyttää niitä ruutuja, joista hyökkääjä saisi eniten pisteitä, ei esim. viimeksi muodostetun yhtenäisen alueen sisältöä.
Kantani perustuu siihen että ko. strategiaa ("Täyttämättä jättäminen") noudatetaan kaikissa tilanteissa. Myös silloin kun isoja alueita ei ole jäljellä, ja vastustajalla on iso yhtenäinen alue missä on muutama paikkaa täyttämättä
Joka skenaariossa on tietysti on poikkeustapauksia, mutta yleisellä tasolla uskallan väittää että mahdollinen tappio on suurempi kuin saavutettava hyöty.
qeijo kirjoitti:
Varmaan ymmärsit että takoitin ympäröityjen alueiden "Täyttämättä jättäminen"..
No edelleen jos ei täytetä ympäröityä aluetta, niin silloin täytetään sen alueen ulkopuolista aluetta, joka ainakin tuossa esimerkkiskenaariossa, jonka Metabolix sanoi "kuuluvan suunitelmaan", oli suurempi. Tämän siis sanoit olevan "aika hassu suunnitelma"
qeijo kirjoitti:
Kantani perustuu siihen että tätä ("Täyttämättä jättäminen") noudatetaan kaikissa tilanteissa.
Mistä kävi ilmi että näin tehtäisiin tai että tämä olisi osa suunnitelmaa? Eli että vältettäisiin isomman yhtenäisen (hyökkääjä+tyhjät) alueen täyttämistä? Jos et päätellyt sitä keskustelusta vaan tekoälyn peleistä tai koodista, niin laita vaikka linkki sellaiseen otteluun ja siirtoon tai sitten viittaus lähdekoodiin.
Grez kirjoitti:
Mistä kävi ilmi että näin tehtäisiin tai että tämä olisi osa suunnitelmaa?
Chiman kirjoitti:
LightOnin puolustuksessa on sellainen virhe, ettei se alueen sulkemisen jälkeen osallistu alueen täyttämiseen, vaan jättää hyökkääjän keräämään maksimipinnat rajatulta alueelta.
Metabolix kirjoitti:
Se kuuluu suunnitelmaan.
Tästä päättelin että: LightOn ei alueen sulkemisen jälkeen osallistu alueen täyttämiseen, vaan jättää hyökkääjän keräämään maksimipinnat rajatulta alueelta.
En ole tutustunut LightOn logikkaan sen kummemmin, joten en osaa ottaa kantaa miten se toimii vastaavissa eri tilanteissa.
Jätit sitten Chimanin viestistä pois olennaisen kohdan
Lainaus kirjoitti:
Virhe näkyy esim. tässä siirrosta 50 alkaen:
https://www.ohjelmointiputka.net/valtapeli/katselu.php?peli=cimple-LightOn
Jos katsot ottelua siirrosta 50 eteenpäin, niin kyllä mielestäni on ihan loogista sanoa tuon kuuluvan suunnitelmaan, jos väitetään että kyseessä olisi virhe.
Toistaalta samassa ottelussa esim. siirrossa 230 näkyy ihan selvästi, että puolustuksen siirto on tyhmä. Sen olisi järkevää tunkea puolustusvuoronsa mille tahansa 2 -kokoiselle alueelle, mutta se tunkeekin puolustussiirtoja 1-kokoisille alueille. Tästä on nyt vaikea sanoa että onko kyseessä suljettujen alueiden välttely, kun ei ole muita kuin suljettuja alueita.
qeijo, olisi varmaan kannattanut edes katsoa mainittua ottelua, niin ehkä olisit tajunnut, mistä puhutaan. Chimanin mainitsema toiminta liittyy tilanteisiin, joissa aktiivisella puolustuksella on saatu hyökkäys kuriin sellaiseen tilanteeseen, että hyökkääjällä on vain yksittäisiä ruutuja alueensa reunoilla. Yleensä ruutuja on vain muutama mutta joissain tapauksissa kymmenenkin. LightOn alkaa sellaisissa tilanteissa tehdä hajanaisia puolustussiirtoja suuremmille tyhjille alueille, jotta seuraava hyökkäys olisi helpompi torjua nopeasti.
Tietenkin taktiikalla voidaan saada myös suuret tappiot (ja varmaan saataisiinkin, jos tekoäly pelaisi muilta osin vielä paremmin), mutta toisaalta hajasiirroilla voidaan saada myös vastaavat hyödyt, kun hyökkääjän seuraavat alueet jäävät vastaavasti paljon pienemmiksi.
Grez kirjoitti:
Toistaalta samassa ottelussa esim. siirrossa 230 näkyy ihan selvästi, että puolustuksen siirto on tyhmä. Sen olisi järkevää tunkea puolustusvuoronsa mille tahansa 2 -kokoiselle alueelle, mutta se tunkeekin puolustussiirtoja 1-kokoisille alueille. Tästä on nyt vaikea sanoa että onko kyseessä suljettujen alueiden välttely, kun ei ole muita kuin suljettuja alueita.
Tuossa on kieltämättä bugi, mutta se on tavallaan eri bugi: neljän puolustajan keskellä piti olla kaikkein huonoin paikka, mutta laitoinkin vahingossa saman arvon myös silloin, kun on kolme omaa ja yksi tyhjä tai hyökkääjä.
Nimimerkki kirjoitti:
qeijo, olisi varmaan kannattanut edes katsoa mainittua ottelua, niin ehkä olisit tajunnut, mistä puhutaan.
Ei minun tarvitse katsoa sitä, kun perustin kommenttini, teidän, tässä foorumissa esitetyihin asioihin.
Sain käsityksen että ympyröityjen alueiden täyttämättä jättäminen kuului tekoälysi suunnitelmaan, koska perustelit sen sillä että ympäriinsä sirottelemat siirrot maksavat itsensä aika hyvin takaisin myöhemmässä puolustuksessa.
Se miten kyseisessä pelitilanteessa pitäisi toimia, on mielestäni tapauskohtaista.
Se on eri asia jos tekoälysi huomioi kyseisessä tilanteessa pelikentän tyhjät alueet, ja tarvittaessa alkaa täyttämään ympäröidyn alueen, jos se näkee sen järkeväksi.?
Siinä tapauksessa olen väärässä ja sunnitelmasi ei ole hassu.
Metabolix kirjoitti:
Tietenkin taktiikalla voidaan saada myös suuret tappiot (ja varmaan saataisiinkin, jos tekoäly pelaisi muilta osin vielä paremmin), mutta toisaalta hajasiirroilla voidaan saada myös vastaavat hyödyt, kun hyökkääjän seuraavat alueet jäävät vastaavasti paljon pienemmiksi.
Kuitenkin tappiot ovat siinä hetkessä konkreettisia, vastaavat hyödyt taas riippuvat vastustajan siirroista. Voihan se olla, että vastustaja ei edes hyödynnä näitä tyhjiä paikkoja. :)
qeijo kirjoitti:
Voihan se olla, että vastustaja ei edes hyödynnä näitä tyhjiä paikkoja. :)
Ko. pelissä ei voi olla hyödyntämättä tyhjiä paikkoja. Vaikka tekoäly kaatuisi tai aika loppuisi, niin pelimoottori sitten nappaa lopuilla vuoroilla tyhjät paikat.
Grez kirjoitti:
Ko. pelissä ei voi olla hyödyntämättä tyhjiä paikkoja. Vaikka tekoäly kaatuisi tai aika loppuisi, niin pelimoottori sitten nappaa lopuilla vuoroilla tyhjät paikat.
Tästähän ei tietenkään ollut kysymys.
Aihe on jo aika vanha, joten et voi enää vastata siihen.