Research and Development 1/^Archief/2009-2010/07/Fase 1

• Property "Auteur1" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/07Gebruiker:Marco Jonkers" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur2" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/07Gebruiker:Stein Keijzers" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur3" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/07Gebruiker:Peter Maandag" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur4" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/07" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Presentatiedoel

Dat het publiek ziet dat ons product werkt.

Inhoud

• Samenvatting project -Marco
• Keuzes gamemechanics -Marco
• TCP/UDP keuze -Peter
• Demo -Stein
• Afsluiting, plannen voor 2de fase -Stein

Inleiding + korte samenvatting

Wij hebben als project dus een spel, gebaseerd op teamwork. Er zijn 2 teams van elk 3 spelers, elke speler heeft een specefiek doel. We hebben de manager van het team, die alles regelt, de aanvaller, die de vijand aanvalt, en de verdediger, die de basis verdedigt. Om ons project te versimpelen hebben we voor Turn-based strategy gekozen, dat is dus dat elk team een beurt krijgt waarin het dingen kan doen. Het hele spel wordt gemaakt in Java.

In de pilot hadden jullie al een klein beetje kennis gemaakt met ons spel, maar het prototype was nog niet af. In deze fase hebben wij ons prototype werkend gemaakt, Stein zal zometeen een demo laten zien, en we hebben voor onszelf uitgezocht wat de beste manier is om de netcode in fase 2 te implementeren, daarover zal Peter wat vertellen.

Gamemechanics

De gamemechanics hebben we al een eerste invulling gegeven. De combat en het puntensysteem zijn nog het meest voor verandering vatbaar.

Combat: We hebben voorlopig dat als twee legers elkaar tegenkomen, ze automatisch tot de dood vechten. De combat verloopt in rondes, elk leger valt 1 keer aan en dit herhaalt zich totdat een van de twee legers dood is. Als een leger meerdere vijandelijke legers tegenkomt, vecht hij ze allemaal achter elkaar. Per aanvalsronde concentreerd een leger zijn aanval op de sterkste eenheid in het vijandige leger, om deze zo snel mogelijk neer te krijgen. Een gebouw aanvallen verloopt op vergelijkbare wijze, met als verschil dat een gebouw vaak niet terug aanvalt en dus het leger vaak meteen wint. Als er verdedigingslegers in het gebouw gestationeerd zijn, dan valt het aanvallende leger eerst al die legers aan voordat hij aan het gebouw begint.

Puntensysteem: Omdat het spel turn-based is moest er een manier zijn om te bepalen wanneer een speler's beurt voorbij is. Dit hebben we op de (standaard) methode voor turn-based games gedaan, namelijk een systeem van punten per speler die afnemen als de speler acties onderneemt. Acties zoals het opvragen van informatie kosten weinig punten terwijl acties zoals een groot gebouw bouwen veel punten kost. De bepaling van kosten van iets is voorlopig best simpel, het is een percentage van de maximale punten afhankelijk van de kosten van het gebouw. Hier kan later nog iets toegevoegd worden zodat het meer kost om gebouwen verder van de basis af te bouwen.

TCP vs UDP

Een belangrijk punt voor ons spel was ook om het op meerdere computers te kunnen spelen. Om ons spel op meerdere computers te kunnen spelen, moeten we op één of andere manier informatie zien te verzenden en de computers laten communiceren. We hebben hierbij de keuze tussen twee internetprotocollen, TCP en UDP. Ik zal hier de voor- en nadelen van beide protocollen opnoemen en vertellen wat onze keuze is geworden.

UDP: het User Datagram Protocol is een low-level connectieloos protocol dat makkelijk te gebruiken is. UDP werkt met pakketjes data van een vaste grootte die verstuurd en ontvangen kunnen worden. In JAVA worden die Datagrams genoemd.

Hier een quote van de java-site: “ A datagram is an independent, self-contained message sent over the network whose arrival, arrival time, and content are not guaranteed. “ 1)

Dit maakt UDP een onbetrouwbaar protocol, maar het is wel makkelijk te gebruiken. Als je iets wil verzenden, verzend je het gewoon. Het is wel heel makkelijk om data te versturen of om te wachten op data die binnenkomt. Het enige wat je hoeft te doen is een new zogenaamd DatagramSocket object aanmaken en een DatagramPacket van een vaste grootte waarin je data kunt ontvangen of die je kunt verzenden. En dan kun je gewoon random data proberen te versturen naar welk ipadres je ook wil. Maar je hebt geen garantie dat het aankomt of dat het in z’n geheel goed aankomt, of als je meerdere pakketten tegelijk verstuurd dat ze in de goede volgorde aankomen. Verzenden lukt altijd, maar of het goed aankomt, dat is de vraag.

Met TCP werkt het anders. Via Het Transmission Control Protocol wordt een verbinding gemaakt tussen een server en een client. Hierdoor is dit een betrouwbaar protocol, maar ook minder efficient. Wat je verstuurt komt ook aan en ook in dezelfde volgorde, anders dan wordt er een exception gegooid. Het is ook moeilijker te implementeren.

Er is een duidelijk onderscheid tussen de server en de client. De server wordt gemaakt door een new serverSocket object aan te maken. Vervolgens kun je de blocking methode accept() aanroepen, die wacht tot er een client probeert te verbinden. Als er dan succesvol een verbinding gemaakt is, moet je de input en output streams van de clientsocket opvragen en dan kun je daar op schrijven. Met behulp van threads kan je de server laten wachten op meerdere binnenkomende connecties en tegelijk laten lezen en schrijven. De client probeert te verbinden met de server door een ander, normaal Socket object aan te maken (bij UDP wordt dezelfde soort socket gebruikt). En vervolgens wordt op dezelfde manier gecommuniceerd via input en output streams.

Voor ons spel is TCP zowieso een must. Belangrijke informatie voor het spel die verstuurd moet worden zijn de commandos die gegeven worden, de veranderingen in de map en wie er aan de beurt is. Er is niet zo veel informatie die verstuurd moeten worden, maar het is wel kritische informatie die niet verloren mag gaan. Ook willen we het snel weten als een speler het spel verlaat, dat is bij TCP makkelijk te achterhalen doordat de vaste verbinding verbroken wordt. Efficiency is bij ons ook niet zo’n probleem, omdat er relatief weinig data verstuurd moet worden. We moeten ook een server hebben die alle informatie doorstuurt aan alle clients en we moeten ook garantie hebben dat dat goed aankomt. Dus wij gaan onze netcode implementeren via dit protocol.

1) http://java.sun.com/docs/books/tutorial/networking/datagrams/index.html

Demo

Hier een demo van ons prototype. Het is dus nog maar een prototype, dus de user interface, gebruiksvriendelijkheid en uitleg zullen nog verbeterd worden.

Start .batje

De interface is dus grotendeels text-based. Bij het opstarten wordt er om de teamnamen en namen van de spelers gevraagd.

Invoer voorbeeldnamen: "Team1 Aanvaller1 Verdediger1 Manager1 Team2 Aanvaller2 Verdediger2 Manager2"

De Teams zijn dan gemaakt. Daarna vraagt het spel om een mapnaam en de folder waar deze map inzit.

Invoer mapinfo: "maps large"

Dan wordt de map geladen. Zoals je ziet verschijnt hij ook in een apart venster. Deze map wordt geupdate als dat nodig is, door het spel. Er staat ook dat de Manager van team 1 0 resources krijgt. We hebben gekozen om de Manager de grondstoffen van het team te laten beheren, en grondstoffen te geven aan teamleden als deze het nodig hebben, omdat dit teamwork promoot.

Het spel vraagt nu om een spelercommando. Omdat we nog helemaal geen gebouwen hebben, kunnen we het beste een Control center bouwen.

Invoer commando: "build controlcenter 20 2"

Er verschijnt nu een gebouw op de kaart. Er staat ook dat die speler al zijn punten heeft verbruikt, waar Marco het eerder over had.

De Verdediger is nu aan de beurt. Deze kan militaire gebouwen enz bouwen, en dat kunnen we wel gebruiken dus bouwen we een barracks.

Invoer commando: "build barracks 18 2"

Invoer commando: "status"

Zoals je kan zien heeft het bouwen van de barracks deze speler 25 punten gekost, en ook een aantal resources. We hebben de militaire activiteit om Legers gecentreerd, omdat dit makkelijker te gebruiken is dan afzonderlijke eenheden. Verdedigingslegers kunnen gebruikt worden om gebouwen te verdedigen. Dat hebben we nog niet meteen nodig, dus geven we de beurt maar aan de aanvaller van dit team. Deze kan misschien wel wat grondstoffen gebruiken, dus geven we onze extra aan hem.

Invoer commando: "team"

De aanvaller is dus "Aanvaller1".

Invoer commando: "pay Aanvaller1 500"

Nu geven we onze beurt door, aangezien we niets meer te doen hebben.

Invoer commando: "pass"

Nu is de Aanvaller van dit team aan de beurt. Nu kunnen we een aanvalsleger maken. Deze legers zijn belangrijk om de vijand aan te vallen.

Invoer commando: "army"

Nu is er dus een nieuw leger gecreerd, op de plek van het hoofdgebouw. Aangezien onze verdediger een Barracks had gebouwt, kunnen we die gebruiken om dit leger te vullen met wat eenheden. Gebouwen zijn dus per team, en niet per speler.

Invoer commando: "list my armies"

Het leger is dus nu nog leeg, wat je ziet aan de 0/100. Dat is de capaciteit. We kunnen even kijken naar de mogelijke eenheden die onze barracks kan bouwen.

Invoer commando: "list friendly buildings" Invoer commando: "info building 1"

Hier zie je alle stats van onze Barracks. De units die het kan produceren staan onderaan. Laten we 5 standaard eenheden naar ons leger trainen.

Invoer commando: "train 0 5 0"

Als we nu de info voor dit leger oproepen, zien we alle units die we hebben getrained.

Invoer commando: "info army 0"

Aangezien we niets meer hoeven te doen, kunnen we nu de beurt wel doorgeven.

Invoer commando: "pass"

Nu is dus het volgende team aan de beurt. Zij kunnen soortgelijke dingen doen, of juist iets heel anders. Dit was de demo.

Afsluiting

In de laatste fase gaan we de UI afmaken en de netcode implementeren en vooral ook heel veel testen. Vragen?