[Alg] Nieuwe GoT contest?

[Soultaker]

Een argument voor zelf kunnen regenereren is dat je je buiten een gevecht kunt klaarmaken voor een nieuw gecht. Als er geen regeneratie bestaat en twee robots raken in gevecht, dan gaat er waarschijnlijk een stuk en de andere raakt beschadigd, waardoor een derde robot de overwinnaar makkelijk kan stukschieten. Binnen een gevecht zijn dat soort dingen wel leuk, maar het is wat flauw als die derde robot wint terwijl 'ie helemaal niet bij het gevecht betrokken was.

Maar ik denk dat het geen essentieel onderdeel is; wat mij betreft laten we het er uit totdat er overeenstemming over bereikt kan worden.

[ Voor 14% gewijzigd door Soultaker op 02-03-2005 15:18 ]

[Voutloos]

Ik ben dan ook voor punten voor een kill + ^{totaal aantal damage uitgedeeld in spel}/₁₀₀=punten + punten voor degene die het einde haalt.
Een beetje zoals de telling van GunBound (maar dan met kleinere beloning voor overwinning), voor wie dat iets zegt.

Met alleen maar ontwijken en alleen maar het laatste schot van het potje te doen kom je er dan niet.

[ Voor 20% gewijzigd door Voutloos op 02-03-2005 15:29 ]

[MLM]

ben bezig een PDF te maken, waar ik ff in ga zetten wat ik nu denk wat het gaat worden, waarin ik al het recente commentaar zal opnemen

[raptorix]

Microsoft had toch al een heel framework voor zo een game? Heet terrarium ofzo, waarom gebruiken jullie dat niet?

[Soultaker]

MLM schreef op woensdag 02 maart 2005 @ 16:36:
ben bezig een PDF te maken, waar ik ff in ga zetten wat ik nu denk wat het gaat worden, waarin ik al het recente commentaar zal opnemen

Lijkt me een goed plan.

raptorix schreef op woensdag 02 maart 2005 @ 16:39:
Microsoft had toch al een heel framework voor zo een game? Heet terrarium ofzo, waarom gebruiken jullie dat niet?

Omdat het niet aan onze eisen voldoet en omdat we Tweakers zijn en graag zelf dingen bouwen.

[raptorix]

Mjah zelf bouwen is leuk en aardig, helaas blijft het meestal bij ideeen, WASP anyone?

[.oisyn]

raptorix schreef op woensdag 02 maart 2005 @ 17:26:
WASP anyone?

Is dat de enige die je weet? Tsk tsk
Het moge duidelijk zijn dat dit geen "kom we gaan met z'n allen iets maken" project is. Als de serverdevelopment bij slechts 1 persoon ligt heeft het gewoon kans van slagen, het is alleen irritant dat mietje nu niets van zich laat horen aangezien hij een groot deel van de software al af heeft.

[ Voor 67% gewijzigd door .oisyn op 02-03-2005 17:42 ]

[MLM]

PDF van wat ik nu heb verzameld, graag inhoudelijke feedback

http://www.student.tue.nl/Q/m.l.v.d.meide/gotpc.pdf

[kunnen]

MLM schreef op woensdag 02 maart 2005 @ 18:18:
PDF van wat ik nu heb verzameld, graag inhoudelijke feedback

http://www.student.tue.nl/Q/m.l.v.d.meide/gotpc.pdf

1 comment:
Je krijgt de nickname van de bot naar je toe gestuurd. Lijkt me niet zo slim, dan kun je strategie tegen die bot schrijven, misschien kun je daar een per wedstijd uniek id nummer voor maken, die aan het begin random wordt gegenereerd per bot?

Verder ziet het er mooi uit

[Verwijderd]

Ik mis ook iets: hoe kom je aan je energie? Ziet hier een maximum aan, of kan je oneindig opsparen?

[ Voor 3% gewijzigd door Verwijderd op 02-03-2005 18:48 ]

[MLM]

mja, er staat in (d8 ik ieg) dat er een maximum is. per beurt krijg je nieuwe energie. kosten van acties en de hoeveelheid die je krijgt moet ik nog finetunen, maar dat komt pas als de server af is

[Soultaker]

PDFje ziet er al heel wat helderder uit. Wat het richten en schieten betreft: misschien kan dat in een enkele actie worden samengevat. Het is duidelijk dat je op elke willekeurige plek kan schieten (dus niet per se in het verlengde van de tank) en aangezien je al richt met een x en een y coordinaat, kun je net zo goed direct die coordinaten gebruiken als doel. (Nu vraag je de clients om eerst die coordinaten te geven en dan nog een keer de afstand die daarbij hoort; beetje overbodig naar mijn mening, zeker aangezien de client intern toch al op een positie zal mikken, van een andere tank bijvoorbeeld, en niet op een hoek+afstand.)

Wat de specificatie nog mist is een lijstje van de beschikbare parameters (energiewaarden van acties enzovoorts), formules voor berekening van schade (OneOfBorg had een voorstel; misschien een varaitie daarop) en het protocol.

Verder ben ik er nog steeds niet zo voor om bots te laten ontploffen zodra ze teveel of te weinig energie gebruiken; een van de doelstelling was dat het een toegankelijke contest moet zijn en het lijkt mij prettiger als de server een beetje tolerant is voor dit soort dingen (dat is echt niet zo moeilijk te schrijven).

Tenslotte is je specificatie nog wat onduidelijk over gebruik van energie. Zoals het er nu staat heb je een (maximale) hoeveelheid energie ter beschikking gelijk aan de (maximale) inhoud van de accu plus wat de energietoevoer die je elke beurt krijgt. Effectief is dat hetzelfde als alleen de accu gebruiken en die achteraf aanvullen, maar wat is het voordeel van jouw formulering? Verder wordt er niet gesproken over het bestaan van maxima aan wat je kan rijden, draaien, schieten, enzovoorts. Komen die er wel, of helemaal niet?

[ Voor 47% gewijzigd door Soultaker op 02-03-2005 19:54 ]

[MLM]

<knipje>

ging ff wat fout met edit/repost coordinatie, sry modjes, doe maar

code:

postcount = postcount - 2

ofzo

[ Voor 212% gewijzigd door MLM op 02-03-2005 20:17 ]

[Orphix]

Trouwens je kan de visualisatie ook expres laten laggen, dus dat de visualisatie een paar (game)ticks achterloopt. Dan is de informatie direct nutteloos voor evt. cheaters. Het is maar een idee want verder vind ik dat je groot gelijk hebt als je zegt dat we elkaar maar moeten vertrouwen dat het er eerlijk aan toe gaat.

[MLM]

Orphix schreef op woensdag 02 maart 2005 @ 19:55:
Trouwens je kan de visualisatie ook expres laten laggen, dus dat de visualisatie een paar (game)ticks achterloopt. Dan is de informatie direct nutteloos voor evt. cheaters. Het is maar een idee want verder vind ik dat je groot gelijk hebt als je zegt dat we elkaar maar moeten vertrouwen dat het er eerlijk aan toe gaat.

idd
* MLM voegt dat toe aan PDF

[MLM]

Soultaker schreef op woensdag 02 maart 2005 @ 19:46:
PDFje ziet er al heel wat helderder uit. Wat het richten en schieten betreft: misschien kan dat in een enkele actie worden samengevat. Het is duidelijk dat je op elke willekeurige plek kan schieten (dus niet per se in het verlengde van de tank) en aangezien je al richt met een x en een y coordinaat, kun je net zo goed direct die coordinaten gebruiken als doel. (Nu vraag je de clients om eerst die coordinaten te geven en dan nog een keer de afstand die daarbij hoort; beetje overbodig naar mijn mening, zeker aangezien de client intern toch al op een positie zal mikken, van een andere tank bijvoorbeeld, en niet op een hoek+afstand.)

hoeken had ik laten vallen, maar idd, zal het toevoegen aan PDF

Wat de specificatie nog mist is een lijstje van de beschikbare parameters (energiewaarden van acties enzovoorts), formules voor berekening van schade (OneOfBorg had een voorstel; misschien een varaitie daarop) en het protocol.

dat vereist finetuning, daar kan ik niet los uit mijn mouw schudden

Verder ben ik er nog steeds niet zo voor om bots te laten ontploffen zodra ze teveel of te weinig energie gebruiken; een van de doelstelling was dat het een toegankelijke contest moet zijn en het lijkt mij prettiger als de server een beetje tolerant is voor dit soort dingen (dat is echt niet zo moeilijk te schrijven).

De specificatie zal duidelijk genoeg zijn om geen fouten te maken

Tenslotte is je specificatie nog wat onduidelijk over gebruik van energie. Zoals het er nu staat heb je een (maximale) hoeveelheid energie ter beschikking gelijk aan de (maximale) inhoud van de accu plus wat de energietoevoer die je elke beurt krijgt. Effectief is dat hetzelfde als alleen de accu gebruiken en die achteraf aanvullen, maar wat is het voordeel van jouw formulering? Verder wordt er niet gesproken over het bestaan van maxima aan wat je kan rijden, draaien, schieten, enzovoorts. Komen die er wel, of helemaal niet?

maxima = hoeveelheid energie die je hebt opmaken

[Soultaker]

Je bedoelt dat er geen limiet is; je kunt dus altijd je hele accu opmaken? Is dat niet vervelend, want dan kun je ofwel gigantische sprongen maken, of je capaciteit is heel beperkt, en bovendien heeft het dan zelden nut om meerdere beurten van je accu gebruik te maken (zodat als je 'm gaat opmaken je bijvoorbeeld vijf beurten hard kan rijden om iemand in te halen).

Niet dat het echt erg is; als het nuttig is kan het altijd later toegevoegd worden.

[MLM]

mja, als je je accu helemaal opmaakt aan rijden, kun je diegene die je achtervolgt niet meer beschieten, terwijl hij zijn accu helemaal kan leegpompen om jouw af te schieten

maar je KAN wel 5 beurten harder rijden, en energie in je accu is altijd handig

[muba]

Schieten en inslag is op hetzelfde moment. Dus je kan geen kogels aan zien komen cq ontwijken?

En rijden dan? Als je zegt, rij daar en daar heen, ben je daar in een klap of kost het gewoon een aantal beurten om je route te bereiken?
En stel dat je een route (rechte lijn) hebt opgegeven, met een afstand en snelheid die laten we zeggen vijf beurten zou kosten, maar tijdens de derde beurt veranderd de bot de route, is dat dan wel makkelijk te doen?

[MLM]

rijden is ook direct, en aangezien sturen + rijden voor de actie schieten wordt uitgevoerd, kun je dus wel een beetje ontwijken

mss, voeg ik rijden en sturen ook wel samen, net als richten/schieten, het is nl ongeveer hetzelfde, en dan ben je het hele hoeken-gedoe kwijt (dat is tog maar irritant voor het programmeren)

[ Voor 44% gewijzigd door MLM op 02-03-2005 21:15 ]

[Verwijderd]

Ik zal toch weer de saaierd zijn die om vereenvoudiging roept: heb je echt twee soorten scans nodig? En echt een los draaiende geschutskoepel?

En ik ben ook niet zo'n fan van, "als je je energie niet besteedt ontplof je".


Spellingscorrecties, want die krijg je ook als je een document ter review aanbiedt:

p1, "..., die een virtuele tank bestuurt" `die' moet `dat' zijn
p1, sectie 4, volgorde van acties: enumerate ipv itemize?
p2, het meervoud van scan is "scans" niet "scan's"
p2, "geinteresseerden" => ge\"interesseerden

En ik zou willen voorstellen het document op te delen in \sections en \subsections, niet GROTE TEKSTEN en \sections.


Misschien is het ook praktisch alle formules al op te nemen in de secties, en dan een grote lijst te maken van "te tweaken parameters" (constanten). En eventueel voorgestelde waarden?


En voor het protocol uitgespecificeerd wordt lijkt het me ook wel handig de verschillende toestanden van een spel (en de server) eerst te beschrijven. Zo lijkt het me dat de server een soort van lobby moet hebben waar spelers verzamelen voor het echte spel gestart wordt. En misschien kunnen er meerdere ronden gespeeld worden (bijvoorbeeld best of 3) in plaats van 1. Dat betekent dat er faciliteiten moeten komen voor restart, etc etc.

[ Voor 43% gewijzigd door Verwijderd op 02-03-2005 21:21 ]

[Soultaker]

Verwijderd schreef op woensdag 02 maart 2005 @ 21:16:
Ik zal toch weer de saaierd zijn die om vereenvoudiging roept: heb je echt twee soorten scans nodig? En echt een los draaiende geschutskoepel?

In het PDFje staat maar één soort scan en de geschutskoepel is niet als zodanig aanwezig; je kan 'toevallig' in een willekeurige richting schieten. Dat maakt het naar mijn mening niet echt ingewikkelder (de client kan zelfs wat makkelijker mikken, omdat 'ie er niet voor hoeft te draaien).

Misschien is het ook praktisch alle formules al op te nemen in de secties, en dan een grote lijst te maken van "te tweaken parameters" (constanten). En eventueel voorgestelde waarden?

Lijkt me ook een goed plan; ik denk dat alleen de schade-formule echt interessant is (de rest is lineair met een constante parameter).

En voor het protocol uitgespecificeerd wordt lijkt het me ook wel handig de verschillende toestanden van een spel (en de server) eerst te beschrijven. Zo lijkt het me dat de server een soort van lobby moet hebben waar spelers verzamelen voor het echte spel gestart wordt. En misschien kunnen er meerdere ronden gespeeld worden (bijvoorbeeld best of 3) in plaats van 1. Dat betekent dat er faciliteiten moeten komen voor restart, etc etc.

Nu maak je het zelf wel erg ingewikkeld. Een basisversie lijkt me eerst wel voldoende. (Sowieso kan de server gewoon wachten tot alle clients er zijn, omdat die toch nog niets kunnen doen/zien tot de server het wil.)

[Verwijderd]

Soultaker schreef op woensdag 02 maart 2005 @ 21:32:
[...]
Nu maak je het zelf wel erg ingewikkeld. Een basisversie lijkt me eerst wel voldoende. (Sowieso kan de server gewoon wachten tot alle clients er zijn, omdat die toch nog niets kunnen doen/zien tot de server het wil.)

Waar, natuurlijk. Toch lijkt het me nuttig als met dat soort zaken nu al rekening gehouden wordt (*schuine blik naar MLM*), omdat ik uit ervaring weet dat het lastig is om ze er later [netjes!] bij te hacken.

[MLM]

ik zat anders in het lobby idee te denken, als een client verbonden is, stuurt die een 'start', waarop het spel start voor die client. Als er nog geen andere clients waren, dan start de server een heel simpele bot, zodat er een tegenstander is. Als er wel waren, dan doe je gewoon mee in de bestaande match. Als je gekilled wordt, respawn je vanzelf weer. Dit is beter voor testen, omdat je eigenlijk geen downtime hebt voor je bot.

geschutskoepel-idee is verwijderd, het is nu gewoon schieten naar een locatie.

in het PDFje staan nu vetgedrukte nicks van dit forum, met daarachter een suggestie, graag feedback daarop.

nog een keertje de URL: http://www.student.tue.nl/Q/m.l.v.d.meide/gotpc.pdf

ow ja, heb de layout veranderd zoals voorgesteld door OneOfBorg + spelfouten (behalve de " op letters, dat begrijp je zo maar )ben geen echte MiXTeX-held

[ Voor 29% gewijzigd door MLM op 02-03-2005 22:05 ]

[El_kingo]

Ik heb het topic al een tijdje met interesse gevolgd maar is het niet makkelijker om de lobby dusdanig te maken dat iedereen op hetzelfde moment start? Dus client meld zich aan bij server en wacht totdat de server een start signaal geeft. Een ronde duurt dan tot er 1 bot over is: "de winnaar" De andere bots (die al dood zijn) krijgen of steeds info door over het spel maar kunnen niet reageren (bijvoorbeeld een standby command o.i.d.) of ze blijven automatisch wachten totdat de server een nieuw start commando geeft.

Wat betreft vriendelijkheid van de server: Op het moment dat de client verkeerde informatie doorgeeft aan de server is de bot automatisch uitgeschakelt en krijgt hiervan een melding (zodat je daar evt. op kunt debuggen.) Klinkt hard, maar moet je je maar aan de specificaties houden...

[MLM]

sparcky schreef op woensdag 02 maart 2005 @ 21:48:
Ik heb het topic al een tijdje met interesse gevolgd maar is het niet makkelijker om de lobby dusdanig te maken dat iedereen op hetzelfde moment start? Dus client meld zich aan bij server en wacht totdat de server een start signaal geeft. Een ronde duurt dan tot er 1 bot over is: "de winnaar" De andere bots (die al dood zijn) krijgen of steeds info door over het spel maar kunnen niet reageren (bijvoorbeeld een standby command o.i.d.) of ze blijven automatisch wachten totdat de server een nieuw start commando geeft.

* MLM voegt dat toe aan PDFje

Wat betreft vriendelijkheid van de server: Op het moment dat de client verkeerde informatie doorgeeft aan de server is de bot automatisch uitgeschakelt en krijgt hiervan een melding (zodat je daar evt. op kunt debuggen.) Klinkt hard, maar moet je je maar aan de specificaties houden...

eensch, maar anderen zijn tegen, dit laat ik even ter discussie

[muba]

Misschien een leuke toevoeging, hoewel van later zorg: zo nu en dan spawnt er ergens op het speelveld een accu-upgrade, waardoor je meer energie kunt opslaan, bijvoorbeeld een stijging van 10%

[MLM]

MUBA schreef op woensdag 02 maart 2005 @ 22:23:
Misschien een leuke toevoeging, hoewel van later zorg: zo nu en dan spawnt er ergens op het speelveld een accu-upgrade, waardoor je meer energie kunt opslaan, bijvoorbeeld een stijging van 10%

voor later zorg idd

ik ga naar mijn kamer nu, en vanaf daar kan ik mijn PDF niet updaten, dus morgen weer een nieuwe versie

[El_kingo]

[b]MLM schreef op woensdag 02 maart 2005 @ 22:04

eensch, maar anderen zijn tegen, dit laat ik even ter discussie

Tsja, dat is dan misschien mijn beoordeling, maar als je een dusdanig 'simpel' protocol hebt moet het geen moeite zijn om dat goed te implementeren.
Op het moment dat een ronde bezig is kun je niet hebben dat je server op z'n spreekwoordelijke bek gaat doordat een client (evt. herhaaldelijk) foutieve data aanlevert.
Vandaar mijn argument om de bot te verwijderen op het moment dat er foutieve data binnenkomt, maar dan wel met de teruggaaf van een melding dat er foutieve data is verstuurd...

Volgende ronde kun je weer meedoen, dat geeft je tijd om aan je bot te sleutelen...

[ Voor 2% gewijzigd door El_kingo op 02-03-2005 23:02 . Reden: typo ]

[FendtVario]

Doen we ook aan achteruit rijden of is dit nutteloos omdat schieten ook direct het draaien van de kopel is?

en ik herhaal deze vraag nog maar even: Wat gebeurt er als je tegen een andere bot aanrijdt (dat kan ook een taktiek zijn). Het lijkt mij dat je beiden energie verliest, afhankelijk van de snelheid van de botsing.

Als een tank ontploft, geeft deze energie dan ook schade aan tegenstanders? Zo ja, komt er dan ook een suicide actie waarmee je kamikaza kan spelen

Als een tank 0 energie heeft ontploft deze dan waarbij ook nog schade wordt uitgedeelt aan toevallig omliggende tanks (net als in worms)?

[Verwijderd]

MLM schreef op woensdag 02 maart 2005 @ 21:36:
ow ja, heb de layout veranderd zoals voorgesteld door OneOfBorg + spelfouten (behalve de " op letters, dat begrijp je zo maar )ben geen echte MiXTeX-held

Pfrrrrt! Ik geef je de LaTeX code er nog gratis bij! Over paarlen en zwijnen enzo .

Just kidding. Bedankt. Ziet er goed uit nu!

[writser]

Over de visualisatie: Ik denk dat het handig is om onderscheid te maken tussen een 'speler' en een 'kijker'. Op deze manier omzeil je het probleem dat spelers gebruik kunnen maken van informatie die alleen bedoeld is voor de grafische interface. Bovendien kan er dan een standaard grafische interface ontwikkeld worden, dan hoeft de rest zich daar niet mee bezig te houden (mag wel natuurlijk ). Zo hoeven deelnemers geen gebruik te maken van de grafische windows / linux API, iets waar veel studenten volgens mij weinig ervaring mee hebben. De code van de speler blijft dan beperkt tot het feitelijke algoritme voor de tank. Dat is goed, want daar draait het tenslotte om . Je hoeft dan alleen een tank te ontwerpen, deze laat je connecten naar de server en met de standaard grafische interface kun je het gevecht volgen. Zo kun je relatief snel een beetje prutsen. Hierdoor wordt ook de drempel om mee te doen wat lager gelegd, wat hopelijk resulteert in meer deelnemers.

Over de spelmodus: Hier moet goed over nagedacht worden. Als je wil bepalen wat de beste bot is, moet je wel een goed matchmaking systeem hebben, waarin iedereen evenveel tegen iedereen speelt. Ook moet er een (beperkte) vorm van beveiliging komen, zodat het niet mogelijk is om voor een bepaalde match een andere tank in te zetten, die in die omstandigheden beter presteert. Natuurlijk kan/moet er ook een gewone lobby komen waar je naar kan connecten met je client(s) om je bot te testen. Maar uiteindelijk zal er toch een soort 'ladder' moeten komen. Misschien eenvoudige authenticatie met username / password?

[Voutloos]

sparcky schreef op woensdag 02 maart 2005 @ 23:00:
Op het moment dat een ronde bezig is kun je niet hebben dat je server op z'n spreekwoordelijke bek gaat doordat een client (evt. herhaaldelijk) foutieve data aanlevert.

Ook een server welke niet de bots laat ontploffen controleert alle input. Iemand die geen input controleert als server moet direct een P&W ban krijgen.

Overigens ben ik ook voor een strenge server. Een rij waardes aan regels laten voldoen is echt niet zo moeilijk. Als je vanaf het begin af streng bent, sluipen er ook minder rare constructies de server in. Op het moment dat er een uitbreiding plaats vindt, mag MLM namelijk meteen al die pleisters voor slordige clients controleren.

Streng zijn scheelt imo juist tijd voor beide partijen.

Vandaar mijn argument om de bot te verwijderen op het moment dat er foutieve data binnenkomt, maar dan wel met de teruggaaf van een melding dat er foutieve data is verstuurd...

Feedback is belangrijk. In het S->C berichtje hoort zeker een tekstveld van variabele lengte voor oa foutmeldingen.

[El_kingo]

Nog even je pdf doorgelezen, lijkt mij prima. Goed werk.

nog 1 puntje: Bij de One-on-One modus van het spel zeg je (ik) dat de bots actief in de match blijven maar niets kunnen doen. Ik denk dat we hetzelfde bedoelen, maar voor de zekerheid: mijn voorstel is dat de bots wel daadwerkelijk van het veld verdwijnen (ontploffen o.i.d.) en daarna gewoon stilletjes blijven wachten totdat de server een algemeen start commando geeft. Na dit start commando gaat de server alle bots "respawnen" en krijgt de bot evt. een extra gratis scan van de server zodat je evt. weet welke kant je op kunt rijden. (Dit laatste kan, hoeft uiteraard niet...)

Zoals FendtVario hierboven al ergens schrijft zal er inderdaad moeten worden nagedacht over botsingen.
Een paar mogelijkheden:
• Botsingen kunnen niet, een tank is 'transparant' en je rijd er dus gewoon doorheen.
• Botsingen kunnen, zonder verlies van schild, echter al je energie die het kostte om naar een bepaald punt te komen gaat verloren als je voortijdig tegen iemand botst.
• Zelfde als hierboven allen nu met verlies van schild. Waarbij de snelheid eventueel een rol speelt in de grootte van de schade (snelheid = afgelegde afstand in die beurt).

De laatste heeft mijn voorkeur...

[Verwijderd]

Als we aan collission detection voor bots gaan doen moeten we ook collission detection voor kogels doen (i.e., je schiet op een lijn waar een tank in de weg staat ontploft de kogel eerder).

Als we aan collission detection gaan doen hebben we nog een nieuwe parameter om te tweaken: de grootte van een robot.

En ik stel dan (om het makkelijk te houden) voor dat de robots gewoon een cirkel zijn. Collission detection op cirkels is makkelijk genoeg.

[ Voor 42% gewijzigd door Verwijderd op 03-03-2005 09:39 ]

[El_kingo]

Verwijderd schreef op donderdag 03 maart 2005 @ 09:38:
Als we aan collission detection voor bots gaan doen moeten we ook collission detection voor kogels doen (i.e., je schiet op een lijn waar een tank in de weg staat ontploft de kogel eerder).

Als we aan collission detection gaan doen hebben we nog een nieuwe parameter om te tweaken: de grootte van een robot.

En ik stel dan (om het makkelijk te houden) voor dat de robots gewoon een cirkel zijn. Collission detection op cirkels is makkelijk genoeg.

Volledig mee eens !!! Had je maar beter op je scan moeten letten...
Robot een cirkel? Je werkt toch met een coördinaten stelsel? een bot is dan gewoon een coördinaat op de 'wereld' komt over/door deze coördinaat een kogel heb jij pech... (lijkt mij, andere/betere ideeën?? graag!!).

[Skaah]

Verwijderd schreef op donderdag 03 maart 2005 @ 09:38:
Als we aan collission detection voor bots gaan doen moeten we ook collission detection voor kogels doen (i.e., je schiet op een lijn waar een tank in de weg staat ontploft de kogel eerder).

Als we aan collission detection gaan doen hebben we nog een nieuwe parameter om te tweaken: de grootte van een robot.

En ik stel dan (om het makkelijk te houden) voor dat de robots gewoon een cirkel zijn. Collission detection op cirkels is makkelijk genoeg.

Dat kan veel gemakkelijker. Iedere tank eindigt altijd op een geheel coördinaat, bijvoorbeeld (7,3). De weg daar naar toe kun je niet botsen, maar als een andere tank ook op dat coördinaat staat, bots je wel.

[MLM]

Ja idd, collision detection is wel leuk, dat moet ik wel kunnen implementeren.

Wat betreft in de match blijven, ik dacht nadat een bot uitgeschakeld wordt, gaat hij direct naar de lobby terug. * MLM herformuleert die zin in de PDF

[El_kingo]

MLM schreef op donderdag 03 maart 2005 @ 09:49:
Wat betreft in de match blijven, ik dacht nadat een bot uitgeschakeld wordt, gaat hij direct naar de lobby terug. * MLM herformuleert die zin in de PDF

Ja inderdaad precies wat ik ook bedoelde...

[jelmervos]

Zeer leuk idee dit. Volg het op de voet maar zal niet actief meedenken. Ik kijk wel wat er uit komt, om vervolgens mee te gaan doen.

Ga zo door en laat dit GoT-project nou eens slagen (is het zelfde als: hou het simpel?).

[MLM]

mja, ik ben niet van plan om het te laten mislukken

er schijnen best wel wat mensen te zijn die mee willen doen
de specificatie van het spel is al een eindje af (de PDF), dus ik ga nu actief devven en protocol specificeren, volgende week ergens heb ik denk ik wel een beta-server draaien

[Coca-Cola]

Ook ik volg dit topic al een tijdje en het begint er zowaar op te lijken dat er iets van de grond gaat komen

Skaah schreef op donderdag 03 maart 2005 @ 09:47:
[...]


Dat kan veel gemakkelijker. Iedere tank eindigt altijd op een geheel coördinaat, bijvoorbeeld (7,3). De weg daar naar toe kun je niet botsen, maar als een andere tank ook op dat coördinaat staat, bots je wel.

Voor kogels geld dat natuurlijk niet, kogels vliegen niet over hele coordinaten, dus er zal in dat geval zeker wel iets van collision detection moeten (moet toch niet echt moeilijk zijn) om te kijken of ze 'onderweg' niet iets raken. Aan de andere kant zou je kunnen zeggen dat die kogels normaal niet in een rechte lijn vliegen, maar met een boog. En dat dus alleen het doel-coordinaat geraakt kan worden en de kogel onderweg gewoon over de tanks heen vliegt

[MLM]

dat is idd ook mogelijk, maar is allebei redelijk goed te implementeren,dat zie ik dan wel weer

[muba]

Het lijkt mij idd ook dat een tank gewoon een heel coordinaat in beslag neemt. Makkelijk collission detecten ook, lijkt me.

Maar ik heb nog een vraag. Als rijden gewoon onmiddelijk gebeurt, dan is het moeilijk richten, toch?
Ik zal een casus schetsen.

Er zijn 2 bots op de server.
In de eerste beurt bewegen beide tanks niet, maar ze voeren wel een scan uit.
De bots ontdekken dat ze een (schaak-)paardesprong van elkaar verwijderd zijn

code:

1
   2

Beurt 2
Tank 1 rijdt 2 coordinaten naar rechts en schiet 1 coordinaat naar beneden.
Tank 2 rijdt 2 coordinaten naar links en schiet 1 coordinaat naar boven.
Beide tanks voeren een nieuwe scan uit, en ze zien weer dat ze een paardesprong verwijderd zijn.

Beurt 3
Beide tanks rijden terug naar hun beginplek en schieten weer.

Etc etc
Dit dansje zal toch eeuwig doorgaan?
Het lijkt mij dat het afleggen van een route gewoon tijd kost. Dan kan een bot ook proberen te voorspellen wat iemand gaat doen en daar iets tegen ondernemen.
Nu is iedereen gewoon aan het teleporten en het is moeilijk om je daar op te orienteren.


En kan je in een beurt ook meerdere keren rijden en schieten enzo, als je maar genoeg energie hebt?

[Voutloos]

MUBA schreef op donderdag 03 maart 2005 @ 12:19:
Beide tanks rijden terug naar hun beginplek en schieten weer.

Etc etc

Je kan maar 60 graden draaien. Dat voorkomt totaal onvoorspelbaar gedrag, je moet meer je best doen om te ontwijken en je kan niet heen en weer rijden. [Ho, kan zijn dat MLM het niet eens was met de 60 graden beperking. ]

Overigens zou 1 van de clients zo slim kunnen zijn dat hij ziet dat de ander elke x^e beurt op dezelfde plek staat en gewoon kunnen zorgen dat hij op beurt x-1 op die plek schiet, aan gezien je wel elke kant op kan schieten. De ander staat ook de andere beurten steeds op een dezelfde plek als x beurten geleden, dus wordt zelfs elke beurt vol geraakt (in jouw schets, want ik neem aan dat men hun bot iets anders laat doen op het moment dat je herhaaldelijk geraakt wordt)

En kan je in een beurt ook meerdere keren rijden en schieten enzo, als je maar genoeg energie hebt?

Alle acties {0,1} keer (0 als je er geen energie in stopt), in vaste volgorde.

[ Voor 15% gewijzigd door Voutloos op 03-03-2005 13:48 ]

[Soultaker]

MUBA schreef op donderdag 03 maart 2005 @ 12:19:
Het lijkt mij idd ook dat een tank gewoon een heel coordinaat in beslag neemt. Makkelijk collission detecten ook, lijkt me.

Dat staat haaks op wat eerder ontworpen is, namelijk een systeem waarin je 'vrij' rijdt. Hoe wil je een draaien van 10 graden maken en vervolgens 1 vakje rijden, als je integer coordinaten gebruikt? Dan kom je dus op een benadering van het doel terecht. De enige manier om dat een beetje nauwkeurig te maken is door een heel gedetailleerd speelveld te nemen maar dan komt het praktisch nooit voor dat twee robots op exact dezelfde positie staan.

Als er collision detect gebeurt, dan is op basis van een bounding box/circle wat mij betreft de enige zinnige optie. Maar op dit moment zou ik er helemaal geen collision detection in stoppen; het maakt de eerste versie alleen maar ingewikkelder zonder iets essentieels toe te voegen en er is geen reden waarom het later niet toegevoegd zou kunnen worden als we later denken dat het leuk is.

Het lijkt mij dat het afleggen van een route gewoon tijd kost. Dan kan een bot ook proberen te voorspellen wat iemand gaat doen en daar iets tegen ondernemen.
Nu is iedereen gewoon aan het teleporten en het is moeilijk om je daar op te orienteren.

Omdat je met discrete tijd werkt zul je altijd 'teleporteren' maar als de maximale afstand beperkt is (wat helaas niet helemaal is overgenomen door MLM) dan is het bij benadering een soepele beweging. In jouw voorbeeld staan de tanks misschien al heel dicht bij elkaar; je moet het meer zien dat als de tanks op 100 meter afstand staan, ze elke keer (bijvoorbeeld) 2 meter kunnen rijden. Als je dan een projectiel 100 meter vooruit schiet en de explosie een radius van 10 meter heeft, kun je nog steeds goed raken.

Je raakt natuurlijk beter naar mate je beter voorspelt waar je tegenstander naartoe gaat. Dat is dus een uitdaging voor de clients. In het eerdere voorstel was het ook de bedoeling om de hoeveelheid graden die je je tankje kunt draaien per beurt te beperken; ook dat is helaas niet overgenomen, want dat zorgt er nu ook juist voor dat de voorspelbaarheid toeneemt. Je doelwit kan dan stil blijven staan, naar voren rijden, of een beetje opzij, maar niet in een hoek van 90 of 180 graden wegvluchten.

[Verwijderd]

Collision detection met discrete beweegstappen is ook weer niet helemaal triviaal bedacht ik me net. We zullen het er in de eerste versie maar uithouden lijkt me.

[Voutloos]

Als je zo goed als op dezelfde positie staat als de tegenstander is het gewoon aan de client om een afstand te nemen zodat je geen last hebt van je eigen splash damage (en ja als beiden dat doen zit het er dik in dat er een rondje misgeschoten wordt, so what), of dat je vol schiet in een soort kamikaze aanval.

[raptorix]

Ik ben op dit moment voor me werk veel bezig met Rich Internet Applications, en dan met name Macromedia Flex, op zich zou ik op vrij makkelijke manier het slagveld grafisch kunnen representeren, inclusief informatie van de tanks. Het enige wat ik nodig heb is dat de server een mogelijkheid heeft om gegevens via xml uit te spugen.

Als er behoefte aan is kan ik dat in elkaar zetten en hosten.

[MLM]

XML is een uitbreiding die GEEN prioriteit heeft

ik kwam idd ook op het idee dat als bots teleporteren, collision detection moeilijker wordt. Nu dacht ik zo:

C:

bot A rijdt in een rechte lijn, van A1 naar A2
bot B rijdt in een rechte lijn, van B1 naar B2
if( lijn(A1,A2) kruist lijn(B1,B2) )
{
kruispunt = punt K
if( (afstand(A1,A2) / afstand(A1,K)) ongeveer gelijk aan (afstand(B1,B2) / afstand(B1,K))
{
-> collision @ K
}
}

[raptorix]

Is er overigens al iets werkend of is er alleen een PDF?

[MLM]

niets public's, zoals ik al eerder postte, ergens volgende week heb ik een public beta af (gepland )

[mocean]

Ik lees volgens mij dat een spel steeds doorgaat totdat één botje heeft gewonnen. Is het niet een beter idee om wanneer je dood gaat, meteen te 'respawnen'?

Anders kan je situaties krijgen met 2 botjes die overblijven, maar die beiden toevallig slecht aanvallen/goed verdedigen en dan kan het wel een tijdje gaan duren.

Als het veld steeds 'vol' blijft, kan je denk ik sneller je bot verbeteren, en is het ook leuker om te volgen.

[ Voor 4% gewijzigd door mocean op 03-03-2005 18:38 ]

[FireWood]

Met de tijden waar het allemaal mee gebeurt, krijg je waarschijnlijk gigantisch snelle battles. Beter gezegd ik denk niet dat je het kan volgen. Als een afslachting 50 beurten kost: 50*200ms is 10 sec. Ik hoop dat je dat nog kan wachten.

[MLM]

mocean schreef op donderdag 03 maart 2005 @ 18:38:
Ik lees volgens mij dat een spel steeds doorgaat totdat één botje heeft gewonnen. Is het niet een beter idee om wanneer je dood gaat, meteen te 'respawnen'?

Anders kan je situaties krijgen met 2 botjes die overblijven, maar die beiden toevallig slecht aanvallen/goed verdedigen en dan kan het wel een tijdje gaan duren.

Als het veld steeds 'vol' blijft, kan je denk ik sneller je bot verbeteren, en is het ook leuker om te volgen.

Heb je het PDFje eigenlijk wel gelezen?

Dat idee staat al in het PDFje, lees die eerst eens door, zodat je constructiever commentaar kan leveren (NFI)

[mocean]

MLM schreef op donderdag 03 maart 2005 @ 20:17:
[...]

Heb je het PDFje eigenlijk wel gelezen?

Dat idee staat al in het PDFje, lees die eerst eens door, zodat je constructiever commentaar kan leveren (NFI)

Volgens mij heb je hoodstuk 6 stiekum toegevoegd nadat ik het gelezen had :-)

[MLM]

mja, ik verander het PDFje wel af en toe
zijn er al mensen begonnen met bedenken van een bot?

[Voutloos]

Ik heb denk ik al een redelijk goede en originele tactiek bedacht. Maar die ga ik niet nu al prijsgeven.

Ik ben zeer benieuwd naar de bèta server. Keep up the good work. (en overhaast je niet)

[ Voor 14% gewijzigd door Voutloos op 04-03-2005 11:15 ]

[Skaah]

Ik ben bezig met het ontwikkelen van de klassen voor de contest (robot, enemy, environment) en in heb al wat logica uitgedacht. Maar voor echte implementaties is het nog vroeg.

PHP uiteraard

[ Voor 6% gewijzigd door Skaah op 04-03-2005 11:21 ]

[Devion]

Bots respawnen is wel het leukste, kun je teminste gewoon doorgaan..

[ Voor 76% gewijzigd door Devion op 04-03-2005 11:24 . Reden: editje ;) ]

[Voutloos]

Devion: Leuk dat je je joystick opmerking wegedit. Ik hoop dat je dat plan dus uit je hoofd hebt gezet, want menselijke besturing was dus niet de bedoeling.

Anders had dit topic wel in SGD gestaan.
_{Dit klinkt misschien iets aanvallend, maar ik heb gewoon veel zin in een faire wedstrijd.}

[mocean]

* mocean is een weekje op vakantie, ga ik eens rustig nadenken over mn tactiek.

Ben benieuwd wat er daarna al werkend is van de servert...

[Devion]

Devion: Leuk dat je je joystick opmerking wegedit. Ik hoop dat je dat plan dus uit je hoofd hebt gezet, want menselijke besturing was dus niet de bedoeling.

Ho hold on, ik had 'm weggeedit omdat ik niet had gezien dat er nog 7 paginas aan reacties waren , enneh het was een reactie op dat met de joystick meespelen weinig nut had want de turn-based zal met bots een heel stuk sneller gaan dan player vs player.

Mijn botje zal fair zijn =)

zijn er al mensen begonnen met bedenken van een bot?

jup, so far so good, main AI script ga ik implementeren via XML zodat ik meerdere tactieken kan toepassen danwel merged of seperaat. app zelf geeft de battlefield aan met de tankjes die de bot 2 secs geleden heeft gezien etc. Geen player input naar de bot zelf behalve tactiek-verandering.

Zit alleen nog met een paar vraagjes richting de server-dev; wat krijgt de bot aan return info trug? locatie, shield, etc maar ook bijv de health van een andere bot die in de buurt is?

enneh hoe zit het de turning radius van de tanks? 360 graden vrijheid of bijv maar 8 (als het een 'tiled' speelveld is)

[ Voor 47% gewijzigd door Devion op 04-03-2005 15:11 . Reden: quote + extra vraagje ]

[MLM]

return info is je eigen HP's (schild-energie)
locatie niet, immers je bevindt je ALTIJD op 0,0 (alles is relatief)
indein je een scan doet krijg je coordinaten van andere bots tov van jezelf (wederom relatief), met nick + HP

draaien is niet gelimiteerd, je geeft een coordinaat op waar je naartoe wil, draaien wordt berekend door server, die daar de energie-kosten aan verbindt.

[ Voor 27% gewijzigd door MLM op 04-03-2005 16:07 ]

[raptorix]

MLM schreef op vrijdag 04 maart 2005 @ 16:07:
return info is je eigen HP's (schild-energie)
locatie niet, immers je bevindt je ALTIJD op 0,0 (alles is relatief)
indein je een scan doet krijg je coordinaten van andere bots tov van jezelf (wederom relatief), met nick + HP

draaien is niet gelimiteerd, je geeft een coordinaat op waar je naartoe wil, draaien wordt berekend door server, die daar de energie-kosten aan verbindt.

Ik neem dus aan dat je dan niet zoiets als een geschutskoepel hebt, die los kan draaien van het onderstel?

[Devion]

misschien zijn het hele oude tankjes met een fixed koepel,
trouwens misschieen een ideetje voor de mensen die straks een gui eromheen bouwen, een 'say' command naar de server dat je teminste nog wat info kunt geven over wat het tankje aan het down is... bijv. -- '[Bot]Devion is currently on the camping tactic' ofzo

[Verwijderd]

Devion schreef op vrijdag 04 maart 2005 @ 15:03:

jup, so far so good, main AI script ga ik implementeren via XML zodat ik meerdere tactieken kan toepassen danwel merged of seperaat. app zelf geeft de battlefield aan met de tankjes die de bot 2 secs geleden heeft gezien etc. Geen player input naar de bot zelf behalve tactiek-verandering.

Ik vraag me of of dat moet mogen. Mag je aanwijzingen geven aan je bot, zoals "aanvallend spelen", "verdedigend spelen"? Zo ja, wanneer? Ik kan me voorstellen dat dit samenhangt met het spelsysteem, als je constant respawnt zou het wel moeten mogen vind ik (tussen respawns in), maar als je constant speelt moet je bot het zelf uitzoeken.

edit:
En is de grootte van het speelveld bekend bij de bot?

[ Voor 7% gewijzigd door Verwijderd op 04-03-2005 17:40 ]

[raptorix]

Zou niet moeten mogen IMO, het leuke is juist dat als ie 20 keer achter elkaar verliest dat ie dan door zou meoten hebben dat ie van tactiek moet veranderen.

[FendtVario]

Devion schreef op vrijdag 04 maart 2005 @ 15:03:
jup, so far so good, main AI script ga ik implementeren via XML zodat ik meerdere tactieken kan toepassen danwel merged of seperaat. app zelf geeft de battlefield aan met de tankjes die de bot 2 secs geleden heeft gezien etc. Geen player input naar de bot zelf behalve tactiek-verandering.

Wat is er zo hot aan XML? Ik heb al gelezen dat iemand een protocol wil dat aan XML doet en nu tacktieken via XML XML is heus geen glorie toch naar succes zoals veel denken.

Ik besteed mijn tijd liever aan een bot die werkt (wordt al moeilijk zat).

[Devion]

zo 'Hot' aan XML.. mmh.. makkelijk data extern hebben staan en makkelijk aan te passen, kunnen enumeraten op de nodes.. beats .ini

Zou niet moeten mogen IMO, het leuke is juist dat als ie 20 keer achter elkaar verliest dat ie dan door zou meoten hebben dat ie van tactiek moet veranderen.

Het gaat er niet om dat -ik- die kan veranderen voor de bot, hij heeft gewoon bepaalde strategieen als default. oa. Seek and destroy methode, defensief, etc.

het enigste wat er in de tactieken staat is:

code:

<!-- 1 = low, 5 = middle, 10 = high -->
<botwars>
    <tactic>
        <name>Search and destroy</name>
        <scanratio>5</scanratio>
        <fireratio>5</fireratio>
        <driveratio>5</driveratio>
        <idleratio>5</idleratio>
        <autotaunt>yes</autotaunt>
        <randomprobabilityfactor>10</randomprobabilityfactor>
        <investigateborderareas>yes</investigateborderareas>
        <conservepower>no</conservepower>
        <shootradius>3</shootradius>
        <attacklowhealth>yes</attacklowhealth>
    </tactic>
</botwars>

zoiets :]

[.oisyn]

Even voor de goede orde, collision detection is loeisimpel met spheres (uh.. cirkels) en als je het vervelend vindt wil ik het ook wel implementeren

Soultaker schreef op donderdag 03 maart 2005 @ 13:46:
Omdat je met discrete tijd werkt zul je altijd 'teleporteren' maar als de maximale afstand beperkt is (wat helaas niet helemaal is overgenomen door MLM) dan is het bij benadering een soepele beweging.

Wat is er mis met gewoon een bewegende cirkel-intersectie, zodat je exact het tijdstip van botsing kunt bepalen?

[ Voor 59% gewijzigd door .oisyn op 04-03-2005 21:54 ]

[Soultaker]

Die opmerking van mij had niet met collision detection te maken.

De reden om geen collision detection te doen is dat het naar mijn mening niet heel veel toevoegt en de simulatie (zowel voor de server als voor de clients) een stuk lastiger maakt. Dan zie ik liever eerst een werkend prototype en dan kunnen we later altijd collision detection toevoegen.

[ Voor 9% gewijzigd door Soultaker op 04-03-2005 21:57 ]

[Devion]

Dan zie ik liever eerst een werkend prototype en dan kunnen we later altijd collision detection toevoegen.

I can agree with that ;-)
Maar met een vast gelegd protocol ben ik op dit moment ook al blij.

[MBV]

oei, ik had iets vaker moeten kijken. Ik ben er 2 dagen niet, en het is al bijna af! Wat ik wilde zeggen met WxWidgets en Qt (2 dagen = 7 pagina's terug) is dat bijde frameworks ook netwerk implementeren. uiteraard geen Gui voor de server.

What's so hot about XML? Is in veel talen (zoals PHP, Javascript e.d.) simpel te parsen. Gevolg is dat het simpel is om een textfile om te zetten naar XML, omdat je het niet meer zelf hoeft te doen.

Waar ik denk dat nu te weinig rekening wordt gehouden is dat je met 200ms tijd tussen 2 turns (of zelfs langer) menselijke interactie kan doen. Stel je voor dat je een bot maakt, die alle informatie die hij binnen krijgt zélf op het scherm zet. Je kan als mens dan misschien live parameters veranderen. Ik zou zoiets iig maken als debugging. Is dat toegestaan?
Waar ik dan aan denk is dus een simpele radar map, en wat drawbars voor aggresiviteit ofzo.

Wat mij ook niet duidelijk is, is hoe groot het veld is. Hoeveel coördinaten zijn er? 10x10? 1000x1000? Bij dat laatste zal je de 'paard-afstand' niet snel hebben. Hoever kan je schieten? 5, 10 of 100 'coordinaten'? Hoever kan je rijden? Die verhoudingen lijken mij erg belangrijk voor het bepalen van een strategie.

[El_kingo]

MBV schreef op zaterdag 05 maart 2005 @ 01:07:
Waar ik denk dat nu te weinig rekening wordt gehouden is dat je met 200ms tijd tussen 2 turns (of zelfs langer) menselijke interactie kan doen. ... <KNIP>
Ik zou zoiets iig maken als debugging. Is dat toegestaan?
Waar ik dan aan denk is dus een simpele radar map, en wat drawbars voor aggresiviteit ofzo.

Als je perse wilt is menselijke interactie altijd mogelijk, als je dat wilt uitsluiten moet iedereen zijn programma opsturen zodat vanaf 1 (evt meerdere in 1 netwerk) computer de bots worden gedraait.
Praktisch niet onmogelijk, maar maakt het debuggen etc. wel een stuk moeilijker.
Ik denk dat voor debuggen info vanuit je bot noodzakelijk is, maar interactie met je bot is gewoon not done...

Daarbij: Cheaten is LAME. Het gaat er om of je bot een tank kan besturen niet of jij dat kan. Het zou mij in dit geval ook niet veel interesseren of ik win of niet, het is gewoon een grappige uitdaging. Achteraf kun je dan zien welke strategie of "AI" het beste resultaat oplevert en daar ben ik dan meer in geinteresseerd.

Wat mij ook niet duidelijk is, is hoe groot het veld is. Hoeveel coördinaten zijn er? 10x10? 1000x1000? Bij dat laatste zal je de 'paard-afstand' niet snel hebben. Hoever kan je schieten? 5, 10 of 100 'coordinaten'? Hoever kan je rijden? Die verhoudingen lijken mij erg belangrijk voor het bepalen van een strategie.

Ik sluit mij hierbij aan. Meer info is wenselijk, maar ik wacht gewoon rustig af aangezien ik denk dat dat vanzelf komt zodra de server verder is ontwikkeld.

[ Voor 6% gewijzigd door El_kingo op 05-03-2005 10:03 . Reden: tiepuh blijv moeiuluk ]

[Mithrandir]

Ik denk dat alle problemen over valsspelen opgelost worden als iedereen zijn/haar broncode openbaar moet maken. Dat zou een heel redelijke regel zijn voor de wedstrijd; wat heb je er aan als iemand wint maar de anderen kunnen er niets van leren?

[Skaah]

We zijn volwassen mensen, laten we afspreken dat we niet gaan cheaten. Cheaten is voor mensen die niet kunnen programmeren.

[Devion]

Cheaten is voor mensen die niet kunnen programmeren. = Amen!

[CyeZ]

Ik zal toch eens gaan kijken naar de mogelijkheden voor PHP te gebruiken. Zoals het er nu naar uit ziet met vereiste reactie tijden van < 1 sec zal het voor mij erg lastig zijn met een lokale client applicatie snel genoeg een reactie terug te sturen (Delay Shanghai <-> Nederland is te groot).

Een leuk voordeeltje van PHP is dan wel dat het een geintrepreteerde taal is, waardoor het eenvoudig is om de bot andere stukken code dynamisch in te laten laden om zo een andere strategie te kiezen.

[kunnen]

Hoeveel mensen zijn eigenlijk al aan hun bot begonnen? Hoe loopt alles? Ik start pas als er een downloadbare versie van de server is

[Soultaker]

Ik wacht tot de specificatie af is en de relevante parameters (duur van een beurt, grootte van het speelveld, energiewaarden, enzovoorts) bekend gemaakt zijn.

[H!GHGuY]

grootte van het speelveld doet er helemaal niet toe:
- als je er links van rijdt, kom je er rechts terug op.
- alle coordinaten worden relatief doorgegeven volgens de kleinste afstand.

[Soultaker]

Dan doet de grootte van de aarde er ook niet toe, want als je lang genoeg naar het oosten loopt kom je via het westen weer terug naar huis.

[Verwijderd]

Soultaker schreef op zaterdag 05 maart 2005 @ 16:35:
Dan doet de grootte van de aarde er ook niet toe, want als je lang genoeg naar het oosten loopt kom je via het westen weer terug naar huis.

Dat zei Columbus ook.

Probeer je nou te zeggen dat hij ongelijk had?

[Sjaaky]

De grote van de wereld is wel enigzins van belang.
Als je een radarscan kan doen van 100 lengtes terwijl de wereld een hoogte x breedte van 50 x 50 heeft kan krijg je leuke effecten. Je ziet jezelf dan namelijk op verschillende plaatsen etc..
Als je met een radarscan bijna de hele wereld kan overzien moet je er op bedacht zijn dat een tank ten zuiden van je ineens in het noorden kan opdoemen. Dit kan je ook in je voordeel gebruiken.
Als je wereld significant groter is dan het gebied dat je kunt waarnemen hoef je met dat soort effecten geen rekening te houden.

Lijkt me dat optie 1 sowieso geen optie is. Optie 2 en 3 lijken me beide speelbaar.

[dingstje]

Het is ook zo dat het wel van belang kan zijn om de kans in te schatten dat er plots een derde opduikt. Als je een scan met straal 10 doet en je ziet niemand en het veld is 1000 groot, is de kans dat er plots iemand opduikt 1/100. Als het veld echter 50 groot is wordt die kans plots 1/5. Dat kan dus wel interessant zijn om je taktiek te bepalen.

[Soultaker]

Verwijderd schreef op zaterdag 05 maart 2005 @ 21:27:
Dat zei Columbus ook.

Probeer je nou te zeggen dat hij ongelijk had?

Columbus had het goede idee: de wereld is rond, als een pannenkoek. Je kunt wel via het oosten naar het westen, maar dan moet je via de onderkant varen en dat is nogal een saaie reis omdat daar niemand woont (dat kan ook niet, natuurlijk, want als je aan de onderkant zit werkt de zwaartekant de verkeerde kant op en val je er vanzelf vanaf).

Maar in onze bot-wereld - die niet rond is, maar hooguit donut-vormig (ook al kloppen de verhoudingen dan niet) en waar je niet vanaf kunt vallen - is het nog steeds van belang te weten hoe groot de wereld is, zodat je allerlei praktische dingen weet zoals hoe lang het duurt voor je iemand weer tegenkomt als je van 'm wegrijdt en dat soort dingen.

De vraag is hoe groot de wereld precies is. Ik vind het in de echte wereld bijvoorbeeld wel fijn om te weten dat ik weliswaar van Arnhem naar Utrecht kan door naar het oosten te reizen, maar dat naar het westen reizen een stuk sneller gaat. Daar sloeg mijn oorspronkelijk opmerking ook op: het is leuk om te weten dat de wereld rondloopt, maar dan is het nog steeds relevant hoe groot die wereld precies is.

[ Voor 11% gewijzigd door Soultaker op 06-03-2005 02:14 ]

[raptorix]

CyeZ schreef op zaterdag 05 maart 2005 @ 13:38:
Ik zal toch eens gaan kijken naar de mogelijkheden voor PHP te gebruiken. Zoals het er nu naar uit ziet met vereiste reactie tijden van < 1 sec zal het voor mij erg lastig zijn met een lokale client applicatie snel genoeg een reactie terug te sturen (Delay Shanghai <-> Nederland is te groot).

Een leuk voordeeltje van PHP is dan wel dat het een geintrepreteerde taal is, waardoor het eenvoudig is om de bot andere stukken code dynamisch in te laten laden om zo een andere strategie te kiezen.

Je zou ook perl kunnen gebruiken, de stap van PHP naar Perl is vrij klein, en de ondersteuning van sockets is stuk beter. Ik denk dat ik zelf wel Perl ga gebruiken maar misschien ga ik ook wel voor VB6

[Verwijderd]

Soultaker schreef op zondag 06 maart 2005 @ 02:04:
[...]
Maar in onze bot-wereld - die niet rond is, maar hooguit donut-vormig (ook al kloppen de verhoudingen dan niet) en waar je niet vanaf kunt vallen - is het nog steeds van belang te weten hoe groot de wereld is, zodat je allerlei praktische dingen weet zoals hoe lang het duurt voor je iemand weer tegenkomt als je van 'm wegrijdt en dat soort dingen.

Om een lang verhaal kort te maken: ik ben 't met je eens.

[Verwijderd]

Mithrandir schreef op zaterdag 05 maart 2005 @ 11:56:
Ik denk dat alle problemen over valsspelen opgelost worden als iedereen zijn/haar broncode openbaar moet maken. Dat zou een heel redelijke regel zijn voor de wedstrijd; wat heb je er aan als iemand wint maar de anderen kunnen er niets van leren?

Ik denk dat de grens tussen cheaten en bugs niet te trekken is. Open source lijkt me niet echt handig want het is niet te controleren en het geeft de eigenschappen van iemands methode prijs. De grens tussen bug of cheat hoeven we niet te trekken wanneer de server stateful is. Wie bij zo'n server dingen wil doen die niet kunnen wordt aan poeier geschoten.

[RedLizard]

Het lijkt me leuk als je de kracht van de kogel tijdens een aantal beurten kunt chargen, zodat je eerst een half uur kunt opladen en dan een waanzinnig lomp schot kunt geven. Dat moet je zoiets hebben als een tweede energiebuffer voor het kanon.

Wat vinden jullie hiervan?

[Coca-Cola]

Het lijkt me verstandig om nog maar even te wachten met ideeen die het geheel nog gecompliceerder maken. Prioriteit moet volgens mij liggen bij het schrijven van de server en een soort van basic uitvoering van het spel. Tegen de tijd dat dit draaiende is kunnen we altijd nog gaan sleutelen aan de regels en de boel ingewikkelder maken (een beetje complexiteit maakt het voor de bot-ai alleen maar leuker )

[Mithrandir]

Verwijderd schreef op maandag 07 maart 2005 @ 11:28:
[...]


Ik denk dat de grens tussen cheaten en bugs niet te trekken is. Open source lijkt me niet echt handig want het is niet te controleren en het geeft de eigenschappen van iemands methode prijs. De grens tussen bug of cheat hoeven we niet te trekken wanneer de server stateful is. Wie bij zo'n server dingen wil doen die niet kunnen wordt aan poeier geschoten.

Het is toch geen doorlopende competitie? Op het eind verwacht ik wel dat iedereen zijn methode prijsgeeft eigenlijk. Dan zijn de wedstrijden geweest en is er een leermoment voor iedereen...

[Verwijderd]

Mithrandir schreef op maandag 07 maart 2005 @ 15:58:
[...]


Het is toch geen doorlopende competitie? Op het eind verwacht ik wel dat iedereen zijn methode prijsgeeft eigenlijk. Dan zijn de wedstrijden geweest en is er een leermoment voor iedereen...

Geen idee. De competitie kan doorlopend genoeg zijn om tijdens de competitie te leren. Misschien zit er een domme (b)loop in m'n algorithme, of waren m'n veronderstellingen over het wedstrijdverloop niet geheel juist. Misschien herkennen mijn tanks elkaar of zo . Als de regels 't toelaten maak ik m'n AI hot-swappable. Schaakcomputers kunnen ook uitgerust worden met aparte strategie voor opening, midgame en endgame.

[muba]

Cheaten is lame, ik sluit me aan bij de afspraak dat niet te doen - als ik mee ga doen, dat weet ik nog niet. Maar als ik mee ga doen, doe ik dat in Perl denk ik.

[MBV]

Maar wil iemand mij vertellen wat cheaten is? Is het cheaten om halverwege het spel wat parameters te veranderen? Is het cheaten om 'mee te kijken' met je bot?

Ik denk dat ik er een oplossing voor weet ook: Voor de top-10 moet de code ingeleverd worden, en de winnaar wordt op 'doping' gecontroleerd. Moeten we wel beslissen dat alles wat naar user-interactie ruikt illegaal is (wat mij de tendens hier lijkt)

[ritsjoena]

Verwijderd schreef op maandag 07 maart 2005 @ 20:05:
[...]Als de regels 't toelaten maak ik m'n AI hot-swappable. Schaakcomputers kunnen ook uitgerust worden met aparte strategie voor opening, midgame en endgame.

Als je bedoelt dat je een ander programma wil starten, dan lijkt me niet dat dat gefaciliteerd word. Dat levert namelijk problemen op met het overdragen van de connectie. Natuurlijk kun je zelf een schil schijven die lokaal die overdracht aanstuurt.

Het is een stuk makkelijker als je in je programma iets opneemt van de vorm:
if #beurten < x then ai_functie_1
else ai_functie_2

Daarmee maak je het jezelf makkelijk en er zal niemand zijn die daar moeilijk over doet. Sterker nog, je bent waarschijnlijk niet de enige die dit gebruikt. (als het zinnig is)

[edit]Overigens wat betreft meekijken: natuurlijk kun je je eigen bot op je eigen scherm gaan afbeelden. Maar gezien de snelheid waarmee dit alles gaat verlopen wens ik je sterkte met realtime ingrjipen.

Wat dat betreft moeten de snelheid van de publieke viewer misschien ook vertraagd worden.

[ Voor 18% gewijzigd door ritsjoena op 08-03-2005 09:52 ]

[ritsjoena]

MBV schreef op dinsdag 08 maart 2005 @ 00:54:
Maar wil iemand mij vertellen wat cheaten is?

cheaten:
1) Het veldoverzicht (voor publiek meekijken) gebruiken in je ai. Dit kan opgelost worden door deze minstens een paar beurten te vertragen. (1 is niet genoeg, denk namelijk zelf maar na hoe je dat kan gebruiken )

2) Gebruik maken van eventuele bugs in de server. Laten we eerlijk zijn en deze gewoon melden, opdat ze eruit gehaald kunnen worden.

3) Meerdere bots connecten en deze te laten samenwerken door hun gegevens rechtstreeks te delen. (hoewel besloten kan worden dit toe te staan) We moeten misschien nadenken over of we meerdere bots van dezelfde persoon willen toestaan. Als we dat doen stel ik voor daar aparte wedstrjid rondes voor te houden. Is wel een interessante toevoeging aan het ai_probleem. Zeker als we niet toestaan dat ze hun gegevens delen (tenzij we daar een actie van maken).

4)...

edit:

Wat niet cheaten is:
1) Een snellere computer kopen, eventueel een cluster supercomputers. Als jij dat er voor over hebt ga je je gang maar. Je zult er niet zo heel veel aan hebben (tenzij je nu iets langzaams hebt). Het algoritme is waarschijnlijk belangrijker.

2) Verschillende algortimes gebruiken voor verschillende situaties. Je kunt toch maar 1 resultaat gebruiken. Let wel op je tijd (toch maar een cluster supercomputers aanschaffen )

3) Alle mogelijkheden van te voren doorrekenen en de resultaten in je ai verwerken. Heb je alleen een probleem als de spel-parameters veranderen. Bovendien ken je niet alle spelparameters.

4) Je eigen scan-geschiedenis bijhouden en inschatten waar wie is gebleven. Er zullen ai's zijn die dit doen.

5) De gegevens van je eigen bot (en ai/geschiedenis) op je eigen scherm/webpage/webstream af te beelden.

6) Je eigen systeem optimaliseren om de laatste clockcycle voor je ai te kunnen gebruiken.

7) ...

dubieus of het cheaten is of niet:
1) realtime ingrijpen. Dit kunnen we en zouden we moeten verbieden, maar gezien de snelheid waarmee dit gaat verlopen wens ik je veel sterkte met deze strategie. Daarom maak ik me er geen zorgen over, doch strikt genomen vind ik het cheaten (je programma moet het zelf op kunnen lossen).

[ Voor 44% gewijzigd door ritsjoena op 08-03-2005 10:11 ]

[Coca-Cola]

ritsjoena schreef op dinsdag 08 maart 2005 @ 09:45:
[...]

1) Een snellere computer kopen, eventueel een cluster supercomputers. Als jij dat er voor over hebt ga je je gang maar. Je zult er niet zo heel veel aan hebben (tenzij je nu iets langzaams hebt). Het algoritme is waarschijnlijk belangrijker.

[...]

Mocht er iemand hier tijd op een cluster willen lenen hoor ik het wel Overigens denk ik dat het optimaliseren van je algoritme een stuk minder tijdrovend is dan het (her)schrijven van je code om (goed) op een cluster te draaien

[.oisyn]

Verwijderd schreef op maandag 07 maart 2005 @ 20:05:
Als de regels 't toelaten maak ik m'n AI hot-swappable. Schaakcomputers kunnen ook uitgerust worden met aparte strategie voor opening, midgame en endgame.

Je bot mag natuurlijk best z'n strategie veranderen, zolang jij daar tijdens het spel maar geen invloed op hebt.