3d labyrint

Tags:    c++

Her er et lille stykke kode jeg har skrevet, det er naturligvis lang fra færdigt, men jeg har et par spørgsmål til hvordan det kan gøres, har nogle problemer der mangler løsninger osv.

Fold kodeboks ind/udKode 

1)
Jeg har lavet en struct 'cell' med 4 boole variabler der hver fylder én bit, altså 4 bit total pr celle, nu forholder det sig sådan at selvom jeg reelt kun har brug for en halv byte pr celle, bruger den 1 byte. Om den bruger 8 eller 16 MB for en sådan 256^3 struktur, gør ikke den helt store forskel, men jeg kunne godt tænkte mig at få løst problemet alligevel hvis det kan lade sig gøre.

2)
I 'new_grid()' tildeler den værdier (0 eller 1) til til alle xy/xz/yz variablerne i cellerne. disse xy/xz/yz skal forstås som vægge i en 3d_labyrint; hvis værdien er 0 er der ingen væg og er den 1 er der en væg.
Det første problem er naturligvis at jeg har brug for en 'ikke pseudo' rand_bit(), men der er et lille problem, her på test stadiet fungerer denne fint nok.
Nu kommr den lumske del
Hver celle har 6 vægge. 3 af disse vægge er defineret i cellen, og de resterende vægge er defineret af de omkring liggende celler.
dvs.
celle xyz har væggene:
GRID[x][y][z].xy
GRID[x][y][z].xz
GRID[x][y][z].yz
GRID[x][y][z-1].xy
GRID[x][y-1][z].xz
GRID[x-1][y][z].yz

strukturen er uendelig/endelig hvilket vil sige hvis man skulle være så uheldig at befinde sig i 257,257,257, befinder man sig i hvirkeligheden i 1,1,1.
det er lidt kringle, men det virker.

Problemet består i at disse celler skal opfylde nogle krav:
De må ikke være lukkede, dvs. der skal være mindst én manglende væg pr celle.
Det skal være muligt at bevæge sig fra en given celle til en anden, uanset placering.

Dette er noget jeg grubler over.

3)
Jeg ønsker at høre en masse gpde idéer til forbedringer o.lign.
Jeg ønsker at høre om fejl og mangler.
Jeg ønsker en interessant diskution om hvorledes man kan/bør løse dette problem, det stykke kode jeg har postet er kun et oplæg, det kan meget vel gøres smartere.

4)
Jeg kan forestille mig at der måske er nogle der grubler over hvad meningen med galskaben er og det er jo naturligvis meningen at der skal skrives et grafisk interface med tiden og derefter kan jeg se adskillige muligheder for hvad det kan bruges til.

5)
I skal vide at jeg er nubegynder og faktisk ikke har været i gang i meget over en uge, jeg har dog lavet en del php scripts osv. men altså stadig en c++ n00b ;-)
Jeg er klar over at meget af dette ville tage sig rigtig godt ud i classes, men jeg har aldrig brug dem før og selv om jeg er igang med at læse på sagen, bliver jeg blot mere og mere forviret...

[Redigeret d. 08/02-06 17:12:02 af Felix Nielsen]



41 svar postet i denne tråd vises herunder
1 indlæg har modtaget i alt 4 karma
Sorter efter stemmer Sorter efter dato
Har skævet til din kode og foreslår følgende:
Fold kodeboks ind/udKode 


Jeg har 3 forslag til delen med

if(choice == 0) {
}
else
if(choice == 1) {
}
etc. etc.



1.
Følgende giver ingen forskel når der kompileres men ser bedre ud på skrift.
Fold kodeboks ind/udKode 



2
Følgende er stort set det samme som første forslag men reduceret.
Fold kodeboks ind/udKode 



3
Det sidste forslag er lettere advanceret: I stedet for at gå gennem op til 6 IF-sætninger hver gang, er det nemmere at gå direkte til koden der skal udføres. Dette gøres ved at bruge en funktionspointer.
bool (*func[6])() = {c0, c1, c2, c3, c4, c5}; definerer et array func med pointere til 6 funktioner der skal returnere en booltype. De 6 funktioner c0() til c5() svarer til de 6 IF-sætninger.
Fold kodeboks ind/udKode 



Fold kodeboks ind/udKode 


Og til sidst er der while løkken i main: while(0==0) kunne erstattes med while(true), men det er nok mest kosmetisk.



Beklager, jeg så forkert, da jeg skrev dette indlæg...

[Redigeret d. 03/02-06 18:58:15 af Nicolai Lyster Fersner]



1: Det er ikke muligt.

2 - 3: Hvis du laver en "path finding" algoritme, kan du bruge den til at finde vej mellem alle celler i labyrinten. Hvis der mangle en vej mellem to celler bliver du nødt til at fjerne en væg.
Du kunne også lave det omvendt. Start uden vægge, indsæt en væg, check at der er sti mellem alle celler, er der ikke fjernes vægen igen. Dette fortsætter du med et passende antal gange, evt indtil du xxx gange i træk ikke kunne sætte en væg.
Mit pacman spil har en pathfinding algoritme til 2D den er ikke ret effiktiv, men kunne bruges som en start:
http://home20.inet.tele.dk/midgaard/snip/pacman.html



Hvad pathfinding algoritmer, så kig evt. på Dijkstra's algoritme, og/eller a* algoritmen (søg på a star istedet for a*)

de finder begge den korteste vej, og ikke den første.

egentlig er Dijkstra's algoritme ikke en shortest path men en cheapest path i en vægtet graf, men vægtes alle knuderne ens, giver det en shortest path.

/Troels



Hvad pathfinding algoritmer, så kig evt. på Dijkstra's algoritme, og/eller a* algoritmen (søg på a star istedet for a*)

de finder begge den korteste vej, og ikke den første.

egentlig er Dijkstra's algoritme ikke en shortest path men en cheapest path i en vægtet graf, men vægtes alle knuderne ens, giver det en shortest path.

/Troels

tja, pathfinding algos, er interessante, men jeg tror hurtigt at jeg vil støde ind i problemer.
Jeg har planer om i sidste ende at have et grid på 256^3.
Hvis jeg skal undersøge om man kan komme fra en hvilken somhelst celle til en anden, vil det kræve at jeg undersøger:
256^3 * 256^3 -1 kombinationer = 2,8 * 10^14.
Jeg har ikke forstand på pathfinders, men jeg kan levene forestille mig at de bruger en hel del recourser.



Man kan jo godt lave algoritmen lidt mere intelligent, f.ex. huske alle de celler der har været besøgt.

Hvis du checker at man fra celle 0,0,0 kan gå til alle celler er det nok, for hvis man kan gå fra 0,0,0 til a,a,a og b,b,b kan man også gå fra a,a,a til b,b,b.

Man skal naturligvis lave en optimeret pathfinding algoritme, og så tror jeg at det er overkommeligt.
Jeg har ikke andre ideer til løsning.



Til Felix:
Kombinationsmængden er ikke større end det kan beregnes mens du lever, selv med de tal du stiller op! men har du overvejet hvor du vil gemme dataene?

der 2^48 kombinationer det svarer til 256Tb hvis vi meget optimistisk tror at vi kan gemme alle de ønskede data i 1byte for hver kombination.

Jeg ved selvfølgelig ikke hvad du skal bruge det til, men jeg ville nok satse på en lidt mere live beregning.

Til Bertel:
Det godt nok længe siden jeg sidst implementerede Dijkstra's algoritme, men så vidt jeg husker, bliver informationer om besøgte knuder gemt, dog vil den formentlig næppe besøge alle knuder (den er jo smart), dette er dog ret nemt at ændre. herefter vil disse så være tilgænglig for aflæsning. Denne beregning vil formentlig kunne gøres på langt under 1s. også selv om alle knuder skal tjekkes.





Til Felix:
Kombinationsmængden er ikke større end det kan beregnes mens du lever, selv med de tal du stiller op! men har du overvejet hvor du vil gemme dataene?


Under alle omstændighederne har jeg ikke tænkt mig at gemme dataerne, hvis jeg skulle ende op med at bruge en path finder algoritme.
Jeg har kun brug for at vide hvis det ikke er muligt at komme fra en given celle til en anden og evt. hvilke celler der er tale om. Derefter løses problemet på den ene eller anden måde, hvorpå der teste igen fra det punk man nåede til.

Jeg tænker dog lidt i andre retninger.
fx kunne man opstille en regel der siger at alle "vægge" i en xy, xz og/eller yz ikke må være slået til, altså der skal være mindst én gennemgang. Man kunne gøre det samme med x, y og/eller z rækker, har allerede testet det på en 2d platform og i sammenhæng "ingen lukkede celler" idéen, hvirker den ganske godt, men den løser ikke problemet.

Alt i alt må jeg sige at jeg ikke tror at en pathfinder algoritme er løsningen, men jeg tager måske fejl.


angående de data der skal gemmes, så tror jeg at der er en løsningen på første "problem" selvom det ikke er det der bliver givet udtryk for.

Jeg har brug for at gemme 256^3 * 4bit in en variabel/struktur, dog ønsker jeg at det skal fyæde så lidt som muligt, hvilket er 8MB. Jeg er blevet foreslået at bruge bitset istedet for en vector.
noget i retning.
Fold kodeboks ind/udKode 

Se det er jo uhyggeligt mange bit at manipulere med og jeg er i tvivl om hvorledes det kan/bør gøres, eller om det overhovedet er den rigtige løsning.

Jeg ved at i undrer jer over at disse sølle 8MB er så vigtige, men jeg ønsker en structur som jeg senere kan scalere hvis det skulle blive nødvendigt.

det var vist alt for nu, men tak for alle svarene, lad dem blive ved med at komme ;-)



Du kan også bruge vector<bool> den bruger også kun ét bit pr. værdi. Men det giver (lige som bit_set) en noget kluntet måde at specificere en celle. Om det er umagen værd kan man diskutere.

Hvis ikke pathfinder metoden er løsningen hvad mener du så er løsningen?



Du kan også bruge vector<bool> den bruger også kun ét bit pr. værdi. Men det giver (lige som bit_set) en noget kluntet måde at specificere en celle. Om det er umagen værd kan man diskutere.

Hvis ikke pathfinder metoden er løsningen hvad mener du så er løsningen?

Har brugt vector bool. dels så har jeg hørt at man bør undgå dette, og dels så brugte den en byte per celle.



t