Lagring/lasting av STORT spillkart (oppdatert!)

[elminzter]

Edit: etterso folk viste veldig lite interesse for å svare på det forrige emnet mitt, så omformulerer jeg hele greia ^^

 

Jeg har altså tenkt å lage meg et spill med isometrisk synsvinkel a la Transport Tycoon der spillkartet er et rutenett...så langt har jeg testa og prøvt meg frem, tenker å representere kartet vha punkter:

class Punkt {
 private int x,y,z;
 private Terrain.grass terrain; //en enum klasse med forskjellige terrengtyper

 (osv...)
}

 

...men jeg har kommet frem til at jeg kommer til å trenge et groteskt antall Punkter for å tegne opp et kart av en noenlunde størrelse

 

så jeg er ikke sikker på hvordan jeg skal laste inn dette kartet in-game, hvis jeg skal ha meg et kart på 1000X1000 så ender jeg opp med en million Punkt-objekter(!)

 

pluss at det vil vel ikke overhodet være praktisk med en Punkt[1000][1000] ??

 

(har vurdert å stykke kartet opp i mange deler slik at jeg ikke trenger å ha alle punktene lastet inn til et hver tidspunkt, men får det ikke til noen grei måte å bytte om på den så du uavbrutt kan scrolle uten å "komme til en ende" av det som er lasta inn...)

Endret 20. mai 2006 av elminzter

[___]

Mitt forrige forsøk på å svare ble kluss, så jeg prøver igjen.

 

Hva med å lage en ny klasse:

 

class Area {
 int origin_x, origin_y, origin_z;
 int length, width;
 private TerrainType terrain;
 ...
}

 

På denne måten så kan du definere opp store flater av en bestemt terrengtype, uten at du trenger å lagre unødig mye data. Eneste ulempen er at du bare kan definere plane flater. Skal du representere f.eks. en skråning, kan du jo lage en descendant av klassen over, og legge til z-koordinatene til hvert hjørne. I opptegningsrutina di må du da beregne høyden til alle "tiles" i skråningen basert på z-koordinatene til hjørnene.

 

Werner

Endret 20. mai 2006 av wernie

[Peter]

Du kan jo bruke teorien bak mye komprimering, å kun lagre differansen fra forrige frame. Dersom differansen er for stor, så lagrer du hele framen.

Personlig ser jeg ikke noe problem med 1000x1000 punkter, sålenge koden er smart kodet.

[oyvind_b]

Du kan eventuelt bruke et Quadtree til dette. Et Quadtree er en struktur som går ut på å dele hele kartet i fire deler, hvor hver del igjen deles i fire, etc, helt til hver del er en "brikke" bred, eller til hele området Quad-en dekker består av samme terrain-type:

 

class Quad
{
  private Quad upperLeft;
  private Quad upperRight;
  private Quad lowerLeft;
  private Quad lowerRight;

  private TerrainType terrainType = ... 
}

Dersom hele "Quad"-en består av kun EN terrain-type kan terrainType-variabelen fylles ut.

 

Dette passer best til kart som har n^2 bredde og høyde, f.eks. 1024x1024.

 

Skjønner?

 

Øyvind

Endret 22. mai 2006 av oyvind_b

[elminzter]

hm, skjønner hva det går ut på i det minste, men jeg klarer ikke helt å se for meg hvordan dette gjør mappet lettere å lagre/laste inn eller å hente data fra...

 

hvis jeg lager et Quadtree der hvert leaf er et punkt i verdenen min, så er jeg ikke helt med på hvordan jeg skal finne de punktene jeg trenger.

 

si hvis jeg har fokus på ei rute og skal tegne opp naborutene slik at jeg får tegna opp alle rutene jeg trenger for å fylle skjermen. feks fokus er på ruta 1000,1000 (x,y) og jeg skal laste inn alle rutene i et kvadrat på 40x40 ruter om dette punktet, hvordan kan et quadmap gjøre dette lettere?

 

jeg må vel da bare finne en eller annen slags "algoritme" for å hente ut alle løv 1 etter 1?? (det er vel selvklart en eller annen obvious måte å gjøre dette på som jeg ikke klarer å gruble meg frem til den ^^)

[wolfbee]

Må si jeg skjønner ikke helt problemet ditt her. Hvorfor kan du ikke ha et vanlig JPanel som har x og y koordinater. Kan du gi et eksempel på bruk, så vi kan få et bedre innblikk i problemstillingen?

[elminzter]

jeg har tenkt å prøve meg fram litt med det, men akkurat nå fokuserer jeg på eksamener