Projektrapport EDA095 Grupp 8 Fredrik Stål, dt08fs5@student.lth.se Per-Gustaf Stenberg, dt08ps5@student.lth.se Mattias Frisk, dt08mf3@student.lth.se Joakim Hembrink, dt08jh8@student.lth.se 16 maj 2012
1 Bakgrund Projektet i kursen nätverksprogrammering avser att utveckla ett program som på något vis ska vara möjligt att användas över ett nätverk. Programmet ska använda sig av protokoll samt funktioner i javabiblioteket som tas upp under kursens gång. Projektet utförs i gruppvis, fem deltagare i vårt fall, och kan påbörjas redan vid första läsveckan. Förutom ett implementerat program finns det en del ytterligare leverabler i projektet. Först ska det skrivas en beskrivning av det tänkta projektet och i slutändan ska det även göras en hemsida där programmet ska finnas tillgängligt för nerladdning samt den här rapporten. 2 Kravspecifikation 2.0.1 Server R1 En server upprättas i spelet av en klient. Endast en klient kan sedan ansluta sig varpå de två spelarna kommunicerar i full duplex. R2 Den klient som upprättat servern agerar som värd. R3 Endast värden skall kunna skicka kommandon till sin egen server. R4 Varje instans av ett spel består av en serverinstans. 2.0.2 Klient R5 Spelet skall ha ett grafiskt användargränssnitt. R6 Då en klient väljer att starta en server skapas en ServerSocket som väntar på anslutning. R7 En klient ansluter sig till servern genom att ange en IP-address. R8 Nerkoppling eller eventuella avbrott av en server skall tas om hand. R9 Kommandon skickas och tas emot via ett terminalfönster. 2.0.3 Spelfunktioner R10 Kontroll av en spelares position. R10 En spelare vinner när den når målet. R11 Ett spel sker i realtid. 3 Modell Det mesta utav klasserna i vårt projekt representerar samt står för den grafiska vyn och även användargränssnittet. Eftersom projektuppgiften och även kursen, syftar till att utveckla program som upprättar anslutningar och bibehålla kommunikation över nätverk kommer dessa klasser att beskrivas i mindre detalj i den här rapporten. 1
Mjukvaruprojektet är uppdelat i olika paket, vardera paket består av klasser ämnade för ett specifikt mål. För en bättre beskrivning, finns det ett paket vid namn gui. Detta paket innehåller klasser för att representera det grafiska användargränssnittet och består även av lyssnare till en användares tangentbord. 3.1 game Paketet game består av klasser som representerar ett pågående spel, bortsett från nätverkskommunikationen samt användargränssnittet. En kort beskrivning av paketets klasser som tas upp i den här rapporten kas ses i figur 1. Figur 1: Huvudklasserna för ett spel. 3.2 gamestates Detta paket tar hand om all rendering och mycket av spellogiken. Varje klass tar hand om vad som ska renderas när den är det aktiva tillståndet. När man programmet startas så körs MenuState-tillståndet först. 3.3 gui Klasserna i det här paketet representerar alla knappar och textfält. Klasserna registrerar och behandlar input från användaren. 3.4 main main-paketen tar hand om uppstart av programmet och även uppstarten för nätverkskommunikationen mellan server och klient. Kort beskrivning av vad klasserna utför kan ses i figur 2. 2
Figur 2: Klasserna i main-paketet. 3.5 network Network-paketet tar hand om all nätverkslogik i programmet. I paketet finns bland annat klasser för olika nätverkspaket som programmet kan skicka. Kort beskrivning för nätverkspaketklasserna kan ses i figur 3. När spelet är igång körs det två separata trådar som tar hand om inkommande respektive utkommande nätverkspaket, dessa kan ses i figur 4. Figur 3: Gränssnitt för nätverkspaketen. 3
Figur 4: Kommunikationstrådarna. 3.6 Interaktion Nätverkskommunikationen i spelet sköts av en inputtråd och en outputtråd. Båda dessa trådar använder sig av samma monitor för att skriva eller hämta nätverkspaket. Själva spelet hämtar också paket ifrån denna monitor. Exempel på när man skickar respektive läser ett nätverkspaket kan ses i figur 5 och 6. Synkroniseringsmetoden är alltså busywait. Nätverkspaketen skickas och hämtas genom serialisering. Figur 5: Skicka paket över en ström. De två trådarna har även tillgång till en ström av objekt. Inputtråden läser paket-objekt från strömmen och skickar de vidare till sin monitor. Outputtråden gör samma procedur åt andra hållet. 4
4 Användarhandledning Figur 6: Ta emot paket över en ström. Att starta programmet är en relativt simpel procedur. Det görs genom att dubbelklicka på Spelet.jar. Det är ej nödvändigt att starta något ytterligare program ifall man som användare önskar att vara värd för ett spel. När spelet har startats upp visas en huvudmeny med diverse menyval. Dessa menyval finns beskrivna i efterföljande underrubriker, bortsett från Exit game, som enbart har funktionen av avsluta spelet. 4.1 Navigering Det första som behöver poängteras är att det inte är möjligt att välja menyval genom att försöka använda en datormus. Navigering i samtliga menyer gör istället via piltangenterna på tangentbordet. För att välja ett menyval trycker man på retur. I vissa lägen är det även möjligt att använda escape för att avsluta eller backa. 4.2 Starta som värd Genom att välja menyvalet Host Game från huvudmenyn skickas användaren vidare till en meny för att välja spelbana. Eter det att en bana valts bytas bilden ännu en gång och nu kommer spelet att vänta på att en annan spelare ansluter sig. I det här läget är det möjligt att via escape återgå till huvudmenyn. 4.3 Ansluta till värd Ifall en användare istället väljer Join Game från huvudmenyn bytas skärmbilden till ett inmatningsfält där en användare kan ange värdnamnet till den värd man vill ansluta sig till. Inmatningen görs genom att enbart trycka på bokstävstangenter och tas emot efter ett tryck på retur. Vad som är nämnvärt är att värdnamnet kan antingen vara det namn på maskinen eller datorn värden startat ifrån eller en IPv4-address till värden. 5
4.4 Inställningar I läget Settings i huvudmenyn är det möjligt för användaren växla till helskärm. Det görs genom enkelt genom att navigera till Toggle fullscreen och sedan trycka på retur. Genom menyvalet Back återgår man till huvudmenyn. En konfigurationsfil kommer att sparas ner på hårddisken. Denna fil kommer att, vid nästa uppstart av spelet, att läsas in och valet av senaste inställningar kommer gälla. 5 Utvärdering Vi tycker att det har gått bra med vårt spel. Vi hade gärna önskat lägga till mer funktionalitet men i brist av tid var det inte möjligt. Minst av tid behövdes för att få rätt på samt göra färdigt nätverkskoden. Bortsett från kraven som beskriver att det går att skicka kommandon över strömmen, uppfylldes samtliga. Anledningen till varför de inte implementerades var p.g.a. vi gick från att skicka kommandon över strömmen till att enbart skicka en spelares position och hastighet. Vi har en bra del av tankar på hur spelet skulle kunna utökas, möjlighet till att spela in ett demo, rörliga hinder och mer än enbart två spelare som exempel. Vi känner att det är rätt svårt, som så mycket när det gäller mjukvara, att estimera den tid som skulle behövas för att införa dessa utökningar. Vi tycker det är bra att det var så pass mycket frihet i valet om projekt och anser att det bör behållas. Vi anser också att det kan tänkas onödigt med de extra leverablerna i slutet av kursen, speciellt skapandet av en hemsida. Anledningen till vårt anseende är att det kan existera kursdeltagare som har liten erfarenhet i att utforma hemsidor och kan då ge en onödig belastning på projektarbetet. Det kan tänkas vara tillräckligt att utveckla programmet för att sedan hålla en redovisning av programmet och funktionalitet för sin projekthandledare. 6 Programlistor Programmet kan hittas på hemsidan för spelet, http://brinkex.com/speletspelet eller direkt på http://brinkex.com/speletspelet/spelet-spelet-source.zip 6