[alg] botwar Bespreking *

[Verwijderd]

Ik heb een prototype-server die op het moment collision detection (radius-methode met previous frame) en splash-damage implementeert. Nu lees ik hier dat er andere mensen ook servers zitten te implementeren? Het blijft moeilijk een organisatie van de grond te krijgen als mensen niet de hele draad lezen...

[Verwijderd]

Mietje, ik wil gerust wel helpen met jouw server, want ik heb geen zin om dubbel werk te doen

ik denk dat iedereen in dit topic wel zin heeft in een contest, maar de organisatie gaat iets anders worden

dus ik biedt mij hulp aan (als ge een VB programmeur kunt gebruiken)
en anders help ik wel met brainstormen enzo

[wacco]

me 3
Alleen inhoudelijk stelt mijn werk nog niet veel voor.
Kan je iets van een link geven naar source oid? Kunnen we meewerken.

[RickN]

Ik vind het huidige idee klinken als VEEEEEEEEEEEL te veel werk. Ik zoek gewoon leuke programmeer probleempjes die je met een beetje analyse op papier en een paar uurtjes programmeren oplost. Dit klinkt meer als een 5 jaren plan..... En mag ik er, voor iemand heel veel tijd gaat steken in de organisatie hiervan, even op wijzen dat bij de vorige GPC de laatste opgave, ook een AI opdracht, slechts één enkele inzending had....

[Soultaker]

Staat er al iets vast, op welk vlak dan ook? De talen die ondersteund worden? De opgave(n)? De communicatie tussen de programma's en de jurysoftware? De platforms die ondersteund worden? Wie dit allemaal gaat organiseren? Wie er deel kunnen nemen? Op welke termijn het een en ander moet gebeuren?

Uit deze thread maak ik namelijk op dat iedereen zijn eigen ideeën heeft en dat werkt natuurlijk niet. Iedereen die nu al meer dan 0 regels code geschreven heeft is fout bezig.

Persoonlijk denk ik, gezien de gang van zaken in deze thread, dat het helemaal niets wordt met een nieuw GPC. Als iemand iets anders kan bewijzen, doe ik graag mee, maar het lijkt me dan vooral leuk als het GPC iets anders biedt dan nu al door initiatieven als CodeCup, C++Bots, RoboWars, USACO, NKP, etcetera aangeboden wordt.

[eXistenz]

RickN schreef op 26 november 2002 @ 19:31:
Ik zoek gewoon leuke programmeer probleempjes die je met een beetje analyse op papier en een paar uurtjes programmeren oplost.

* eXistenz sluit zich aan bij RickN

[ Voor 6% gewijzigd door eXistenz op 26-11-2002 19:35 ]

[wacco]

Zal ik dan maar ff een samenvatting maken? Post em in een minuutje of tien...
Verder denk ik dat mietje, tremor_b, JayTaph zich er wel in kunnen vinden...
...en qua inzendingen dat ook Creepy, MisterData, cobratbq, xychix en J~R~R ook wel mee gaan doen.
Not to mention El_Quedro voor graph-app, en wiseman voor server.
Mensjes wat zijn we enthousiast!

[xychix]

Wanneer het idd een groot project lijkt te worden dan moet zoiets geregeld worden via iets als phpproject oid en niet alleen op een forum.

maar ik denk dat als we niet uitkijken het allemaal te ingewikkeld word!
Maargoed, een paar man op de server. deze dienenen een duidelijke interface bekend te maken zodat de spelers ook tijdig aan het bouwen kunnen.

http://www.gamerz.net/c++robots/c++robots.tar.gz
kijk er op zijn minst eens naar ! een server en een aantal voorbeeld bot's. Niet socketbased

[ Voor 20% gewijzigd door xychix op 26-11-2002 19:48 ]

[Verwijderd]

wacco schreef op 26 November 2002 @ 19:41:
Zal ik dan maar ff een samenvatting maken? Post em in een minuutje of tien...
Verder denk ik dat mietje, tremor_b, JayTaph zich er wel in kunnen vinden...
...en qua inzendingen dat ook Creepy, MisterData, cobratbq, xychix en J~R~R ook wel mee gaan doen.
Not to mention El_Quedro voor graph-app, en wiseman voor server.
Mensjes wat zijn we enthousiast!

Ik doe idd wel mee, als het maar niet te gecompliceerd wordt. Ik ben nl webdeveloper en heb dus weinig ervaring met algorithmes, hoewel een simpele bubblesort nog wel wil lukken natuurlijk

[wacco]

- Qua connectie hoeven de meeste mensen zich niet druk te maken, dat wordt allemaal (waarschijnlijk) geregeld door de mensen die zich aangesproken voelen. Zolang je maar uit jou programma kan connecten naar de -nog later bekent te maken- ip en poort. (sockets dus)

- Qua programmeertaal ben je helemaal vrij, zolang je maar de sockets voor elkaar krijgt. (waarschijnlijk, zie volgende punt)

- Onder welke OS het moet gaan draaien is nog even een beetje discussie. Het is namelijk nog niet duidelijk of de uiteindelijke eindmatches op een paar systemen gedraaid gaan worden, of vanaf je eigen systeem.

- Verder zijn er een hoop spellen gesuggereerd, van simpel tot erg pittig, maar het idee nu is dat we dus gewoon een simpel tankspelletje gaan maken. Met de mogelijkheid om in 5kb code je tank gewoon alles te laten nuken wat ie maar ziet, tot de die-harders die het allemaal retetactisch gaan aanpakken. Who will win? Idunno...

Dan wil ik nog een dingetje in de groep gooien: (beetje radicaal, maar wil het niet voor me houden) als we nou een app bouwen (eentje voor linux, eentje voor windows) die connect met server, en ook grafisch alles mooi maakt, en dat je dáár dan met stdin/stdout je AI aan het werk kan zetten. Krijgen we alles realtime grafisch mooi in beeld en het proggie kan ook acten als server en soort van tussenpersoon, wat dan weer scheelt in de bandbreedte.
Then again is dit misschien weer een beetje té veel werk, om alleen maar de contest draaiende te krijgen...

[bigben04]

wacco schreef op 26 November 2002 @ 18:08:
bigben04: had jij ook dat het per letter ging? hmmmzz...

Yep, de communicatie werkt wel maar de implementatie is een beetje brak
Niet zo gek omdat je het onchanged() event gebruikt voor de textbox van de messages. Je kan beter een keypress afvangen en dan bij elke enter de string versturen.

edit: wacco: ja, begrijp ik. De sockets werken in ieder geval

ff ontopic ook nog: ik denk dat een simpel tankspelletje zoals het voorstel nu is best te doen moet zijn, en ik ben hier zeker voor in om mee te doen (met een client), daar hoef je nog geen die-hard programmeur voor te zijn.

[ Voor 27% gewijzigd door bigben04 op 26-11-2002 20:06 . Reden: toevoeging ]

[wacco]

Mja, dat had ik al in gedachte... maar dan krijg je prolly ook weer dat multiline van het intikvakje aan moet staan (anders gaat ie pingen), dat verneukte de layout weer, etc etc veel te veel geklier voor iets wat sockets moest testen

[Verwijderd]

Je idee zit er goed uit wacco, alleen mis ik of het turn-based of realtime wordt.

[wacco]

turn-based.
Sockets en dan realtime wordt niks, want dan wordt de competitie afhankelijk van je systeem en internetverbinding.

[.oisyn]

Heel tof dat iedereen nu gaat programmeren enzo, maar is het niet handig om wat specs online te gooien?

protocol voornamelijk, dan kun je zien wat de mogelijkheden zijn

[wacco]

protowat?
How about we schoppen text heen en weer? Zie mijn proggie paar posts terug...

[.oisyn]

Een specificatie van het protocol is nou juist wat je precies verstuurt, en wat dat betekent

[Verwijderd]

het idee wat er nu is bevalt me ook wel, simpel robot game, wat turn-based is

maar het protocol zal inderdaad afgesproken moeten worden, dus concreet de mogelijkheden die de server gaat bieden (scan,move,shoot,...) , de commando's die hier voor gebruikt gaan worden, en de vorm van de returnwaardes

voor zover ik het begrijp is mietje al bezig aan een server?
zo ja, heb je al delen van het protocol af ??

p.s. ik d8 aan hele simpele commando's zoals:
schiet(raket,x1,y1,x2,y2) --> type en de begin en eindcoördinaten
move(x1,yx,x2,y2)
...

[bigben04]

.oisyn schreef op 26 November 2002 @ 21:26:
Een specificatie van het protocol is nou juist wat je precies verstuurt, en wat dat betekent

Precies, om een client te proggen moet je toch echt weten wat/hoe je allemaal met de server kan communiceren.
Ik denk echter wel dat een protocol pas echt vastligt als de serverapplicatie redelijk gevorderd is.

[Orphix]

Ik heb de thread wat zitten volgen, maar het ziet er niet hoopvol uit. Ik wil best wat moeite steken in een client maar laat er aub een organisatietje achter zitten.
Ofwel, zoals ik het een beetje zie:
Maak 1(!) server. Deze wordt geprogrammeerd door 1 persoon (waarbij ik mietje persoonlijk de voorkeur geef) en laat deze een groot gedeelte maken. In een vroeg stadium gezamenlijk werken is gedoemd te mislukken. Tuurlijk mag er wat worden gediscussieerd worden over het ontwerp en de gebruikte technieken, maar beslis op een gegeven moment en ga dan verder. Anders komt het nooit van de grond.

Evt. servers e.d. vind ik zwaar oninteressant, trouwens verwachten jullie echt dat er 24/7 botjes op gaan draaien? Ik neem aan dat er een datum komt waarbij een contest komt en dat de clients of lokaal gaan draaien bij iemand of via internet. De server zal ook lokaal gebruikt kunnen worden als ik het goed begreep dus dan is testen helemaal makkelijk.

En verder, het is geen highly-advanced-3d-game ofzo die we aan het maken zijn. Als er 'spectators' (botjes die niet meedoen) worden ondersteund door de server kunnen fanatiekelingen daar hun interface voor schrijven, maar laat de server aub klein, snel en stabiel(!). Ik stel zelfs voor dat de server helemaal geen GUI bevat. Dat kan altijd nog via een spectator.

Het belangrijkste is het spel en daar heb ik tot nu toe erg weinig over gehoord. Wat gaat er nou gebeuren? een zeeslag? hebben we fractie? splash-damage(?)? Dit is denk ik nog het belangrijkste en als dat af is komen de technische details wel.

Anyway zo ver mijn inbreng. Dit is allemaal niet persoonlijk bedoeld trouwens, maar ik merk vaak dat er iets te enthousiast wordt omgesprongen en the sky the limit is en te vroeg op de details ingegaan wordt. Het gevolg is dan dat je uiteindelijk niks hebt, en dat zou ik jammer vinden

[Orphix]

bigben04 schreef op 26 november 2002 @ 21:43:
Ik denk echter wel dat een protocol pas echt vastligt als de serverapplicatie redelijk gevorderd is.

Dit moet je juist van tevoren vastleggen. In het protocol leg je impliciet ook de spelregels vast, de manier waarop robots kunnen bewegen, reageren, informatie krijgen, etc.
Je gaat toch ook niet eerst een website maken en vervolgens HTML bedenken?

[wacco]

Idd. we kunnen wel lullen over een protocol, maar hebben we niet een spel nodig om een protocol voor te bedenken?

[.oisyn]

Orphix schreef op 26 November 2002 @ 21:52 iets over spectators

dat lijkt me geen goed plan, je zou een spectator dan kunnen gebruiken om te kijken waar iedereen is... hoewel het natuurlijk wel handig is om als gebruiker je bot te testen

[bigben04]

Orphix schreef op 26 November 2002 @ 21:54:
[...]

Dit moet je juist van tevoren vastleggen. In het protocol leg je impliciet ook de spelregels vast, de manier waarop robots kunnen bewegen, reageren, informatie krijgen, etc.
Je gaat toch ook niet eerst een website maken en vervolgens HTML bedenken?

Ja, maar vaak loop je bij het coden van de hele zooi dan wel tegen onverwachte dingen aan waardoor het protocol aangepast moet worden, en dan is het niet zo praktisch als X clients zich weer allemaal aan moeten passen.

[Orphix]

.oisyn schreef op 26 november 2002 @ 22:06:

[...]


dat lijkt me geen goed plan, je zou een spectator dan kunnen gebruiken om te kijken waar iedereen is... hoewel het natuurlijk wel handig is om als gebruiker je bot te testen

hmm je bedoelt dat iemand een spectator en bot op z'n comp laat spelen en die onderling informatie laat uitwisselen? Lijkt me vrij immoreel

[Orphix]

bigben04 schreef op 26 November 2002 @ 22:09:
[...]


Ja, maar vaak loop je bij het coden van de hele zooi dan wel tegen onverwachte dingen aan waardoor het protocol aangepast moet worden, en dan is het niet zo praktisch als X clients zich weer allemaal aan moeten passen.

Daarom moet je het van tevoren specificeren. Kan de server het in 1x goed implementeren. Ik zou ook niet met de clients beginnen voordat de server klaar is trouwens.

[.oisyn]

bigben04 schreef op 26 november 2002 @ 22:09:
[...]


Ja, maar vaak loop je bij het coden van de hele zooi dan wel tegen onverwachte dingen aan waardoor het protocol aangepast moet worden, en dan is het niet zo praktisch als X clients zich weer allemaal aan moeten passen.

het is dan ook noodzaak om van tevoren goed over dingen na te denken. Wat zijn kan een bot allemaal, wat zijn de gebeurtenissen, hoe zit het speelveld in elkaar... dat soort dingen dus

Pas daarna kun je er een applicatie omheen bouwen, aangezien dan voor de server bekend is wat de mogelijkheden zijn en dan weet je dus ook wat er geimplementeerd moet worden

[cobratbq]

wacco schreef op 26 November 2002 @ 19:41:
Zal ik dan maar ff een samenvatting maken? Post em in een minuutje of tien...
Verder denk ik dat mietje, tremor_b, JayTaph zich er wel in kunnen vinden...
...en qua inzendingen dat ook Creepy, MisterData, cobratbq, xychix en J~R~R ook wel mee gaan doen.
Not to mention El_Quedro voor graph-app, en wiseman voor server.
Mensjes wat zijn we enthousiast!

Yep ik doe wel mee hoor.

[bigben04]

het is dan ook noodzaak om van tevoren goed over dingen na te denken. Wat zijn kan een bot allemaal, wat zijn de gebeurtenissen, hoe zit het speelveld in elkaar... dat soort dingen dus

Ja dat is wel waar. Maar dan moeten we in deze thread ook wel wat concreter worden want anders wordt het idd niks. Iedereen moet het dus wel min of meer eens worden over wat exact de regels/mogelijkheden van het spel worden.

Ik wil iig zeker wel meedoen.

[ Voor 35% gewijzigd door bigben04 op 26-11-2002 22:23 . Reden: quote toegevoegd ]

[cobratbq]

Laten we eerst een protocol standaard vaststellen. Vervolgens kunnen we bespreken hoe/waar/wanneer/waarom de server moet draaien en dan kan iemand de server (af)schrijven. En daarna gaan we pas verder kijken...

[wacco]

Iemand moet nu gewoon ff het hele idee van dat tankspel uitwerken. Zodra dat duidelijk is, ook qua gameplay, kunnen we verder discusseren over protocollen.
Dan servercode, en tot slot ook daadwerkelijk de hele competitie.

[Orphix]

wacco schreef op 26 november 2002 @ 22:40:
Iemand moet nu gewoon ff het hele idee van dat tankspel uitwerken. Zodra dat duidelijk is, ook qua gameplay, kunnen we verder discusseren over protocollen.
Dan servercode, en tot slot ook daadwerkelijk de hele competitie.

Precies en aangezien mietje begonnen is met het concept en ook al wat van de server heeft gemaakt zal die al wel een duidelijk beeld hebben van hoe hij vindt dat het moet worden. Ik stel voor dat we wachten op hem tot hij met de specificaties aankomt en dan kunnen we daar eventueel op reageren.

[.oisyn]

* .oisyn agrees with Orphix

[Verwijderd]

Ok, even wat uitleg (moest vanavond weg).
Als je een game-engine schrijft waarbij potentieel zeer veel bewegende objecten zijn is het zaak eerst een efficiente collision detection te schrijven, daar staat of valt die engine mee. (Collision detection is niet zo makkelijk als het lijkt als je objecten hebt die snel bewegen, en als er veel objecten zijn moet je ervoor zorgen dat je niet elk object tegen elk ander gaat collision-testen.) Daarnaast heb ik wat met splash-damage gespeeld om te zien hoe ik verschillende physics-constanten het beste instel.

Wat ik nu aan code heb staan is zuiver een prototype waarop ik kan testen of die collision detection werkt (en dat lijkt goed te gaan), en kan testen of je niet de kans loopt door kettingreacties de halve wereld te laten exploderen met splash-damage (nu mee bezig). Je hebt dus weinig aan die code zo lang als de physics van de engine (zeg maar de natuurkundige wetten) nog niet vast staan.

Over het protocol: het heeft nog geen zin een protocol vast te stellen als we het er nog niet over eens zijn wat het spel er precies moet beinhouden, de spelregels bepalen hoe ons protocol er gaat uitzien.

Tot slot wat ik nu plan als regels:

• Iedere speler heeft één tank tot zijn beschikking. Is die tank vernietigd, dan is het spel voor de betreffende speler afgelopen. De "last man standing" wint.
• Een tank produceert een vaste hoeveelheid energie per speelbeurt. Die energie vloeit automatisch naar een buffer waarin energie tot een bepaalde bovengrens opgespaard kan worden. De speler hevelt energie vanuit de buffer over naar de andere vier deelsystemen van de tank om hem zo te besturen. Raakt de buffer overvol dan explodeert de tank.
• Aandrijving: de speler geeft een richting en een hoeveelheid energie (tot een maximum) aan. Er is hoge frictie, de tank staat binnen een beurt stil als er een beurt geen energie naar de aandrijving gaat; en een tank kan bij elke snelheid een willekeurig scherpe bocht maken (zelfs 180 graden dus).
• Schild: de speler geeft een hoeveelheid energie (tot een maximum) aan. Het schild verliest iedere beurt een vaste hoeveelheid energie, en verliest bij schade een hoeveelheid energie ter grootte van de damage (dit wordt duidelijk bij het punt explosies); is de damage hoger dan de hoeveelheid energie in het schild dan explodeert de tank (dit kan dus ook veroorzaakt worden door die vaste energieafname per beurt).
• Wapen: de speler geeft een richting en twee hoeveelheden energie (tot een maximum) aan. Het wapen lanceert projectielen die een eigen schild en een eigen energiebuffer (maar geen energiebron) hebben. Het schild van een projectiel verliest (net als een tank) een vaste hoeveelheid energie per beurt; ontstaat er op die manier of door een directe botsing schade aan het projectiel, dan explodeert het. Projectielen kunnen alleen tanks direct raken; geen andere projectielen. (Je kunt dus de lengte van je schoten bepalen door de hoeveelheid energie in het schild, en de kracht bepalen door de energie in de buffer).
• Scanner: de speler geeft een hoeveelheid energie (alweer tot een maximum) aan. Bij de volgende speelbeurt krijgt de speler de positie van alle objecten die zich binnen een bepaalde staal van de tank bevinden, waarbij die straal afhankelijk is van de energie. (Geen scanlines dus, maar een complete "radarsweep"; met scanlines duurt het eeuwen voor je weet hoever een voorwerp van je af is.)
• Explosies: wanneer een tank of projectiel explodeert, wordt alle energie in de energiebuffer vrijgegeven als (splash)damage. De damage neemt kwadratisch af bij het toenemen van de afstand tot de explosie.
• Speelveld: het speelveld is vierkant en in zich gesloten (dwz. als je er boven uitrijdt kom je er onder weer in). De grootte van het vierkant staat nog niet vast, ik denk zelf aan iets als 500 maal het oppervlak van alle deelnemende tanks. Ik ben er ook nog niet uit of ik wel of geen hindernissen plaats; ik neig zelf naar geen hindernissen omdat dat een groot deel van het "artillerie-effect" (je hoeft niet precies te raken om schade te doen) van de projectielen ongedaan maakt. Ik denk dat die projectielen meer taktische wendingen bieden dan hindernissen.

[bigben04]

Nou, dit ziet er prima uit denk ik zo. Simpel genoeg om geen genie te hoeven zijn om een enigszins werkende tank te maken en toch ook wat mogelijkheden om 'advanced' AI te programmeren. Ik zou zeggen maak maar!
Ik denk inderdaad dat het handiger is om het zonder obstakels te doen, omdat het anders al weer lastiger wordt om een redelijke kans van het raken van een vijand te bereiken (voor de minder intelligente tanks, waar de mijne er ongetwijfeld 1 van gaat worden ).

[Gerco]

Dit klinkt inderdaad als een leuk spel om te spelen, nu nog hopen dat het ook echt van de grond gaat komen.

[MisterData]

Tankspel lijkt me een goed idee. Ik neem aan dat het ook turnbased is? Dan wordt het tijd dat er iemand een servertje gaat schrijven maw, wie heeft er tijd over atm? We moeten het ook nog over de datum ed hebben. Ik stel zelf voor om het GPC niet meer in December te houden, omdat er dan veel mensen weg zijn naar wintersport (en naar familie met kerst enzo ). Misschien begin Januari?

[Creepy]

wacco schreef op 26 November 2002 @ 19:41:
Zal ik dan maar ff een samenvatting maken? Post em in een minuutje of tien...
Verder denk ik dat mietje, tremor_b, JayTaph zich er wel in kunnen vinden...
...en qua inzendingen dat ook Creepy, MisterData, cobratbq, xychix en J~R~R ook wel mee gaan doen.
Not to mention El_Quedro voor graph-app, en wiseman voor server.
Mensjes wat zijn we enthousiast!

Hmm iets TE enthousiast volgens mij....

Als ik wat ga in leveren zijn het wat voorbeeld bots, geen "echte" competitie bots. Ik denk dat daar me de tijd voor gaat ontbreken. Dus misschien moet ik ff met mietje overleggen of ik nog een voorbeeld bot kan schrijven
Als ik op een bepaald moment online moet zijn om mee te kunnen doen dan doe ik zoiezo niet mee..dat gaat me dan echt teveel tijd kosten.

Ik zelf blijf erbij dat het voor een "echte" got competitie net iets te ver gaat (alhoewel het al wat is versimpelt) en dat er maar weinig mensen hier zijn die echt doorhebben hoeveel werk het is een fatsoenlijke server op te zetten (waarvan mietje er gelukkig 1 van is ).

[DaCoTa]

@mietje:
Iets wat mogelijk onbalans kan veroorzaken is dat - kan ook onduidelijkheid in het verhaal of het lezen daarvan zijn - bepaalde acties instantaan uitgevoerd kunnen worden. E.g. ik zie met een korte scan dat er een kogel aan komt, ik weet de impact en pomp per direct genoeg energie naar mijn schild. Aangezien de aanvaller en de verdediger dan minder energie hebben, kan er een soort 'remise' toestant onstaan van vurende en verdedigende tankjes.

Dit effect is denk ik het 'gevaarlijkst' bij de beweging van de tank en de besturing van het schild. Als deze principes zo worden afgesteld dat je effect over meerdere beurten hebt, dan zijn 'deadlock' situaties al veel minder vaak voorkomend denk ik.

En als ik het goed begrijp, kun je een tank niet stil laten staan en niks doen, omdat de energievoorraad dan overloopt. Dat is wel een erg interessant gegeven

Let wel, dit is nu misschien een brug te ver om over te discussieren, als de engine daadwerkelijk draait lijkt het me dat het finetunen qua implementatie niet echt moeilijk meer is.

[NaliXL]

Mensen, dit ziet er allemaal leuk uit. Ik denk dat ik ook wel wil meedoen. Verder denk ik dat obstakels in het veld het eigenlijk wel leuk maken, zodat tanks e.d. daar achter kunnen schuilen. Heb inmiddels al wat ervaring opgedaan met RoboCode, en het gaat me nu redelijk goed af.

Overigens vind ik het grootste nadeel van Robocode dat je de coördinaten van vijanden doorkrijgt in graden t.o.v. jezelf. Ik hoop echt dat je die in jouw versie doorgeeft in vaste coördinaten, dat maakt het een stuk makkelijker werken imho.

Mietje, zit er ook een grafische weergave in van het hele gebeuren, zodat we later ook een DivX-je terug kunnen kijken van wat er gebeurd is? (of beter nog : we kunnen allemaal live meekijken op een soort terminals)?

[Orphix]

Ziet er goed uit mietje Count me in als het zover is.

Nog twee vraagjes:
1) Wat gebeurt er bij tanks die op elkaar knallen?
2) Zijn 'spectators' mogelijk? (oftewel hoe wil je de eventuele gui handlen?)

[NaliXL]

Owja : ik krijg net een ingeving wat misschien leuk is : Het kan zijn dat er tanks geschreven worden die blindelings rijden en schieten. Om die reden lijkt het me een goed idee om mijnen te implementeren. Iedere meedoende tank krijgt een aantal mijnen aan het begin van het spel, die op willekeurige plaatsen neergelegd worden... Natuurlijk moeten mijnen ook zichtbaar zijn op radarsweeps, zodat je niet door domme pech kunt verliezen wat dat betreft.

[Orphix]

NaliXL schreef op 27 november 2002 @ 11:56:
Het kan zijn dat er tanks geschreven worden die blindelings rijden en schieten.

En wat maakt dat uit? Een beetje tactische tank zou daar van moeten kunnen winnen. Houdt het ook spannend een beetje random movement.

offtopic:
ik wil niet direct m'n tankje bij voorbaat al uitsluiten

[NaliXL]

Orphix schreef op 27 November 2002 @ 11:59:
[...]

En wat maakt dat uit? Een beetje tactische tank zou daar van moeten kunnen winnen. Houdt het ook spannend een beetje random movement.

offtopic:
ik wil niet direct m'n tankje bij voorbaat al uitsluiten

Da's dus niet/nauwelijks AI te noemen. Een beetje zigzaggen en schieten kan iedereen wel....

[Verwijderd]

DaCoTa schreef op 27 november 2002 @ 10:53:
@mietje:
Iets wat mogelijk onbalans kan veroorzaken is dat - kan ook onduidelijkheid in het verhaal of het lezen daarvan zijn - bepaalde acties instantaan uitgevoerd kunnen worden. E.g. ik zie met een korte scan dat er een kogel aan komt, ik weet de impact en pomp per direct genoeg energie naar mijn schild. Aangezien de aanvaller en de verdediger dan minder energie hebben, kan er een soort 'remise' toestant onstaan van vurende en verdedigende tankjes.

Geen enkele actie gebeurt instantaan. Elke speler geeft bij zijn beurt de gewenste commando's; en pas nadat de laatste speler in een beurt zijn commando's heeft gegeven worden ze uitgevoerd, als het ware dus simultaan voor alle spelers.

En als ik het goed begrijp, kun je een tank niet stil laten staan en niks doen, omdat de energievoorraad dan overloopt. Dat is wel een erg interessant gegeven

Je kunt zo lang stilstaan als je wilt, als je er maar voor zorgt dat je de overtollige energie op eoa. manier kwijtraakt. Dat kan door je schild helemaal vol te pompen, "long range" scans te maken of zware projectielen te schieten. (Het lijkt me overigens sowieso geen goed idee om lang stil te staan, je bent dan een sitting duck.)

NaliXL schreef op 27 november 2002 @ 11:34:
Overigens vind ik het grootste nadeel van Robocode dat je de coördinaten van vijanden doorkrijgt in graden t.o.v. jezelf. Ik hoop echt dat je die in jouw versie doorgeeft in vaste coördinaten, dat maakt het een stuk makkelijker werken imho.

Hierover heb ik ook zitten nadenken. Ik denk dat het toch het gemakkelijkste is om relatieve posities door te geven omdat het speelveld in zich gesloten is. Als ik absolute posities doorgeef moeten de clients er rekening mee houden dat het speelveld "wrapped". (Als het speelveld 500x500 groot is staan tankjes op coordinaten (0, 0) en (490, 490) dus dicht bij elkaar...)

Orphix schreef op 27 November 2002 @ 11:41:
Ziet er goed uit mietje Count me in als het zover is.

Nog twee vraagjes:
1) Wat gebeurt er bij tanks die op elkaar knallen?

Het zelfde als dat een projectiel op een tank knalt: de energie in de schilden word van elkaar afgetrokken, en de tank waarbij die energiewaarde onder 0 komt explodeert. (Het is dus geen goed idee tegenstanders te rammen, ook al weet je zeker dat je meer schild hebt: je schildenergie gaat dramatisch omlaag, waarna de tegenstander explodeert...)

2) Zijn 'spectators' mogelijk? (oftewel hoe wil je de eventuele gui handlen?)

Dit is zondermeer mogelijk, ik kan zonder veel problemen een spectator mode implementeren. Als mensen zin hebben om (OpenGl) observer-clients te schrijven, implementeer ik die spectator mode.

[El_Quedro]

waarom doen we het niet qua Worms stijl? Zwaartekracht en wind spelen ook een grote rol..
maar met een AI is dat zo bekeken natuurlijk maar het is wel net dat beetje moeilijk heid erbij.. waardoor zelfs misschien een AI robot zou kunnen missen....

[NDF82]

Hoeveel commando's mag je dan per beurt uitvoeren?1, 2, 3, of net zoveel totdat je energie op is?

[Verwijderd]

NDF82 schreef op 27 november 2002 @ 12:56:
Hoeveel commando's mag je dan per beurt uitvoeren?1, 2, 3, of net zoveel totdat je energie op is?

1 aandrijvingscommando,
1 schildcommando,
1 wapencommando, en
1 scancommando

[NDF82]

Ah, ok, en hoe wordt de winnaar van zo'n GPC bepaalt? Want ik kan wel twee clients maken (1 als spectator en 1 als deelnemer) en deze onderling laten communiceren. Of wordt de code ook beoordeelt (en zo ja, door wie )?

[wacco]

Als de energie op is van een projectiel, lijkt me dat ie explodeert. Maar hoe hard? Z'n energie is toch nul? En hoe zit het qua snelheid? Is dat vast bij projectielen of kan dat met een derde parameter worden afgesteld (een soort van afschotenergie)?

Verder klinkt het leuk, maar ik ben vóór obstakels, die je dan bijvoorbeeld met scansweep ziet. Dit vraagt ook om een soort van bevestiging elke keer van je locatie, als je bijvoorbeeld tegen een muur aan knalt zonder dat je het door hebt. En verschillende ondergronden (die je ook weer ziet in sweeps) is ook erg leuk, dan kan je bijvoorbeeld voor een langere, maar snellere route kiezen als je dat wilt. Maar dat kan dan ook weer consequenties hebben, bijvoorbeeld dichtbij een andere tank, etc etc

[NaliXL]

wacco schreef op 27 November 2002 @ 13:23:
Als de energie op is van een projectiel, lijkt me dat ie explodeert. Maar hoe hard? Z'n energie is toch nul? En hoe zit het qua snelheid? Is dat vast bij projectielen of kan dat met een derde parameter worden afgesteld (een soort van afschotenergie)?

Het lijkt mij logisch dat een projectiel de energie houdt die erin gestopt word behoudt tot het einde. Dat einde lijkt mij dan een van de zijkanten van het veld of een tegenstander.

Verder klinkt het leuk, maar ik ben vóór obstakels, die je dan bijvoorbeeld met scansweep ziet. Dit vraagt ook om een soort van bevestiging elke keer van je locatie, als je bijvoorbeeld tegen een muur aan knalt zonder dat je het door hebt. En verschillende ondergronden (die je ook weer ziet in sweeps) is ook erg leuk, dan kan je bijvoorbeeld voor een langere, maar snellere route kiezen als je dat wilt. Maar dat kan dan ook weer consequenties hebben, bijvoorbeeld dichtbij een andere tank, etc etc

Zeker, dit zou het idd. een stuk leuker maken. Ook meer een uitdaging. Je zou dan bijvoorbeeld niet altijd een robot hoeven te schrijven die goed is in ontwijken, maar je zou er ook een kunnen schrijven die goed is in verstoppen en snipen...

[Orphix]

wacco schreef op 27 November 2002 @ 13:23:
Als de energie op is van een projectiel, lijkt me dat ie explodeert. Maar hoe hard? Z'n energie is toch nul? En hoe zit het qua snelheid? Is dat vast bij projectielen of kan dat met een derde parameter worden afgesteld (een soort van afschotenergie)?

Als je schiet geef je 2 energie waardes mee. Een daarvan is de afstand die het maximaal kan overbruggen en een is de energie die het heeft bij impact.
Je kan het zien als artillerie: Je bepaalt de hoogte (range) en het gewicht van de kogel (impact). Verschil is wel dat het hier 2d is en een tank die onderweg wordt geraakt dus wel de l*l is.

[Verwijderd]

NaliXL schreef op 27 November 2002 @ 13:50:
Het lijkt mij logisch dat een projectiel de energie houdt die erin gestopt word behoudt tot het einde. Dat einde lijkt mij dan een van de zijkanten van het veld of een tegenstander.

Een projectiel vliegt altijd met de zelfde snelheid (nu 100 m/s + de initieele snelheid van de tank). Een projectiel heeft 2 vormen van energie aan boord: schildenergie en explosie-energie. Omdat de schildenergie elke speelbeurt afneemt, kun je daarmee bepalen hoe ver een projectiel vliegt voordat het explodeert. Verder zijn er geen zijkanten aan het speelveld, zie het alsof het speelveld het oppervlak van een bol is.

Zeker, dit zou het idd. een stuk leuker maken. Ook meer een uitdaging. Je zou dan bijvoorbeeld niet altijd een robot hoeven te schrijven die goed is in ontwijken, maar je zou er ook een kunnen schrijven die goed is in verstoppen en snipen...

Verstoppen is easy, goed schieten en ontwijken is moeilijk. Ik kan situaties verzinnen waarbij de twee laatste tanks in het spel eindeloos om een obstaken blijven draaien zonder ooit de kans te krijgen op elkaar te schieten. Daarnaast maken obstakels de projectielen ineffectief, er is in een 2D spel geen mogelijkheid om over een obstakel heen te schieten. Maw. obstakels beperken het aantal taktische wendingen en maken het schrijven van een bot (te) gemakkelijk (mn. houdt een obstakel tussen jezelf en de meerderheid van de andere tanks).

[MisterData]

NDF82 schreef op 27 November 2002 @ 13:21:
Ah, ok, en hoe wordt de winnaar van zo'n GPC bepaalt? Want ik kan wel twee clients maken (1 als spectator en 1 als deelnemer) en deze onderling laten communiceren. Of wordt de code ook beoordeelt (en zo ja, door wie )?

Daar zat ik ook al aan te denken. Het leukste is volgens mij als iedereen wanneer hij dat wil z'n botje kan uitproberen op de server (of op afgesproken tijden). Je kan voorkomen dat er een spectator en een bot tegelijk zijn ingelogd vanaf 1 plek door ofwel een wachtwoord te vereisen of door op IP te controleren (helaas werkt dat niet met proxyservers) En er moet ook een tijdlimiet op het uitvoeren van de commando's, anders kan ik net zogoed een GUI maken en zelf voor AI spelen

[MisterData]

Owjah, nog een paar dingen:
- Ik wil wel even kijken of er een mooie JavaScript-implementatie in C++ is, dan maak ik daar wel een wrapper omheen zodat iedereen die geen echte progfreak is (of de mensen die nog nooit met sockets hebben gewerkt, als die bestaan) toch mee kan doen.

- Mensen die nog nooit een AI hebben gemaakt kunnen eens kijken op www.gamedev.net. Ik meen dat daar een aantal artikelen te vinden zijn over het schrijven van een AI.

[Verwijderd]

Je kunt spectator clients alleen gebruiken om te "spieken" indien je de absolute posities van de objecten in het speelveld weet. Als zowel de spectators als de spelende clients relatieve posities van de server krijgen wordt het erg lasig om te spieken: je moet dan zeer complexe pattern-matching algoritmes gaan bedenken.

[.oisyn]

Verwijderd schreef op 27 november 2002 @ 03:12:
Ok, even wat uitleg (moest vanavond weg).
Als je een game-engine schrijft waarbij potentieel zeer veel bewegende objecten zijn is het zaak eerst een efficiente collision detection te schrijven, daar staat of valt die engine mee. (Collision detection is niet zo makkelijk als het lijkt als je objecten hebt die snel bewegen, en als er veel objecten zijn moet je ervoor zorgen dat je niet elk object tegen elk ander gaat collision-testen.) Daarnaast heb ik wat met splash-damage gespeeld om te zien hoe ik verschillende physics-constanten het beste instel.

hier wil ik even mijn mening over spuien
Je overschat het echt zwaar. Er zijn niet eens zoveel bewegende elementen. Je hebt de tanks, waarvan er imho hooguit 16 in de arena zijn (meestal veel minder), en natuurlijk de missiles, die bovendien alleen de tanks kunnen raken en niet elkaar. Niet dat het geen goede zaak is om sowieso optimalisaties in te voeren, maar in principe is dit heel goed te brute forcen (dus elk object testen met elk ander object, behalve missile <-> missile dus). De snelheid waarmee objecten bewegen maakt bovendien helemaal niets uit, behalve dat er potentieel meer colliders zouden kunnen zijn

[MisterData]

Ik heb al een scripting-engine gevonden, is er iemand die even een protocol inelkaar wil zetten? Ik zat zelf te denken aan een MSN-like protocol, dus zoiets:

code:

c> USR MisterData
s> USR OK
c> BOT FirstBot
s> BOT OK [eventueel hier nog een x- en y-coordinaat meegeven, of andere zaken zoals begin energie]

// als de bot aan de beurts is
s> YOURTURN
c> YOURTURN OK // even iets terugsturen om te bevestigen dat de bot nog aan de lijn is
c> MOVEWEAPON 1
c> SHOOT 90
c> ENERGYLEFT
s> 100
c> ENDTURN

Iets dergelijks dus

[ Voor 14% gewijzigd door MisterData op 27-11-2002 15:04 ]

[.oisyn]

MisterData schreef op 27 november 2002 @ 15:03:
Ik heb al een scripting-engine gevonden, is er iemand die even een protocol inelkaar wil zetten? Ik zat zelf te denken aan een MSN-like protocol, dus zoiets:
[code]
c> YOURTURN OK // even iets terugsturen om te bevestigen dat de bot nog aan de lijn is

dat is iets wat door het TCP protocol afgehandeld wordt, en is derhalve dus vrijwel overbodig

[Verwijderd]

.oisyn schreef op 27 november 2002 @ 15:02:
hier wil ik even mijn mening over spuien
Je overschat het echt zwaar. Er zijn niet eens zoveel bewegende elementen. Je hebt de tanks, waarvan er imho hooguit 16 in de arena zijn (meestal veel minder), en natuurlijk de missiles, die bovendien alleen de tanks kunnen raken en niet elkaar.

Ik houd rekening met tot 64 clients. Elke client kan projectielen afschieten die max ongeveer 10 speelbeurten "in de lucht" blijven. Dat maakt dus al max. 640 objecten, zonder evt. obstakels.

De snelheid waarmee objecten bewegen maakt bovendien helemaal niets uit, behalve dat er potentieel meer colliders zouden kunnen zijn

De snelheid doet er natuurlijk wel toe als die snelheid zo hoog is dat objecten binnen 1 frame geheel "door" een ander object heen kunnen vliegen. (En dat kan omdat projectielen snel en klein zijn.) Ik gebruik nu een collision detection die gebaseerd is op dit algoritme (maar dan 2D).

[NaliXL]

Verwijderd schreef op 27 November 2002 @ 15:19:
De snelheid doet er natuurlijk wel toe als die snelheid zo hoog is dat objecten binnen 1 frame geheel "door" een ander object heen kunnen vliegen. (En dat kan omdat projectielen snel en klein zijn.) Ik gebruik nu een collision detection die gebaseerd is op dit algoritme (maar dan 2D).

Hmm, misschien is het gemakkelijker voor jezelf en voor ons om een soort laserkanon ervan te maken, dus geen bewegende projectielen. Tanks zelf gaan zo hard niet denk ik...

[Verwijderd]

Het is niet gemakkelijker voor mij om een werkende collision detection te dissen en een nieuw algoritme te verzinnen

[.oisyn]

Verwijderd schreef op 27 November 2002 @ 15:19:
[...]

Ik houd rekening met tot 64 clients. Elke client kan projectielen afschieten die max ongeveer 10 speelbeurten "in de lucht" blijven. Dat maakt dus al max. 640 objecten, zonder evt. obstakels.

Dan nog kun je voldoen zonder een spatial partitioning systeem... testen of 2 objecten mogelijk kunnen botsen gaat ook vrij snel. Als ze van elkaar af bewegen kun je ze gelijk negeren, dat elimineert al 50% van de gevallen. Dan kun je ook nog testen of hun boundingspheres (met beweging erbij) elkaar overlappen, wat ook zo gedaan is

De snelheid doet er natuurlijk wel toe als die snelheid zo hoog is dat objecten binnen 1 frame geheel "door" een ander object heen kunnen vliegen. (En dat kan omdat projectielen snel en klein zijn.) Ik gebruik nu een collision detection die gebaseerd is op dit algoritme (maar dan 2D).

hmm, zo te horen deterministic collision detection, niet echt een lekker systeem. Bij continuous collision detection test je niet op een bepaald punt, maar een beweging die een object per frame aflegt. Dan kun je precies zien tot hoever een object kan bewegen zonder te botsen, en dan eindigt het ook precies op een raakpunt, en niet dat er dan nog ruimte tussen objecten in zit. Dit is ook de manier wat algemeen wordt gebruikt in games.

Wat bounding spheres betreft, de tanks zijn natuurlijk niet echt rond... maar dat maakt natuurlijk niet zo heel veel uit. Heeft ook wel weer z'n voordelen omdat je niet rekening hoeft te houden met de orientatie van tanks, en het is relatief snel

[Verwijderd]

.oisyn schreef op 27 November 2002 @ 16:01:
Dan nog kun je voldoen zonder een spatial partitioning systeem... testen of 2 objecten mogelijk kunnen botsen gaat ook vrij snel. Als ze van elkaar af bewegen kun je ze gelijk negeren, dat elimineert al 50% van de gevallen. Dan kun je ook nog testen of hun boundingspheres (met beweging erbij) elkaar overlappen, wat ook zo gedaan is

Ik werk niet met spatial partitioning maar met coordinate sorting. Voor de rest doe ik exact wat je voorstelt: ik werk met moving bounding spheres.

hmm, zo te horen deterministic collision detection, niet echt een lekker systeem. Bij continuous collision detection test je niet op een bepaald punt, maar een beweging die een object per frame aflegt. Dan kun je precies zien tot hoever een object kan bewegen zonder te botsen, en dan eindigt het ook precies op een raakpunt, en niet dat er dan nog ruimte tussen objecten in zit. Dit is ook de manier wat algemeen wordt gebruikt in games.

Dit is toch exact wat ik doe, of begrijp ik je verkeerd? Het enige verschil is dat ik niet verder reken naar de exacte plek waar de collision plaatsvindt, maar volsta met het gegeven dat er een collision plaatsvindt of niet. Zoals de pysics nu staan kunnen 2 tanks elkaar niet veel overshooten (en eentje zal exploderen), en bij een projectiel/tank collision neem ik gewoon het centrum van de tank als plaats van de explosie (een tank heeft een radius van 3m, een projectiel een radius van 0.1m).

[.oisyn]

Verwijderd schreef op 27 november 2002 @ 16:22:
Dit is toch exact wat ik doe, of begrijp ik je verkeerd? Het enige verschil is dat ik niet verder reken naar de exacte plek waar de collision plaatsvindt, maar volsta met het gegeven dat er een collision plaatsvindt of niet. Zoals de pysics nu staan kunnen 2 tanks elkaar niet veel overshooten (en eentje zal exploderen), en bij een projectiel/tank collision neem ik gewoon het centrum van de tank als plaats van de explosie (een tank heeft een radius van 3m, een projectiel een radius van 0.1m).

nou begrijp ik niet helemaal wat je bedoelt. Kijk je gewoon op welke nieuwe plek de tank zou komen te staan, en of dat kan? En als het niet kan dan blijft ie gewoon op dezelfde plek? (Deterministic)

Of traceer je echt de sphere van z'n huidige positie naar z'n volgende, en kijk je hoever dat kan, en vervolgens beweeg je de tank zover, zodat 2 tanks die met elkaar botsen ook daadwerkelijk tegen elkaar komen te staan? (Continuous)

In het eerste geval heb je idd dat je zei dat het kan dat een object 'door' een ander object heengaat als ie te snel beweegt, in het tweede geval kan dit niet, en zal het aantal berekeningen ook niet afhangen van de snelheid van een object

.edit: ik heb net dat artikel van gamedev doorgelezen, en da's idd continuous. Dan snap ik niet dat je kunt zeggen hoe het mogelijk kan zijn dat er bij hoge snelheden objecten door elkaar heen kunnen gaan

[ Voor 10% gewijzigd door .oisyn op 27-11-2002 17:18 ]

[Verwijderd]

Er begint wat vaart in te komen zie ik!

Maar de projectielen begrijp ik niet helemaal... Je schiet een projectiel en geeft die de kracht v/d explosie en de maximale uithoudingstijd mee. Dat betekent dus dat het een aantal beurten duurt voordat de projectiel bij de tank is. Inmiddels heeft de tank het projectiel allang opgemerkt en gaat gewoon opzij. Of snap ik het nu verkeerd?

[Verwijderd]

.oisyn schreef op 27 November 2002 @ 16:32:
.edit: ik heb net dat artikel van gamedev doorgelezen, en da's idd continuous. Dan snap ik niet dat je kunt zeggen hoe het mogelijk kan zijn dat er bij hoge snelheden objecten door elkaar heen kunnen gaan

Mja, we lullen langs elkaar heen Wat ik in het begin schrijf is exact wat jij zegt: met deterministic collision detection heb je kans dat snelle objecten door elkaar heen vliegen. Daarom zeg ik dus dat het niet zo eenvoudig is als het lijkt; je moet op eoa. manier continuous checken. Ik zit niet zo in de gamedev-hoek, dus ben ik niet zo op de hoogte van terminologie als continuous vs. deterministic. Vandaar dat ik me een beetje ongelukkig uitdruk soms

Verwijderd schreef op 27 November 2002 @ 17:17:
Maar de projectielen begrijp ik niet helemaal... Je schiet een projectiel en geeft die de kracht v/d explosie en de maximale uithoudingstijd mee. Dat betekent dus dat het een aantal beurten duurt voordat de projectiel bij de tank is. Inmiddels heeft de tank het projectiel allang opgemerkt en gaat gewoon opzij. Of snap ik het nu verkeerd?

De projectielen veroorzaken splash-damage, dus je krijgt ook schade als een projectiel je niet precies raakt maar in je buurt explodeert.

[ Voor 28% gewijzigd door Verwijderd op 27-11-2002 17:33 ]

[.oisyn]

ah ok, dan snappen we elkaar nu

[ Voor 3% gewijzigd door .oisyn op 27-11-2002 17:32 ]

[wacco]

Ik gaat nog ff doorzeuren over die projectielen... als een projectiel op je af komt kan je best ver genoeg opzij gaan. Je scant ver, ziet dat ding aankomen, en gaat vol gas ervandoor. Big chance dat je op tijd weg bent.
Wordt een stuk lastiger als een paar vars onduidelijk zijn:
- hoe snel gaat het projectiel?
- hoe krachtig is het projectiel?

De eerste kan je volgens mij, voor zover ik begreep, niet echt instellen (of is de maximale af te leggen afstand in een vast tijdsbestek erdoorheen gedraaid?) en de tweede var weet ik niet precies of je die via je scan meekrijgt. Ook als je een tank op je scan ziet, zie je dan hoeveel energie in z'n schild zit en hoeveel energie z'n buffer bevat?

Dan nog een laatste puntje: objecten niet, okee, maar verschillende ondergronden ja! En tot slot: twee bots die oneindig rondjes blijven crossen doen iets niet goed, want wat als er nog een derde bot is? (die is er wel niet, maar hoe kunnen ze dat weten? daar horen ze rekening mee te houden) En bedenk ook, de meest simpele AI zal waarschijnlijk zoiets zijn:
enemy! energie? laag. wegwezen! -twee rondjes later- enemy! energie? vol (duh... twee rondjes gecrost) mooi. knallen met die hap.
Dan zijn er natuurlijk een paar triggerwaarden (hoogstwaarschijnlijk) en de kans dat die bij twee bots hetzelfde zijn is _klein_.
Maar goed, dan geen obstakels. Maar wel verschillende ondergronden pleeaaaze.

[Verwijderd]

wacco schreef op 27 november 2002 @ 17:40:
Ik gaat nog ff doorzeuren over die projectielen... als een projectiel op je af komt kan je best ver genoeg opzij gaan. Je scant ver, ziet dat ding aankomen, en gaat vol gas ervandoor. Big chance dat je op tijd weg bent.
Wordt een stuk lastiger als een paar vars onduidelijk zijn:
- hoe snel gaat het projectiel?
- hoe krachtig is het projectiel?

De snelheid van het projectiel is vast (100 m/s + de snelheid van de tank). De kracht van het projectiel kun je niet zien in een scan, en de schildwaarde ook niet (maar dit is een protocol-kwestie, kan zo veranderd worden). Of je in staat bent een volledig geladen projectiel zo te ontwijken dat je 0 damage krijgt is daarmee compleet afhankelijk van de maximum snelheid van de tank (en die ligt nog niet vast).

Maar goed, dan geen obstakels. Maar wel verschillende ondergronden pleeaaaze.

Realiseer je wel dat het spel hierdoor een orde van grootte complexer wordt. Het wordt taktisch een slechte keuze om langzaam terrein te kiezen omdat je daar moeilijker projectielen ontwijken kunt. Voor de server maakt het niet veel verschil, ik tile gewoon het speelveld en geef elke tile een bepaalde (random) frictie. Voor de clients wordt het echter een heel stuk moeilijker; ook bv. het berekenen of je een bepaalde plek binnen een bepaald aantal beurten bereiken kunt wordt lastig.

[MisterData]

.oisyn schreef op 27 November 2002 @ 15:05:

[...]


dat is iets wat door het TCP protocol afgehandeld wordt, en is derhalve dus vrijwel overbodig

Niet als je tussendoor de netwerkkabel eruittrekt (of als [strike]@home[/strike] je provider weer aan het nukken is) Maar het is inderdaad vrij overbodig. Met YOURTURN OK kun je natuurlijk nog wat andere parameters meegeven. Verder ben ik aan het worstelen met SpiderMonkey , want ik ben iets aan het maken waarmee je in JavaScript je bot kan schrijven. Zodra ik de protocolspecs heb kan ik dit dus afmaken

[Verwijderd]

zou het misshien ook niet mogelijk/leuk zijn als elke speler bij het begin van het spel bijvoorbeeld 1000 punten krijgt, deze mag de computer dan vrij verdelen over ernergie/schild/wapens/snelheid/...

[Soultaker]

MisterData schreef op 27 November 2002 @ 18:00:
Niet als je tussendoor de netwerkkabel eruittrekt (of als [strike]@home[/strike] je provider weer aan het nukken is)

Dan trek ik de stekker eruit NADAT je "YOURTURN OK" verstuurd hebt (en de bevestiging ontvangen), ok?

[.oisyn]

[nohtml]

MisterData schreef op 27 november 2002 @ 18:00:

Niet als je tussendoor de netwerkkabel eruittrekt (of als [strike]@home[/strike] je provider weer aan het nukken is)

juist wel, wat voor extra nut heeft zo'n commando volgens jou? Zie bijvoorbeeld het voorbeeld van Soultaker. Als je de netwerkkabel eruit trekt treedt er een timeout op, zelfs zonder dat je data probeert te versturen of ontvangen, zo zit het TCP protocol nou eenmaal in elkaar. En dat kun je dus detecteren

[DaCoTa]

Ik denk dat het handig is als mietje zover is, een protocol spec publiceerd. Dat zal vast en zeker een boel vragen beantwoorden en nieuwe vragen opwerpen. Ben iig erg benieuwd hoe het gaat worden! Ik denk dat, als er een gladiator style combat gespeeld wordt, de omgeving in eerste instantie zo simpel mogelijk gehouden moet worden. Het is denk ik al een hele opgave om een goede tank te ontwikkelen, zonder rekening te houden met ondergrond, wind, etc.

Oh ja, een item uit robosoccer: als een meting van een grotere afstand gebeurd, dan zit daar een bepaalde ruis op de gegevens. Dus als een tank voor je neus staat, krijg je goede gegevens. Als de tank 100 meter verderop staat, kan de meting er zo 10 meter naast zitten.

Ik weet dat dit laatste ook al weer een complicerende factor is, maargoed, het schoot me even te binnen.

[Verwijderd]

dat is in feite zeer simpel te maken,

als de afstand 100m is: getal = echte waarde + random_getal
en het random_getal is dus bevoorbeeld minimum 0 en maximum 5, dus maximum 1/20 afwijking ofzo

[bigben04]

Verwijderd schreef op 27 November 2002 @ 18:39:
dat is in feite zeer simpel te maken,

Dat is wel zo, maar om er in de client rekening mee te houden levert wel meer moeilijkheden op.

[xychix]

Mietje... don't go to high ! please.. ik zal er alles en alles aan doen om zeker mee te doen door een goede BOT in te zetten maar het lijkt alleen maar ingewikkelder en ingewikkelder te worden...., het is wel cool als er een makkelijke commandbased interface komt (kun je ook stiekem met telnet meespelen)
maar ik word een beeeetje bang voor het benodigde niveau... en tijd...

[MisterData]

Soultaker schreef op 27 November 2002 @ 18:02:
[...]

Dan trek ik de stekker eruit NADAT je "YOURTURN OK" verstuurd hebt (en de bevestiging ontvangen), ok?

Het was maar een ideetje van me hoor Dan haal je dat in de uiteindelijke specificatie eruit.

[Verwijderd]

Ow, nog een ding Iedereen is hier al wanhopig projectielen aan het ontwijken, terwijl je ook nog een andere optie hebt als je beschoten wordt: plaats een eigen projectiel ergens in de buurt van het projectiel van de tegenstander. Projectielen kunnen elkaar weliswaar niet direct raken, maar als jouw projectiel explodeert veroorzaakt het splash damage die de schildwaarde van het vijandige projectiel reduceert. Daardoor wordt de afstand die het vijandige projectiel kan afleggen kleiner...

[wacco]

Eej mietje, das niet eerlijk! Dat valt onder tactics!

Verder:

Verwijderd schreef op 27 november 2002 @ 17:55:
[...]

Realiseer je wel dat het spel hierdoor een orde van grootte complexer wordt. Het wordt taktisch een slechte keuze om langzaam terrein te kiezen omdat je daar moeilijker projectielen ontwijken kunt. Voor de server maakt het niet veel verschil, ik tile gewoon het speelveld en geef elke tile een bepaalde (random) frictie. Voor de clients wordt het echter een heel stuk moeilijker; ook bv. het berekenen of je een bepaalde plek binnen een bepaald aantal beurten bereiken kunt wordt lastig.

Voor de mensen die er nog niet zo handig in zjin: die kunnen het gewoon negeren, en bij de return simpelweg de waarde van de positie van hun tank oven nemen.
Voor mensen zoals ik (die er wat moois van proberen te maken) kunnen proberen er voordeel uit te halen, zoals eromheen rijden, mijnen leggen op de snelle tussenstukken, etc. Dat maakt het alleen maar leuker, ook voor degene die een rij-en-nuke-AI te simpel vinden

[MisterData]

Mietje, kun je misschien even een lijstje geven met wat een bot allemaal kan? Dus dan bedoel ik zaken als schieten, rijden, suicide enzo. Dan kan ik die alvast in m'n JavaScript-wrapper inbouwen. De protocol-implementatie komt dan later wel

[wacco]

Ehm... ik begrijp dat MisterData heel erg fanatiek aan het coden is, maar is dat ook al de bedoeling? Of ben je gewoon een proggie aan het schrijven -waarmee- je een AI kan schrijven?

Of loop ik zwaar achter?

[.oisyn]

wacco: je loopt niet achter, mensen moeten gewoon even geduld hebben

[wacco]

oef... geduld argh, daar ben ik veel te enthousiast voor
Ik zit lekker sockets in c uit te pluizen, dat progt toch lekkerder dan vb. En ik ben een beetje code aan het bestuderen dat 'schijnt' te werken onder linux... dus misschien dat het ook nog echt wat wordt.

Want hoe willen we het nou gaan organiseren? Iedereen tegelijk online of alles op één systeem? I hope the last one, want iedereen tegelijk online is natuurlijk gedoemd te mislukken...

[MisterData]

wacco schreef op 27 november 2002 @ 21:06:
Ehm... ik begrijp dat MisterData heel erg fanatiek aan het coden is, maar is dat ook al de bedoeling? Of ben je gewoon een proggie aan het schrijven -waarmee- je een AI kan schrijven?

Of loop ik zwaar achter?

Nee. Als je had gelezen wat ik hierboven heb gezegd, ben ik bezig met een soort programma waarmee je JavaScript code kan gebruiken om de logica van je bot in te programmeren. Dan hoef je niet meer allerlei socket-troep te schrijven. En het geeft de mensen die niet zo goed kunnen proggen toch een kans, omdat JavaScript nogal simpel is (tenminste op de manier waarop ik het wil doen, en dat is gewoon door met wat functieaanroepen de bot besturen). Daarom wil ik alvast weten hoe het technisch in elkaar gaat zitten. Het schrijven van zo'n wrapper is niet zo moeilijk, het bestaat gewoon uit een Js-Parser die je gewoon kunt aanroepen. Dan moet je nog wat JS-functies mappen naar gewone functies en dan ben je klaar. Verder kan ik straks dus de protocol-implementatie erin bouwen.

Dit zal dus straks ook voor de rest beschikbaar komen En ja, ik heb tijd over

[ Voor 1% gewijzigd door MisterData op 27-11-2002 22:16 . Reden: link was fout ]

[MisterData]

wacco schreef op 27 November 2002 @ 21:17:
oef... geduld argh, daar ben ik veel te enthousiast voor
Ik zit lekker sockets in c uit te pluizen, dat progt toch lekkerder dan vb. En ik ben een beetje code aan het bestuderen dat 'schijnt' te werken onder linux... dus misschien dat het ook nog echt wat wordt.

Want hoe willen we het nou gaan organiseren? Iedereen tegelijk online of alles op één systeem? I hope the last one, want iedereen tegelijk online is natuurlijk gedoemd te mislukken...

Wat dacht je van iedereen tegelijk online op 1 (afgesproken) tijdstip? En als iemand dan niet kan, dan gaat de Jury het progsel draaien.

[MisterData]

.oisyn schreef op 27 november 2002 @ 21:09:
wacco: je loopt niet achter, mensen moeten gewoon even geduld hebben

Ach, ik had niks te doen en heb proefwerkweek, dus.....

[wacco]

wauw, d'r bestaat ook een edit knop weetje
maar dat klinkt als een goed initiatief! Hoop dat het ook gaat werken

En dan wil ik graag ff verder details weten over het protocol (heb geen zin om te wachten op een beta, en dan realiseren dat het _absoluut_ niet is wat we in gedachten hadden)

Verwijderd schreef op 27 November 2002 @ 13:02:
[...]

1 aandrijvingscommando,
1 schildcommando,
1 wapencommando, en
1 scancommando

Moeten ze allemaal doorgegeven worden, en krijg je dan pas het resultaat, of mag je eerst ff scannen, en dan iets zien om er vervolgens op te gaan knallen? See my point?

Dan zit ik nog een beetje met het draadje dat geopent moet gaan worden als de contest van start gaat. Wat gaan we daar in posten?
Tactisc? Beetje stom, die hou je namelijk lekker voor jezelf als je wilt winnen.
Code? Beetje onhandig, niemand snapt er toch wat van, want niemand weet hoe je het geïmplenteerd hebt in je AI.
Wipjes? Ja kom op nou zeg, het is geen 3d contest van w&g
Of alleen maar resultaten van pre-fights van bots? En leuke reports van de bugs die uit die battles kwamen rollen en waar dus nog getweakt moet worden aan de bots?

Then again, die laatste kan natuurlijk wel de nodige discussiestof opleveren

[ Voor 1% gewijzigd door wacco op 27-11-2002 22:10 . Reden: typo ]

[wacco]

btw: het is http://www.mozilla.org/js/spidermonkey/
en ik moet afleren zoveel smilies te gebruiken

[MisterData]

wacco schreef op 27 november 2002 @ 22:09:
wauw, d'r bestaat ook een edit knop weetje

Het is gewoon fantastisch Jim

maar dat klinkt als een goed initiatief! Hoop dat het ook gaat werken

Werken gaat het zeker, alleen wanneer is nu de vraag....

En dan wil ik graag ff verder details weten over het protocol (heb geen zin om te wachten op een beta, en dan realiseren dat het _absoluut_ niet is wat we in gedachten hadden)

Die komen er pas wanneer iemand de specs voor het protocol gaat verzinnen. Mietje lijkt me daarvoor de beste persoon.

[...]


Moeten ze allemaal doorgegeven worden, en krijg je dan pas het resultaat, of mag je eerst ff scannen, en dan iets zien om er vervolgens op te gaan knallen? See my point?

Ik neem aan dat je eerst mag scannen voordat je gaat vuren. Scannen kost echter ook energie

Dan zit ik nog een beetje met het draadje dat geopent moet gaan worden als de contest van start gaat. Wat gaan we daar in posten?
Tactisc? Beetje stom, die hou je namelijk lekker voor jezelf als je wilt winnen.
Code? Beetje onhandig, niemand snapt er toch wat van, want niemand weet hoe je het geïmplenteerd hebt in je AI.
Wipjes? Ja kom op nou zeg, het is geen 3d contest van w&g

Eventuele vragen, en problemen over de opzet van het contest.

Of alleen maar resultaten van pre-fights van bots? En leuke reports van de bugs die uit die battles kwamen rollen en waar dus nog getweakt moet worden aan de bots?

Tijdens de ontwikkelfase moet het IMHO gewoon mogelijk zijn om je bot ergens (op een server) te kunnen testen.

Then again, die laatste kan natuurlijk wel de nodige discussiestof opleveren

Daar zijn we hier toch voor

[MisterData]

wacco schreef op 27 november 2002 @ 22:12:
btw: het is http://www.mozilla.org/js/spidermonkey/
en ik moet afleren zoveel smilies te gebruiken

* MisterData gaat de fantastische edit-knop ook es gebruiken

[cobratbq]

Hoop stof, veel goede ideëen, maar uhm.....
Kan er niet een vast stukkie client geschreven worden die de AI-script parsed en daarna een reply terugstuurd?
Dan heb je helemaal geen javascript parser nodig.
En als iedereen een andere code heeft voor het replyen via sockets dan is dat toch ook aardig probleem-rijzend of nie?

[Danfoss]

Leuk initiatief en ik ga denk ik wel mee doen (als ik 't voor elkaar krijg om ziets te coden)

Alleen snap ik het geloof ik nog niet helemaal
Wat ik ervan begrijp gaat het ongeveer zo werken: (in simpele taal )

GPC - Turnbased Tankwars
- Tanks zijn (client)programma die communiceren naar een (server)proggramma via socks.

Gameplay:
1 Per beurt krijgt tank een zooi data van de server (locatie andere tanks, projectielen, eigen energie waarden???)
2 Tank doet iets met die gegevens en stuurt een zooi data (beweging, vuren etc.) terug naar server.
3 Als alle tanks een beurt hebben gehad, verwerkt de server de ontvangen data.
4 Beurten beginnen opnieuw.

Zo toch?

[wacco]

"Heb je al die abworkers al eens gebeld henk?"
"Jazeker Jim, ik heb ze allemaal afgebeld"
"Goedzo henk, bel ze maar allemaal af, want ik heb hier de oplossing voor je!"


cobratbq, krijg je dan niet dat iedereen in een vast soort script taal moet werken?
Enneh, dat is het idee Danfoss

[xychix]

wacco schreef op 27 November 2002 @ 21:17:
oef... geduld argh, daar ben ik veel te enthousiast voor
Ik zit lekker sockets in c uit te pluizen, dat progt toch lekkerder dan vb. En ik ben een beetje code aan het bestuderen dat 'schijnt' te werken onder linux... dus misschien dat het ook nog echt wat wordt.

Want hoe willen we het nou gaan organiseren? Iedereen tegelijk online of alles op één systeem? I hope the last one, want iedereen tegelijk online is natuurlijk gedoemd te mislukken...

Hierboven staat ergens een Windhoos versie, ik heb ook wel een BSD versie, die zou onder linux moeten werken (ik hebdan echer alleen een server variant!)

Ik neem aan dat wanneer je over je eigen mijnen rijd ze ook ontploffen ? anders word het wel easy he !

Ik hoop dat iemand een Pseudocode dummybot op kan zetten en een DUIDELIJKE interface beschrijving want aan een server zonder 101% heldere interface heeft niemand wat !

Ik heb ook geen geduld, maar ook geen tijd (op dit moment dan) daarom ben ik nog niet aan't coden

[ Voor 24% gewijzigd door xychix op 28-11-2002 07:19 ]

[MisterData]

cobratbq schreef op 27 November 2002 @ 22:18:
Hoop stof, veel goede ideëen, maar uhm.....
Kan er niet een vast stukkie client geschreven worden die de AI-script parsed en daarna een reply terugstuurd?
Dan heb je helemaal geen javascript parser nodig.
En als iedereen een andere code heeft voor het replyen via sockets dan is dat toch ook aardig probleem-rijzend of nie?

Euhm het implementeren van een JS-parser heb je zo gedaan hoor

[MisterData]

Danfoss schreef op 27 November 2002 @ 22:42:
Leuk initiatief en ik ga denk ik wel mee doen (als ik 't voor elkaar krijg om ziets te coden)

Alleen snap ik het geloof ik nog niet helemaal
Wat ik ervan begrijp gaat het ongeveer zo werken: (in simpele taal )

GPC - Turnbased Tankwars
- Tanks zijn (client)programma die communiceren naar een (server)proggramma via socks.

Gameplay:
1 Per beurt krijgt tank een zooi data van de server (locatie andere tanks, projectielen, eigen energie waarden???)
2 Tank doet iets met die gegevens en stuurt een zooi data (beweging, vuren etc.) terug naar server.
3 Als alle tanks een beurt hebben gehad, verwerkt de server de ontvangen data.
4 Beurten beginnen opnieuw.

Zo toch?

Jepz

[MisterData]

xychix schreef op 28 November 2002 @ 07:15:
[...]

Hierboven staat ergens een Windhoos versie, ik heb ook wel een BSD versie, die zou onder linux moeten werken (ik hebdan echer alleen een server variant!)

Ik neem aan dat wanneer je over je eigen mijnen rijd ze ook ontploffen ? anders word het wel easy he !

Ik hoop dat iemand een Pseudocode dummybot op kan zetten en een DUIDELIJKE interface beschrijving want aan een server zonder 101% heldere interface heeft niemand wat !

Ik heb ook geen geduld, maar ook geen tijd (op dit moment dan) daarom ben ik nog niet aan't coden

Ik ben bezig met een progsel waarmee je je bot zelf in JavaScript kunt schrijven, en dan heb je geen ingewikkelde scripts nodig, hoef je ook niet met sockets te klooien

[MisterData]

Is er trouwens iemand die een goede, crossplatform library kent voor sockets? Ik heb tot nu toe altijd gewerkt met JNetLib van Nullsoft en met wxWindows maar de eerste is een beetje brak (kan niet met proxyservers overweg enzo) en de tweede is te groot vrees ik... iemand een goed alternatief?