quickfur wrote:I decided to temporarily put aside the visualization part of a game, and go back to a slices approach.
If you like, this would be the view of a 5D being playing a maze game on a 4D screen. )
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,
bo198214 wrote:quickfur wrote:I decided to temporarily put aside the visualization part of a game, and go back to a slices approach.
hahahaIf 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 wrote: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.
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?
bo198214 wrote:quickfur wrote: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 (???)). Thats why even 2d maces are interesting (where the walls can at most being homeomorphic to the circle).
quickfur wrote: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.
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!
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.
bo198214 wrote:quickfur wrote: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 wrote: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.
bo198214 wrote:quickfur wrote: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).
bo198214 wrote: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.
bo198214 wrote: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 wrote: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.)
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.
PS: I did not make a windows package because of the visibility option bug.
What bug?
houserichichi wrote: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?
Users browsing this forum: No registered users and 0 guests