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

Möte 15/2

Staffan tycker att vi har lite oklar frågeställning?
Vad vill vi uppnå? Vad tror vi resultatet kan vara vid slutet?

Kan lägga till:

Mellan purpose / assignment:
Vilka olika delar måste finnas med i en spelmotor.
* Referenser för enskilda bitar och helheten.

Vi måste göra alla dessa delar i en Spelprototyp för att visa på helheten.

Resultatet ska avspegla syftet.

Vad vi individuellt gör spelar mindre roll.


Referenser?
Bör vi ha, enhetligt format.

Kolon i rubriker, bort.

Raka högermarginaler?

Skicka ett mail till staffan för att fråga om fysik exjobbet.

Assignments/Difficulties:
* Referenser (kan vara för att utförligare beskriva tekniken)

Justera tidsplanen (datum?)

Direkt så har stavfel ingen påverkan men indirekt så ger det eventuellt en negativ helhetsbild.

Prioriteringslistor:
För varje del så skriv upp funktionella krav
Så många som möjligt
Säga vilka krav är absolut kritiska
Missnöjda med arbetet om dom här inte är med
Dom här borde vara med
Dom här hade vara trevligt om dom var med
Bonus funktioner...


(nätverk: Att en när en peer går ut så kan den broadcasta för att hitta andra peers).

Kravspec som bilaga till planeringsrapport

Sjunde punkten är deadline, borde speca vilken deadline. Deadline för group report?


Två olika sätt att jobba med iterationer:
Allt i varje iteration och bara förbättra i varje kommande iteration.
Andra är att bygga en kärna och sedan utöka den för varje kommande iteration.

Argumentera för det sättet vi valt och argumentera mot det andra sättet.

Sätta figuren (gantt-schemat) efter texten som beskriver den, figuren sammanfattar bra.

5.3 Constraints (Limitations)
underrubrik under 2
Många fler constraints

Staffan skulle sätta constraints kapitlet som ett underkapitel till Purpose.

Constraints på fysik väldigt oklar.

Säga mer vad vi inte tänker titta på när det gäller grafik.

Ingen användartestning, lägg in det i constraints.
Användargränssnitt, lägg in det i constraints. Bara så mycket så att vi själva kan testa.

Spelkoncept borde vara bilaga.


Tillägg:
* Begränsningar
* speldelar


SPELKONCEPT:
Vi har diskuterat att... Ta bort jag/Vi form.

RIMLIGHET:
Staffan tycker att arbetsinsatsen känns rimlig eftersom vi inte siktar på att utveckla Quake 10 :)

Titta på grupprapporterna på spelprojektskursen som ligger ute. Liknande förutsättningar som vi har.

12/2 -2007

How could a Game Engine with realistic physics work in a Peer-to-Peer Multiplayer environment?

Problem:
P2P-synchronize, regions.
* Support many users
* Can join a game at any time
* deadreckoning - fysik - mösimös

Java, limitations?

Game Engine:
* Hur får man datastrukturer att stödja dom olika regionerna.
* Hur ska realistisk fysik fungera i p2p.


Grafik:
* Partikelsystem
* Snyggt och inte lagga
* Vad kan göras lokalt och vad måste samordnas.

Avgränsningar:

Nätverk:
* Inget fokus på att lösa fusk/kryptering/osv...
* Inget fokus på speldesign.
* Ingen AI
* Programverifiering

Metod:
Simuleringar, Testningar,

Vi möts 13:00 på Onsdag.

Andreas/Flavve Introduktion
Andreas Bakgrund .5sida
Syfte David .5 sida
Metod/Genomförande Flavius .75 sida
Tidsplan Joakim 1 sida
Problem/Uppgift 1.5 sidor
Avgränsningar .5 sidor
Danwei Sy ihop Problem/Uppgift/Avgränsningar
Joel Sammanställa dokument (rödtråd)

Levereras Onsdag 08:00

Möte Torsdag 08:00 med staffan.

Möte 2007-02-08

Första mötet med staffan:
Deadline för planeringsrapport bestämdes till 16/2 kl 17:00.
Rapporten ska högst vara 5 sidor och innehålla, tidsplan - översikt över planeringen och arbetet fram till slutlig deadline samt arbetsuppdelning.

Rapporten ska i stora drag vara uppbyggd enligt följande:

1. Tanke, Plan
2. Metod
3. Analys (enl Staffan "varför blev det inte som vi tänkte oss")

Delmål:
Tidig version av rapport som kan granskas av annan grupp

Syfte och mål:

• nätverksbit
• grafik

Staffan sa: "Syfte: Göra ett ??___?? javaspel"
Vi ska fylla i resten på ett sådant sett att vårt gemensamma syfte och mål reflekterar samtligas personliga mål (i den mån detta går).


Efter att Staffan gått bestämdes att Flavius skulle skriva upp ett generellt spelkoncept till nästa möte. Nätverksgruppen klargjorde att nätverksdelen skulle lösas med Peer2Peer.


Vi nämnde även att vi skulle börja tänka på begränsningar inom varje område inför planeringsrapporten som ska vara inlämnad Fredagen den 16:e februari.

Möte 2007-02-07

Närvarande: Joel, Joakim, Flavius, Danwei

Vi delade in oss i följande grupper inför inlämningsuppgift 1:
Joakim & Joel: fördjupning inom spelmotor, grafik, datastrukturer
Danwei & Flavius: fördjupning inom fysikmotorn

Det diskuterades också om att utvidga fokuset på projektet, att tyngden inte enbart ska ligga på nätverksdelen. Mer om det senare.

Möte 2007-02-05

Sekreterare roterar mellan mötena.

PM Skapar agenda på Wikin innan mötet så alla kan komplettera.

Obligatorisk närvaro, annars särskilda skäl.

Försök att komma i tid ~10minuter "OK".

Alla delar upp sina uppgifter inom gruppen.

* Diskuterar problem med näteverk. P2P eller C/S.

Beslutsordning:
* PM har veto.

Sekreteraren ska posta mötesanteckningarna på bloggen efter mötet.

Hur ska vi dela upp arbtet?
Fys/Spelmotor?
Grafikmotor/2D.
Nätverk.


Projektrapport!

Vi måste stämma av med Staffan vad som förväntas av rapporten? Ska den vara teknisk eller mer inriktad på gruppdynamik/projektet i sig...


Alla läser igenom "Riktlinjer för genomförande och examination av kandidatarbetet på Chalmers" och funderar igenom Bilaga 3.

Någon tar kontakt med Staffan för att säkerställa att han är närvarande vid mötet på Torsdag mellan 08-10.

Alla måste ha ett google konto för att kunna rapportera in tiden i tidsloggen.

Möte 1/2

Vi diskuterara hur viktigt det är att komma i tid till möten och vi kommer

fram till att vi accepterar 10 min diff.

Vi diskuterar spelide:

- Spelidé:
Olika skepp ska kunna väljas med olika egenskaper.
Gravitation för skepp och skott tillsammans med begränsat bränsle.
Olika skepp (taktik). stora rör sig långsamt, små snabbt.
Lagspel mellan multiplayersarna.
Bränsleförbrukning kan vara en grej.
Om man dör så spawnar man eller så vinner det andra laget.
Capture the flag.
Sköldar

- Spelidé min
Fungerande grafik och fysik
flera spelare på samma bana.

- Spelgrupper
Grafik:
Joel, Danwei, Joakim

Fysik Ljud:
Flavve

Nätverk:
Daniel, Andreas?

- Teknik
Applet: Inte
Swing AVt

- Syfte, mål, avgränsningar:

Möte 01/29

Här är det jag skrev ner ifrån mötet.

Uppgifter som skall lösas:

1. CVS/SVN - Chalmers (Danwei?)
2. Blogg - Andreas
   
3. Wiki - Andreas
   
4. Mailinglista - David

Vi bestämde följande tider för möten:
Måndagar 15-
Torsdagar 08-10

Tills imorgon tisdag skall alla ha skickat förslag på tid för återkopplingen.

Ett förslag på spel som nämndes var
Subspace En nyare klient kallad Continuum kan tankas ner här.

/Andreas