Dungeons & Drawing With xTalk

A forum to share your demonstrations stacks, fun stacks, games, etc.
User avatar
OpenXTalkPaul
Posts: 1872
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Amazing Mazes With C++

Post by OpenXTalkPaul »

It's faster when NOT putting those 1s and 0s text into a text field because of the toll that I mentioned earlier, storing it in memory is better, or you could stream a file like this as chunks of lines read/written to/from a file, like in First In / First Out (FIFO) buffer.

So here's a screen of this working with input from my Piano Widget using this PBM>Image method to "Draw" a Sequence of Notes. This is storing the 1s and 0s in a custom property so that the engine doesn't need to waste time rendering that text into a text field.
MIDIPianoRollBitMapExperiments.jpg
MIDIPianoRollBitMapExperiments.jpg (135.71 KiB) Viewed 2381 times
While a key is pressed on the Piano it writes new rows to that 1s & 0s text every time my timer loop checks what notes are on highlighted on the Piano (The Piano Widget can can do chords too), and then updates the image, scaling it to fit inside the scrolling group, which only needs to render a portion of the image.
The new rows are all 127 pixels (because MIDI music notes), so I have a constant variable set up that is a row of 127 zeros, I just need to update the 0s that need to change to 1s (to represent the musical NoteOn) and add the rows onto end of the sequence container variable (or whatever sort of container you're using).
User avatar
richmond62
Posts: 3275
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Amazing Mazes With C++

Post by richmond62 »

Someone else had a go:

https://forums.livecode.com/viewtopic.p ... ze#p227755
-
Screenshot 2024-02-17 at 20.24.07.png
Screenshot 2024-02-17 at 20.24.07.png (467.35 KiB) Viewed 2375 times
-
It generates a GROUP of graphics which could be imported as a image with a single line of code.
-
Amaze.png
Amaze.png (3.82 KiB) Viewed 2374 times
https://richmondmathewson.owlstown.net/
User avatar
OpenXTalkPaul
Posts: 1872
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Amazing Mazes With C++

Post by OpenXTalkPaul »

richmond62 wrote: Sat Feb 17, 2024 6:21 pm Someone else had a go:

https://forums.livecode.com/viewtopic.p ... ze#p227755
Excellent, I'll check it out, thanks.

I've looked at that book that is mentioned, and lots of example code based on those algorithms, I've just never had the time to try to implement them.

I should say that drawing speed wise the absolute fastest x,y grids that I have been able to make have been Widgets, which (unlike classic controls which uses Cairo graphics) are rendered by libSkia, which is the same rendering engine used in Google browsers
User avatar
OpenXTalkPaul
Posts: 1872
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Amazing Mazes With C++

Post by OpenXTalkPaul »

To really answer xActions question 'over there' about SVG exporting of lists of x,y points...

This is the handlers I added to the IDE. They were added to the file revidelibrary.8, along with a menu item added to revMenubar file. They enable copying graphic controls (or a line delimited list of a bunch of graphic objects), and copies the resulting SVG File to the clipboard so that I can paste them directly into Adobe Illustrator as vector path lines with the same shapes as the graphics controls that were passed to it. I've only tested with macOS and Adobe, but they can adjust it if need be for use with Linux / InkScape or whatever.

Code: Select all

on revOXTIDEGraphicPointsToSVGPath pObjs
   -- Answer "Copy as SVG Paths" & cr & pObjs
   put the selectedObjects into tTargetObjList
   filter lines of tTargetObjList with "graphic id*"
   repeat with x = 1 to the number of lines in tTargetObjList
      put the top of (line x of tTargetObjList) & cr after tTops
      put the left of (line x of tTargetObjList) & cr after tLefts
   end repeat
   filter lines of tTops without empty
   filter lines of tLefts without empty
   sort tTops; sort tLefts
   put line 1 of tTops into tTop
   put line 1 of tLefts into tLeft
   repeat with x = 1 to the number of lines in tTargetObjList
      put graphicsToSVGPathString( (line x of tTargetObjList), tTop, tLeft)  & cr after tSVGStrings
   end repeat
   filter lines of tSVGStrings without empty
   try
      lock clipboard
      set the rawClipboardData to empty
      set the clipboardData["text"] to tSVGStrings
      put "<svg version="&quote&"1.1"&quote&" xmlns="&quote&"http://www.w3.org/2000/svg"&quote&" xmlns:xlink="&quote& \
      "http://www.w3.org/1999/xlink" &quote& " xml:space="&quote&"preserve"&quote&"><path d="&quote& tSVGStrings &quote&"/></svg>" into tSVGWrapped
      set the rawClipboardData["public.utf8-plain-text"] to textEncode(tSVGWrapped,"UTF-8")
      set the rawClipboardData["com.adobe.illustrator.svg"] to textEncode(tSVGWrapped,"UTF-8")
      set the rawClipboardData["com.adobe.illustrator.svgm"] to textEncode(tSVGWrapped,"UTF-8")
      set the rawClipboardData["com.adobe.svg"] to textEncode(tSVGWrapped,"UTF-8")
   catch tError
      Answer Warning tError
   end try

   -- put tSVGStrings
end revOXTIDEGraphicPointsToSVGPath

function graphicsToSVGPathString pTargetObj pTopOrigin pLeftpTopOrigin
   try
      if pTopOrigin is empty then
         put the top of pTargetObj into tTop
      else
         put pTopOrigin into tTop
      end if

      if pLeftpTopOrigin is empty then
         put the left of pTargetObj into tLeft
      else
         put pLeftpTopOrigin  into tLeft
      end if
      put the effective points of pTargetObj into tLinePoints
      repeat with x = 1 to (the number of lines in tLinePoints)
         subtract tLeft from item 1 of line x of tLinePoints
         subtract tTop from item 2 of line x of tLinePoints
      end repeat
      put "M " before line 1 of tLinePoints
      repeat with x = 2 to (the number of lines in tLinePoints)
         put "L " before line x of tLinePoints
      end repeat
      put cr & "Z" after tLinePoints
   end try
   replace cr with " " in tLinePoints
   if tLinePoints is not empty then return tLinePoints
end graphicsToSVGPathString
I wrote similar routines that I used in that SVG Glyphs Browser, which I also added to my OpenXTalk DPE version of the IDE some months ago.

Code: Select all

function wrapSVGPathDataToSVGXML pSVGPathData
   put "<?xml version="&quote&"1.0"&quote&" standalone="&quote&"no"&quote&"?>" & cr into pSVGXML
   put "<!DOCTYPE svg PUBLIC "&quote&"-//W3C//DTD SVG 20010904//EN"&quote&" "&quote&"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"&quote&">" &cr after pSVGXML
   put "<svg version="&quote&"1.0"&quote&" xmlns="&quote&"http://www.w3.org/2000/svg"&quote&cr after pSVGXML
   -- write "width="&quote&"128px"&quote&" height="&quote&"128px"&quote&" viewBox="&quote&"0 0 128.000000 128.000000"&quote& cr to file tFileName
   put "preserveAspectRatio="&quote&"xMidYMid meet"&quote&">" &cr after pSVGXML
   put "<path d="&quote& pSVGPathData &quote&" />" & cr after pSVGXML
   put "</svg>"  after pSVGXML
   return  pSVGXML
end wrapSVGPathDataToSVGXML
This function takes an SVG Path string, like would be used with the SVGIcon Widget or similar, and wraps it in some XML to make it into the SVG file format and returns it as the result, which you can then write to 'whatever name.svg which you should be able to import into InkScape or use for extruding to 3D in Blender.
xAction
Posts: 285
Joined: Thu Sep 16, 2021 1:40 pm
Contact:

Re: Amazing Mazes With C++

Post by xAction »

Well that was easy. Would never even have thought of setting the 'text' of an image.
MazeCollectorv8_pbm_only.oxtStack
(291.57 KiB) Downloaded 91 times
THISFILE.png
THISFILE.png (426 Bytes) Viewed 2357 times
New version retains the old scripts, but generates everything on the fly to PBM data, no graphics generated.
Right click to export your PNG.

Now to modify it for arbitrary dimensions.

The idea behind the graphics objects is they are scriptable.

Slap a script into them
bump into them with an object
something happens, a door opens, a trap is sprung, etc.
A glow effect is applied, a single pixel around the border changes, etc.

Or you can click on one and get some data from them like "Is this a door or a monster?"
Or put images in them...which I can't image writing with PBM data, yikes.

Tracking everything in virtual number space is a bit inhuman.

Here's the script for easy access:
on BinaryMazeDataToPBMImage tBinaryString
lock screen

if tBinaryString is empty then put getMazeAsString() into gMazeBinaryMazeData

--- global gMazeBinaryMazeData will contain the binary for the most recent maze

--- pMazeData will result with spaces padding the color (black/white) data of the PBM
put "" into pMazeData
repeat for each char tBit in gMazeBinaryMazeData
put tBit & space after pMazeData
end repeat

filter lines of pMazeData without space & empty --- tLineHorzLength resets to 0 if empty+space line is found!!
filter lines of pMazeData without empty

put the number of lines of pMazeData into tVertLength
repeat with y = 1 to tVertLength
put the number of words of line y of pMazeData into tLineHorzLength
repeat with x = 1 to tLineHorzLength
get word x of line y of pMazeData
if it = 0 or it = 1 then
put it &" " after tNewLine
else
put it & cr after msg
next repeat
end if
end repeat
put tNewLine & cr after tData
put empty into tNewLine
end repeat

filter lines of tData without empty
put "P1" & cr & the number of words of line 1 of tData && the number of lines of tData & cr & tData into tData

if there is not an image "Maze_PBM" then create image "Maze_PBM"
set the text of image "Maze_PBM" to empty
set the text of image "Maze_PBM" to tData

---- gGridWidth, gGridHeight should be number of rows or columns / divided by width or height of the stack
set the height of image "Maze_PBM" to tVertLength*gGridWidth
set the width of image "Maze_PBM" to tLineHorzLength*gGridHeight

set the topLeft of image "Maze_PBM" to 0,0
unlock screen
end BinaryMazeDataToPBMImage
Accidentally found an interesting side effect, if you concatenate a bunch of maze data into the text of the image, you combine the mazes into one image. Naturally if your image size remains the same dimensions, the new image data get squished into the available space.
User avatar
OpenXTalkPaul
Posts: 1872
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Amazing Mazes With C++

Post by OpenXTalkPaul »

xAction wrote: Sat Feb 17, 2024 9:52 pm Well that was easy. Would never even have thought of setting the 'text' of an image.
MazeCollectorv8_pbm_only.oxtStack
THISFILE.png

New version retains the old scripts, but generates everything on the fly to PBM data, no graphics generated.
Right click to export your PNG.
Nice! Much shorter times for rendering the mazes using pixels.
The idea behind the graphics objects is they are scriptable.

Slap a script into them
bump into them with an object
something happens, a door opens, a trap is sprung, etc.
A glow effect is applied, a single pixel around the border changes, etc.
Well there's probably 100s of ways you could go with these concepts, and probably many optimizations that could be done to speed them up further.

For my plans for the MIDI Piano Roll view controller thing I was working on, in addition to using the X plane coordinate as MIDI note number, I would use levels of opacity of the line as the Velocity Parameter for NoteOn messages (Range 0-127).
MIDI note messages has three parameters: Channel, Note or Pitch, and Velocity. Velocity is equates to 'how hard the note was pressed or plucked'. The first parameter of a MIDI NoteOn is channel, which (typically) has a range 1-9,11-16 (10 is reserved for drums in MIDI), I was thinking I can map those numbers to color, so channel 1 might be Blue, 2 orange, 3 magenta, etc. Ultimately the goal is to be able to layer these 16 'bitmaps' to get a composite image for a graphical representation that shows all the Notes of a sequence on all 16 channels (with liminosity or opacity levels as 'velocity').

I could even do that in this semi-human readable PBM text-fake binary format. Look at the Wikipedia article and the other format options available to use:
PGM example
The PGM and PPM formats (both ASCII and binary versions) have an additional parameter for the maximum value (numbers of grey between black and white) after the X and Y dimensions and before the actual pixel data. Black is 0 and max value is white. (Not shown are the newline character(s) at the end of each line.)

Example (magnified)

Code: Select all

P2
# Shows the word "FEEP"
24 7
15
0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
0  3  3  3  3  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15 15 15 15  0
0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0 15  0
0  3  3  3  0  0  0  7  7  7  0  0  0 11 11 11  0  0  0 15 15 15 15  0
0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0  0  0
0  3  0  0  0  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15  0  0  0  0
0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
PPM example
This is an example of a color RGB image stored in PPM format. (Not shown are the newline character(s) at the end of each line.)

Image

Code: Select all

P3
# "P3" means this is a RGB color image in ASCII
# "3 2" is the width and height of the image in pixels
# "255" is the maximum value for each color
# This, up through the "255" line below are the header.
# Everything after that is the image data: RGB triplets.
# In order: red, green, blue, yellow, white, and black.
3 2
255
255   0   0
  0 255   0
  0   0 255
255 255   0
255 255 255
  0   0   0
Of course it is probably more efficient to use one of the binary format and set the bits/bytes in a variable or custom property that holds the collection of 'pixels'. A graphical rendering provides the same info as the text version of the sequence, so I only need to look at the textual-numeric version while I'm debugging.

On the other side, storing the text-numbered version in a some non-visible container but NOT rendering it on screen in anyway, allows me to keep track of the 'behind the scenes' thing quickly and I can still 'put' that data into a field when I do want to look at all of the underlying numbers, quickly and easily compared to using binary data where I would first have to read bits or (single or triplets) bytes of data and convert to integer numbers that are humans can make some sense of (ie. 0 -255 number)

Or you can click on one and get some data from them like "Is this a door or a monster?"
Or put images in them...which I can't image writing with PBM data, yikes.

Tracking everything in virtual number space is a bit inhuman.
So my thinking about this format as it relates to mazes generation, solving mazes, and/or walking a 'character' around inside the maze, etc. is largely inspired by an ancient (and rather obscure it seems) HyperCard XFCN (an external function) thing that was simply called "Basic 3D View", that did a fake 3D 'rooms' ( more like hallways ) that rendered based on a text-based map info that you could pass to the external as parameter. That is the XTernal that I want to recreate (but better) for our engine:
Basic3DviewXternalViewjpg.jpg
Basic3DviewXternalViewjpg.jpg (83.96 KiB) Viewed 2348 times
So in that the 'W' character for wall, another character for open area. Characters being used to keep track of position and view to render that is front view of the 'first-person player'. A similar methods could be developed with NetPBM that used number pixel values to indicate different things within the maze, like in only the grayscale version of PBM 'image' a 50% grey pixel (127) could be your 'player', and maybe some other shade of pixel (lets say 64) represents a 'key' item to find, and another that represents a door, another for traps, or a few 'monsters' that are also moving around inside the map, or whatever else you can think of. Because we would be using a text field, all of these values can be treated 'word' chunks, so we can scan through lines of this 'level map' grid using xTalk chunk expressions, and also use it to quickly generate a graphical 'god mode' representation we can quickly peek at (my goal for this is recreating something like Atari 2600 game called Tunnel Runner, which is still fun to play IMO https://www.youtube.com/watch?v=xX0DoIp ... eRefresh=1). It would probably be MUCH faster, but perhaps even less human-friendly, to store this map as multidimensional array in memory (which you could the add attribute keys like 'monster power level' to), so any optimization like that could come later in the development process, after the logic and the rest of the game is worked out.
Keeping track of everything as 'word' values in a text field, we can do text/font things like click on words by make every word in the field be an underlined link styled text so you can them with an 'on linkClicked' handler, you could use find/replace to quickly alter your map, you could use the syntax 'set the imageSource of character to {imageID | imageName | imageURL |empty}' to alter the way characters are display in the field (for example you could use a smiley face emoji to replace your special 'player' character within the text field that's displaying your map/level, ...just a few ideas.
ATRITUNNELRUNNER.jpg
ATRITUNNELRUNNER.jpg (47 KiB) Viewed 2347 times
User avatar
OpenXTalkPaul
Posts: 1872
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Amazing Mazes With C++

Post by OpenXTalkPaul »

So what made (makes) Tunnel Runner for Atari 2600 fun for me?
Was it just that this was like my first exposure, outside of an Arcade, to incredible 1st person 3D graphics that put YOU the player INSIDE the game like Tron or something (LOL)?
No (although I'm sure there's a nostalgia at work here), it was the gameplay. The way they were able to stretch the very limited hardware capabilities of the circa 1977 Atari 2600, the manic pacing, and the manic 'music' and 'foot step' sound, and the way it was synchronized together that could get my 8-10 year old self's adrenaline going.
And also that the levels are random generated, so you couldn't just learn the level by repeat playing it.
The pacing was like: the more you went straight forward in the map the faster the frame rate would get, and the faster the sequence of musical notes too, until you slammed into a wall or a monster, if you were lucky you could stop before hitting a monster and go in reverse to not get eaten by the monster, when you did hit a monster it was a sort of manic cut-screen with the sprite of monster getting scaled up filling the screen as it swallowed you.
You could hold the fire button to temporally display the map along with the important items on the map, but the longer you held the button would drain the map peeking time you had left.
Levels would get harder by both getting faster frame speed-wise and also by showing you less information on the map view. For example, one level may not show you where the maze exit door is so you just have to find it, the next level might only show you where you've already visited on the map, the next level might not show you where the monsters are on the map view (but you can still tell when they're near by the music it would play), next the amount of time to view the map would become shorter, and so on until became nearly impossible, unless you were really 'in the zone', for me this game required the bing in 'the zone' to get far and a similar adrenaline rush that Activision's Padle game Kaboom gave me.
TunnelRunner3Dview.jpg
TunnelRunner3Dview.jpg (53.74 KiB) Viewed 2341 times
TunnelRunnerMonster.jpg
TunnelRunnerMonster.jpg (47.56 KiB) Viewed 2341 times
Oh, there were other items on the map too, like 'transporters' that would instantly (after a little cut scene) transport your player to some other random location on the map. You had to find the door key, and then find the maze exit to get to the next level. You got points for how quickly you could do the levels, and bonus points for any time you had left of your map viewing time allotment.
xAction
Posts: 285
Joined: Thu Sep 16, 2021 1:40 pm
Contact:

Re: Amazing Mazes With C++

Post by xAction »

I spent a bit of Christmas shopping money on Tunnel Runner from the Kay-Bees bargain bin, even came packaged with an awesome looking "TRON" style controller. Both were terrible. I really wanted to like that game and that controller.
I wonder how soon after viewing that 3D maze stack did Bungie start working on Pathways Into Darkness

To use PBM as a data reference format, ie, "something in this data means something else entirely to software"
Have a look at Dungeon Strikes Back
Hmm they haven't updated their website to https, your browser might say no to the downloads. Oh you'll find "DSB81.zip" in the clones folder here.

It's map editor didn't exist for...oh decades maybe, so the developer stored various dungeon elements such as doors, traps, monster spawn locations, switches, etc as colored pixels in a pbm file, as the original game stored them on floppy disks with ILBM files. In DSB the Lua scripts directly read that PBM (actually PCX) to define the in game graphic world. The color of the pixel will define what the item is, but also the wall side or floor or ceiling data the thing is attached to. Pretty ingenious.
Here's a blown up dungeon from the 0.34 version of DSB
map00_big.png
map00_big.png (1.47 KiB) Viewed 2335 times
And here's the (image filtered) dungeon's binary data in the PBM drawing stack.
DSB_To_PBM.png
DSB_To_PBM.png (28.74 KiB) Viewed 2335 times
The idea has always been to work toward that, easy to read text files are just a convenience, the mazes are just starting ...templates? for making dungeon type things, with larger rooms being the focus for some action to happen and the hallways offering decision making and maybe even strategy. And of course a program that just writes that stuff? It's like Generative Artificial Intelligence level 2 out of 10000.
User avatar
OpenXTalkPaul
Posts: 1872
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Amazing Mazes With C++

Post by OpenXTalkPaul »

xAction wrote: Mon Feb 19, 2024 6:48 am I spent a bit of Christmas shopping money on Tunnel Runner from the Kay-Bees bargain bin, even came packaged with an awesome looking "TRON" style controller. Both were terrible. I really wanted to like that game and that controller.
I wonder how soon after viewing that 3D maze stack did Bungie start working on Pathways Into Darkness
I got it with News Paper Delivery Route money from a bargain bin of a local toy shop called Discount Harry's.

To each their own, personally I love that game (and I still have that analog stick controller, but not the game cartridge). It was probably my favorite late Atari 2600 era game (probably around 1981-2-ish, I was 11-12yrs old), it had that extra long cartridge to fit additional chips inside IIRC. If you turned (tapped left or right) a just the right time before you would've slammed into a wall and stopped, you could keep going at whatever frame speed you had accelerated up to so you could really keep going full speed through much of he map. Sure you'll get tired of it after a while, but for me that's the same with most games. I'm not a big gamer these days (but all three of my sons are).

Anyway, it should be remake-able using just simple engine, basic stuff. I think the important thing to accomplish here is to create a system that draws to graphics renderings to screen based on ascii-text 'maps','levels' or game board and allows for directional controls to move characters around on that map/level/board. Graphic shapes or images can be swapped out with other graphics or even different (3D!) rendering engine later.
User avatar
OpenXTalkPaul
Posts: 1872
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Amazing Mazes With C++

Post by OpenXTalkPaul »

xAction wrote: Mon Feb 19, 2024 6:48 am It's map editor didn't exist for...oh decades maybe, so the developer stored various dungeon elements such as doors, traps, monster spawn locations, switches, etc as colored pixels in a pbm file, as the original game stored them on floppy disks with ILBM files. In DSB the Lua scripts directly read that PBM (actually PCX) to define the in game graphic world. The color of the pixel will define what the item is, but also the wall side or floor or ceiling data the thing is attached to. Pretty ingenious.
Ah, so someone already thought of it!

Well, great minds think alike :-D
A similar methods could be developed with NetPBM that used number pixel values to indicate different things within the maze, like in only the grayscale version of PBM 'image' a 50% grey pixel (127) could be your 'player', and maybe some other shade of pixel (lets say 64) represents a 'key' item to find, and another that represents a door, another for traps, or a few 'monsters' that are also moving around inside the map, or whatever else you can think of. Because we would be using a text field, all of these values can be treated 'word' chunks, so we can scan through lines of this 'level map' grid using xTalk
I was sticking with grayscale because to RGB color pixels would triple the data size, a triplet of bytes (or words in the ascii version) chunks per each pixel, while grayscale would only be 1 byte (or one 'word' the ascii text version), the one-bit binary version being the tiniest amount of bytes since you can fit 8 pixels of the map in each byte (if you're worried about fitting on floppy disk, lol).
xAction
Posts: 285
Joined: Thu Sep 16, 2021 1:40 pm
Contact:

Re: Amazing Mazes With C++

Post by xAction »

There's a reason for the colors, it's all bitwise math.
EnumAdventure.png
EnumAdventure.png (62.49 KiB) Viewed 2304 times
Enum_Adventure_v1.oxtStack
(8.55 KiB) Downloaded 103 times

so a room with everything is gray 136, but then you have some X variations of each thing
4 types of doors, 4 types of floors, 8 monsters, 8 types of chest armor, 8 types of swords,
Each of those things get their own enumeration and you run out of gray.

Kind of cool though, if we had bionic vision and brain implants we could encode whole software in a little picture.
xAction
Posts: 285
Joined: Thu Sep 16, 2021 1:40 pm
Contact:

Re: Amazing Mazes With C++

Post by xAction »

I asked Bing CoPilot to give me a list of all the elementary RPG dungeon elements and dumped that list into the old Bitwise Enumerator gizmo to see what colors come out. Grasycale will only show if the value is under 256.
Enum_Adventure_v2.oxtStack
(20.26 KiB) Downloaded 100 times
EnumAdventurev2.png
EnumAdventurev2.png (59.92 KiB) Viewed 2301 times
User avatar
overclockedmind
Posts: 300
Joined: Sat Apr 30, 2022 9:05 pm
Location: Midwest US
Contact:

Re: Dungeons & Drawing With xTalk

Post by overclockedmind »

Since this went "Dungeons," especially the 3 dimensional sort, it's become sort of inspirational to me.

The second I saw it in 3D (looking like that one Windows screensaver) I instantly remembered that a LOT of the actual battles to be had in the original Dragon Warrior for the NES were very much like this (or they were a monster with the type of place you were standing, "flat" behind it.)

And then you guys went and made it a dungeon crawler as I was reminiscing about Dragon Warrior :lol: It was sort of like you were reading my mind, very wild.

I know I've brought up a JRPG that I want to do beforehand, so I was finding just the talk of the maze as inspirational, remembering playing stuff where you typed "pick up key" and hit return and wham, you were carrying around a key. That brought me to times that I had furiously (in my younger days) made maps and other notes about a given game. Man, that's been awhile back!

I was also thinking that the mazes (even before it 'got better') could be: generate a maze, and let that be a then on-paper inspiration for levels, locations of things/baddies and the like (I say inspiration because I would personally bring the maze picture up, and then draw approximately what was on screen, just to add some variety, and then I'm sure I'd be writing stuff about what the levels were like, et al below the maze bit.)

Awesome work, my hat's off to all of you!
MBA (Early 2015, 8GB/512G SSD, Monterey 12.7.2)
System76 serv12 (64GB RAM, 2TB SSD, 2TB HD, Win 10 Pro x64)
Power Mac 3,1 Project - Needs TLC will get it soon
Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests