Möte 8/3 -07

Närvarande: Alla

Sista vecka med design som uppgift, ska vara klart imorgon fredag. Vad var och en ska göra tills ikväll:

Joel: Flowchart över skepp som skjuter (game-design), Sätta ihop det till en fil
Andreas: Spel/fysik motor, frekvensdiagram
Joakim: Grafik (system-design), Klassdiagram, Sekvensdiagram. Ändra om flowchart om kontrollera skepp till
Flavius: Gamedesign doc, Rita nya interfaces
Danwei: Grafik (game-design)
David: Ändra om flowchart om skepp träffad till riktig UML, Missagreement flowchart (system-design) och även annat om nätverk

Varit lite problematiskt att synca och få arbetet att flyta nu i ett par veckor pga massinsjukningar, förhoppningsvis tillfrisknas det.

Temporärt bestämt slut-möte imorgon vid 13

Möte 5/3 - 07

Närvarande: David, Joel (Danwei, Andreas var sjuka?)

Diskuterade lite olika lösningar på hur nätverket och spelmotorn behöver kommunicera och hur man löser vissa problem.

Vad skickas från fysikmotorn ut till de andra peersen?
Endast information om det egna skeppet, ett paket bör innehålla följande:

• Skeppets rörelse, Kordinater för pos, Vridningsgrad (vart den pekar), Fart-vektor (vart den är på väg och i vilken hastighet)
• Info om skepp träffat: Vilket skott träffade?
• Info om skeppets avfyrade skott: Positioner och vektorer för dessa, (minor, skott, etc)
• Info om skepp lever: Om skeppet sprängdes pga skott eller kollision med kropp eller är intakt

Dead reckoning:

• Om en peer ej har fått ny info från en annan peer använder dess fysikmotor den gamla infon för att uppdatera dess skepp
• Kommer ny info hoppar skepp till denna möjliga nya position (då vi tidigare har förutsatt att vi inte tar hänsyn till extrem latency är detta ej ett problem)
  

När man skjuter:

• Även om ens skott ser ut att träffa så flyger de igenom fiendens skepp tills man får registrerad träff (vilket bör gå på nolltid)
• Skulle man träffa med dessa skott som flög igenom
  

Flyga in i planeter:

• I och med dead reckoning är det samma här, andras skepp ser ut att flyga igenom tills konfirmation (bättre än att de ska sprängas för att sedan dyka upp nån annanstans)

Vad händer vid uppdateringar?

• Fysikmotorn uppdaterar info (från andras skepp och objekts positioner med spelarens möjliga aktion, vektor och skott kan ändras etc)
• Skickar ny info till grafikmotor
• Skickar till alla Peers i sin region/grupp (RegionPeers)

Uppdatering i nätverk

• Alla RegionPeers skickar till varandra
• ChefRegionPeerern skickar till de närliggande ChefRegionPeerserns
• De närliggande ChefRegionPeerserns skickar till sina RegionPeers

En anser träff, en annan anser miss:
Då det ej är full (eller möjligtivs ingen) direkt synkronisering utan alla försöker köra i ett visst uppdateringsintervall och går det så går det så infördes dead reckoning. Dock så innebär detta exempelvis att ett skepp kan anse att den träffar medans motståndaren anser sig vara någon helt annanstans. Då vi som tidigare inte bekymrar oss särskilt om latency så blir det i så fall synd om den stackarn som har slött nät då ett majoritetsbeslut kommer inträffa på följande vis:

• Om bägge spelare inblandade är överens om träff, inget särskilt behövs, alla glada och nöjda
• Om missnöjda så när ChefRegionPeerern får info om detta skickar den en förfrågan till alla i regionen om vilken de har (om det exempelvis är endast en extrem flaskhals blir han ensam, har han vissa nära sig så blir de några osv men förhoppningsvis löser detta det okej).
• Denne skickar sedan ut majoritetsbeslutet och de som ansåg annorlunda får därmed ändra sig
• Om ChefRegionpeerern tidigare skickade ut annan info till närliggande regioner får detta skickas om

TILL TORSDAG:
Andreas: Klassdiagram, Tech-spec
Flavius: Game design Doc (det som är kvar)
Danwei: Sekvensdiagram (några stycken, om texten här ovan och om grafik-fysik-spelmotor)
Joakim: Sekvensdiagram (med Danwei)
Joel: Fysikmotor, halv-pseudo
David: Flowcharts som ej är klara, sätta ihop

Möte 1/3 - 07

Närvarande: David, Joakim, Andreas, Flavius, Joel

Saknades en hel del till game design doc, bland annat beroende på att Flavius hårddisk hade slutat fungera.

Diskuterades en del hur P2P och dess regioner ska fungera (ska det finnas en över-chef som känner till alla region-chefer?) och ska grafikmotor kommunicera tillsammans med fysikmotorn? Andreas och David ska diskutera P2P och studera exempelvis JXTA för att få lite svar.

Nästa vecka behövs det sättas igång med System design doc, tills dess ska några till flow-charts ha gjorts (i fake-uml) för game design doc.
Styra skepp - Joakim
Skepp skjuter - Andreas
Den överliggande - David

Möte 26/2

Närvarande: David, Andreas, Joakim

Möten måndagar: Tid flyttad till 17.00 då detta passar alla

Game design dokument i stort sett klart torsdag, allas delar ska skickas in i gott skick senast 16.00 onsdag, jag sätter sedan ihop det och skickar ut senast 21.00 och sedan ska det ha lästs igenom innan mötet.

På torsdag kommer det börjas på system design doc, deadline nästa fredag (tillsammans med game design doc)

Möte 22/2-2007

Vi fick synpunkter och feedback på planeringsrapporten. Överlag bra! Enda synpunkten var att det var svårt att få en överblick hur dom olika kraven prioriterade.

Vi bestämde att två stycken designdokument ska tas fram. Game Design Specification och System Design Specification. Deadline för dessa är om 2v.

Arbetsfördelning tills nästa möte:
Vision Statement + Concept Art
Joakim

Marketing Information
-Inluderas Ej

Legal Analysis
-Inluderas Ej

Gameplay
-Flavve

Game characters + Concept Art + Övriga objekt
-Danwei

Story
-David

Game World
-Joel

Technical Spec.
-AK



Vart var ni andra?

Möte 2007-02-19

Vi har diskuterat interfacet, game-modes, skeppmodifikation och spelidén ytterligare.

Interface:
Innehåller:

1. En minimap som innefattar en begränsad radie kring spelaren.
2. Chat som även fungerar som kommando-konsoll.
3. Styrkemätare, energimätare och ändliga inventarier(missiler, minor etc.).
   

Skeppets sköld:
Skeppets sköld/energi laddas upp kontinuerligt.
Tre saker påverkar skölden negativt:

1. Fientlig eld
2. Nitro
3. När man skjuter
   

När sköldmätaren är tom tar skeppet skada av fientlig eld. Ev. kan olika delar skadas såsom vingarna, motorn, sköldgeneratorn (laddar upp skölden) eller kanonerna.

Gravitation:
Skepp, skott och missiler påverkas av gravitationsfält.
Objekt går att dela in i två grupper:

1. Med gravitationsfält:
   Planeter (fixa) och högdensitetsasteroider (rörliga)
   
2. Utan gravitationsfält:
   Vanliga asteroider, skepp, skräp etc.

Kolliderar ett skepp med en planet eller en asteroid så exploderar det alt. förlorar mkt. kraft.
Skepp skulle eventuellt kunna släppa gravitations-minor.

Ammunition:
Vanliga skott är en oändlig resurs. Missiler och ev. minor är en ändlig resurs, som måste laddas på i en depå/spelarens bas.

Game-modes:

1. Capture the flag:
   Hämta motståndarlagets flagga och flyg den till hembasen ger ett poäng för laget.
   Då spelare dör spawnas nytt skepp i hembasen.
   En spelrunda har ett tidstak; när tiden är slut vinner laget med flest poäng.
2. Team deathmatch:
   Poäng ges till spelare för eliminering av fiendeskepp. Då spelare dör spawnas nytt skepp på godtycklig position.
   En spelrunda har ett tidstak; när tiden är slut adderas spelarnas poäng i vardera lag.
   Laget med flest poäng vinner.

Level editor:
En enkel level-editor med grafiskt gränssnitt bör implementeras.

Skeppmodifikation:
Till en början finns fördefinierade skepp med olika: topphastighet, acceleration, antal missiler/bomber, rotationshastighet, massa, sköld/energi och storlek.

Till på torsdag:
Flawe fixar PDF-dokument på design-mallar.
David gör en skiss på interface.
Alla kollar upp sina lediga tider så vi kan stämma en ny tid för måndagsmötet.

Arbetsfördelning Planeringsrapport

Arbetsfördelning:

Andreas:
Skriva kravspec, prioritera krav.

Joakim:
Krav på grafik
Skriva om beskrivning av iterationerna
Fixa datum i ganttschema.
Fixa så att vi har en flik för gemensamma aktiviteter.

David:
Omstrukturering av dokumentet
Maila Staffan
Detaljera problem/uppgift för nätverk.

Flavve:
* Krav på fysik
* Vad finns i en spelmotor

Joel:
Krav på spelmotor.

Danwei:
Skriva om konceptet och översätta det.




Vi använder Word och .doc