Motivering:
Jag upplever att behovet av att starta upp Unity och exportera om så fort det är någon ändring i banor eller export/import koden är otillfredsställande och skapar onödig stress i situationer där man bara behöver ha något fungerande.

Förslag till åtgärd:
Ha en genomtänkt intern release hantering.

• Ändringar i kodbasen som kräver förändring av export/import pipelinen ska öka minor version typ från 1.2 till 1.3.
  -- I git finns ett workflow kallat gitflow. Där jobbar man i en development branch som alltid ska vara kompilerbar. Nya features utvecklas i "feature branches" där det är upp till varje feature utvecklare att se till att deras feature fungerar i develop inan den mergas in. På så sätt hålls develop ren och körbar. Vid planerade tillfällen mergear man develop till en release branch, där man inte utvecklar något nytt men testar och rätta brytande buggar. När en release är stabil mergas den branchen till en retail branch som bara innehåller "releaser" dvs nya utgåvor med ett versionsnummer. Release branchen mergas också tillbaks till develop så att de rättningar man gjorde förs tillbaks in i fortsatt arbete.
• Levlar och assets paketeras vid varje release och förs in i FraktalOktav projektet under release bygget (dvs i release branchen) och kommer då automatiskt mergas tillbaks till develop efter releasen är klar.
• Planering av releaser är en grupp aktivitet och kan tex göras i samband med sprint planering. En sprint bör givetvis resultera i en release som har de features man planerat för sprinten. Det bör dock även planeras in ett antal releaser till vilka man kan sätta mål för att bli klar med tasks. Speciellt sådana som man på förhand kan förutse kommer att behöva ändra import/export pipelinen.
• Minor releases, ex 1.2.x, kan man göra när rent kodbaserade nya features blir tillgängliga för testning/användning utanför proggruppen lite vid behov. Viktigt är dock att dessa inte kräver nya assets eller ny import från Unity.

Förslaget är baserat på mina upplevda behov från programmeringssynpunkt men jag tror det även kan vara bra för LD/SG att hantera sina produkter i releaser. Jag tror det skulle underlätta kommunikationen genom att man kan prata om tydliga versioner i stället för att gissa om det var det senaste man pushade eller glömde pusha, har alla inblandade samma versioner av saker och ting?

Nackdelar:

• Att jobba med striktare konfigurationsledning gör det svårare att rusha fram resultat. Devs lite mindre flexibilitet.
• Det krävs en del planering. Tror dock att det också kan vara ett stöd i sprintplaneringen och kan hjälpa till att fokusera på vilka mindre steg vi kan behöva ta under sprinten.

Need to have a way to work with Text similar to sprites ie can create, edit and delete them and have them beautifully rendered by the graphics engine.

Här är några saker jag funderat på:

1. Vad är vad är livscykeln för ett GameObject och dess komponenter? Kan man förutsätta att alla andra GameObjects finns när Init() körs? Kan Init() komma att köras mer än en gång?
2. Man bör aldrig i en Component förutsätta att externa beroenden alltid är uppfyllda t.ex. att det finns en Scene, att Scenen innehåller en Player etc. Men vad ska vara korrekt sätt att hantera om nödvändiga beroenden inte är uppfyllda?

Since we are depending of level information and assets to match and also require a compatible version of the software I think it would be a good thing to pack this data in a single file format. My suggestion would be to use a archive file-format such as zip and a virtual filesystem to mount said file to. This would allow allow us an easy way to handle asset/level updates separet from the code base.

In practise this would mean that we can swap the entire Bin/Assets file tree by mounting a single file. That also means we would have a manageable way to review the game with different "asset packs" say in early prototyping with quick assets in different styles.

It would also provide a good starting point for handling DLCs :-D