Hej all.

Jag är nybörjare på c++
Men försöker ändå få ihop ett snake spel
Jag har gjort allt utom att få en svans på min lilla orm för jag har ingen aning om hur man skall lösa detta.

Det jag alltså vill ha hjälp med är att få till en slags svans på min orm.

Vet ej hur man infogar kod på detta forum (finns det nån code-paste av nåt slag??) så jag låter bli (så jag inte får skäll) men om ni vill att jag skall göra detta så kan jag fixa det.


M.V.H. Jonas

BTW. hur byter man lösen på denna sida den knappen är grå under mina inställningar.

Vi börjar från slutet:

<b>>hur byter man lösen på denna sida den knappen är grå under mina inställningar.</b>
Inte möjligt, tyvärr.

<b>>Vet ej hur man infogar kod på detta forum (finns det nån code-paste av nåt slag??) så jag inte får skäll) men om ni vill att jag skall göra detta så kan jag fixa det.</b>
I ditt fall skriver du < code c++ > </ code > (utan mellanslag), och koden emellan. Men ta bara med lite kod.

<b>>Jag har gjort allt utom att få en svans på min lilla orm för jag har ingen aning om hur man skall lösa detta.
Det jag alltså vill ha hjälp med är att få till en slags svans på min orm.</b>
Tyvärr så låter det lite fel; du har gjort allt utom att få till en svans för att du inte har en aning om hur du ska lösa det.

Hur som helst så kan jag beskriva hur jag hade gjort det:
1. Först en tvådimensionell array, "board[20][20]", där ormen rör sig.
2. Sen så har man en riktning, och en "nuvarande position". Nästa position blir då nuvarande + riktning.
3. Sen beror det lite på hur man vill göra. Du kan ha en lista med svansen, std::list<point>, där du tar bort sista, och lägger till den nya först. Annars kan du låta arrayen ha siffror som motsvarar hur länge sen rutan fylldes i, eller något i den stilen.

Okay skall se om jag kan få ihop nåt på det sättet.

Har dock en liten fråga till kan man först generera en spel plan och sen "lägga på" ett lager med masken

Eller måste man generera allt samtidigt som jag har det nu??
det flimrar väldigt mycket nu eftersom allt uppdateras hela tiden.

Så här har jag gjort nu.

a=0;
while (a < plan_y+3) {cout<<"\xdb";a++;}
cout << "\n";
   while (loop_x <= plan_x)
   {
   loop_y=0;
   cout << "\xdb";
      while (loop_y <= plan_y)
      {
         
         if (loop_x == x && loop_y == y)                {w='@';}
         else if (loop_x == mat_x && loop_y == mat_y)   {w='*';}
         else                                           {w=' ';}
         
         if (x == mat_x && y == mat_y)
         {
            mat_x=rand() %plan_x;
            mat_y=rand() %plan_y;
            poang=poang+level;
            antal_mat++;
            if (antal_mat == 1)
            {
               antal_mat = 0;
               level++;
               if (hastighet > 16)
               hastighet=hastighet-15;
            }
         }  
         
         cout << w;
         loop_y++;
      }
   cout << "\xdb";
   cout << "\n";
   loop_x++;
   }
b=0;
while (b < plan_y+3) {cout<<"\xdb";b++;}

cout << "\nDin po\x84ng : " << poang;
cout << "\n    Level : " << level  << "    " << hastighet ;
Sleep(hastighet);
}

Tack för svar.

/Jonas

><b>Har dock en liten fråga till kan man först generera en spel plan och sen "lägga på" ett lager med masken</b>

Givetvis kan du göra det, rita ut spelplanen först, sedan masken och uppdatera för varje steg.

/Peter

Men då kommer ju masken nedanför spelplanen

Hur skall jag få den att starta från x y 0 0 igen så jag ritar ovanpå en annan bild om du förstår vad jag menar.

M.V.H. Jonas

När det gäller att få till din mask så finns det en antal olika lösningar. Vad du måste göra är att på något sätt holla kolla på var varje enskillt element i din mask (som ju växer dessutom) är, och i vilken ordning de till kom så att de tas bort i rätt ände, från slutet, när masken rör sig.

Det sätt jag löste det på när jag gjorde ett mask spel var att ha en vektor där jag sparade varje del av masken. In i denna vektor har jag sedan två pekare eller variabler eller hur man nu väljer att lägga upp det. En som talar om var information om var huvudet just nu finns (inte på skärmen, men var i vektorn som huvudets position finns) och en som talar om var svansen (det sista elementet i masken) finns i vektorn.

När du precis börjar spelet så kommer maskens huvud och dess startposition att lagars först i vektorn. Beroende på hur lång din mask är från starten kan du sen behöva fylla i det med, i min version var masken bara ett huvud vid starten. Svansen pekade då på exakt samma plats som huvudet. För varje "omgång" när masken sen rör sig i en ruta så fyller man i den nya positionen på huvudet i vektorn på platsen efter huvudet. Om masken inte skall växa så tar man också bort den sista platsen, den som svansen pekade på. Skall masken växa, så gör man inte detta.

Man måste också uppdatera skärmen, vill man inte rita om hela skärmen så behöver man bara göra följande, rita dit ett huvud på den nya platsen, rita dit ett vanligt masksegment där senaste huvudplatsen fanns, och om masken inte växte, radera den plats där sista mask segmentet fanns, dvs svansen.

Håll reda på i vilken ordning du uppdaterar dina pekare eller indikatorer på var i din vektor som huvudet och svansen finns och när de uppdaterar skärmen, man kan få tänka till lite men det skall inte vara så svårt.

Eftersom hela masken finns lagrad i din vektor kan man givetvis när som återskapa hela masken. Börja med huvudets position, och gå sedan längs vektorn tills man kommer till svanspositionen och rita ut masken på skärmen.

Ett beslut du behöver ta är hur stor din vektor behöver vara. Extremfallet är att den måste kunna hålla information om en mask som är lika stor som spelplanen. Det är et minimum. Så om spelplanen består av 40x40 rutor, måste du ha 1600 datafält i din vektor som var och en kan ha information om x och y koordinaten. Du måste också se till att när pekarna på huvudet och svansen kommer till slutet så börjar de om från början. Det är inga problem eftersom de är för stunden oanvända delar av vektorn. I mitt fall så ville jag kunna spara hela spelet och visa upp en repris, då fick jag ha en vektor som var mycket större eftersom jag inte kunde "börja om" i den. Eftersom min mask växte vart tionde steg som masken tog så hade jag i exemplet ovan behövt en vektor med 16000 fält.

När det gäller hur man skriver på en vis position på skärmen så beror det på vilken typ av program du skrivit, ett consolprogram eller ett windowsprogram? Det blir lite olika men WIndows har funktioner i båda fallen för att skriva text (din mask verkar ju bestå va just text) på valfri plats på skärmen. Kommer inte ihåg de utantill men kan kolla up. För windowsversionen som jag skrev tror jag coordinaterna för var man skrev texten var en del av "TextOut" funktionen som Windows har och jag använde (använder Windows GDI för grafiken). För consolprogram så skall det finnas en function som placerar markören på valfri plats och text som sedan skrivs hamnar där och inte "längst ner". Gjorde en snabbsökning och hittade SetConsoleCursorPosition som verkar vara ett alternativ.

Har en känsla av att du skriver ett console program och här är en länk till en del användbara functioner som Windows tillhandahåller för dig:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/console_functions.asp

Förmodligen finns även programbibliotek till din kompilator med mera som kanske tillhandahåller liknande funktioner så du inte anropar Windows direkt men där är jag inte så hemma.

Hoppas det inte var för oklart, terminologin var kanske inte den bästa.

En vector för det jobbet är inte rätt val. Man ska använda list för sådana grejer, alternativt ha en stor matris där varje ruta är ett tal som representerar hur länge rutan har levt eller har kvar att leva.

>En vector för det jobbet är inte rätt val. Man ska använda list för sådana grejer,

Kanske fel ordval då, vet inte vad en "list" är. Som jag sa i mitt fall så fungerade inte matrisen för skärmen då jag ville kunna spara hela spelet. Dessutom får man problem med en matris då man inte på ett enkelt sätt kan hitta den plats som funnits längst och således skall tas bort. Man kan vissreliggen komma ihåg den senast man tog bort och sedan leta runt den för nästa, men det känns knappast som en smart lösning. Hur länge en ruta levt i sig är inte intressant då masken alltid "växer" vid huvudet och "försvinner" vid svansen. Vill man modifiera spelet till att fungera på annat sätt så kan det kanske vara en möjlighet. Vill man sen ha fler än en mask så känns det ännu naturligare att ha separat vektor (eller list) för varje. Visst måste man till slut ha någon form av matris för hela skärmen för att holla koll på om man krockar med något. Men där finns mer än själva masken, till exempel kan man vilja ha hinder i banan. Man kan där också lägga in ramen runt om för att enkelt kuna se om man krockar med den. Att dock spara hela maskens ordning i den känns mest som en onödig minnesoptimering för mig, det rör sig inte om stora mändgder data om man håller till på en vanlig dator.

Summa sumarum, visst kan man ha matris, men det låser in en ganska mycket (jag provade det också en gång i urtidens begynnelse när jag programmerade min först masken i Pascal på Compisdatorer och sedan fluttade den till DOS miljön på en 286:a. Ganska snabbt lämnade jag matrissättet då jag ville ha andra funktioner med och behöll den endast för att hålla koll på vilken del av skärmen som var tom eller upptagen.

ÄNDRING: Med list, menar du någon form av länkade listor? Viss kan man göra det, fast det känns också det lite onödigt i denna situationen då det inte rör sig m mycket minne, och du faktiskt vet din övre gräns för hur mycket data du behöver kunna spara, men visst, vill man göra så går det bra det med, en variant på en vektor i princip.

<b>>Som jag sa i mitt fall så fungerade inte matrisen för skärmen då jag ville kunna spara hela spelet. </b>
Men det du säger är ju att du representerar det som en vector som är lika stor som hela matrisen?
Och att du sen sparar hela den vektorn så många gånger som spelet kan köras?
Det är ju identiskt med att göra en matris, på exakt samma sätt.

<b>>Dessutom får man problem med en matris då man inte på ett enkelt sätt kan hitta den plats som funnits längst och således skall tas bort.</b>
Njae... man har en matris med nummer i [0, n] där 0 representerar "inget masksegment" och i representerar "masksegment som kommer leva i steg till", och vid varje runda minskar alla nollskillda värden med ett. Sen ritar man upp hela matrisen, och för de punkter där den är nollskild så ritar man ett masksegment.

Fördelen är att man dessutom kan låta saker som bara ska finnas en viss tid representeras på samma sätt, och att du utan problem kan ta bort mer än ett segment åt gången, om du skulle vilja det.

<b>>Vill man sen ha fler än en mask så känns det ännu naturligare att ha separat vektor (eller list) för varje.</b>
Naturligare, men det är inga problem med en matris heller, man har bara två ställen som är "nuvarande mask", och hanterar allt annat på samma sätt.

<b>>Att dock spara hela maskens ordning i den känns mest som en onödig minnesoptimering för mig, det rör sig inte om stora mändgder data om man håller till på en vanlig dator.</b>
Det är inte en minnesoptimering, det är en förenkling.

<b>>Summa sumarum, visst kan man ha matris, men det låser in en ganska mycket</b>
Själv anser jag raka motsatsen, visst kan man ha en annan representation, men det låser in en ganska mycket. Faktum är att hela din vektor eller länkade lista kan realiseras i själva matrisen utan några direkta problem.

<b>>Med list, menar du någon form av länkade listor? Viss kan man göra det, fast det känns också det lite onödigt i denna situationen då det inte rör sig m mycket minne, och du faktiskt vet din övre gräns för hur mycket data du behöver kunna spara, men visst, vill man göra så går det bra det med, en variant på en vektor i princip.</b>
Ja, det är i allmänhet en länkad lista.
Det handlar inte om minnet (även om det naturligvis kan bli en viss vinst i det), det handlar bara om att det är mycket lättare att hantera det i en list.

Ska du ha en std::vector, så måste du hela tiden ha ett index till "första position" och ett till "sista position", om du inte vill ha sjukt dålig prestanda. Ska du ha en std::list, så är det bara att köra push_back, push_front, pop_back och pop_front när du vill ha nya element eller ta bort gamla.

Det finns liksom ingen vinst någonstans med en vektor. Det blir inte enklare, det blir inte flexiblare, det blir inte snabbare, och det kräver inte mindre minne än de två andra varianterna.

Jag fick det att funka genom att lägga x i en array och y i en array och sen sortera den så att den bara inehåller dom senaste så att den inte bara blir längre och längre utan att man tar nån mat.

men jag har fått lite fler problem just nu om ni kollar följande kod:

		/////////////////////////////////////////////////////Sätt ut mat
		coloratrib('y');
		if (x == mat_x && y == mat_y)
		{
			sam_mat++;
			/*
               mat_ok=1;
			for (int i;i<=sam_mat+1;i++)
			{
               do 
               {*/
                   mat_x=rand() %plan_x;
		    mat_y=rand() %plan_y;
                  /*
               } while(mat_x == orm_x[i] && mat_y == orm_y[i]);
               }*/
			temp_poang = level*10;
			poang=poang+temp_poang;
			antal_mat++;
			if (antal_mat == 10)
			{
				antal_mat = 0;
				level++;
				if (hastighet >= 25)
					hastighet=hastighet-25;
			}
			
		}
		
		gotoxy(mat_x,mat_y); cout << "*";
		coloratrib('b');
		gotoxy(plan_x+3,1);
		cout << (int) poang;
		gotoxy(plan_x+3,4);
		cout << (int) level;
		/////////////////////////////////////////////////////Spara ormens position
		orm_y[sam_mat+1]=y;
		orm_x[sam_mat+1]=x;
		//sam_mat=7;
		arr = 0;
		while (arr <= sam_mat)
		{
			orm_y[arr] = orm_y[arr+1];
			orm_x[arr] = orm_x[arr+1];
			arr++;
		}
		/////////////////////////////////////////////////////Sätta ut hela ormen
		coloratrib('r');      
		for(int i=0;i<=sam_mat;i++)
		{
			gotoxy(orm_x[i],orm_y[i]); 
			if(i==0)           
				cout << " ";
			else
				cout << "O";
		}
		_sleep(hastighet);
		gotoxy(0,plan_y+2);
	}

(Inte hela koden)
Om ni vill att jag skall skriva hela koden så säg till men den är runt 200 rader detta är där jag sätter ut matbitar sparar ormens position och skriver ut ormen.


Som ni ser har jag försökt få koden att kolla ifall maten hamnar mitt i ormen men jag får det inte riktigt att funka.

Så ni får gärna kolla om ni kan se hur jag skall lösa det.

Sen har jag försökt att få gameloopen (finns inte med i ovan kod) att avbrytas när man åker in i sej själv men när jag försöker så dör man så fort spelet startar.

Detta får ni gärna oxå ge tips på.


Ni får även ge tips på hur jag kan förbättra koden i övrigt oxå.

Tack så jatte mycket för all hjälp

M.V.H. Jonas

Angående vektor/list så beror det nog på att jag programerar mest i C. Din list verkar ju vara en redan implementerad lista och du slipper skriva och hålla reda på den. Jag har istället gjort den koden själv. Resultatet är i princip densamma med skillnaden att du använder ett färdigt paket för din lista. Ser inte skillnaden i "enkelheten" som du pratar om det blir varken enklare eller mer komplicerat i något av fallen, man kan ju likaväl implentera dina push och pop för vektorn som för listan. Den största skillnaden mellan lista och vektor är att du inte syslar med dynamisk minnesallokering i en vektor men är begränsad i en storlek. Dessutom är det inte lika lätt att direkt komma åt ett element i mitten av listan som i en vektor då man måste vandra igenom den. Båda metoderna har för och nackdelar, i en hel del fall kan man anvädna vilken som, i andra fall är en klart bättre än den andra.

Förstår din implementering av matrisen bättre och kan se en del fördelar men också nackdelar. Tex så kan du ju inte spara spelet med din matris vilket man kan göra med en vektor/lista. Att alltid för varje steg behöva gå igenom hela matrisen och uppdatera varje plats känns också onödigt, vilket du ju måste göra. Vill man dessutom ha funktioner som gör att masken växer i annan hastigehet än normalt av någon anledning vid något specifikt tillfälle eller under en tid), så måste gå igenom och uppdatera varje segment så att tidsfaktorn blir rätt, det kräver också att man i matrisen sparar VAD som finns i varje plats så man bara updaterar (rätt) mask och inget annat.

Du måste också hålla rätt på aktuell maxtid istället för på slutplatsen (startplatsen måste ju båda hålla rätt på så man vet vad huvudet finns), så ser inga fördelar med just matrisen där heller. Att ta bort flera segment kan man ju lika lätt göra oavsett sättet man sparar, i båda fallen krävs en aning extra kod som hanterar det.

I stort så skulle jag säga två olika system men ser begränsningar i matrisen om man vill spara spelet och kunna spela upp det igen, då den bara kan hålla situationen för tillfället. Plus att jag anser (men det är personlig åsikt förståss) matrisen bökigare då man måste hålla på att updatera allting varje "runda" eller om något händer,

När det gäller grafiken så behöver man i inget fall, inte matrisen heller rita om allt. Du behöver bara rita om platser där något försvinner eller ändras (huvud på ny plats, huvud blir segment) eller tex mål. Det har nog inte så mycket med lagringsform att göra dock.

Bara en kort kommentar till en av dina frågor:

"Sen har jag försökt att få gameloopen (finns inte med i ovan kod) att avbrytas när man åker in i sej själv men när jag försöker så dör man så fort spelet startar."

Känns som om du kollar vid antingen fel tillfälle eller efter fel sak. Vad du måste kolla är om huvudets NYA plats, när det skall flyttas, är tomt eller upptaget. Om ledigt, då kan du flytta huvudet dit och markera platsen som upptagen. I denna test kan man givetvis också lägga in koll om det var maten man stötte på eller något annat som inte gör att spelet skall ta slut utan ger andra effekter. Själv har jag en mask som växer med tiden och inte om man äter, men förutom mat (som ger poäng) så kan det även finnas annat som gör att masken inte växer tex.

En detalj och kanske inte så viktigt men som kan vara bra att tänka igenom är om maskens huvud kan gå in i platsen som maskens svans lämnar i samma stund. Jag har gjort så att så inte är faööet i mitt spel, men båda alternativen är ju möjliga. I det senare fallet måste man då först ta bort svansen innan man flyttar huvudet och kollar efter ledig plats.

<b>>Angående vektor/list så beror det nog på att jag programerar mest i C. Din list verkar ju vara en redan implementerad lista och du slipper skriva och hålla reda på den.</b>
Ja, man använder ju naturligtvis de inbyggda datastrukturerna i språket, och det är ju C++ det är frågan om här.

<b>Ser inte skillnaden i "enkelheten" som du pratar om det blir varken enklare eller mer komplicerat i något av fallen, man kan ju likaväl implentera dina push och pop för vektorn som för listan.</b>
Om jag har en vector<x> och en list<x>, där jag skall lägga till ett element i början och ta bort ett i slutet så skulle jag för vector göra något i stil med (pseudo):

int startpos, endpos;
vector<x> v;
nextstep(){
  startpos++;
  endpos++;
  v.at(startpos) = getnextpos();
  paint(v);
}

paint(v){
  for(int i=startpos; i<endpos; i++)
    paint(v.at(i));
}

(eller ännu värre genom att stuva om skiten varje gång)

för list eller queue skulle jag göra:

int startpos, endpos;
list<x> v;
nextstep(){
  v.push_front(getnextpos());
  v.pop_back();
  paint(v);
}

paint(v){
  for_each(v.begin(), v.end(), paint);
}

Det tycker iaf jag är väsentlig förbättring.

<b>Den största skillnaden mellan lista och vektor är att du inte syslar med dynamisk minnesallokering i en vektor men är begränsad i en storlek.</b>
Nej, minnesallokering och storleksbegränsning ägnar man sig inte åt i vettiga implementationer.

<b>Dessutom är det inte lika lätt att direkt komma åt ett element i mitten av listan som i en vektor då man måste vandra igenom den.</b>
Nej, och det finns inte heller någon poäng med att göra det i det här fallet.

<b>Förstår din implementering av matrisen bättre och kan se en del fördelar men också nackdelar. Tex så kan du ju inte spara spelet med din matris vilket man kan göra med en vektor/lista. </b>
Jo, naturligtvis. Jag förstår ärligt talat inte vad du menar när du säger det.

<b>Att alltid för varje steg behöva gå igenom hela matrisen och uppdatera varje plats känns också onödigt, vilket du ju måste göra.</b>
Jovisst, men det är ingen stor eller svår operation. En eller två for-loopar med {if(a[i][j]>0) a[i][j]--;}

<b>>Vill man dessutom ha funktioner som gör att masken växer i annan hastigehet än normalt av någon anledning vid något specifikt tillfälle eller under en tid), så måste gå igenom och uppdatera varje segment så att tidsfaktorn blir rätt, det kräver också att man i matrisen sparar VAD som finns i varje plats så man bara updaterar (rätt) mask och inget annat.</b>
Ja, det är ju inget problem?

<b>>Du måste också hålla rätt på aktuell maxtid istället för på slutplatsen (startplatsen måste ju båda hålla rätt på så man vet vad huvudet finns), så ser inga fördelar med just matrisen där heller. Att ta bort flera segment kan man ju lika lätt göra oavsett sättet man sparar, i båda fallen krävs en aning extra kod som hanterar det.</b>
Nej, då har du missförstått. Står det 0 så finns det inget i rutan, står det en siffra så är det ett masksegment i rutan. Vid varje steg minskar man alla värden >0 med ett. Det finns ingen ytterligare kontroll.

<b>>Ni får även ge tips på hur jag kan förbättra koden i övrigt oxå. </b>
Det här är egentligen lösningen till alla dina problem: Strukturera upp koden!

Dela in allting i funktioner. Låt varje funktion ha ett klart och tydligt specificerat syfte. Gör all uppritning i en enda funktion. (T.ex. "paint").

Då får du mycket lättare att se hur du gör. Det blir något i stil med:

int main(){
  init();
  char input=' ';
  while(input != 'q')
  {
     paint();
     input = getinput();
     nextstep(input);
  }
}

void paint(){
   //rita upp planen, beror på vad du har för representation
}

char getinput(){
  //vänta en liten stund och ta input om det kommer någon.
}

void nextstep(char action){
   handleaction(action); //se till att byta riktning om det behövs
   moveforward(); //rör masken ett steg framåt, kolla samtidigt om det blir en krock, eller om den äter någon mat
   putfood(); //sätt ut mat om det är rätt tid för det   
}

Sen delar du in funktionerna i så små delar att de verkligen är enkla att hantera för sig. Då är det inga problem att göra spelet.

>Om jag har en vector<x> och en list<x>, där jag skall lägga till ett element i början och ta bort ett i
>slutet så skulle jag för vector göra något i stil med (pseudo):

Det intressanta i detta fallet är ju egentligen inte vilken av en lista och array some generellt är mest enkel, utan vad som när det gäller att hålla reda på en mask verkar vettigt (och enklast om man nu vill ha det så). Som jag sagt tidigare så ser jag ingen fördel (oavsett om man använder inbyggda versioner av vektorer eller listor) med att använda en dynamisk länkad lista framför en vektor då fördelarna med länkade listor inte har någon betydelse för den typ av sparningar av data som vi gör. Kodmässigt blir det ingen större skillnad i alla fall. Att diskutera generella sätt att ta bort eller lägga till element är ganska onitressant men går att göra i fallet med en mask lika enkelt i båda fallen.

Dina kodexempel är ganska ointressanta eftersom de inte efterliknar situationen i ett spel som masken och kan inte se den "väsentliga" förbättringen. Förbättring ur vilken aspekt då? Ser ingen sådan.

>Nej, minnesallokering och storleksbegränsning ägnar man sig inte åt i vettiga implementationer.

Då får du väll lära dig hur länkade listor fungerar och poängen med dem. En av anledningarna till att använda dem är just att man allokerar minne dynamisk efter behov när mer data skall stoppas undan. En fördel är just att man inte behöver tala om i förväg storleken man vill ha. Bara för att du inte förstår hur länkade listor implementeras så betyder det inte att, det är på ett visst sätt.

>Nej, och det finns inte heller någon poäng med att göra det i det här fallet.

Tex om man vill kunna spara spelet. Vill man av någon anledning göra andra tillägg i spelet som gör att det kan vara bra att komma åt ett element mitt i så är man låst och får göra större ändringar.

>Jo, naturligtvis. Jag förstår ärligt talat inte vad du menar när du säger det.

Din matris kan ju bara hålla koll på hur det ser ut just för stunden. Den innehåller ingen information om hur masken rört sig tidigare. Du kan således inte spara ett spel för att tex visa upp det efteråt, tex i form av en repris. Om man istället har en vektor/lista form så är det ju busenkelt genom att man inte raderar informationen om var masken varit utan behåller den, men kommer ihåg var svansen befinner sig just nu. Det stora problemet med din lista blir då att den inte klarar av att ha enkelt ha en "svans" mitt inne i den. Förhoppningsvis har implementeringen av listor som du nämner någon möjlighet att länka till element mitt inne i listan annars blir det problem.


>Jovisst, men det är ingen stor eller svår operation. En eller två for-loopar med {if(a[i][j]>0) a[i][j]--;}

Nej, men ganska onödig. Att hålla på och gå igenom massa data bara för att känns ju lite onödigt i mitt tycke. Med tanke på ditt "väsentliga förbättring" ovan så är jag tveksam tilll vad du egentligen menar med förbättringar i koden.


>Nej, då har du missförstått. Står det 0 så finns det inget i rutan, står det en siffra så är det ett
>masksegment i rutan. Vid varje steg minskar man alla värden >0 med ett. Det finns ingen ytterligare
>kontroll.

Så klart du måste hålla koll på maxtiden, annars vet du ju inte vad du skall skriva in för värden när ditt huvud växer. Du beklagade dig över att man måste hålla koll på både huvud och svans med "min" vektor och jag konstaterar bara att du måste hålla koll på tider istället. När masken växer så skall man givetvis inte minska några värden, då växer ju aldrig masken, däremot måste man kolla om det är masken i en ruta så visst finns det extra koll. Du angav att en födel med din matris var att man kan ta bort flera ellement åt gången, och jag ser inte hur man inte kan göra det oavsett hur man implementerar att spara masken.

Utanför detta ligger också att vill man start och göra mer anvancerade saker som kräver att man på något sätt går igenom masken blir det genast större problem med din matris, man måste då leta segment i matrisen i de fyra riktingarna runt en position för att se var "nästa" segment finns. Har man dessutom gjort mer avancerade saker som att flera segment kan ha samma "livstid" så kan man ju hamna i situationen där man inte vet hur masken egentligen går då flera element runt en viss position kan ha samma tid.

Ett annat problem blir om man vill kunna start a och mer än en sak i varje position. Det kan antingen vara masken som av någon anledning ibland skall kunna korsa sig själv, det kan vara hinder som rör sig över banan eller kanske mål/mat som skall kunna dyka upp på en plats där masken redan befinner sig. Kanske inte realistiska exempel men med en matris blir sådan tillägg väldigt svåra att göra om inte omöjliga.

Desenaste exemplen blir ju överkurs och har egentligen inte med en enkel implmentation av masken att göra, men man måste vara medveten om vilka begränsningar man bygger in i sina datastrukturer. Särskillt om man vill ropa bu och bä åt andra och hävda att de är helt fel.

<b>>Det intressanta i detta fallet är ju egentligen inte vilken av en lista och array some generellt är mest enkel, utan vad som när det gäller att hålla reda på en mask verkar vettigt (och enklast om man nu vill ha det så). Som jag sagt tidigare så ser jag ingen fördel (oavsett om man använder inbyggda versioner av vektorer eller listor) med att använda en dynamisk länkad lista framför en vektor då fördelarna med länkade listor inte har någon betydelse för den typ av sparningar av data som vi gör.</b>
Ja, det är ju exakt det som är listornas fördel. En lista representerar maskens utseende och hur den beter sig på ett rimligt sätt, när en vektor är minst sagt orimlig och man där måste hålla koll på var i vektorn som masken just nu är. För listan så är det så att hela listan i sig är masken.

<b>>Dina kodexempel är ganska ointressanta eftersom de inte efterliknar situationen i ett spel som masken och kan inte se den "väsentliga" förbättringen. Förbättring ur vilken aspekt då? Ser ingen sådan.</b>
Öh, inte efterliknar situationen?
Jag skrev dem just så som jag skulle ha skrivit i båda fallen. Förbättringen ligger i att list-koden är kortare, elegantare, och lättare att förstå.

<b>>Då får du väll lära dig hur länkade listor fungerar och poängen med dem. En av anledningarna till att använda dem är just att man allokerar minne dynamisk efter behov när mer data skall stoppas undan. En fördel är just att man inte behöver tala om i förväg storleken man vill ha. Bara för att du inte förstår hur länkade listor implementeras så betyder det inte att, det är på ett visst sätt.</b>
Naturligtvis vet jag hur länkade listor fungerar och vad som är poängen med dem. Men det finns ingen vettig programmerare som skulle få för sig att syssla med minnesallokering i C++ om man inte bygger sin egen högst specialiserade struktur.
Och det är just poängen med länkade listor som gör så att de är lämpade att representera en mask som både rör sig och krymper och växer.

<b>>Tex om man vill kunna spara spelet. Vill man av någon anledning göra andra tillägg i spelet som gör att det kan vara bra att komma åt ett element mitt i så är man låst och får göra större ändringar.</b>
Om man vill komma åt något i en lista för att spara spelet gör man en traversering av listan eftersom man oavsett vill komma åt alla andra element i listan. Om du har någon rimlig variant som kräver att man skulle komma åt ett element i mitten av listan så kan ju du nämna det. Vad jag vet så är det antingen huvudet, svansen eller alla element som är det intressanta.

<b>>Din matris kan ju bara hålla koll på hur det ser ut just för stunden. Den innehåller ingen information om hur masken rört sig tidigare. Du kan således inte spara ett spel för att tex visa upp det efteråt, tex i form av en repris.</b>
Öh?
Spara varje steg i en större tredimensionell matris, spara den tredimensionella matrisen och, om man känner för det, komprimera alltihopa, då det har ganska låg entropi. Även en run-length coding funkar nog bra.
Med din metod måste du ju utöver själva masken även spara all mat, och alla andra grejer som uppstår i ytterligare en struktur, och spara med den.

<b>>Utanför detta ligger också att vill man start och göra mer anvancerade saker som kräver att man på något sätt går igenom masken blir det genast större problem med din matris, man måste då leta segment i matrisen i de fyra riktingarna runt en position för att se var "nästa" segment finns. Har man dessutom gjort mer avancerade saker som att flera segment kan ha samma "livstid" så kan man ju hamna i situationen där man inte vet hur masken egentligen går då flera element runt en viss position kan ha samma tid.</b>
Det löser man enkelt genom att spara "riktning till nästa" eller "riktning till föregående" i varje element, om man har behov av något sånt. Det blir i praktiken en länkad lista, och det var den första representationen jag nämnde, en hybridrepresentation.

<b>>Kanske inte realistiska exempel men med en matris blir sådan tillägg väldigt svåra att göra om inte omöjliga.</b>
Nej, då har förutsättningarna helt förändrats, hela spelet skiljer sig, och då kan man inte förvänta sig att tidigare metoder automatiskt ska fungera. Men det är inget problem. Om masken ska kunna korsa sig själv var som helst så blir hela spelidén tämligen meningslös. Om det är vid vissa "övergångar", så vet man ju dem på förhand, och det är inget större jobb att fixa. Om man ändå vill ha flera såna i varje punkt så kan man utan problem göra en länkad lista i varje punkt, och alltid visa det översta elementet.

<b>>Förhoppningsvis har implementeringen av listor som du nämner någon möjlighet att länka till element mitt inne i listan annars blir det problem.</b>
Eftersom vi diskuterar i C++-forumet så förutsätter jag att du känner till standarbiblioteket (fd STL), men för att friska upp minnet så, ja, du kan använda std::list::iterator för att komma åt vilka element som helst.

<b>>men man måste vara medveten om vilka begränsningar man bygger in i sina datastrukturer. Särskillt om man vill ropa bu och bä åt andra och hävda att de är helt fel. </b>
Jag är fullt medveten om begränsningarna, men jag väger även in hur lätta datastrukturerna är att använda, och hur realistiskt de är anpassade till vad de representerar.
En matris är en generell variant som på många sätt är lättkodad, och som minst sagt räcker för det Jonas är ute efter.
En lista eller en kö har en tät koppling till hur en mask fungerar, och det är enkelt att relatera en förändring i tillståndet ("maskens sista element försvinner") till kod ("worm.pop_back()")
En vector fungerar men för den så motsvarar samma förändring i tillståndet koden "worm_tail_pos++", vilket knappast är intuitivt.

>Öh, inte efterliknar situationen?
>Jag skrev dem just så som jag skulle ha skrivit i båda fallen. Förbättringen ligger i att list-koden är
>kortare, elegantare, och lättare att förstå.

Kortare kod (källkod dessutom, inte kompilerad kod) är varken bättre eller förbättring. Ofta kan det vara tvärt om. Det är dussutom busenkelt att i båda exemplen göra koden ännu enklare. Att du i ena fallet bakar in tex paint funktionen i loop instuktionen men inte i det andra är sådant exempel, varken "kortare" (förmodar du räknar rader eller nått, vad vet jag), elegantare eller lättare att förstå. Dessutom så har du strippat ut delar av koden som i verkligheten inte kommer att ligga ihop och kommer att ha kringkod (tex om masken växer). Ytterligare en sak är att du förutsätter att man vill rita om hel masken varje gång, ganska onödigt, men försåeligt om du använder listan. Dessutom så har du ju i fallet med listan ett funktionsbibliotek i bakgrunden som du använder, man kan på liknande sätt använda för en vektor, då kan man få exakt samma kod i båda fallen. Det kan till och med vara en fördel om man vill kunna byta sätt att spara data, i detta fall masken, utan att behöva rota i koden som styr själva spelet.


>Naturligtvis vet jag hur länkade listor fungerar och vad som är poängen med dem. Men det finns ingen
>vettig programmerare som skulle få för sig att syssla med minnesallokering i C++ om man inte bygger
>sin egen högst specialiserade struktur.

Bara för att du inte skriver egen kod som gör det betyder ju inte att det inte sker. Då kan man ju inte komma och påstå att man inte sysslar med det bara för att man använder annan kod som gör det åt en. Man måste ju ha klart för sig hur de programbibliotek eller inbyggda funktioner man använder fungerar, deras för och nackdelar med mera. Som jag sagt tidigare som jämför du dessutom äpplen med påron då du i ena fallet (listor) pratar om en en implementering av dessa där du inte sysslar med dem direkt (de kan lika väl vara en vektor i bakgrunden utan att du har en susning egentligen och ja, jag vet att så inte är fallet, men det kan vara vad som) och i ena fallet när du kodar allt själv. Man kan lika väl använda ett annat paket med funktioner för listor och ha exakt samma funktionalitet för ditt program. Båda har för och nackdelar, lär dig dem och argumentera inte utifrån att du kan skriva kod som är en rad kortare i ena fallet.

>Om man vill komma åt något i en lista för att spara spelet gör man en traversering av listan eftersom
>man oavsett vill komma åt alla andra element i listan.

Poängen är inte HUR man gör. Man kan givetvis i vilken form man väljer att spara data, lista, träd, vektor, matris, tabeller, databaser, vad som, komma åt all data, annars vore det ju inget vidare. Poängen är att välja en metod som passar ens implementering. I det flesta fall kan man välja flera som alla fungerar lika bra. Det är min poäng och vad jag försöker säga medans du hävdar att lista är det enda rätta. Visst kan man gå igenom en hel lista tills man kommer till rätt element, men det betuder inte att det är ett bra sätt.

Exempel? Kan finnas massor. Jag har till exempel experimenterat med att man ibland kan korsa sin egen mask. Man kan vilja göra grafiska saker med masken som rör annat än huvudet eller svansen.

>Spara varje steg i en större tredimensionell matris, spara den tredimensionella matrisen och, om man
>känner för det, komprimera alltihopa, då det har ganska låg entropi. Även en run-length coding funkar
>nog bra.

Och det skulle vara "kortare, elegantare och mer lättförståeligt" hur? Det verkade ju vara dina kriterier på väsentligt förbättrad kod. Att hålla på och spara tomrum i en matris känns ju helt befängt. Att behöva hålla på att komprimera ännu fånigare. Man behöver inte alls spara mat och liknande. Det räcker med att spara tex den start "seed" som används för slumptals generatorn. För uppspelning av repriser använder jag exakt samma kod som för att spela, enda skillnaden är att istället för att updatera maskens huvudposition, så hoppar jag över den raden då den nya positionen redan finns i min vektor. Jag behöver då inte ha massa speciell kod för att visa reprisen eller låta den bli ett bildspel av sparade matriser "bilder". Igen, visst fungerar båda metoderna, men inse fördelarna och nackdelarna.

Att skapa en tredimensionell matris blir ju dessutom i själva verket i princip en vektor där varje ellement har hela skärmen. Fast du vill kanske spara dina matriser i en länkad lista. Matrisen ser jag som en variant på vektorn och det är inget större fel på den metoden i detta fallet även om det är massa "dödrum". Men hur löser du det med din lista? Tredimensionelle länkad lista? Knappast. Det var din länkade lista jag kritiserade mest för svagheten med att spara masks hela spel då du förlörar alla de "fördelar" du nämner försvinner men du vinner inga av vektorns fördelar.


>Jag är fullt medveten om begränsningarna, men jag väger även in hur lätta datastrukturerna är att
>använda, och hur realistiskt de är anpassade till vad de representerar.
>En matris är en generell variant som på många sätt är lättkodad, och som minst sagt räcker för det
>Jonas är ute efter.

Då en matris i princip är en vektor fast i två dimensioner (eller en vektor en matris i en dimension) så har jag svårt att färstå vad du har emot en vektor men inte matris, argumenterar för lista kontra vektor men anser att en matris är lättkodad fast precis påstått att din lista är "kortare, enklare och mer lättförståelig". Jag hävdar inte att någon metod är mer rätt eller fel. Vad jag protesterar mot är när någon kommer och påstår att "det är fel val" eller "man ska använda.." och så vidare. Och som argument dessutom har totalt ovidkommande saker. Att man dessutom är blind för de begränsningar man bygger in gör det inte bättre coh bara för att man kan lösa dem med sin inlåsta metod så betyder det inte att man kan strunta i dem.

>En lista eller en kö har en tät koppling till hur en mask fungerar, och det är enkelt att relatera en
>förändring i tillståndet ("maskens sista element försvinner") till kod ("worm.pop_back()")

Man kan ju göra precis samma sak med en vektor. Att man har en fun some döljer det underliggande arbetet fungerar ju oavsett vad man använder för datastruktur. Det har inget med data strukturen utan hur man implementerar gränssnittet mot det (om man nu inte vill jobba direkt mot data strukturen).