
I. Vesmir - obecne
--------------------------------------------------------------------------------

Vesmir bude staticky, tj. hvezdy se nebudou bezne menit, bude je mozne jen pridavat, ale pak se musi vygenerovat cele datove struktury odznova - rebuild indexu. Kazda lod bude nalezet prave jedne hvezde s tim, ze tato hvezda bude vzdy nejblizsi ze vsech hvezd. 


II. Reprezentace vesmiru
--------------------------------------------------------------------------------

Vesmir bude dvourozmerny, vsechny hvezdy budou mit souradnice [x,y], datovy typ double. K reprezentaci hvezd bude vyuzit kd-strom, ktery umi indexovat vicerozmerna data. Tento kd-strom bude vytvoren na zacatku ze seznamu hvezd a bude tak vyvazeny. Kazda hvezda bude definovat tzv. region a vsechny lode, ktere jsou v danem regionu, ma hvezda ve svem seznamu. Region je oblast tech bodu prostoru, ktere jsou k dane hvezde blize, nez ke vsem jinym hvezdam. Region bude konvexni mnohouhelnik, definovany nerovnostmi, aby bylo snadne poznat, ze lod nezmenila region (v tom pripade zadna nerovnost neni porusena). Pritom tyto nerovnosti nebudou v databazi, nybrz budou pokazde vygenerovany pomoci Voronoi diagramu - regiony jsou bunky daneho Voronoi diagramu, kde body jsou hvezdne systemy. 

Invarianty:
 i) Kazda lod ma prirazen region, ktery patri nejblizsi hvezde.
 
 ii) Kazda hvezda ma korektni seznam vsech lodi, ktere jsou v danem regionu.
 
 iii) Regiony se neprotinaji a KAZDA OBLAST JE PODMNOZINOU NEJAKEHO REGIONU!!!
 
Cely vesmir je pak rozparcelovan na dane regiony. Vzhledem k pouziti nerovnosti je nutne pouzit presnejsi datovy typ - double, nebot poruseni nerovnosti potrebujeme urcit presne, domnivam se, ze by se presnost ztracela pri pouziti celych cisel.

Generovana data pri startu serveru: kd-strom, nerovnosti (z voroneho diagramu)

Dale, kazda lod patri prave do jedne oblasti. Zrychleni hvezdy bereme jako konstantu.

III. Datove polozky lodi a slunecnich soustav
--------------------------------------------------------------------------------

a) Lode budou mit nasledujici datove polozky vzhledem k pohybu/vesmiru:
 - ID regionu, do ktereho nalezi {NENI V DB}
 - ID oblasti, do ktere nalezi
 - poloha: (x,y)
 - rychlost: (dx,dy)
 - zrychleni: (ddx, ddy)
 - smer tahu motoru: (x,y), norma je sila motoru (v nekterych oblastech je zrychleni primo rovno tomuto vektoru)
 - mnozina casu eventu {NENI V DB}

b) slunecni soustava:
 - seznam lodi ktere jsou v regionu dane slunecni soustavy, std :: set {NENI V DB}
 - nerovnosti urcujici dany konvexni mnohouhelnik (region) {NENI V DB}
 
c) vesmir:
 - kd-strom se vsemi hvezdami

IV. Akce a cile
--------------------------------------------------------------------------------

Akce: Aktuálně prováděná akce lodi. Může se jednat například o zastavení, stání lodi na místě, přistávání atp. Podle akce lodi se nastavuje síla tahu motoru a směr, kterým motor táhne.

Cíl: Jedná se o "vyšší" cíl lodi, například dolétnutí k hvězdě na pozici xxx na její oběžnou dráhu, pronásledování lodě a další obdobné věci. 

Uživatel může zadat akce i cíle.

V. Správa eventů
--------------------------------------------------------------------------------

Hrozí, že bude generováno množství eventů, které budou aktivovany za znacnou dobu, napriklad kdyz se nastavi let lodi na velmi pomalou rychlost - pak bude trvat velmi dlouho, nez lod vyletne z oblasti popr. regionu. To cini problem, nebot tyto eventy se budou hromadit. Proto maximalni doba, za kterou se event aktivuje, cini deset minut normalniho casu. Zaroven, aby se negenerovalo prilis mnoho eventu, pokud potrebujeme event A v case t0 a mame v mape event B v case t1, kde t1 < t0, pak event A nezarazujeme do fronty, nebot dany problem vyresi event B - budto se neco zmeni (treba dojde palivo), nebo event B korektne vygeneruje zpetne event A, pokud se nic nezmenilo. Usetri to generovani zbytecnych eventu, generuji se jen ty, ktere potrebujeme aktivovat drive, nez nejdrivejsi aktualni event v mape.

Eventy budou generovany mimo jine v nasledujicich pripadech:
 - vstup do oblasti, vystup z oblasti
 - vystup z regionu
 - pristani na zakladne
 - dojde palivo, atd.
 
 
VI. Pronasledovani
--------------------------------------------------------------------------------

Urza navrh implementaci slozitejsiho algoritmu, ktery by se realizoval pozdeji (az budou naprogramovany zakladni funkcnosti a budou fungovat). Pro zacatek bude myslim stacit iterativni algoritmus - pronasledujici lod se bude kazdou sekundu aktualizovat udaje o svych motorech atd. vzhledem k sledovane lodi, tak aby dorazil na jeji misto.

VII. Akce ve volnem prostoru
--------------------------------------------------------------------------------

A) STOP - v případě, že je vektor rychlosti a zrychlení nulový, nedělej nic. Jinak zapni motory v opačném směru, než je rychlost a to do té doby, než je vektor rychlosti nulový, pak vypni motory.

B) NOTHING - nic nedělej, tj. nech motory vypnuté, loď volně pluje v prostoru danou rychlostí (případně stojí)

C) ACCELERATE - loď zrychlí na danou rychlost, pak vypne motory (zadá se i směr)

Zatáčení (změna směru) nebude akce (ale může se realizovat tak, jak říkal Urza, případně pomocí ACCELERATE změnou směrového vektoru)

