[Alg] Nieuwe GoT contest?

[H!GHGuY]

Modbreak:

Deze topic is anders begonnen dan z'n titel doet vermoeden, discussie over een nieuwe contest begint hier: [rml]Creepy in "[ Alg] Nieuwe GoT contest?"[/rml]

Voor je ideeën spuit over een nieuwe contest, bedenk dan dat in principe alle talen mee mogen doen en het derhalve vooral gaat om algoritmische implementaties, niet low-level optimalisaties waarin native talen vrijwel altijd een voordeel zullen hebben

ikzelf heb me vorige avond even zitten verdiepen in het zo snel mogelijk genereren van priemgetallen
en heb een 3tal algoritmes gemaakt en toen dacht ik:
misschien eens een lekker programmeer-wedstrijdje om uit te voeren op GoT?

"bereken priemgetal 100.000.000 in een zo kort mogelijke tijd" (met 2 als het eerste)

als jullie dit zien zitten, dan moeten er natuurlijk enkele dingetjes vastgelegd worden (wie compileert/test) en hoe moet de code eruitzien? maar dat zijn zorgen voor 'dan'.

dit is dus even peilen naar interesse...

[ Voor 33% gewijzigd door .oisyn op 26-01-2005 15:17 ]

[_Squatt_]

Is een tijdje geleden nog een (leuk) topic over geweest.

* _Squatt_ is even zoeken

-- edit[0]
Onder meer in [rml][ c++] Array wordt veranderd bij overzetten[/rml] staat wat interessant leesvoer, kun je zien hoe jouw code zich staande houdt .

-- edit[1]

HIGHGuY schreef op woensdag 26 januari 2005 @ 00:31:
ik heb nochtans de search overlopen maar nix gevonden wat op dit topic leek

Ik ging ook meer in op het genereren van priemgetallen, niet het wedstrijd element .

[ Voor 82% gewijzigd door _Squatt_ op 26-01-2005 00:33 ]

[H!GHGuY]

_Squatt_ schreef op woensdag 26 januari 2005 @ 00:25:
Is een tijdje geleden nog een (leuk) topic over geweest.

* _Squatt_ is even zoeken

ik heb nochtans de search overlopen maar nix gevonden wat op dit topic leek

[Zoijar]

Mag ik ze in template code genereren in m'n compiler? Dan is de uitvoer tijd vrij snel bij draaien

[Verwijderd]

Heee

Ik heb mijn code nog steeds, ik heb nog een beetje getuned, resultaat:

code:

Highest prime: 4294967291 (0s)
Computing primes: (104.03s) 203280221 (6.92s)
Total time: 110.95s

Oftewel 203280221 priemen (dat zijn alle 32-bits priemen) in 104.03 seconden. (Het duurt nog 6.92 seconden om ze te tellen). Nog steeds op een Athlon XP1600+

Zoijar: het printen van tweehonderdmiljoen getallen kan wel ff duren (vermoedelijk langer dan ze genereren).

[Zoijar]

Verwijderd schreef op woensdag 26 januari 2005 @ 02:23:

Zoijar: het printen van tweehonderdmiljoen getallen kan wel ff duren (vermoedelijk langer dan ze genereren).

Hehe, ja ok Maar het xxx-te getal, wordt een constante, na heel lang compilen Dus push 'xxx'; call cout; oid

[Creepy]

HIGHGuY schreef op woensdag 26 januari 2005 @ 00:22:
als jullie dit zien zitten, dan moeten er natuurlijk enkele dingetjes vastgelegd worden (wie compileert/test) en hoe moet de code eruitzien? maar dat zijn zorgen voor 'dan'.

dit is dus even peilen naar interesse...

Als je dit soort zaken voortaan eerst met 1 van de moderators wilt opnemen dan graag

Daarnaast denk ik niet dat een competitie op deze manier erg veel nut gaat hebben. Er is genoeg informatie en code op het web te vinden om een relatief snel algoritme te vinden dat de uiteindelijke verschillen in de implementatie verschillen zitten van datzelfde algoritme (kick me if I'm wrong ), terwijl het denk ik leuker is om zelf een algoritme te (moeten) verzinnen. Nou kan je dat wel vragen natuurlijk, maar je kan het vrij moeilijk afdwingen.

Overigens, goed om te zien dat er wel een eventuele interrese is voor een GoT P&W contest

[OZ-Gump]

Sowieso is er wel interesse in een GoT P&W contest, niet alleen voor deze met priemgetallen!
Ik zou het ook wel leuk vinden om mee te doen, als er daadwerkelijk een contest komt. Lijkt me dan wel leuk om het niet bij één taal te houden, maar om die ook vrij te laten. Dan kun je misschien bij ongeveer dezelfde algoritmes de invloed/kracht van de compiler en/of taal zien.

[ Voor 35% gewijzigd door OZ-Gump op 26-01-2005 09:00 ]

[Verwijderd]

Creepy schreef op woensdag 26 januari 2005 @ 08:52:
Daarnaast denk ik niet dat een competitie op deze manier erg veel nut gaat hebben. Er is genoeg informatie en code op het web te vinden om een relatief snel algoritme te vinden dat de uiteindelijke verschillen in de implementatie verschillen zitten van datzelfde algoritme (kick me if I'm wrong

/me kicks

Een zeefalgoritme is idd. snel gevonden en die zeefalgoritmes hebben de zelfde tijdscomplexiteit, maar dat wil niet zeggen dat er geen (grote) constante factor aan tijdswinst uit te persen is door handig te coden. Het zou dus meer een wedstrijdje optimalizeren worden, maar daar leer je ook van; sterker nog, daar leer je zaken van die je in elk toekomstig project kunt toepassen.

[H!GHGuY]

Creepy schreef op woensdag 26 januari 2005 @ 08:52:
[...]

Als je dit soort zaken voortaan eerst met 1 van de moderators wilt opnemen dan graag

Daarnaast denk ik niet dat een competitie op deze manier erg veel nut gaat hebben. Er is genoeg informatie en code op het web te vinden om een relatief snel algoritme te vinden dat de uiteindelijke verschillen in de implementatie verschillen zitten van datzelfde algoritme (kick me if I'm wrong ), terwijl het denk ik leuker is om zelf een algoritme te (moeten) verzinnen. Nou kan je dat wel vragen natuurlijk, maar je kan het vrij moeilijk afdwingen.

Overigens, goed om te zien dat er wel een eventuele interrese is voor een GoT P&W contest

oki, ik had nog zitten twijfelen of'k eerst een modje zou contacteren, maar toen heb'k dit topic veranderd van wedstrijd -> interesse wedstrijd. op die manier kunnen mods hier ook reageren, en is het nog altijd niet definitief.

wat die algoritmes betreft: ik heb zelf gisteren en 10tal minuutjes zitten googlen op code om priemgetallen te zoeken, en ik heb niet echt iets performant gevonden.

en wat een contest betreft: of het nu priemgetallen zijn, of iets anders, ik zou zeker wel eens graag een P&W contest doen... dus als het nu van mij uit is, of van jullie... go for it

[ Voor 4% gewijzigd door H!GHGuY op 26-01-2005 10:47 ]

[.oisyn]

Zoijar schreef op woensdag 26 januari 2005 @ 02:39:
[...]

Hehe, ja ok Maar het xxx-te getal, wordt een constante, na heel lang compilen Dus push 'xxx'; call cout; oid

Ik ben benieuwd welke compiler om kan gaan met een dergelijke diepe recursie

---

Is het niet interessant om die AI contest weer op te pakken? Mietje, was jij daar niet ooit een framework voor aan het maken?

[ Voor 18% gewijzigd door .oisyn op 26-01-2005 10:51 ]

[Creepy]

* Creepy was ook bezig met een klein AI "framework" met daarbij de mogelijkheid voor ondersteuning voor de meeste ontwikkelomgevingen en een linux/windows koppeling.

Ik zal dat weer eens oppakken en kijken hoe snel ik iets bruikbaars heb. Maar als iemand ander al iets heeft liggen... (oeh, das bijna een script request ).

[Verwijderd]

.oisyn schreef op woensdag 26 januari 2005 @ 10:50:
Is het niet interessant om die AI contest weer op te pakken? Mietje, was jij daar niet ooit een framework voor aan het maken?

Oei, dat is meer dan twee jaar geleden; dat project is nooit afgekomen door een ziekenhuisverblijf van zo'n 7 maanden. Voor zover ik me kan herinneren was de physics-engine af maar moest het netwerkgedeelte nog geschreven worden, ik zal eens in mijn archief kramen als ik thuis ben.

[H!GHGuY]

* H!GHGuY voelt het tintelen onder de nagels...

[MLM]

* MLM is geïnterresseerd in een contest. (bookmarkt)

[Solovine]

Ik kan helemaal niet programmeren in C++, het lijkt me echter wel leuk om dit topic te volgen.
Misschien komt er uiteindelijk wel een leuke benchmark uit, als vervanging voor Superpi of Pifast.

[.oisyn]

Hmm dit zorgt dus voor verwarring, even titel fixen en modbreak plaatsen in startpost

[P_de_B]

Een contest is altijd leuk, maar het moet denk ik niet een te groot project zijn, anders verliezen veel mensen hun intresse.

[pjvandesande]

Intressen heb ik zeker! Alleen moet het wel een leuk en zinnige contest zijn.

/14 is kwa contests en groepprojecten niet dendert, maar komt meer omdat er ten 1e al een hoop verschillende talen op de markt zijn. En wij /14'ers nou eenmaal te druk zijn.

Maar ik hou dit in de gaten en ik moet zeggen dat ik het ontzettend leuk zou vinden als er iets word ondernomen. Ik laat me verassen.

[OZ-Gump]

Eerste ideetje dat bij me opkomt:
Het schrijven van een algoritme voor het oplossen van een labyrint. Het labyrint wordt aangeleverd in een vaste indeling (databestand, image, ...) en het algoritme moet zo snel mogelijk alle mogelijke oplossingen voor het labyrint berekenen.

Het is maar een eerste ideetje ...

[ Voor 8% gewijzigd door OZ-Gump op 26-01-2005 15:27 ]

[Verwijderd]

De opzet van de oude contest was simpel:

1) Er moest een server komen, de wedstrijd bestond uit het schrijven van een client. Dit heeft als voordeel dat zowat iedere taal kan meedoen (mits er niet gepleit wordt voor overkill-protocollen als XML; keep it simple).
2) Het ging om een 2d "tank" spelletje waarbij het de bedoeling was om tegenstanders (andere AIs) te vernietigen. Er kon gereden en geschoten worden met explosieve kogels (maw. je moest een "ontstekingstijd" voor je schoten berekenen adhv. de afstand tot het doel, hoe meer je reed hoe minder je kon schieten).

[Gerco]

Verwijderd schreef op woensdag 26 januari 2005 @ 15:37:2) Het ging om een 2d "tank" spelletje waarbij het de bedoeling was om tegenstanders (andere AIs) te vernietigen. Er kon gereden en geschoten worden met explosieve kogels (maw. je moest een "ontstekingstijd" voor je schoten berekenen adhv. de afstand tot het doel, hoe meer je reed hoe minder je kon schieten).

Zoiets? Deze is wel alleen in c++, dus dan kan niet iedereen meedoen, maar een multi-taal, multi-platform versie hiervan kan me wel bekoren.

Punt is dus wel om een server hiervoor te hebben waarmee de boel volautomatisch afgehandeld kan worden net als met c++robots. Op die manier heb je sneller een ongoing iets en iedereen kan er volledig op zijn eigen schema aan werken en meteen resultaat zien (heel belangrijk!).

[.oisyn]

Ik vind het oude idee wat mietje boven me beschrijft het leukst. Het is toegankelijk voor iedereen en je hoeft niet zoveel te weten van algoritmische concepten. Ook is het veelzijdig; er is geen vaste output voor een bepaalde input en er is vziw geen algehele winnende strategie bekend. De ene zal er voor kiezen om vooral defensief te werken, terwijl de ander vindt dat een aanvallende strategie veel beter is. En daarnaast is het ook nog eens gewoon leuk om naar te kijken

[pjvandesande]

.oisyn schreef op woensdag 26 januari 2005 @ 15:59:
Ik vind het oude idee wat mietje boven me beschrijft het leukst. Het is toegankelijk voor iedereen en je hoeft niet zoveel te weten van algoritmische concepten. Ook is het veelzijdig; er is geen vaste output voor een bepaalde input en er is vziw geen algehele winnende strategie bekend. De ene zal er voor kiezen om vooral defensief te werken, terwijl de ander vindt dat een aanvallende strategie veel beter is. En daarnaast is het ook nog eens gewoon leuk om naar te kijken

Dat concept is zeker leuk. Vooral om de verschillen te zien van verschillende tanks/robots. Ik ben benieuwd!

[Verwijderd]

Als die tank-contest nog een keer van de grond af komt, zou dat zeer leuk zijn! Nog leuker als het ook server-side wordt opgenomen, zodat je achteraf precies kan zien wat er goed en mis ging. En dan in een soort van toernooi-opzet, waarbij je eerst een paar keer mag oefenen (a la F1)

[Verwijderd]

Was er al een argument tegen het gebruik van robocode als framework (behalve dan natuurlijk dat iedereen ideeën kan jatten van robots die te downloaden zijn van het internet, maar daar is vast wel wat op te vinden)?

Je zou dan bijvoorbeeld elke nacht automatisch een competitie kunnen spelen van alle geuploade robots.

[ Voor 17% gewijzigd door Verwijderd op 26-01-2005 17:10 ]

[Verwijderd]

Een tegenarument is dat het (als ik 10 seconden naar de homepage kijk, dus correct me if I'm wrong), voor Java is. Bovendien had mietje misschien nog wat oude code liggen van een server, dus dat kan dan gebruikt worden.

[.oisyn]

Verwijderd schreef op woensdag 26 januari 2005 @ 17:11:
Een tegenarument is dat het (als ik 10 seconden naar de homepage kijk, dus correct me if I'm wrong), voor Java is. Bovendien had mietje misschien nog wat oude code liggen van een server, dus dat kan dan gebruikt worden.

Dat hoeft geen probleem te zijn, je kunt ook gewoon zo'n Robot interface implementeren als proxy die alles over het netwerk verstuurt, zodat alsnog makkelijk elke taal gebruikt kan worden.

Het voordeel van een eigen framework is echter wel dat wij in principe full control hebben; we kunnen makkelijk features toevoegen mocht dat nodig zijn.

[H!GHGuY]

misschien een combinatie van de 2 vorige:

tanks starten op spawnpoints in een ruim labyrinth.
het spel verloopt in beurten.
eventueel een mogelijkheid voorzien tot samenwerken (in het ergste geval is het 1 tegen allen tot die ene eraan is)

[Verwijderd]

ff wat losse opmerkingen

• Het is/was niet de bedoeling dat we een andere contest exact copieren, dat maakt het te makkelijk om bestaande code te jatten en aan te passen.
• Onderschat de tank-opzet niet, de positie van rijdende tanks voorspellen (om ze te raken) is niet zo eenvoudig als die andere tanks ondertussen van richting veranderen; daarbij moet je ook zorgen dat je zelf zo min mogelijk geraakt wordt.
• Het geheel zou geimplementeerd moeten worden volgens een echt client-server model, zodat iedere taal (met beschikking over tcp/ip) kan meedoen.
• Ik heb de (c++) code hier voor me, de engine is ongeveer af, maar het netwerk-gebeuren moet nog; ik zal dit weekend (druk, druk) kijken of ik er snel een mouwtje aan kan passen zodat we iets hebben om mee te werken.

[Verwijderd]

Lijkt me een leuk idee. Ik ga in elk geval zeker meedoen.

En een algoritmische contest is op zich ook wel leuk, bijvoorbeeld zoals gedaan wordt op het NK programmeren.

Je krijgt een set problemen (en beperkte tijd), en moet dan proberen zoveel mogelijk problemen uit die set op te lossen. Bij elk probleem krijg je voorbeeld in- en uitvoer, en na inzending wordt het programma getest tegen een aantal verborgen (maar vaste) testsets van in- en uitvoer, die bijvoorbeeld extreme gevallen controleren.

Het enige nadeel is wel dat er veel werk gaat zitten in het organiseren van zo'n contest.

[H!GHGuY]

Verwijderd schreef op woensdag 26 januari 2005 @ 17:42:
ff wat losse opmerkingen

• Het is/was niet de bedoeling dat we een andere contest exact copieren, dat maakt het te makkelijk om bestaande code te jatten en aan te passen.
• Onderschat de tank-opzet niet, de positie van rijdende tanks voorspellen (om ze te raken) is niet zo eenvoudig als die andere tanks ondertussen van richting veranderen; daarbij moet je ook zorgen dat je zelf zo min mogelijk geraakt wordt.
• Het geheel zou geimplementeerd moeten worden volgens een echt client-server model, zodat iedere taal (met beschikking over tcp/ip) kan meedoen.
• Ik heb de (c++) code hier voor me, de engine is ongeveer af, maar het netwerk-gebeuren moet nog; ik zal dit weekend (druk, druk) kijken of ik er snel een mouwtje aan kan passen zodat we iets hebben om mee te werken.

en ik denk dat we't ook redelijk "klein" moeten houden.
mijn oorspronkelijke voorstel (met die priemen) was in 2 avonden gemaakt, en is amper 2 A4's code. wanneer we TE groot gaan is er teveel werk nodig, en wordt het moeilijk om genoeg mensen te krijgen om dit tot het eind af te werken.
als iedereen rondcrosst en vuurt, dan moet je ook al beginnen rekening houden met lag?
daarentegen als je in beurten werkt (evt? simultaan?) ontloop je dit probleem


edit: ander voorstel:
iemand geeft een random stuk code (dat in verschillende talen herschreven is op een gelijke manier) en iedereen moet die code proberen optimaliseren.
dit kan voor:
- geheugengebruik
- snelheid
(- diskspace van de executable??)
wie het meest percent winst haalt (binnen een taal) wint voor zijn discipline.

[ Voor 24% gewijzigd door H!GHGuY op 26-01-2005 18:25 ]

[Verwijderd]

HIGHGuY schreef op woensdag 26 januari 2005 @ 18:17:
[...]
als iedereen rondcrosst en vuurt, dan moet je ook al beginnen rekening houden met lag?
daarentegen als je in beurten werkt (evt? simultaan?) ontloop je dit probleem

Goed punt. Maar met een client-server architectuur kun je nog steeds best een turn-based spel maken.


En je `clockcycles persen' contest vind ik persoonlijk niet zo heel leuk om te doen.

[ Voor 11% gewijzigd door Verwijderd op 26-01-2005 18:35 ]

[Verwijderd]

Ik sluit me volledig bij OneOfBorg aan.

@mietje: de engine is dus nog dezelfde als van een paar jaar geleden? Dan kan ik ff het oude topic opzoeken en vast een beetje gaan brainstormen.

[ Voor 1% gewijzigd door Verwijderd op 26-01-2005 18:38 . Reden: typo ]

[MSalters]

Verwijderd schreef op woensdag 26 januari 2005 @ 02:23:
Heee

Ik heb mijn code nog steeds, ik heb nog een beetje getuned, resultaat:

code:

Highest prime: 4294967291 (0s)
Computing primes: (104.03s) 203280221 (6.92s)
Total time: 110.95s

Oftewel 203280221 priemen (dat zijn alle 32-bits priemen) in 104.03 seconden. (Het duurt nog 6.92 seconden om ze te tellen). Nog steeds op een Athlon XP1600+

En nou kan ik moregn de hele dag gaan debuggen waarom ik op 203270917 uitkom
Gaat wel snel, klopt ook nog tot de 100000

[Verwijderd]

Verwijderd schreef op woensdag 26 januari 2005 @ 18:34:
Goed punt. Maar met een client-server architectuur kun je nog steeds best een turn-based spel maken.

Je werkt bij dit soort servers met een "heartbeat", je stelt gewoon dat de gamestate 1x in de (bv.) 0.1 seconden wordt geupdate. Die 100 ms is genoeg om clientlag te voorkomen, terwijl ik niet verwacht dat er zoveel objecten gesimuleerd moeten worden dat het doorgeven van de gamestate richting clients veel bandbreedte gaat kosten. Hoe dan ook, dat laatste probleem is op te lossen door een server met een dikke pijp.

Verwijderd schreef op woensdag 26 januari 2005 @ 18:37:
Ik sluit me volledig bij OneOfBorg aan.

@mietje: de engine is dus nog dezelfde als van een paar jaar geleden? Dan kan ik ff het oude topic opzoeken en vast een beetje gaan brainstormen.

Jep, er wordt daar wat gekissebist over protocollen ed., maar nog geen echt relevante info. (Ik werd toen plots zwaar ziek en heb het forum meer dan een jaar niet meer bezocht.)

MSalters schreef op woensdag 26 januari 2005 @ 18:41:
En nou kan ik moregn de hele dag gaan debuggen waarom ik op 203270917 uitkom
Gaat wel snel, klopt ook nog tot de 100000

Ik heb mijn code online gezet, misschien heb je er wat aan met het vergelijken van de uitkomsten. De timer class gebruikt de POSIX ::times() call, die zul je evt. moeten porten of eruit slopen.

edit:
Tip: bij het testen van de priemen is het handiger om bij de laatste priem (het grootste getal) te beginnen, fouten zitten meestal achter in de zeef (ivm. overflows ed.).

[ Voor 8% gewijzigd door Verwijderd op 26-01-2005 20:56 ]

[Skaah]

Ik zou graag een contest zien waarbij het ook mogelijk is om iets in PHP mee te laten doen. Snelheidsdingen zal PHP altijd verliezen.

[pjvandesande]

Skaah schreef op donderdag 27 januari 2005 @ 10:01:
Ik zou graag een contest zien waarbij het ook mogelijk is om iets in PHP mee te laten doen. Snelheidsdingen zal PHP altijd verliezen.

PHP is een scripttaal, ik voel hier zelf niet veel voor. Maar PHP kan communiceren met sockets, dus je zou zelf dmv PHP mee kunnen doen.
Hoewel ik dit niet zo zie zitten.

[Verwijderd]

Ik zou graag vandaag of morgen weten of het zinvol is mijn weekend aan die server code op te offeren

offtopic:
MSalters: ik heb gisteren een oude versie van de code geplaatst. De oude versie is exact het zelde algoritme, maar geschreven voor een oude linux en geeft compiler warnings/errors.

[Creepy]

questa schreef op donderdag 27 januari 2005 @ 10:07:
[...]


PHP is een scripttaal, ik voel hier zelf niet veel voor. Maar PHP kan communiceren met sockets, dus je zou zelf dmv PHP mee kunnen doen.
Hoewel ik dit niet zo zie zitten.

Ik was bezig met net zoiets als dat mietje heeft, maar dan gebeurt alle communicatie via stdin en stdout voor de clients. Ook PHP kan er dan aan meedoen (als zijnde "CGI" app), nagenoeg elke taal dan

Dat scripttalen niet mee zouden mogen doen vindt ik onzin.

Mietje: Als ik het zo lees zijn er zat mensen die mee zouden willen doen. Misschien dat het handig is als je hier nog kan posten hoe de server <-> client communicatie nu ongeveer gaat om te kijken of iedereen hier mee uit de voeten kan en om een gevoel te krijgen hoe simpel of complex het is om een werkende client te maken.

[ Voor 23% gewijzigd door Creepy op 27-01-2005 11:48 ]

[pjvandesande]

Creepy schreef op donderdag 27 januari 2005 @ 11:47:
[...]

Dat scripttalen niet mee zouden mogen doen vindt ik onzin.

Mee eens, het is wel leuk om te zien obsoluut. Ik vind het voor mezelf een beetje onzin, dat bedoelde ik te zeggen.

[eamelink]

Ik vind een tank-contest inderdaad erg leuk.

Het voordeel is dat het redelijk 'doorlopend' kan zijn. Op een gegeven moment is je priemgetallen ding af, en dan ben je klaar.

Hier kan je lekker toernooitjes houden, daarna je tank verbeteren, opnieuw enzo...

En het kan nog leuk zijn om naar te kijken als er tenminste ook een toeschouwers interface op de server komt

[Gerco]

Als het iets is waar ik gewoon om 3 uur 's nachts een programma kan testen, resultaten terugkrijgen en weer wat verder optimizen, dan doe ik zeker mee. Als het een "om <tijd> op <datum>" kun je je spullen testen achtig iets is, moet ik verstek laten gaan.

[Verwijderd]

Python ahoy!

Maar voor de duidelijkheid: is het de bedoeling dat de clients vanaf de eigen computers van de spelers komen te draaien? Of worden ze opgestuurd en op een centrale machine gedraaid?

Want bijvoorbeeld 's nachts automatisch toernooitjes draaien is er natuurlijk niet bij als de clients bij de programmeur draaien. Van de andere kant valt niet elke scriptingtaal te gebruiken als de bots op de server komen te draaien (tenzij de server op verzoek volgepompt wordt met programmeeromgevingen, -talen en -libraries).

[Verwijderd]

Tof idee..... van die tank batle.

Ik ben er zeker bij. Al heb ik totaal geen ervaring met AI coden

[H!GHGuY]

Verwijderd schreef op donderdag 27 januari 2005 @ 12:59:
Tof idee..... van die tank batle.

Ik ben er zeker bij. Al heb ik totaal geen ervaring met AI coden

dan ben je niet alleen, maar het is zeker een uitdaging

[Verwijderd]

Indien het mogelijk is om een c# botje de gebruiken doe ik ook zeker mee. Ik ken niks van AI, maar het interesseert me wel enorm

[djc]

Verwijderd schreef op donderdag 27 januari 2005 @ 12:51:
Python ahoy!

Indeed. Ik ben ook wel geinteresseerd in een potje tank-knallen.

Vind het punt van asynchronisme wat Gerco hierboven aanstipt trouwens wel sterk.

[.oisyn]

Gerco schreef op donderdag 27 januari 2005 @ 12:44:
Als het iets is waar ik gewoon om 3 uur 's nachts een programma kan testen, resultaten terugkrijgen en weer wat verder optimizen, dan doe ik zeker mee. Als het een "om op " kun je je spullen testen achtig iets is, moet ik verstek laten gaan.

Het lijkt me handig om de server downloadbaar te maken zodat je die ook gewoon bij je thuis kan draaien. Dan heb je alleen nog bots nodig om mee te testen, we kunnen de bots van de deelnemers natuurlijk ook gewoon online zetten maar dan heb je weer dat je van tevoren je bot zo kan programmeren dat ie goed werkt tegen bepaalde tegenstanders, maar overall eigenlijk helemaal geen winning team is. Dit is dus iets waar we nog even over na moeten denken.

[Verwijderd]

Creepy schreef op donderdag 27 januari 2005 @ 11:47:
Mietje: Als ik het zo lees zijn er zat mensen die mee zouden willen doen. Misschien dat het handig is als je hier nog kan posten hoe de server <-> client communicatie nu ongeveer gaat om te kijken of iedereen hier mee uit de voeten kan en om een gevoel te krijgen hoe simpel of complex het is om een werkende client te maken.

Dat protocol lag dus nog niet vast, er is wel al wat over geschreven in [rml][ alg] botwar Bespreking *[/rml], maar dat strandde toen op ziekte (niet alleen de mijne) Aangezien er animo genoeg is, flans ik zaterdag snel een (nieuw) voorstel voor het protocol in elkaar en post dat hier.

edit:
Het grootste probeem met het client-server model is mi. cheaten tegengaan, het is moeilijk te controleren of er geen AIs "teamen"; en (misschien nog erger) of er geen clients zijn die niet door een AI maar door een joystick of iets dergelijks bestuurd worden. Daar zat ik dus over te broeden.

[ Voor 20% gewijzigd door Verwijderd op 27-01-2005 15:00 ]

[.oisyn]

Verwijderd schreef op donderdag 27 januari 2005 @ 14:56:
Het grootste probeem met het client-server model is mi. cheaten tegengaan, het is moeilijk te controleren of er geen AIs "teamen"; en (misschien nog erger) of er geen clients zijn die niet door een AI maar door een joystick of iets dergelijks bestuurd worden. Daar zat ik dus over te broeden.

Ik denk dat we maar gewoon erop moeten vertrouwen dat dat niet gebeurt. Het lijkt me dat de sources van de bots van de deelnemers downloadbaar moeten zijn, als er iemand cheat dan is dat snel genoeg te zien imho

[H!GHGuY]

eventueel kan de server draaien als een programma met "plugins"
elk maakt dan een plugin met een vastliggende interface (die de spelers dan enkel hoeven te implementeren)

dan zend iedereen zijn plugin met sourcecode in, en dan wordt het server-programma 1 maal gestart met alle plugins van iedereen.
de uitkomst wordt dan op 1 of andere manier door de server gelogd zodat iedereen weet wat er gebeurt.

dit zorgt echter wel voor de extra last dat er gezorgd moet worden dat er voor elke taal plugin-code beschikbaar is waarop verder gebouwd wordt.

[Creepy]

Source downloadbaar zouden we wel verplicht moeten stellen.
Kan je er eventueel nog extra competities bij verzinnen zoals kleinst werkende bot, most obfuscated bot, etc. etc.

[Verwijderd]

Ik probeer mij even een beeld te vormen van hoe het ongeveer zou werken, want het is mij niet helemaal duidelijk (net als de rest )....

De server heeft een speelveld in zn geheugen waar een x aantal tankjes op rondrijden. Elk van deze tankjes wordt bestuurd door een client die verbonden is via tcp/ip.
Een client is het programma dat draait op de pc van een deelnemer.

De problemen die ik dan zie:

Als het niet turn based is, zal er door lag geen zak meer van de posities e.d kloppen.

Wel turn based zou beteken dat elke client beurtelings een x aantal stapjes mag zetten en een x aantal kogels schieten. Nu creeer je echter weer nieuwe problemen doordat je tussen je beurten door een 'sitting duck' bent en anderen jouw kogels makkelijker zien aankomen.(Kan het niet helemaal goed uitleggen, maar voor mn gevoel werkt dit ook niet helemaal)...

Kan iemand het idee wat verhelderen misschien?

PS. vals spelen moet je geen rekening mee gaan houden. Dat krijg je toch nooit waterdicht.

[Verwijderd]

HIGHGuY schreef op donderdag 27 januari 2005 @ 16:02:
eventueel kan de server draaien als een programma met "plugins"
elk maakt dan een plugin met een vastliggende interface (die de spelers dan enkel hoeven te implementeren)

dan zend iedereen zijn plugin met sourcecode in, en dan wordt het server-programma 1 maal gestart met alle plugins van iedereen.
de uitkomst wordt dan op 1 of andere manier door de server gelogd zodat iedereen weet wat er gebeurt.

dit zorgt echter wel voor de extra last dat er gezorgd moet worden dat er voor elke taal plugin-code beschikbaar is waarop verder gebouwd wordt.

Daar heb ik ook aan zitten denken. Dan heb je een hoop praktische problemen minder. En kun je eventueel de server altijd laten runnen zodat de botjes non stop vechten. Het botje dat het langst blijft leven is het beste. Zodra hij kapot gaat spawnd hij gelijk weer (eventueel met nieuwe code). Zo kun je ook altijd je nieuwe code testen met alle 'echte' bots. Nadeel is wel dat de server heel erg complex wordt......met zo'n plugin architectuur.

PS. De source van je bot moet je geheim kunnen houden vind ik!!!
Je gaat je geheimen toch niet prijsgeven. Bij de Formule 1 gaat ferrari toch ook niet naar Williams om te vertellen hoe ze net die extra grip hebben verkregen bijvoorbeeld...

[djluc]

Als je slim genoeg bent kan je op basis van de code van andere nog betere code ontwikkelen. Ik denk dat het resultaat door opensource alleen maar beter wordt.

[FendtVario]

Interessante wedstrijd, ga misschien wel proberen mee te doen. Gister na een opmerking hier de Robocode van IBM gedownload maar dat valt nog niet mee een leuke robot te schrijven.

Denk niet dat de bots direct opensource moeten zijn; minder bedreven proggers kunnen dan toch een heel sterke bot maken en daardoor hoog eindigen. Aan het einde van de competitie kun je ze wel vrijgeven, dan kun je kijken waarom tweaker x van je gewonnen heeft.

[.oisyn]

Verwijderd schreef op donderdag 27 januari 2005 @ 16:11:
Wel turn based zou beteken dat elke client beurtelings een x aantal stapjes mag zetten en een x aantal kogels schieten. Nu creeer je echter weer nieuwe problemen doordat je tussen je beurten door een 'sitting duck' bent en anderen jouw kogels makkelijker zien aankomen.(Kan het niet helemaal goed uitleggen, maar voor mn gevoel werkt dit ook niet helemaal)...

Dat hoeft natuurlijk niet, het is een kwestie van de turns zo klein mogelijk maken (dus niet 100 stappen zetten en 10 kogels schieten, maar eerder 1 stap en één kogel per 5 turns oid)

[Mithrandir]

Verwijderd schreef op donderdag 27 januari 2005 @ 16:19:
[...]


Daar heb ik ook aan zitten denken. Dan heb je een hoop praktische problemen minder. En kun je eventueel de server altijd laten runnen zodat de botjes non stop vechten. Het botje dat het langst blijft leven is het beste. Zodra hij kapot gaat spawnd hij gelijk weer (eventueel met nieuwe code). Zo kun je ook altijd je nieuwe code testen met alle 'echte' bots. Nadeel is wel dat de server heel erg complex wordt......met zo'n plugin architectuur.

PS. De source van je bot moet je geheim kunnen houden vind ik!!!
Je gaat je geheimen toch niet prijsgeven. Bij de Formule 1 gaat ferrari toch ook niet naar Williams om te vertellen hoe ze net die extra grip hebben verkregen bijvoorbeeld...

Waarom zouden we dan nog een competitie maken? Voor de showoff van de beste programmeurs hier?

Het punt is juist om een groepsgevoel te creeren, open source bots horen daarbij imho.

Lijkt me verder een tof plan!

[Orphix]

Zeker een tof idee. Als het goed opgezet wordt ben ik van plan mee te doen.

Het probleem van lag zie ik niet zo. Het spel hoeft toch niet 'realtime' plaats te vinden. Het zijn geen menselijke tegenstanders, dus het maakt niks uit of het nou met 40fps of met 2fps gaat. Je krijgt met een lagere framerate niet meer of minder informatie om je acties op te baseren.

Enkel heeft je computer meer processorkracht om die acties door te redeneren maar ik denk niet dat daar de bottleneck in zit. Het probleem van lags ben je dan bij een lage framerate volgens mij wel kwijt.

[Verwijderd]

Mithrandir schreef op donderdag 27 januari 2005 @ 17:05:
[...]

Waarom zouden we dan nog een competitie maken? Voor de showoff van de beste programmeurs hier?

Het punt is juist om een groepsgevoel te creeren, open source bots horen daarbij imho.

Lijkt me verder een tof plan!

Ik ben t ermee eens dat het groepsgevoel telt, maar het is niet voor niks een contest/competitie!
Wat jij wilt is een theekransje van bots..;)

Hoe dan ook, opensource of niet. Ik ben erbij

[Verwijderd]

.oisyn schreef op donderdag 27 januari 2005 @ 17:04:
[...]


Dat hoeft natuurlijk niet, het is een kwestie van de turns zo klein mogelijk maken (dus niet 100 stappen zetten en 10 kogels schieten, maar eerder 1 stap en één kogel per 5 turns oid)

Waarom niet gewoon 1 actie (lopen danwel schieten danwel draaien) per tick?

Je kan het bijvoorbeeld zo doen:

code:

1. Server stuurt "request for action during tick X" naar alle clients
2. Clients sturen de actie die ze in die beurt uit willen voeren naar de server (ze krijgen die van elkaar niet te zien)
3. Zodra alle acties van alle clients binnen zijn kan de tick uitgevoerd worden (om te zorgen dat de framerate zo hoog mogelijk is)
4. Als een client te lang geen actie voor een beurt doorstuurt (zeg 5 seconden), dan wordt hij gedisconnect en gedropt (of zijn beurt gaat gewoon voorbij, kan ook)
5. Nadat de tick verwerkt is wordt de nieuwe gamestate naar alle clients gestuurd.
6. X := X + 1
7. Ga terug naar 1.

En voor zover mogelijk (verzoekje ), hou het protocol alsjeblieft zoveel mogelijk tekst-based, dan is het zo portable mogelijk (naar andere programmeertalen/andere OSsen/andere processorarchitecturen).

[ Voor 57% gewijzigd door Verwijderd op 27-01-2005 17:31 ]

[Creepy]

Verwijderd schreef op donderdag 27 januari 2005 @ 16:19:
[...]

PS. De source van je bot moet je geheim kunnen houden vind ik!!!
Je gaat je geheimen toch niet prijsgeven. Bij de Formule 1 gaat ferrari toch ook niet naar Williams om te vertellen hoe ze net die extra grip hebben verkregen bijvoorbeeld...

"Geheimen"? Je moet echt wel met iets gigantisch briljants gaan komen wil het echt een geheim zijn
Juist voor het extra competitie element vindt ik dat de source beschikbaar moet zijn voor de jury (in elk geval diegene die de competitie leidt). Nadat de bot matches zijn gespeeld kan de source echt opensource worden voor iedereen. Zo geef je in elk geval je geheim niet prijs aan je concurrenten.

En zoals ik al had voorgesteld: extra ongein/vermeldingen voor kleinst werkende bot, meest onleesbare bot (brainfuck of whitespace liefhebbers hier? ) etc. lijken mij best leuk

Daarnaast denk ik dat we even moeten wachten op de uitleg van mietje over het protocol en het turnbased of niet voordat we daar (weer) oeverloos over gaan praten...

[ Voor 13% gewijzigd door Creepy op 27-01-2005 17:29 ]

[Verwijderd]

Ik heb gisteravond de eerder aangehaalde post over bot wars een doorgespit en per buurt was het tijdelijke protocol van mietje:

code:

#  G <richting> <energie> // Beweeg de tank
# S <energie> // Meer energie naar het schild
# V <richting> <energie> <energie> // Vuur een projectiel af
# R <energie> // Doe een radarscan

Alle commando's konden 1x per buurt worden uitgevoerd. De volgende buurt krijg je het resultaat terug.

Maar misschien is ook dat weer veranderd natuurlijk

[H!GHGuY]

hmm lekker concept met die energie dingen etc...

mss wel koel om het iets uit te breiden kwestie van AI:
elke beurt krijgt iedereen een hoeveelheid energie. en die kan hij/zij spenderen naar believen. rijden + schieten kan + schild opladen + ... zolang je energie hebt.

binnen 1 beurt kan je ook zoveel energietransacties doen zoals je wilt (dit telkens 1 maal naar verschillende onderdelen maar een transfer duurt wel 1 beurt)
en mss nog een add-on: B <energie> laadt batterij op. batterij loopt echter altijd langzaam leeg. dus heb je bij beurt 1 nog 50 energie in je batterij dan is die bvb volgende beurt nog 47 of zo.

dus bvb: stel je krijgt 15 aan energie dan kan ik kan kiezen om met 5 energie links-voorruit te rijden, en een schot van 4 energie uit te voeren in een andere richting, en gelijk met 1 energie m'n schild opladen. de overige energie stop ik dan bvb in m'n batterij voor volgende beurt.

ook wordt er met substappen gewerkt: dus rijden met 5 energie en dan vuren met 4 <> vuren met 4 en dan rijden met 5. dit ook om de plaatsbepaling gemakkelijker te bepalen.

klinkt mss allemaal wat snel geredeneerd maar het is slechts een voorstel natuurlijk.

[Voutloos]

Hangt van het protocol af, of je naast het instellen van de kracht van de acties dus ook de volgorde kan opgeven. Zal voor het zien van de gevechten een stuk spectaculairder zijn en is denk wel goed te maken voor de server.

Maar dan moet wel gegeven zijn wat er gebeurt als bot 1 schiet en rijdt en bot 2 eerst rijdt en dan schiet: gebeurt het rijden van bot 2 dan voor of na het schieten van bot 1?

[ Voor 3% gewijzigd door Voutloos op 27-01-2005 20:41 ]

[Verwijderd]

Mijn opzet was eigenlijk iets anders:

• Je krijgt elke "beurt" (1x per 0.1 seconden) een bepaalde hoeveelheid energie, zeg 50 eenheden.
• Er is een "buffer" of "accu" waarin je energie tot een bepaalde hoeveelheid -zeg 250 eenheden- kunt opsparen.
• In alle deelsystemen van een tank kan per "beurt" maximaal de zelfde energie geperst worden als in de complete buffer (dus ook 250 eenheden).
• Komt er meer dan 250 eenheden energie in de buffer dan ontpof je (alle 250+ eenheden worden omgezet in spash damage voor de andere tanks in de buurt).

Dit betekent in de praktijk dat je bewuste keuzes moet maken wat betreft je energiehuishouding, je kunt bv. besluiten constant alle 50 eenheden per "beurt" in je aandrijving te stoppen, je kunt echter ook (max. 0.5 seconden) helemaal niks doen en zo energie opsparen om een sprintje te trekken met 5x de maximum kruissnelheid (of voor het plaatsen van een schot met een enorme explosieve kracht).

Hoe die energieverhoudingen precies getuned gaat worden moet ik nog uittesten, in het vorige topic heb ik voorlopige waardes gepost.

edit:
Voor de duidelijkheid: je mag elk commando 1x uitvoeren per "beurt", alle commando's die je per beurt opgeeft worden tegelijk uitgevoerd en wel bij het ingaan van de volgende beurt. Elke beurt duur even lang, 0.1 seconden. Maw. alle tanks bewegen als het ware synchroon en geen enkele tank heeft voordeel tov een andere tank door de volgorde waarop de tanks in een beurt worden afgehandeld.

[ Voor 22% gewijzigd door Verwijderd op 27-01-2005 21:03 ]

[.Johnny]

wat is er eigenlijk mis met een handgestuurde bot? als iemand dat lukt is dat volgens mij al knap zat? (zul je in elk geval de interface moeten bouwen, en dan nog: die preciezie van een beetje ai bot wordt letterlijk killing in zo'n game natuurlijk)

[.oisyn]

Dit is een Programming & Webscripting contest, geen Spielerij contest, dát is er mis mee

mietje: leuk systeem, heb je tenminste ook nog wat anders om rekening mee te houden dan alleen het speelveld
Wat voor informatie krijg je eigenlijk door? Gewoon de posities van alle spelers? Of ook nog dingen als health en energieniveau en kogels en mijnen? En als je niet alles doorstuurt, support je dan nog wel een protocol voor een viewer die wel alle informatie kan krijgen? Het lijkt mij namelijk wel leuk om het in 3D te visualiseren

[ Voor 75% gewijzigd door .oisyn op 27-01-2005 21:38 ]

[mocean]

Leuke contest!

Paar vraagjes / ideetjes
1) Zorgt een energie ervoor dat een kogel een bepaalde afstand gaat afleggen?
2) Vliegt een kogel een paar ticks, of is ie gelijk bij t slachtoffer?
3) Hoe krijg je een speelveld terug; enkel tanks & posities, of ook kogels, snelheden, richtingen?
4) Krijg je een schaderapport van je tank?
5) Zie je hoe zwak een ander is, of wat zijn energie is?

Ben benieuwd...

[Verwijderd]

Je zult een tijdlimiet op elke beurt moeten zetten. Anders krijg je een situatie waarin je alle mogelijke uitkomsten van een battle gaat proberen te bepalen, wat uiteraard veel rekenwerk met zich meebrengt. Zo'n strategie moet niet toe te passen zijn lijkt me.

[H!GHGuY]

Voutloos schreef op donderdag 27 januari 2005 @ 20:40:
Hangt van het protocol af, of je naast het instellen van de kracht van de acties dus ook de volgorde kan opgeven. Zal voor het zien van de gevechten een stuk spectaculairder zijn en is denk wel goed te maken voor de server.

Maar dan moet wel gegeven zijn wat er gebeurt als bot 1 schiet en rijdt en bot 2 eerst rijdt en dan schiet: gebeurt het rijden van bot 2 dan voor of na het schieten van bot 1?

dat bedoelde ik met substappen ofwel ticks zoals anderen mij hierboven al voorzegden.

maar ik bedenk net dat je het daardoor wel moeilijk maakt om iets te raken. Dus mss toch laten varen en gewoon 1 beurt is 1 actie.

[MLM]

Al met al een zeer goed idee.
Ik ben ook zeer een fan van een viewer waarin je alles kan zien, met ondersteuning voor tekst vanaf de bots, zodat je kan "debuggen" door de beslissingen na te gaan van de bot.

[Verwijderd]

Ok, meer vragen, meer antwoorden.

.oisyn schreef op donderdag 27 januari 2005 @ 21:27:
Wat voor informatie krijg je eigenlijk door? Gewoon de posities van alle spelers? Of ook nog dingen als health en energieniveau en kogels en mijnen? En als je niet alles doorstuurt, support je dan nog wel een protocol voor een viewer die wel alle informatie kan krijgen? Het lijkt mij namelijk wel leuk om het in 3D te visualiseren

De informatie die je doorkrijgt is afhankelijk van de energie die je in je radarscan steekt, hoe meer energie hoe groter de radius van je radarscan Op zo'n radarscan zie je de positie van kogels en tanks, een (willekeurig) id voor elke tank (zodat je je op een vijand kunt richten en die achtervolgen) en de hoeveelheid energie die een tank in zijn schilden gestopt heeft (schilden weren splash- en crash-damage af, zonder schilden ontplof je als je geraakt wordt). Je krijgt dus geen richting of snelheid van objecten door, die mag je zelf berekenen uit de resultaten van twee scans.

Een "observer mode" waarbij je de complete gamestate doorkrijgt moet makkelijk te realiseren zijn (en de opzet is 2D, er zijn geen hoogteverschillen)

mocean schreef op donderdag 27 januari 2005 @ 21:30:
Paar vraagjes / ideetjes
1) Zorgt een energie ervoor dat een kogel een bepaalde afstand gaat afleggen?
2) Vliegt een kogel een paar ticks, of is ie gelijk bij t slachtoffer?
3) Hoe krijg je een speelveld terug; enkel tanks & posities, of ook kogels, snelheden, richtingen?
4) Krijg je een schaderapport van je tank?
5) Zie je hoe zwak een ander is, of wat zijn energie is?

1) Bij het schieten heb je twee energiewaardes, een voor de afstand die het schot moet afleggen en een voor de explosieve lading -hoe zwaar het schot ontploft als het de gewenste afstand heeft afgelegd.
2) Zoals het nu is ingesteld vliegt een kogel 10x zo snel als de maximumsnelheid van een tank (dat kan nog veranderen)
3 & 5) Zie boven.
4) Ja, je krijgt voor het begin van een beurt door hoeveel energie er in je accu en in je schilden zit.

Verwijderd schreef op donderdag 27 januari 2005 @ 21:37:
Je zult een tijdlimiet op elke beurt moeten zetten. Anders krijg je een situatie waarin je alle mogelijke uitkomsten van een battle gaat proberen te bepalen, wat uiteraard veel rekenwerk met zich meebrengt. Zo'n strategie moet niet toe te passen zijn lijkt me.

Je hebt 0.1 seconden per beurt de tijd om de hele battle te brute-forcen

HIGHGuY schreef op vrijdag 28 januari 2005 @ 10:41:
dat bedoelde ik met substappen ofwel ticks zoals anderen mij hierboven al voorzegden.

maar ik bedenk net dat je het daardoor wel moeilijk maakt om iets te raken. Dus mss toch laten varen en gewoon 1 beurt is 1 actie.

Je kunt elke mogelijke actie (rijden, schieten, schilden, radarscan) 1x doen per beurt, anders krijg je problemen; versimpeld voorgesteld: beurt 1 doe je een radarscan en ziet een doel, beurt 2 rijd je er heen, beurt 3 doe je weer een radarscan en je ziet dat je elkaar bent voorbijgereden... dat maakt het pas moeilijk om iets te raken

[.oisyn]

Verwijderd schreef op vrijdag 28 januari 2005 @ 11:34:
(en de opzet is 2D, er zijn geen hoogteverschillen)

Dat leek me idd duidelijk, maar dat neemt niet weg dat een 3D visualisatie niet realiseerbaar is

[Verwijderd]

Het is wel leuk dat het spelconcept uitgebreid is, maar wordt het niet een beetje te ingewikkeld op deze manier? Ik bedoel, ik denk dat ik met al die opties en caveats al moeite zou hebben als mens te spelen, laat staan een bot te programmeren die het speelt.

Kunnen we niet beter met een eenvoudig concept beginnen en het uitbreiden met meer opties als blijkt dat de robots het eenvoudige spel goed beheersen? Ik ben namelijk bang dat we anders straks allemaal kleine spastjes gaan krijgen die van het hele spel niks bakken...

[MLM]

Komt er een (al dan niet verplichte) "interface" die je moet gebruiken?
Iets als een socketimplementatie?
Is het de bedoeling als je een opdracht krijgt van de server dat je dan pas mag beginnen met berekenen? Of mag je ook een extra thread gooien om je CPU fullpower te gebruiken (tussentijds de opdrachten)?

Hoe "schiet" je eigenlijk?
Maakt je kogel een parabool? Of gaat hij horizontaal totdat hij een tank raakt?
Dus stel: tanken A, B en C staan op een rij (in die volgorde), en tank A schiet op tank C, raakt hij dan tank B?

[ Voor 28% gewijzigd door MLM op 28-01-2005 11:52 ]

[Verwijderd]

Bouw het in Unreal Tournament C .

[Creepy]

MLM schreef op vrijdag 28 januari 2005 @ 11:49:
Hoe "schiet" je eigenlijk?
Maakt je kogel een parabool? Of gaat hij horizontaal totdat hij een tank raakt?
Dus stel: tanken A, B en C staan op een rij (in die volgorde), en tank A schiet op tank C, raakt hij dan tank B?

Het is 2d, wat denk je zelf?
Ik denk dat als dit in 3d uitgevoerd zou worden dat de meesten wel zullen afhaken. In 2d is iets als dit erg goed te maken. Maar in 3d wordt het al een heel ander verhaal

[Woy]

MLM schreef op vrijdag 28 januari 2005 @ 11:49:
Komt er een (al dan niet verplichte) "interface" die je moet gebruiken?
Iets als een socketimplementatie?
Is het de bedoeling als je een opdracht krijgt van de server dat je dan pas mag beginnen met berekenen? Of mag je ook een extra thread gooien om je CPU fullpower te gebruiken (tussentijds de opdrachten)?

Hoe "schiet" je eigenlijk?
Maakt je kogel een parabool? Of gaat hij horizontaal totdat hij een tank raakt?
Dus stel: tanken A, B en C staan op een rij (in die volgorde), en tank A schiet op tank C, raakt hij dan tank B?

Het wordt idd gewoon een socket implementatie, want dan kan elke taal die tcp/ip ondersteund meedoen.

En het lijkt mij dat je mag doen met threads wat je maar wilt, je mag per tick ( 0,1 seconden ) toch maar een keer opdrachten doorsturen, dus het is niet zo dat als je computer sneller kan rekenen dat je opeens ook sneller kan bewegen ofzo. Het enige voordeel van een snellere computer is dat je meer mogenlijkheden door kunt rekenen.

[Verwijderd]

Ik snap het hele opzet nog niet volledig, maar ik heb wel interesse, alleen weet ik nog niet goed in welk taal ik zou meedoen
En afhankelijk van wanneer de contest zal plaats vinden (heb namelijk een druk semester dat me opwacht.) Maar ik ga deze thread in het oog houden.
Het opzet lijkt me super leuk om te programmeren.

[MLM]

rwb schreef op vrijdag 28 januari 2005 @ 12:02:
[...]

Het wordt idd gewoon een socket implementatie, want dan kan elke taal die tcp/ip ondersteund meedoen.

Mja dat begrijp ik, maar worden daar verplichtingen aan gesteld?

En het lijkt mij dat je mag doen met threads wat je maar wilt, je mag per tick ( 0,1 seconden ) toch maar een keer opdrachten doorsturen,

Jeej

dus het is niet zo dat als je computer sneller kan rekenen dat je opeens ook sneller kan bewegen ofzo. Het enige voordeel van een snellere computer is dat je meer mogenlijkheden door kunt rekenen.

Dus: hoe sneller = hoe beter, want meer mogelijkheden is beter "inzicht"
Het is best mogelijk dat een P4 van een P2 wint op deze manier

[Woy]

MLM schreef op vrijdag 28 januari 2005 @ 12:18:
[...]

Mja dat begrijp ik, maar worden daar verplichtingen aan gesteld?

[/qoute]

Ja je moet je aan het protocol houden, daar is een protocol natuurlijk voor

[qoute]
Dus: hoe sneller = hoe beter, want meer mogelijkheden is beter "inzicht"
Het is best mogelijk dat een P4 van een P2 wint op deze manier

Dat zou idd kunnen. Maar ik denk dat de strategie die je kiest belangrijker is dan de snelheid van je computer.

[Verwijderd]

rwb schreef op vrijdag 28 januari 2005 @ 12:31:
[...]

Dat zou idd kunnen. Maar ik denk dat de strategie die je kiest belangrijker is dan de snelheid van je computer.

Op een P4 kan je meer clients naast elkaar draaien dan op een P2. Met gelijke strategie zal de P4 beter scoren. Zeker als de clients in team-verband opereren.

[Verwijderd]

Dat is onzin. Ten eerste is het specifiek niet de bedoeling om samen te werken. Ten tweede zal een P4 bij gelijke strategie alleen maar eerder klaar zijn dan een P2 (en dus geen betere resultaten halen!), maar aangezien het toch turn-based is, maakt dat geen zak uit.

[Gerco]

Even over die 0.1 seconde. Is dat 0.1 seconden echte tijd?

Ik voorzie namelijk wel een paar problemen met mensen op slome verbindingen en dergelijke. 100ms is niet veel over een netwerk waar je ook nogeens minimaal de helft aan latency kwijtbent.

Dit geldt uiteraard alleen voor battles over internet, maar het lijkt me dat het uiteindelijke toernooi dat wel moet gaan worden, of iemand moet 10pcs met verschillende OSsen en een shitload aan dev omgevingen hebben rondslingeren

[Verwijderd]

Klinkt erg leuk en ik ga ook zeker meedoen.

Alleen ben ik wel bang voor de moeilijkheidsgraad kwa de wiskunde die hier bij komt kijken.
Dit was ook mijn grootste probleem bij de eerder genoemde Java botwar ding van IBM.

Hou het dus zeker in de gaten

[Verwijderd]

Verwijderd schreef op vrijdag 28 januari 2005 @ 12:55:

Alleen ben ik wel bang voor de moeilijkheidsgraad kwa de wiskunde die hier bij komt kijken.
Dit was ook mijn grootste probleem bij de eerder genoemde Java botwar ding van IBM.

Zoveel wiskunde komt hier toch niet bij te kijken, op het eerste zicht lijken het gewoon simpele berekeningen te zijn. We gaan hier geen AI van hoogstaand niveau maken he... (als ik meedoe, ga ik dat toch zeker niet doen.)

[H!GHGuY]

hmm
ik zou op een radarscan toch wel snelheden meegeven hoor. ofwel moet een schot direct-impact zijn. maw geen snelheid geven aan kogels maar gewoon een lijn trekken en als er iets staat dan raakt het diezelfde beurt.
want als je 2 opeenvolgende beurten zo'n scan zou doen dan heb je wel de posities en snelheden van schoten, maar aangezien iedereen in gelijk welke richting kan rijden tijdens een beurt kan je eigenlijk nooit een positie bepalen. en wanneer je dan wil knallen, is de kans dat je ook maar IETS meehebt vrij klein.

het zou nl heel makkelijk te programmeren zijn dat als je tank rijdt, en hij ziet op z'n radar ook maar 1 kogel dat hij direct 90° koers veranderd en nooit geraakt wordt.

[MLM]

HIGHGuY schreef op vrijdag 28 januari 2005 @ 13:20:
het zou nl heel makkelijk te programmeren zijn dat als je tank rijdt, en hij ziet op z'n radar ook maar 1 kogel dat hij direct 90° koers veranderd en nooit geraakt wordt.

Dat was mijn idee

[OZ-Gump]

Anderen kunnen daar dan weer op reageren door standaard naast de tank te schieten wanneer ze zulk gedrag zien. Het plaatsen van een krachtiger schot (qua ontploffing) heeft ook schade als gevolg, dus ik denk dat dat wel meevalt...

Aan de andere kant: als je alleen maar aan het ontwijken bent zul je ook niet snel winnen...

[Verwijderd]

het zou nl heel makkelijk te programmeren zijn dat als je tank rijdt, en hij ziet op z'n radar ook maar 1 kogel dat hij direct 90° koers veranderd en nooit geraakt wordt.

Ik denk dat dat wel mee zal vallen. Een kogel gaat zoals het er nu uitziet namelijk 10x zo snel als een tank maximaal kan gaan. Angezien kogels ook splash damage geven, is het toch vrij lastig (zo niet ongmogelijk) om helemaal verschoond te blijven van schade.

[ Voor 27% gewijzigd door Verwijderd op 28-01-2005 13:29 ]

[Voutloos]

Dit is gewoon een van de mogelijke tactieken. Daar moet je geen probleem van maken, maar de tactiek gewoon voor jezelf houden.

Bewijs maar als de wedstrijd bezig is dat je een goede tactiek hebt.

Richting kan je gewoon afleiden als je 2 meetpunten hebt. Bij 1 meetpunt niet, dus moet je een beurt wachten. Dat geldt ook voor je tegenstander, tenzij ehij middels een grotere radarscan je al eerder gezien had. Maar dat is weer zijn tactiek. Richting niet kant en klaar aan elke client uitreiken maakt het qua implementatie gewoon interessanter.

Laten we gewoon rustig het protocol afwachten.

[Verwijderd]

Ik blijf bij een UT2004 mod. Alles zit er al in. Tanks, kogels, server, stats, fysice, collision detection, programmeerbaar. Maak een map met 1 vlakke kamer en 't is 2-D .

[FendtVario]

Zoals je waarschijnlijk gelezen hebt is het leuke van socketimplementatie juist dat alle talen mee kunnen doen. Ik vind dat een groot voordeel. UT is een leuk spelletje maar om nu even met UT-c een bot te maken Daardoor zullen een hele berg potentiele spelers afvallen.

[MLM]

Verwijderd schreef op vrijdag 28 januari 2005 @ 13:28:
[...]


Ik denk dat dat wel mee zal vallen. Een kogel gaat zoals het er nu uitziet namelijk 10x zo snel als een tank maximaal kan gaan. Angezien kogels ook splash damage geven, is het toch vrij lastig (zo niet ongmogelijk) om helemaal verschoond te blijven van schade.

Maar als je maar net ver genoeg weg rijdt dat de kogel je mist, dan ontploft hij toch niet maar vliegt hij verder? Of kun je als je een kogel schiet opgeven dat hij na x meters moet ontploffen?

[OZ-Gump]

Of kun je als je een kogel schiet opgeven dat hij na x meters moet ontploffen?

Dat is inderdaad het geval! Je geeft aan hoe ver hij moet vliegen en met welke kracht hij ontploft. En dat gebeurt, of er nu iets in de buurt is of niet. Vandaar dat je met een dergelijke methode dus toch altijd schade oploopt.

[Verwijderd]

OZ-Gump schreef op vrijdag 28 januari 2005 @ 14:58:
[...]
Dat is inderdaad het geval! Je geeft aan hoe ver hij moet vliegen en met welke kracht hij ontploft. En dat gebeurt, of er nu iets in de buurt is of niet. Vandaar dat je met een dergelijke methode dus toch altijd schade oploopt.

Niet perse nodig. Als de vijand bewegelijker is dan verwacht mis je 'm alsnog. Of wat als de vijand op de inkomende projectielen schiet ?

[Mithrandir]

Verwijderd schreef op vrijdag 28 januari 2005 @ 15:30:
[...]


Niet perse nodig. Als de vijand bewegelijker is dan verwacht mis je 'm alsnog. Of wat als de vijand op de inkomende projectielen schiet ?

Dat ligt dus aan hoe hard je de ontploffing hebt staan. Of de vijand het interessant vind om het inkomende projectiel tegen te houden door een raket? Ik denk het niet, maar dat is natuurlijk voor iedereen zelf uit te zoeken.

[Verwijderd]

Verwijderd schreef op vrijdag 28 januari 2005 @ 15:30:
[...]

Of wat als de vijand op de inkomende projectielen schiet ?

Dat was dacht ik niet mogelijk.