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: