Another 4D game in the works :-)

[quickfur]

Kudos to pat for attempting to make a 4D game. I still have reservations about the way 4D rendering is done, but hey, who am I to complain since I haven't done better myself. :-) Anyway, in my discouragement in still not having successfully programmed a sane 4D->3D->2D projection (which requires a sane way to unambiguously represent transparent surfaces, which is much, MUCH harder than it sounds), I decided to temporarily put aside the visualization part of a game, and go back to a slices approach.

And so I wrote a character-based 4D maze game, ala Nethack. Basically, it shows you a tetracubic slice of the maze using a 2D array of planes, suitably slanted to give an illusion of isometric projection. (If you like, this would be the view of a 5D being playing a maze game on a 4D screen. ) Here is a screenshot:

http://eusebeia.dyndns.org/~hsteoh/4maze/4maze-1.txt

NOTE: the above URL has been updated.

In the screenshot, the player is represented by the '&' in the center. Walls are represented by '/', and parts of the maze hidden from view are represented by ':'. The '@' is the exit portal, and the '$'s are items that you must collect before you can enter the exit portal. And yes, there is visibility clipping, just to make things harder. The current visibility code isn't ideal, since it can "see through" walls diagonally but the player can't move diagonally (it may seem nice to be able to move diagonally, but believe me, you don't want to deal with 79 possible directions from every location), but it does give you teasing peeps at passages you haven't been to and don't know how to reach. :-)

It's fun to be able to actually navigate a 4D maze without needing to understand projections and maintain your orientation, but focus on the actual geometry of the place. And I must say, this is hard. I thought I had 4D visualization down until I played my first non-trivial maze. The way passages can twist in 4D is just extremely difficult to keep track of, and it's extremely easy to get lost even though your orientation is fixed.

Anyway, if people are interested, I may put the code up somewhere. Currently, it needs a Unix-like OS (or CygWin) to work, unless somebody can be bothered to port it to conio.h or something like that.

Also, once I finish up with a new, looping maze generator, I'll add more gameplay elements to it, such as items (other than the gold you have to collect), and maybe some kind of storyline, and eventually a 4D city.

Comments?

[bo198214]

I decided to temporarily put aside the visualization part of a game, and go back to a slices approach.

hahaha

If you like, this would be the view of a 5D being playing a maze game on a 4D screen. )

Oh, you mean the character can walk into all 4 directions as on the surface of a 5d planet ...

Anyway, if people are interested, I may put the code up somewhere. Currently, it needs a Unix-like OS (or CygWin) to work, unless somebody can be bothered to port it to conio.h or something like that.

If you want it to be widely used, provide either executables for the common OS's or make a webpage for online playing (for example program also html output and make a cgi of it).

Also, once I finish up with a new, looping maze generator,

Oh I would like to have also some hand picked mazes.
(if you omit all the effort for visualization then you have to balance it by put the effort into mace making.)
Does it make sense to use 3d torus and 3d sphere and some otherwise knotted 3d walls?

[quickfur]

I decided to temporarily put aside the visualization part of a game, and go back to a slices approach.

hahaha

If you like, this would be the view of a 5D being playing a maze game on a 4D screen. )

Oh, you mean the character can walk into all 4 directions as on the surface of a 5d planet ...

You could think of it like that. Or you could think of it as a Descent-style movement where you can move in all 4 directions freely (not confined by gravity).

Anyway, if people are interested, I may put the code up somewhere. Currently, it needs a Unix-like OS (or CygWin) to work, unless somebody can be bothered to port it to conio.h or something like that.

If you want it to be widely used, provide either executables for the common OS's or make a webpage for online playing (for example program also html output and make a cgi of it).

The main problem is that I don't have Windows at home, and therefore don't have access to a Windows C++ compiler. If you do, I'd appreciate any help in making the code portable (and in building executables on my behalf). This might take a lot of effort, though, unless there is a Curses/Ncurses port to Windows that has most of the same functions. But it might be worth the effort.

Also, once I finish up with a new, looping maze generator,

Oh I would like to have also some hand picked mazes.
(if you omit all the effort for visualization then you have to balance it by put the effort into mace making.)

Or story writing. I've just added a (preliminary) story mode to the game, where a storyline (admittedly rather contrived) sorta provides an excuse for leading the player through increasingly difficult mazes.

Does it make sense to use 3d torus and 3d sphere and some otherwise knotted 3d walls?

Why not? It'd have to be suitably "pixelated", though, since movement is limited to the 8 cardinal directions.

I was also toying with the idea of generating a maze where movement is across the surface of a 24-cell, or maybe a suitably pixelated duocylinder. Maybe I'll make a 4D building in the shape of a 24-cell... you wouldn't be able to tell it was a 24-cell, though, unless you were looking for it. The interior of a 24-cell is surprisingly simple.

[bo198214]

The main problem is that I don't have Windows at home, and therefore don't have access to a Windows C++ compiler. If you do, I'd appreciate any help in making the code portable (and in building executables on my behalf). This might take a lot of effort, though, unless there is a Curses/Ncurses port to Windows that has most of the same functions. But it might be worth the effort.

Hm, I have windows but only the cygwin tools (including gcc). Dont know whats needed to compile.
What about the other possiblity of putting it on a server. You have a home page but do you have also server access? Does it allow execution of cgi-scripts?

sorta provides an excuse for leading the player through increasingly difficult mazes.

*g*

Does it make sense to use 3d torus and 3d sphere and some otherwise knotted 3d walls?

Why not?

Hm, I mean it is also not that thrilling to put the knotted 2d surfaces (sphere, torus, sphere with handles) in a 3d mace. The appeal of a mace seems not to lie in the topological structure of the walls. (Another thing is if the space of the mace itself is a certain topological structure, e.g. if a 2d mace is located on a sphere with handles or on a Klein bottle, but that would be already quite puzzling in 3d mace. Though the Poincare conjecture was the most difficult to prove in 3d, so maybe the topology of 4d manifolds is again simpler (???)). Thatswhy even 2d maces are interesting (where the walls can at most being homeomorphic to the circle).

[quickfur]

The main problem is that I don't have Windows at home, and therefore don't have access to a Windows C++ compiler. If you do, I'd appreciate any help in making the code portable (and in building executables on my behalf). This might take a lot of effort, though, unless there is a Curses/Ncurses port to Windows that has most of the same functions. But it might be worth the effort.

Hm, I have windows but only the cygwin tools (including gcc). Dont know whats needed to compile.

If you have cygwin + gcc, you should be able to compile the game with no modifications. But making an executable that can run on Windows installations without cygwin is another story.

What about the other possiblity of putting it on a server. You have a home page but do you have also server access? Does it allow execution of cgi-scripts?

I have full root access to the server. The problem, though, is how to interface the game with a cgi script. It requires true interactivity, which is a bit tough to program with a cgi interface. Maybe some sort of telnet server might be appropriate here, although I'm a bit reluctant about doing this until I know the full security consequences of this. (One bad thing about running a public server is that you never know who's paying you a visit... I've had all sorts of things from port scanning to password guessing to web server exploit attempts. Fortunately none of it worked, but I wouldn't take comfort in that.)

sorta provides an excuse for leading the player through increasingly difficult mazes.

*g*

Does it make sense to use 3d torus and 3d sphere and some otherwise knotted 3d walls?

Why not?

Hm, I mean it is also not that thrilling to put the knotted 2d surfaces (sphere, torus, sphere with handles) in a 3d mace. The appeal of a mace seems not to lie in the topological structure of the walls.

I'm not sure I understand what you're getting at here.

(Another thing is if the space of the mace itself is a certain topological structure, e.g. if a 2d mace is located on a sphere with handles or on a Klein bottle, but that would be already quite puzzling in 3d mace. Though the Poincare conjecture was the most difficult to prove in 3d, so maybe the topology of 4d manifolds is again simpler (???)). Thats why even 2d maces are interesting (where the walls can at most being homeomorphic to the circle).

Well, in terms of topological structure, I don't think a 4D maze is that much more "interesting"... what's particularly interesting about a 4D maze, at least in my experience when playtesting countless 4D mazes, is the discovery of such things as a passage turning and twisting in an unexpected way that can only happen in 4D, that makes you go, Oooh, right, of course! In 4D you can turn like that!

Right now, I've only made non-looping mazes (although in an earlier testing version of the game I did have highly looping mazes), with star topology and tree topology. In terms of topology, these aren't all that interesting; but what is interesting is that sometimes you miss a branch in the tree because visually, you still make unconscious assumptions that are only valid in 3D. Then later on, you suddenly realize, oh wait, there are really eight possible directions from any given location in 4D! I need to go back and re-explore that intersection.

Or, you spot another location in the maze that you can't reach from a particular place, and then you find the tunnel nearby that leads to it, which twists "past" the other places your mind has unconsciously modelled as an impassible 3D region, and then you realize, wow, so 4D really does let tunnels tangle up in ways you'd never expect!

Anyway, maybe I should put up the current snapshot of the code, just so people with cygwin or a native *nix system can give it a twirl and give me some feedback.

[quickfur]

Hmm, interesting. I've just found this:
http://pdcurses.sourceforge.net/
It's a Windows port of the (n)curses library which my game uses. That means it should be much less of an effort to make the game compilable on Windows. Of course, that still requires somebody who has a (native) Windows C++ compiler.

[bo198214]

The problem, though, is how to interface the game with a cgi script. It requires true interactivity, which is a bit tough to program with a cgi interface.

Hm, I dont know how you programmed for curses, but I guess you have a model which you can redraw on the screen and react on some input key strokes. The html-correspondent would be to put out a html page and have a group of buttons which correspond to the keystrokes. And each press of a button calls the cgi with suitable parameters.
Ok but indeed you need some persistence either by running it as a daemon or by saving the current state in a temporary file, which is probably quite cumbersome. (Then the 3rd simpler solution would be Java but nobody wants to hear it )

at least in my experience when playtesting countless 4D mazes, is the discovery of such things as a passage turning and twisting in an unexpected way that can only happen in 4D, that makes you go, Oooh, right, of course! In 4D you can turn like that!

hm. but not a topological wondering? (what ever I mean with that *ggg*)

Anyway, maybe I should put up the current snapshot of the code, just so people with cygwin or a native *nix system can give it a twirl and give me some feedback.

*nod*

[quickfur]

The problem, though, is how to interface the game with a cgi script. It requires true interactivity, which is a bit tough to program with a cgi interface.

Hm, I dont know how you programmed for curses, but I guess you have a model which you can redraw on the screen and react on some input key strokes. The html-correspondent would be to put out a html page and have a group of buttons which correspond to the keystrokes. And each press of a button calls the cgi with suitable parameters.
Ok but indeed you need some persistence either by running it as a daemon or by saving the current state in a temporary file, which is probably quite cumbersome. (Then the 3rd simpler solution would be Java but nobody wants to hear it )

It's more complicated than that... the game adjusts itself to your terminal size settings, and doing that in HTML is non-trivial at best. And no, I'm not planning to port this to Java. It's probably actually harder to port to Java than cgi...

at least in my experience when playtesting countless 4D mazes, is the discovery of such things as a passage turning and twisting in an unexpected way that can only happen in 4D, that makes you go, Oooh, right, of course! In 4D you can turn like that!

hm. but not a topological wondering? (what ever I mean with that *ggg*)

Well, topologically-speaking, it's just a tree, and we all know what trees are like. The difference here is that trees can be embedded in 4D in extremely interesting ways.

Anyway, maybe I should put up the current snapshot of the code, just so people with cygwin or a native *nix system can give it a twirl and give me some feedback.

*nod*

OK, I've uploaded a snapshot of the code here: http://eusebeia.dyndns.org/~hsteoh/4maze.tar.gz

Even though it's a tarball, WinZip should have no problem unpacking it. Let me know if you have any troubles compiling it.

The game itself is, of course, incomplete. There are only about 3 or 4 levels, after which you get a short "you have won" message and the game quits. Of course, it will be more interesting in the final version. The levels are all randomly-generated, so each time you play, it will be different. Try it a few times, and let me know what you think.

Oh, one final note... the larger your terminal resolutions, the better. The game adapts itself to your terminal resolution, but trying to solve a 4D maze with seeing only a 3x3x3x3 slice at a time is not exactly a pleasant experience. A standard 80x24 terminal gives you 7x5x5x3, which is slightly better, but I personally prefer at least 7x5x5x5.

[bo198214]

It's more complicated than that... the game adjusts itself to your terminal size settings, and doing that in HTML is non-trivial at best.

Ok, but some buttons or a form for different screen resolutions would do it too. There is even a 4th option: flash

So I just tried the game.
1. I would find it less confusing if I could move my player around and from time to time adjust him to the center instead of that he is always in the center.
2. I dont understand your visibility mechanism. If I move left/right or up/down then in the 4th dimension appear new structures. Can you explain this in comparision to a 3d maze, please.
3. Where are the moving monsters? *nudge* That would quite spice up the game. Ok, but at that stage it is fine without monsters.
4. If you want me to provide windows executables you need a versioning. I called the posted version 1.0a.

So I prepared a windows binary. But I can not really test it without cygwin (because I dont want to uninstall cygwin for that purpose). Though A dependency checker showed my that the provided dlls should be enough. So every windozer out there please try

4maze-0.1a-win32.zip

Simply unpack it into a directory and then you can double click the executable (or make a shortcut to it on the desktop).

[quickfur]

It's more complicated than that... the game adjusts itself to your terminal size settings, and doing that in HTML is non-trivial at best.

Ok, but some buttons or a form for different screen resolutions would do it too. There is even a 4th option: flash

Ewww!!

So I just tried the game.
1. I would find it less confusing if I could move my player around and from time to time adjust him to the center instead of that he is always in the center.

Does that really make it that confusing? I decided to always keep the player in the center because after all the view is usually only 5x5x5x5 or somewhere thereabouts, so you can only take a few steps before it has to scroll.

I could add this as an option, I suppose.

2. I dont understand your visibility mechanism. If I move left/right or up/down then in the 4th dimension appear new structures. Can you explain this in comparision to a 3d maze, please.

In the 3D case, imagine if you were moving only in 2 dimensions (left/right, up/down), but you pass corridors going off to the front and back, and so as you pass them, you get a glimpse of parts of the maze behind them.

So the 4D case is analogous... you are just seeing the structures pass by ana and kata of where you are. The game does not treat the 4th direction separately from the others; the visibility code does exactly the same thing in all directions. So if you understand why the 2D slice looks the way it does, then the 4D case is simply an extension of that.

Maybe I can add a testing option which disables the visibility code, so that you can see how things scroll around without getting confused by the clipping. Would that help?

3. Where are the moving monsters? *nudge* That would quite spice up the game. Ok, but at that stage it is fine without monsters.

Actually, I was planning to introduce them, although later in the game. The first few levels are really to get the player used to moving around in 4D; then there will be an episode where you have to move reliably (not just stumbling around) in order to not get eaten...

4. If you want me to provide windows executables you need a versioning. I called the posted version 1.0a.

Actually, this version of the game is 2.0. There is a 1.0 which is old and rather unfriendly. I guess I really should put the version number into the game itself.

So I prepared a windows binary. But I can not really test it without cygwin (because I dont want to uninstall cygwin for that purpose). Though A dependency checker showed my that the provided dlls should be enough. So every windozer out there please try

4maze-0.1a-win32.zip

Simply unpack it into a directory and then you can double click the executable (or make a shortcut to it on the desktop).

Thanks a lot for doing this! Did you need to make any changes to the code, or did it compile as-is? If you made any changes, I'd like to have them so that you don't have to keep doing it every time.

Anyway, did you manage to finish all the levels currently there? I've added three more since, which are rather evil. Only for the seasoned 4D adventurer.

[quickfur]

OK, I've just uploaded a new version of 4maze. This latest snapshot adds 3 more levels with a new maze generator that makes loops and wide passages. The last level is extremely evil in difficulty, so be warned...

Also, at bo198214's request, the game now understands the -v option (run the game as '4maze -v'), which causes the map view to scroll only when the player moves to the edge of the view, instead of always keeping the player in the center. During the game, you can also press 'C' to center the view. (This command has no effect if -v is not used, obviously.)

Furthermore, there is now a -x option, which completely turns off the visibility code. This may help beginners understand what exactly is happening in the map view.

Anyway, here is the tarball: http://eusebeia.dyndns.org/~hsteoh/4maze/4maze_2.0.2.tar.gz

Please try it out and let me know what you think.

Also, I've reorganized my web directory a bit, so the old version is now here: http://eusebeia.dyndns.org/~hsteoh/4maze/4maze_2.0.1.tar.gz

[bo198214]

Wow that was fast!
Unfortunately both links return a "not found"
So I could not verify your claims *nudges*.

The code of the first version was indeed vanilla (no modifications at all, clean compile. Though I never heard of cons ... And now we can start the make-utility-war-thread!)

Though I gave it only the first two levels ... but with the new options ... sounds very promising.

[quickfur]

Wow that was fast!
Unfortunately both links return a "not found"
So I could not verify your claims *nudges*.

Ack!!! I mistyped the URL. That'll teach me to post before testing the links. I've fixed it in the previous post, please try again.

The code of the first version was indeed vanilla (no modifications at all, clean compile. Though I never heard of cons ... And now we can start the make-utility-war-thread!)

Well, Cons used to be one of the best Make replacements out there... but now it's superceded by SCons, which is written in Python. Unfortunately, that means people are less likely to have it, since Perl is more common than Python. (Unless I'm wrong.)

Though I gave it only the first two levels ... but with the new options ... sounds very promising.

Well, the visibility option is really a test... I didn't envision the game without visibility clipping. In fact, if you manage to get to the last level (or figure out how to "cheat" to get there without playing the other levels), you'll notice that one of the features of that level is completely worthless if you can already see everything.

But anyway, this is still an early development version, so who knows. Maybe things will change a lot depending on what people think about the game.

[bo198214]

Ok, due to current lack of time I merely visited the first two levels.
I like the uncentered moving.
Seeing everything is essential for the first trainings to know whats going on (Though you rascel still hide the gold and the exit!)
As used to vi keys, I would like to have a keyboard configuration (file).

I think it is a nice game, with a good base idea.
(Though for me personally the natural screen clipping is enough arduousness for my weak memory )
Perhaps some day it will even have a multiuser possibility

PS: I did not make a windows package because of the visibility option bug.

[quickfur]

Ok, due to current lack of time I merely visited the first two levels.
I like the uncentered moving.
Seeing everything is essential for the first trainings to know whats going on (Though you rascel still hide the gold and the exit!)

Huh? Not sure what you meant by that. If you ran it with -x, it will show everything, gold or not.

But if you think no vis clipping for the first few levels is essential, maybe I can add an xray device to the first two levels. (Maybe later in the game you can buy/acquire the xray device as a bonus or something.)

As used to vi keys, I would like to have a keyboard configuration (file).

Originally I mapped it to vi keys, but changed to the current layout as better suited for the 4 pairs of directions. But yes, having a keyboard config file would be very nice. I'll add that to the TODO list.

I think it is a nice game, with a good base idea.
(Though for me personally the natural screen clipping is enough arduousness for my weak memory )

Well, maybe I've been biased from having played 100's of games without clipping before I implemented clipping, so I've already learned how to move around. But for a new player, I guess having clipping would be very difficult at first until you get used to it.

Perhaps some day it will even have a multiuser possibility

Well, multiplayer + turn-based mechanism doesn't really work very well. Making it non-turn based is a possibility, although it will require a major code overhaul.

PS: I did not make a windows package because of the visibility option bug.

What bug?

[bo198214]

Huh? Not sure what you meant by that. If you ran it with -x, it will show everything, gold or not.

Hm, seems I have to apologize. Probably the gold ore and the exit simply scrolled out of sight (and I never thought that this would happen with my 13x7x7x7 view field).

But if you think no vis clipping for the first few levels is essential, maybe I can add an xray device to the first two levels. (Maybe later in the game you can buy/acquire the xray device as a bonus or something.)

And then also buy ability to save game at a certain state? *makes very doubtful guesture*

Originally I mapped it to vi keys, but changed to the current layout as better suited for the 4 pairs of directions. But yes, having a keyboard config file would be very nice. I'll add that to the TODO list.

But currently I realize I can also live with current key mapping.

PS: I did not make a windows package because of the visibility option bug.

What bug?

Ok here is then the

2.0.2 windows version

[houserichichi]

Hey the windows version doesn't work for me...I keep getting an error about opening the terminal cygwin. Anyone know what that's all about?

[quickfur]

Hey the windows version doesn't work for me...I keep getting an error about opening the terminal cygwin. Anyone know what that's all about?

Oops. Apparently the dll's bo198214 provided isn't sufficient to run it. I guess you need to install cygwin for it to work. We were hoping that this wasn't necessary.

If anyone who has a (native) C++ compiler for Windows who's willing to make Windows executables for me, please let me know.

[papernuke]

When I open the 20.2.0 version, it just opens the files, not the thing.