Plotting a dungeon

[jchase1970]

Here's how I went about it,

I picked 6 spots for rooms to appear around.

That gave me 10 paths to those 6 possible rooms which are also the path intersections.

I then randomly picked paths for each intersection to connect to another intersection. remembering if they link to intersection 1 or not.

I then gave each room a random possibility of 50% to be there or not. so you may have no rooms or you may have 6 rooms or anything in between.

The math for room placements randomly offsets the room location 0 to +-2 places. This lets the rooms be out of alignment and look less like they are tied to the 6 locations.

The last thing was to pick exit locations.

 

A few easy changes can do alot, you can make it like maze man and generate a series of mazes but storing the random seed value for each maze. Then knowing how you want these to connect you can have it not randomly put the start and exit paths in but use a calculation to have them in a linking pattern. Like wise it would be easy to add random stairs at the intersections for linking levels in a 3d fashion. These stairs would have to be stored somehow so a matching stairs is on the maze it leads to. An array would be the easiest thing to do this with.

 

I had a few errors so be sure and use the bug fixes in the second post. I Ran it with the fixes and it looks almost right. I had 1 dungeon pop up with the far right 2 intersections not accessible, I think I know why, but not to worried about it now. Think I'm going to go get some sleep

[jchase1970]

definitely cool man... I've looked over your comments, and I like this method. Very interesting. =) I am going to try to write my own, but I will more than likely end up using some of your mathematical functions. This is certainly efficient. It's interesting that you start with a possible 10 starting points that start a passageway, rather than beginning with a room. =) Certainly a different method than I was shooting for initially.

 

I'm going to play with your code a bit and see what I can incorporate into my own efforts. I'm quite a ways away from having a successful algorithm, but seeing your code is giving me some ideas for how to proceed, thank you. =)

 

 

I didn't have to draw the start path 1st because of how I designed it, see post above. Since I know my 6 intersections that all need to be connected and with it know those points I know where I can come into or exit from the maze.

 

It's kinda like the one I made on the pc except it scans the map array for a floor spot and then builds a room for it. This way is faster for the TI since I don't scan for anything, I know my possible places. But it fallows that method in building a room on a path rather then linking rooms with paths.

 

Also,

Your welcome, It was fun to come up with it glad you asked.

John

[Opry99er]

This is the hope... I want to create something VERY similar to this video for the TI.... It's Rogue. I posted this to the berylrogue thread before, but I just recently downloaded Rogue source and I'm trying to understand it... I'm not a very good source reader though. =) Especially in foreign languages

 

 

Adam's Dark Maze design does this...

 

- Plot a number of chambers on the screen

- Each are 3x3 blocks in size of empty space

- Store the center location of each into a stack for later calculation

- It's okay if they overlap, but they should stay within the boundaries

- For each chamber, plot four hallways in all cardinal directions away from the center

- If it encounters a boundary, change to a random direction

- Periodically, change to another direction

- When it encounters an empty space that's not the original chamber, end that direction for that chamber

- Random directions should use some intelligence, if it doubles back on itself it will end prematurely

 

 

I also started reading about recursing and visited the sites Matthew suggested early in the thread... I'm very much a fan of the idea of the maze generating "on the fly", or each time you reach a new "level". =) I'll be playing with this some more today... BTW, if you guys haven't read Matthew's HK program description, you should... it's pretty cool how he designed that program. In assembly, takes less than a second. In XB, it takes minutes. =)

Edited November 18, 2010 by Opry99er

[Opry99er]

Hey John... I assume your method could be adapted to work on a larger scale? Say, 80x80? I had thought about trying this out in assembly and populating a block of memory with generated map data and using it to experiment on this principle... I will try several methods before I'm happy, I'm sure... =) I really like the way that Rogue video looks...

[jchase1970]

Original Rogue maps are very much like what I gave you for the TI. Rouge maps are a map of 9 possible rooms always in the same 9 spots. As mine used only 6 possible rooms.

 

In Rogue they generate the map for the level when you enter the level. Then as you move around you explore it and discover the map. I was working on a TI-Rouge but never finished the map structure on it. It's still on the back burner of something I want to do. My problem I had was finding a good way to store the info per level of what was explored and visible. It easy to pop the rooms onto a stack and store a flag if it has been explored yet or not, but I never came up with a good method for the hallways since each step into a hallway reveals just 1 more step.

[Opry99er]

Very good info to have... =)

 

I have your program running on my emulator right now... I've been watching it generate rooms for the last 10 minutes. =)

 

BTW, Adamantyr's Dark Maze reveals one step at a time too. VERY neat how that program works. I've been playing it more and more lately... It's really quite informative.

Edited November 18, 2010 by Opry99er

[jchase1970]

Rouge is a test to reach the bottom of a 100 level dungeon. The PC version was in 80 column mode and I believe it stored the whole map per each level as it created it in memory. But again I'm not sure how to do this on the TI with only 16k to work with.

 

I'm just rattling some stuff off here as I work though some of the math...

 

method 1

Simplest way to store map as an array of bytes after it is created but way to much memory usage. 80x23 map size 1840 bytes per level. 184k per the 100 levels. of course the ti screen would be 32x23 or 736 bytes, but still huge for 100 levels

 

method 2

store room info

location x,y 2 bytes

size x,y 2 bytes

has it been revealed 1 byte

5 bytes per room time 9 possible rooms 45 bytes

 

Hallways ??????

each hallway section has 3 bytes x,y, has it been revealed?

if limit total hallway segments to 256/3 or 85 then you could use 1 string of 256 bytes to store the info.

85 total hallways segments is doable on the smaller TI screen.

 

so total memory needed per level is 256+45, 301 bytes per level

 

 

So that is one way.

If TI had Bit variables you could store the 'has it been revealed' flag in a single bit. which would save around 50 bytes per level.

 

 

So I'm still not sure how to go about this. Of course the easiest way would be a one way dungeon where you can't go back to levels you already were on. But that wouldn't be Rouge as in Rouge you need to go back levels to go to shops and increase XP by fighting the randomly generated monsters again. But this would be a option so you wouldn't have to store the levels.

[jchase1970]

I'm not sure how the original Rouge was but I think I read somewhere it was a one way trip down. I do know that not every game of Rouge is winnable. Everything is randomly generated, that includes weapons,potions,monsters, so the game can spawn high level monsters to soon and you can't kill them, you may never find the right potions or weapons or armor you need to beat the dragon at the end. But that was the appealing thing about it. Not if you beat it but how far into the dungeon you could get.

[Opry99er]

I like that "one way" option.... I think that would be a possibility.... Additionally, 100 levels is probably unnecessary, but that is inconsequential... I need to figure a way to generate a 64x48 dungeon in the Rogue model (2x screens high by 2x screens wide) and once we get a working model there, the number of levels can be determined later on. For now, though... I will try to focus on a simple 32x24 fullscreen model. I would like some more twists and turns in the passageways I'm digging--- I'll be on this most of the day today.

[jchase1970]

Here is something else I was working on on the PC last year. It's the random world map generator. I tried several ways of making random worlds, this is the fastest I could get to work. It's uses a fractal method.

 

Press the spacebar to make another map and esc to exit.

 

 

 

I wanted to make a fully randomly generated world, I have tables made to generate hobbles,villages,towns,cites, random dungeons. All kinds of stuff, but it all became way to much for a one man team to do.

fract landscape.zip

[Opry99er]

Wow--- that's pretty fascinating. . I'll be home in about an hour and I'm looking forward to trying this.

[Opry99er]

My problem I had was finding a good way to store the info per level of what was explored and visible. It easy to pop the rooms onto a stack and store a flag if it has been explored yet or not, but I never came up with a good method for the hallways since each step into a hallway reveals just 1 more step.

 

In assembly this would actually be very fast... Simply keep a pointer at the given map location and do a VSBW to immediately display the next step in the passageway. If we use the visual model of the video I posted earlier, there is no need for scrolling--- so the whole process becomes very simple...

[jchase1970]

Here's a sub to draw a random horizontal path, I'll leave it to you to make a vertical path one and put it into the program.

 

I did add it to the program and it looks nice except the original path connecting logic needs to be fixed because it can draw lines connecting 2 points from 2 of the 6 set points and therefor can draw a line over where a line is, for ex the top left point can try to connect to the bottom left point but when it plots paths from the bottom left it's doesn't know if a path already exist to the top left point and may choose to make one even if one is already there.

 

1 CALL CHAR(34,"108004200108A002")
7 Y=INT(RND*24)+1
8 CALL CLEAR
10 CALL HLINE(1,Y,31)
20 GOTO 7

300 sub hline(x,y,l)
301 py=y::px=x
rem plot beginning and end
305 call hchar(y,x,34,1)::call hchar(y,x+l,34,1)

rem go up or down and plot 
307 M=INT(RND*3)::IF M=2 THEN M=0::GOTO 309
308 IF M=0 THEN M=-1 ELSE M=1

REM NOW CHECK FOR IN RANGE
309 IF ABS(PY+M-Y)<INT(L/2) THEN 312  

REM IF OUT HIGH THEN LOWER 
310 IF PY+M-Y<0 THEN M=1::GOTO 312
311 IF PY+M-Y>0 THEN M=-1

rem check for in INbounds 
312 IF PY+M<1 THEN M=1 :: GOTO 314 
313 IF PY+M>24 THEN M=-1 
314 PY=PY+M

rem plot
320 call hchar(py,px,34,1)

rem move right 1
330 px=px+1
331 l=l-1
rem plot
332 call hchar(py,px,34,1)

rem l>0 ? then move right again
340 if l=1 then 350
341 px=px+1
342 l=l-1
rem plot
343 call hchar(py,px,34,1)

344 if l>1 then 307
rem connect vertically
350 if abs(py-y)=0 then 370
360 if py>y then call vchar(y,px,34,2) else call vchar(py,px,34,2)
370 subend

Edited November 18, 2010 by jchase1970

[matthew180]

I love mazes for some reason, but at the same time they can be boring. Too complicated and boring to solve in a first-person perspective, usually too easy when you can see the whole maze from the top. The idea of making a "dungeon" is much more appealing, and it also lends to games that usually involve monster and combat, so there is an aspect of fun.

 

Anyway, long ago I went searching for maze and dungeon generating info and site on the web. Any Google search will quickly turn up the "Think Labyrinth" website, and in particular the "Computer Mazes" section:

 

http://www.astrolog.org/labyrnth.htm

http://www.astrolog.org/labyrnth/maze.htm

 

I highly recommend you lose yourself on that site for a day or two (it would take about that long.) Good maze stuff in there.

 

Also, on my quest for "dungeon generation", I found this site where the guy is making a game for his kids and he describes a recursive back tracker (one of the images):

 

http://foothills.wjduquette.com/archives/001000.html

 

On a subsequent page he talks about the dungeon problem:

 

"Perfect mazes can be fun to solve, but they really don't make very good dungeon levels."

 

He then goes on to demonstrate a method to make the maze more sparse (another one of the attached images (I can't control the order)):

 

http://foothills.wjduquette.com/archives/001014.html

 

 

Finally there is, what I consider, the best dungeon site not on the Internet (it is gone now.) Back when this site was up, it was very cool. Luckily we have the Wayback Machine and they even saved the zip files where the guy (Jamis Buck) provided the source code! I have downloaded all of it and I'm looking into setting it up on my own server. I don't know what happened to Jamis Buck, but the site was cool and his method work really well.

 

http://web.archive.org/web/20080203123815/www.aarg.net/~minam/dungeon_design.html

 

He describes how he makes a maze into a dungeon. On those pages, as a download, is also an offline windows version of the generator. I ran it an included the dungeon it generated (another one of the images), as well as the text it generated describing each room, its contents, booty, etc. The program will export a dungeon as a PNG for the map, and RTF for the room descriptions.

 

 

 

Room #1:

Door (east, 4 from north):  wooden, good, stuck
Door (west, 4 from north):  wooden, simple, stuck
Door (south, 2 from west):  iron, locked, trapped
 [trap: pit trap (40 ft. deep) (CR2) (Find/Disable DC 21)]

Features:

corpse (adventurer)
teeth
lamp
hay (pile)


Room #2:

Door (west, 2 from north):  wooden, good, free

Monsters:

krenshar (1)

Treasure:

400 silver coins (40 gp)
Holy water (2) (50 gp)

Features:

dice
carving
iron bars


Room #3:

Door (east, 1 from north):  wooden, good, stuck

Empty


Room #4:

Door (west, 5 from north):  (secret) side-sliding, gesture trigger, trapped
 [trap: scything blade trap (CR1) (Find/Disable DC 21)]

Monsters:

Whargar, male dwarf (hill) War1:
 CR 1; Size M (4 ft., 0 in. tall); HD 1d8+1; hp 9; Init +2 (+2 Dex);
 Spd 20 ft.; AC 12 (+2 Dex); Attack +4 melee, or +3 ranged;
 SV Fort +3, Ref +2, Will -2; AL LE;
 Str 17, Dex 14, Con 13, Int 9, Wis 7, Cha 8.

Languages Spoken:  Common, Dwarven.

Skills and feats:
 Appraise +1, Craft +1, Hide +2, Intimidate +3, Listen +0, Move silently +2, Spot +0; Alertness.

Possessions:  900 gp  in gear.


Treasure:

720 gold coins (720 gp)
gemstone - sardonyx (70 gp)

Features:

flint and tinder
discarded weapons
rack


Room #5:

Door (south, 3 from west):  (concealed) wooden, simple, free, behind rubbish, trapped
 [trap: pit trap (20 ft. deep) (CR1) (Find/Disable DC 21)]

Monsters:

Qillanna, female elf (high) War1:
 CR 1; Size M (5 ft., 0 in. tall); HD 1d8+2; hp 10; Init +3 (+3 Dex);
 Spd 30 ft.; AC 13 (+3 Dex); Attack +4 melee, or +4 ranged;
 SV Fort +4, Ref +3, Will +0; AL CE;
 Str 17, Dex 16, Con 14, Int 10, Wis 10, Cha 13.

Languages Spoken:  Common, Elven.

Skills and feats:
 Climb +7, Hide +3, Listen +2, Move silently +3, Ride +7, Search +2, Spot +2; Track.

Possessions:  900 gp  in gear.

Amos, male elf (high) War1:
 CR 1; Size M (5 ft., 3 in. tall); HD 1d8+1; hp 9; Init +3 (+3 Dex);
 Spd 30 ft.; AC 13 (+3 Dex); Attack +4 melee, or +4 ranged;
 SV Fort +3, Ref +5, Will -1; AL CE; Str 16, Dex 16, Con 13, Int 11, Wis 8, Cha 13.

Languages Spoken:  Common, Elven.

Skills and feats:
 Disable device +2, Hide +3, Intimidate +3, Intuit direction +0, Listen +1,
 Move silently +3, Search +2, Spot +1; Lightning reflexes.

Possessions:  900 gp  in gear.


Treasure:

30,400 silver coins (3040 gp)
+2 longsword, keen
- Int 12, Cha 10, Wis 8 communicates by Semiempathy, Neutral good
- Magic missile (200-ft. range, 3 missiles), 3/day
- Ego: 6 (28315 gp)

Features:

cracks
box
pole
corpse (monster)
table (large)

Hidden Treasure (Search DC 21):

100 gold coins (100 gp)

Trap:

spiked pit trap (20 ft. deep) (CR2) (Find/Disable DC 21)


Room #6:

Door (east, 3 from north):  wooden, simple, free

Monsters:

fire beetle, giant (vermin) (3)

Treasure:

80 silver coins (8 gp)


Room #7:

Door (north, 2 from west):  wooden, strong, locked

Monsters:

centipede, medium-size monstrous (vermin) (2)

Treasure:

120 silver coins (12 gp)


Room #8:

Door (west, 4 from north):  wooden, good, free
Door (east, 3 from north):  iron, locked

Features:

urn
corpse (adventurer)
charcoal bin
chest of drawers
iron bars


Room #9:

Door (east, 3 from north):  stone, free, trapped
 [trap: spiked pit trap (20 ft. deep) (CR2) (Find/Disable DC 21)]

Trap:

hail of needles (CR1) (Find/Disable DC 21)


Room #10:

Door (north, 4 from west):  iron, locked

Monsters:

hobgoblin (1)
goblin (2)

Treasure:

32 platinum coins (320 gp)
160 gold coins (160 gp)
gemstone - banded eye agate (14 gp)
gemstone - white opal (1000 gp)
potion: ghoul touch (300 gp)


Room #11:

Door (north, 3 from west):  wooden, strong, free, side-sliding

Monsters:

fire beetle, giant (vermin) (4)

Treasure:

22 gold coins (22 gp)


Room #12:

Door (east, 1 from north):  wooden, strong, stuck

Empty


Room #13:

Door (east, 5 from north):  (concealed) false wall, stuck

Monsters:

darkmantle (1)

Treasure:

95 gold coins (95 gp)
gemstone - pink pearl (110 gp)
Masterwork greataxe (320 gp)

Features:

paint
portcullis


Room #14:

Door (south, 4 from west):  wooden, good, locked, trapped
 [trap: poison needle trap (CR2) (Find/Disable DC 21)]

Features:

equipment (broken)
manger
hole
tapestry

 

 

 

All the source is available except for his "Town" generator. I'll let you know if I get it up and running on my server.

 

Enjoy!

 

Matthew

maze.rtf

Edited November 19, 2010 by matthew180

[Opry99er]

Yea, I've been reading that website for a couple days now. =) Lots of info... the theory of it is very cool... I'm becoming enamored with this process... You might call it a slight obsession. =)

 

You guys want to see something absolutely incredible?

 

http://www.astrolog.org/labyrnth/maze/largest.zip

Edited November 19, 2010 by Opry99er

[Opry99er]

You know, in reading more on the internet... I've been looking at this the wrong way... bear with me:

 

The entire process of building a dungeon comes from the mind. In my mind, I lay out the map, develop the passageways, plot chambers, populate it with items, monsters, etc. However, as I started trying to develop my dungeon generating program, I started by thinking about system limitations, display syntax, etc... I started thinking, "How can I plot outward from a chamber going "up" or "left" when there is no "REVERSE HCHAR" or "UPSIDE-DOWN VCHAR". Then I walked away from the code I was trying to hack together and started reading.... on both Adam's and Matthew's suggestions.

 

Reading the link Matthew posted by Jamis Buck, he described how he developed his algorithm part by part and then ended the article by saying:

 

All that remains is to display the dungeon, and that has nothing to do with dungeon generation algorithms.

 

And then it struck me. The method by which a dungeon is developed has "nothing to do with" displaying it!! Like Adam suggested earlier, I went back to my graph paper and REALLY started thinking about "why" I was drawing it the way I was.... THAT is the algorithm... What happens after that is really inconsequential to the maze itself. =) The maze algorithm exists and mazes are generated EVEN IF you never display them... This may not be "groundbreaking" to some of you, but for me it was a nice slap in the face.

 

 

I don't know how I am going to use this new knowledge... I tried to read the C/C++ source code that exists online for several different maze/dungeon generating algorithms, but it may as well have been written in Chinese... My next step is to determine what my mental process is... what "makes up" my algorithm. =)

[jchase1970]

My source for my mazes I included in the file is basically the same thing Jamis Buck and is in a hybrid basic format. What he calls SPARSENESS I made a function call DILUTE and that function is used after the maze is made, because that alters a maze, nothing to do with creating it.

 

The actual function to generate the maze could be converted to TI basic really easily.

 

Function generate_map(xsize,ysize,straightness)
SizeX      = xsize
SizeY      = ysize
Open       = 2
NotOpen    = 3
AllChecked = SizeX*SizeY
LastDirection = Rand(0,3)
North      = Open
South      = Open
East       = Open
West       = Open 
TimeUp     = False

Function is like declaring a SUB in TI, the rest here is just predefining variables.

 

 

;make map array fill with walls
Dim map(SizeX-1,SizeY-1)
For x=0 To SizeX-1
For y=0 To SizeY-1
Map(x,y) = Wall
Next
Next

next is just making an array to hold the maze and setting it to all walls. At the beginning of the file I define wall=4 and flr=5

 

 

Repeat
Moved = False
NumFailedMoves = 0
ChangeDirection = True

this is the beginning of the loop to repeat the algorithm need a couple of flags reset.

 

 

;check strightness factor
;otherwise random percent chance
If Rand(1,100) < straightness Then 
	ChangeDirection = False
	Dir = LastDirection
EndIf

here is a check for how straight the maze will be, it's nothing more then pick a random number between 1 and 100 and compare it to the straigthness factor using a IF THEN

 

 

Repeat
;pick a direction to move at random
If ChangeDirection = True Then 
	Dir = Rand(0,3)
	LastDirection = Dir
EndIf

ChangeDirection = True

Select Dir
;north
Case 0
	If North = Open Then 
		Moved = True
		CurrentY = CurrentY - 1
	EndIf
;south
Case 1
	If South = Open Then 
		Moved = True
		CurrentY = CurrentY + 1
	EndIf
;east
Case 2
	If East = Open Then 
		Moved = True
		CurrentX = CurrentX + 1
	EndIf
;West
Case 3
	If West = Open Then 
		Moved = True
		CurrentX = CurrentX - 1
	EndIf
End Select

Until Moved = True 

SELECT and CASE is the same as ON GOTO here I pick 1 of 4 directions and see if it's ok to move to

 

 

ECT...

 

The maze is created in a 2d array and when it needs to be shown it as simple as

For x=0 To SizeX-1
For y=0 To SizeY-1
If map(x,y) = Wall Then Rect x*10,y*10,10,10,1
Next
Next 

2 nested FOR NEXT loops reading the array line by line and drawing a box when there is a wall

 

 

 

Looking at it now I see several things I can do to make it better, but that is true with all programs. I included the code for you to look at hoping you would see it is just basic without line numbers and easy to fallow along with.

 

You could add line numbers and put in TIBasic commands and this would work on the TI with only minor changes

Edited November 19, 2010 by jchase1970

[Opry99er]

Excellent!! John, you're a wealth of knowledge. I am truly blessed to know you, Matthew, Adam, and all the great minds on here. It's making more sense now---

 

I'm still not on you guys' level, and I'll be the first to say that I'm pretty dense... But I'm motivated.

 

I really need to work on my understanding of (x) dimensional arrays... The ARRAY is where the map is created... Displaying is secondary. Thanks again

Edited November 19, 2010 by Opry99er

[jchase1970]

In this case, making a maze or map, Think of the array as nothing more then a piece if graph paper. Or the character spaces on the screen.

 

dim maze(24,32)

 

A maze that fits full screen on the TI 24 tall and 32 wide.

 

 

 

Next think of several pieces of graph paper in a book, that's a 3 diminsional array.

 

dim maze(24,32,10)

 

10 pages, or screens that are set to TI fullscreen size.

 

 

 

Now if you pre generate those 10 pages of mazes you are storing 10 pages in memory.

so to display page 1 you have this

for x=1 to 32

for y=1 to 24

if maze(y,x,1)=1 then call hchar(y,x,33)

next y

next x

 

the 1 in the maze(y,x,1) point to page 1

then character 33 would be a wall tile

the array will be full of walls and floors walls are 1 floors are 0

no need to have a if then for floors Because we only have 2 options draw or not draw, the floor is there by not drawing.

[+adamantyr]

And then it struck me. The method by which a dungeon is developed has "nothing to do with" displaying it!! Like Adam suggested earlier, I went back to my graph paper and REALLY started thinking about "why" I was drawing it the way I was.... THAT is the algorithm... What happens after that is really inconsequential to the maze itself. =) The maze algorithm exists and mazes are generated EVEN IF you never display them... This may not be "groundbreaking" to some of you, but for me it was a nice slap in the face.

 

Congratulations! Perceiving the difference between design and the code itself is an important step in any software development.

 

Adamantyr

[Opry99er]

Great stuff... Manipulating an array is much easier than manipulating the screen... I just had a cool success on my end here--- I'll post my first algorithm when it is complete-- should be tomorrow. Thanks again guys.

[matthew180]

And then it struck me. The method by which a dungeon is developed has "nothing to do with" displaying it!! Like Adam suggested earlier, I went back to my graph paper and REALLY started thinking about "why" I was drawing it the way I was.... THAT is the algorithm... What happens after that is really inconsequential to the maze itself. =) The maze algorithm exists and mazes are generated EVEN IF you never display them... This may not be "groundbreaking" to some of you, but for me it was a nice slap in the face.

 

It is always groundbreaking for everyone individually. Like Adam said, these are the kinds of steps you go through as you practice computer science. I didn't have my "Ah Ha" of Data vs. Presentation until long into my "career". Now that you understand that concept, let me give you a few other "names" for it that you may have seen elsewhere:

 

MVC: Model (the data), View (what you see), Controller (glue code/logic). Invented in Smalltalk, made popular in the last decade. Heavily used now, even in places where the method does not make sense (people love to use the same tool for all jobs.)

 

MDI: Multiple Document Interface. This is a Microsoft "thing", but applies to any OS where you have multiple child windows that belong to the same application (like having more than 1 image open in graphics programs).

 

Beryl Scroller: Invented by ... Sorry, could not resist. However, the same idea was used in that code. The "data" has nothing to do with the display. The game is played in memory, specifically in the array in high memory where the virtual representation exists. Drawing on the screen is simply taking part of that data and interpreting it for the screen.

 

Remember what I said about the screen being an "output only" device? If you are using GCHAR then you are doing something wrong IMO (exceptions to follow). However I realize that BASIC (XB included) has serious limitations and you don't have time to transfer 768 bytes from memory to the screen every 60th or 30th of a second. Actually you don't even do that in assembly; not on older computers anyway. Modern games (even 2D ones) simply redraw the entire screen every frame, which is required for FPS games anyway. If you have time (CPU runtime, i.e. a fast enough modern computer) then redrawing the screen simplifies things immensely. However, graphical OSes don't redraw the display every frame either. They have this idea of a "dirty rectangle" which identifies those parts of the screen that need to be updated. We do that kind of thing too, since it means we only need to update what changed (which is usually a very small part of the screen.)

 

The sad thing about BASIC and using an array to represent the screen is that BASIC stores arrays in VDP RAM... So, you don't get faster access to your memory like you would on a system that stores variables in CPU RAM. So in this case, GCHAR might be your friend. An alternative could be to use an assembly routine to store data in the low memory and also a routine to update the screen from that memory. Or, just use assembly from the start.

 

 

I don't know how I am going to use this new knowledge... I tried to read the C/C++ source code that exists online for several different maze/dungeon generating algorithms, but it may as well have been written in Chinese... My next step is to determine what my mental process is... what "makes up" my algorithm. =)

 

C is not that hard really, and the syntax was adopted in some form by many other languages (loosely using the term) out there including PHP, JavaScript, Java, C++, and C#. While you may not need to learn C (or something close), you should get familiar enough with the syntax to read the code. Code reading is where you will get some of your most important "Ah Ha!" moments, and avoiding looking at code because "it is written in C, and I don't know C", is a "bad thing". The language itself is not hard, people make things hard. Anyone can write really bad confusing code using any language, including BASIC. But that does not stop you from reading programs like MazeMan, or the programs posted in the contests here. Apply the same thinking to any code you read, even if you don't know the language.

 

All languages need to do the same things in some form: conditions, branching, loops, logic, and data storage. In BASIC you write "IF A<>0", in C you write "if (a != 0)", not so different really...

 

What really makes reading code hard is understanding the idea or algorithm behind what the code is doing. I read an article about a husband / wife team who wrote the original "Dragon Voice Recognition" software that IBM eventually bought. The article was about "deep code" and that even someone who had been programming for 20 years (which I have) would not be able to understand the code (which I couldn't) without understanding the science of voice recognition (which I don't).

 

What I'm trying to stress here is, don't be afraid of the syntax, that's not the hard part. Understanding the underlying science of what the code is doing, that's the hard part and has nothing to do with programming. However, code can be a common ground between sciences. I don't understand mathematics notation very well (nothing past basic notation like y = x(f) or whatever), so when I'm reading a book with that kind of theory I glaze over. But, if there is an implementation of the theory in a code example, then it is being written in such a way that I can understand what is happening (for y=0 to x). Through code I can understand what the person was trying to say with mathematics, and eventually I can understand the science. Then the next time I see that mathematics notation I can say "oh yeah, that's how they write a FOR NEXT loop". Ah Ha!!

 

Matthew

Edited November 19, 2010 by matthew180

[Opry99er]

That's alot to take in. =) Thank you, Matthew. I'm going to take some time here and study and experiment. When I re-emerge, I should have something worthwhile. =) And the Beryl scroller you wrote is still my favorite piece of code I've seen so far. Clean, crisp, effective, and innovative. Looking at mine, I was really predicating my scrolling on the visual elements of the "map". I realize now that it's DATA... it's a very cool revelation. It's like I took my sunglasses off and I can see more clearly. =) Very cool stuff.

[jchase1970]

http://www.youtube.com/watch?v=NkwJ-g0iJ6w

[Opry99er]

I often like to take on projects that are problematic.... It would be relatively easy for me to write several "Honeycomb Rapture" clones which are multiple moving SPRITEs and one check for collision... I could crank out as many of these as I wanted and increase my game library drastically... But I've already done it... It's not challenging for me anymore... In XB anyway. Calimari Carl is pretty much that very thing... Save for the wrinkles like collecting treasure and oxygen tanks as opposed to reaching the honeycomb... But we know what happened there-- I lost interest in that project. So I move to something more mentally stimulating and get lost in it until I

 

A) succeed

B) get frustrated and move on

 

I think much of the reason for this is that I do this stuff because it's fun to learn. Assembly is hard for me, but it'd a challenge to figure out how to manipulate a machine as opposed to writing line numbers... This maze algorithm is hard for me to grasp, but for some reason I am really excited about it.

 

What does any of that mean? Just that I am glad I haven't gotten frustrated and gave up... That has been a problem for me over the years in many areas of my life... I've been coding (if you can call it that) for 2 years and I'm only just now starting to "get it." That's exciting.