However, the perspective is still wrong. The 6 "diagonal" lines are unaligned, i.e. not using the same vanishing point. Check the explanation for "one-point perspective" at http://en.wikipedia.org/wiki/Perspective_(graphical) if you don't know what I mean.
I agree with all of your points, in particular that the perspective is still wrong, and that the door in front of the player is indeed a little too wide. I will fix the graphics in the next version.
I now remember about the concept of vanishing point from school, but I will read the Wikipedia page, because I have not applied this since I left school. I must have forgot about it again. It will be interesting to read up on this again!
I am currently working on the double FOR ... NEXT that can be reduced to 1 saving a lot.
I originally tried replacing this:
1 CLS:
DIM m(862):
READ p,d,n,z,q:
FOR f=1 TO 25:
LET m(32*f)=1:
NEXT f:
FOR g=7 TO 8:
LET p=p+d:
LET m(p)=1:
POKE 22462+p,g+8*(p=q):
NEXT g:
LET d=CODE "d$CE"(RND*4+.5)-68:
LET d=d-2*d*m(p+d+d):
POKE (m(p+d+d)=0)*(p+d>64)*(p+d<800)*n,6:
LET p=64*INT (RND*12)+2*INT (RND*15)+66:
POKE (f<205)*n,15-3*m(p):
DATA 672,-USR 7766^0,23620,1,130
with this:
1 CLS:
DIM m(862):
READ p,d,n,z,q,g:
FOR g=g-1 TO g:
LET p=p+d:
LET m(p)=1:
POKE 22462+p,15+(p=q):
NEXT g:
LET d=CODE "d$CE"(RND*4+.5)-68:
LET d=d-2*d*m(p+d+d):
POKE (m(p+d+d)=0)*(p+d>64)*(p+d<800)*(p+d+d<>32*INT ((p+d+d)/32))*n,4:
LET p=64*INT (RND*12)+2*INT (RND*15)+66:
POKE (g<180)*n,12-3*m(p):
DATA 672,-USR 7766^0,23620,1,130,0
The latter version seems 4 positions shorter, but this saving actually comes from removing the color difference between "rooms" and "passages" (which is important for game "ChamberMaze"). Adding back this kind of distinction would take more than 4 positions, which is the reason I abandoned this idea. Unless there's anything else I'm missing?
I agree with all of your points, in particular that the perspective is still wrong, and that the door in front of the player is indeed a little too wide.
OK!
BTW I see no problem about a wide door, as long as the side doors are adjusted to look like they have the same size...
1 CLS:
DIM m(862):
READ p,d,n,z,q,g:
FOR g=g-1 TO g:
LET p=p+d:
LET m(p)=1:
POKE 22462+p,15+(p=q):
NEXT g:
LET d=CODE "d$CE"(RND*4+.5)-68:
LET d=d-2*d*m(p+d+d):
POKE (m(p+d+d)=0)*(p+d>64)*(p+d<800)*(p+d+d<>32*INT ((p+d+d)/32))*n,4:
LET p=64*INT (RND*12)+2*INT (RND*15)+66:
POKE (g<180)*n,12-3*m(p):
DATA 672,-USR 7766^0,23620,1,130,0
I came up with this:
1 CLS:
DIM m(862):
READ p,d,n,z,q,g:
FOR g=g-1 TO g:
LET p=p+d:
LET m(p)=1:
POKE 22462+p,15+(p=q):
NEXT g:
LET d=CODE "d$CE"(RND*3+1)-68:
LET d=d-2*d*m(p+d+d):
LET j=p/32+d/16:
POKE (m(p+d+d)=0)*(j>1)*(j<25)*(j<>INT j)*n,4:
LET p=64*INT (RND*12)+2*INT (RND*15)+66:
POKE (g<180)*n,13-4*m(p):
DATA 672,-USR 7766^0,23620,1,130,0
You are right about the amount of space won, but that is
due to the irregular jumps.
Too bad this idea doesn't allow POKEing rooms and corridors with different colors, otherwise we could use it to optimize ChamberMaze.
I have also considered using this kind of generator with the original 3D view. Right now, we have 2 different games using this 3D view:
- Labyrin3D has a very simplistic generator (actually it's so simplistic that the result is not really a maze, it's more like a "room full of obstacles", i.e. a labyrinth instead of a maze), but the generator is very fast and short enough to support additional features (a better looking overhead map and a countdown).
- 3D Maze has a more sophisticated generator, that is quite slow but generates much better (more challenging) mazes and it's still short enough to support the 3D view.
If we were successful on porting ChamberMaze's generator to the original 3D view version, the result would be better than the 2 variations we have: a maze as challenging as 3D Maze, generated almost as fast as Labyrin3D. And since this would not require differentiation between rooms and passages, the algorithm above would work fine. Unfortunately, it doesn't look like there's a way to make it fit. I tried using all tricks we discussed so far (even using CODE INKEY$ inside DATA, using LET d=d/e despite of visual distortions and removing improvements that prevented the player from start facing a wall), but even so the result I got was still 35 positions above the limit. Thus I don't think it's even worth it to pursue this idea anymore. Besides, it's not really a problem that we have to break down the game "features" into different variations, just like we did with a couple previous one-liners.
BTW I will be traveling for the next few days and so I may not have Internet connection for a while. Right now, it seems we have already finished Labyrin3D (see #499 and #508 ), 3D Maze (see #488 ), and PathFinder (see #373, #374, #381, and #399 ). Also ChamberMaze is close to completion, and the concept for the 5th game (perhaps to be called "A-Maze"?) is well defined. We didn't discuss the generator algorithm to be used in this case, but there are plenty of choices now. For instance, most generation algorithms could be changed to store 1 in rooms and 2 in passages (or vice-versa), so if there's enough space to implement the feature of activating the overhead map during the game, it would show rooms and passages differently. Or we could continue to store value 1 in all positions, and use a routine like this to print the overhead map:
LET v=8:
FOR f=...
POKE 22496+f,m(f)*v:
LET v=24-v:
NEXT f:
OK that's all I had in mind to leave as "advice" before leaving. Have fun!
I have joined the routine to draw a frontwall with the drawingroutine for the sidewalls. This saved 3 bytes, but due to the altered code I could replace the exit-condition and skip another 11 bytes.
My latest version was therefore 38 bytes under max.
I have added the direction print to the game as discussed earlier.
This is now my code:
1 CLS :
DIM m(3e3):
LET m(INT (RND*5)*2+1430)=USR 7766^0:
FOR r=1 TO 31:
FOR s=1 TO 23:
READ p,z,j,i,w,m(i+i-z*(1<r>r/16)),m(i+i+(s<11)),m(i+i):
POKE 22496+s*32+r,15*m(i)+(i=p):
RESTORE :
NEXT s:
NEXT r:
READ n,n,n,n,n,n,n,n,n,k,u,z,j,p,c,d,q:
POKE (k<1)*n,8:
CLS :
PRINT #1;"^><v"(2+j/46+(j>0)):
LET a=c:
LET c=d+d:
LET d=INT (d*.7):
LET f=INT (a*.35-d):
LET o=m(q):
FOR e=-.5 TO 1:
LET w=f-f*m(q-e*2*j)*o:
PLOT 128+a*e,88-d-w:
LET t=(2-o)*(c*o-a)*e:
DRAW t,w*o:
DRAW 0,2*d+2*f*(1-o):
DRAW -t,w*o:
POKE n-o*n,8:
NEXT e:
LET q=q+z:
POKE (p<1427)*n,8+7*(q<i):
DATA 110,46,1,r*z+s,RND,w*(r>2)<.7,w>.3,1,23620,
CODE INKEY$,(k=54)-(k=55),z+u*(j-z*u),
z*(2117*(z*z=1)-1)/46,p+(k=57)*z*m(p+z),250,117,p
Still 7 bytes under the limit.
(the data is placed over 3 lines to keep it readable)
I have travelled on trains in the Netherlands, and they run at very high speeds compared to what I am used to. In the Netherlands, I've been on the "Double-decker" trains, and some German "Deutsche Bahn" trains.
If you got the train in the UK, and travelled 130km you would have more time to work on oneliners than you could ever wish for, assuming the usual signal and track problems etc... Actually, that would probably be too much time!
Fortunately, I only live a short distance from my current place of work, and usually get the bus (10-15 minutes), but no time for oneliners at all during this short trip.
Anyway I am going offtopic. :D
I have saved your current version of the game.
Like Einar, I may also be away for the oneliners for a day or two! This is simply because I very often take a break from them to do other things. I enjoy the oneliners much more after a break, but I'll probably be back around the weekend, some time,
I started to think about doing a lightforce-style scroller, but upside down, using the SCR CT system variable to provide 256 scrolls, at which point the terrain could change for the next level. Working title: 'Canyon'. I think this is as fast as you're going to get in basic! Only half the space available used so far, but I'm going to be away for a week, so that will give you plenty of time to think about and comment on:
Is this the fastest we can do in basic?
What's your recommendation for collision detection? an if. . .then statement?
I think there'll be space for one aggressive alien at a time, hopefully which fires bullets. Anyone got a good AI for (a) a colliding alien and (b) a shooting alien?
1
CLS :
DIM r$(32):
LET p=11:
LET s=14:
LET r$(p)="I":
LET r$(p+8)="I":
POKE 23692,0:
LET f=PEEK 23688:
LET g=PEEK 23689:
FOR a=0 TO 255:
POKE 23688,f:
POKE 23689,g:
PRINT r$(1 TO 32):
READ f,g:
PRINT OVER 1;AT 0,s;" W ":
READ r$(p),r$(p+8),p,r$(p),r$(p+8),s:
RESTORE :
NEXT a:
DATA PEEK 23688,PEEK 23689,"","",p-1*(p>1)+RND*3-1*(p>21),"I","I",s-(IN 64510<191)+(IN 57342<191):
What's your recommendation for collision detection? an if. . .then statement?
Easiest collision detection is with ATTR
Set aliens (and fire) in another colour than the player.
When the wants to print at an ATTR place with alien colours, he's hit
I have the data ready, timing ready, movement of player ready.
During test I got some errors in the roomnumbering so in stead of
a 32-cimal counting system I will switch to a 40-cimal counting system.
(...cimal as in decimal, hexadecimal)
Only thing to add is the cubemovement, which I have figured out and tested in EXCEL.
When everything is working we can plan on cube-display.
I have the data ready, timing ready, movement of player ready.
During test I got some errors in the roomnumbering so in stead of
a 32-cimal counting system I will switch to a 40-cimal counting system.
(...cimal as in decimal, hexadecimal)
Only thing to add is the cubemovement, which I have figured out and tested in EXCEL.
When everything is working we can plan on cube-display.
I have just learnt that "40-cimal" is known as a quadragesimal system, not that I've ever used that word in my life before. I suppose I would just write it as a "base 40" system.
Great to see development is progressing on that one. I've still done zero further work on mine, because I keep getting involved in other threads. Still, there's all the time in the world I guess!
I have joined the routine to draw a frontwall with the drawingroutine for the sidewalls.
I always thought it was not worth it trying to "unify" the DRAW statements, but your latest version just proved otherwise. Great catch!!! :)
I checked your idea in further detail and realized it was possible to reduce it even more, saving another 33 positions from the latest version you posted. Here's a new version optimized directly from yours:
1 CLS :
DIM m(3e3):
LET m(INT (RND*5)*2+1430)=USR 7766^0:
FOR r=1 TO 31:
FOR s=1 TO 23:
READ p,z,j,i,w,m(i+i-z*(1<r>r/16)),m(i+i+(s<11)),m(i+i):
POKE 22496+s*32+r,15*m(i)+(i=p):
RESTORE :
NEXT s:
NEXT r:
READ n,n,n,n,n,n,n,n,n,k,u,z,j,p,c,d,q:
POKE (k<1)*n,8:
CLS :
PRINT #1;"^><v"(2+j/46+(j>0)):
LET o=m(q):
LET a=c:
LET c=(d+d+a)*o-a:
LET d=INT (d-.3*o*d):
FOR e=-.5 TO 1:
LET w=INT (.35*a-d)*(1-m(q-e*2*j))*o:
PLOT 128+a*e,88-d-w:
DRAW (c-a)*e,w:
DRAW 0,d+d:
DRAW (a-c)*e,w:
NEXT e:
LET q=q+z:
POKE (p<1427)*n,8+7*o*(q<i):
DATA 110,46,1,r*z+s,RND,w*(r>2)<.7,w>.3,1,23620,CODE INKEY$,(k=54)-(k=55),z+u*(j-z*u),z*(2117*(z*z=1)-1)/46,p+(k=57)*z*m(p+z),250,117,p
The version above is 40 positions under the limit, which means we would have enough free positions to implement both compass and move limit, and also to put back a separate loop to improve keyboard checking (although it seems some players would find the old system annoying while others would not even notice a difference, your mileage may vary). A candidate release containing all such changes is listed below:
1 CLS :
DIM m(3e3):
LET m(INT (RND*5)*2+1430)=USR 7766^0:
FOR r=1 TO 31:
FOR s=1 TO 23:
READ p,z,j,i,w,m(i+i-z*(1<r>r/16)),m(i+i+(s<11)),m(i+i),n:
POKE 22496+s*32+r,15*m(i)+(i=p):
RESTORE :
NEXT s:
NEXT r:
LET k=CODE INKEY$:
POKE (k<1 OR s>124)*n,11:
READ n,n,n,n,n,n,n,n,n,u,z,j,p,c,d,q:
CLS :
PRINT ,124-s;#1,"NEWS"(2+j/46+(j>0)):
LET o=m(q):
LET a=c:
LET c=(d+d+a)*o-a:
LET d=INT (d-.3*o*d):
FOR e=-.5 TO 1:
LET w=INT (.35*a-d)*(1-m(q-e*2*j))*o:
PLOT 128+a*e,88-d-w:
DRAW (c-a)*e,w:
DRAW 0,d+d:
DRAW (a-c)*e,w:
NEXT e:
LET q=q+z:
POKE (p<1427)*n,8+8*o*(q<i):
DATA 110,46,1,r*z+s,RND,w*(r>2)<.7,w>.3,1,23620,(k=54)-(k=55),z+u*(j-z*u),z*(2117*(z*z=1)-1)/46,p+(k=57)*z*m(p+z),250,114,p
This version imposes a maximum of only 100 moves, since the compass makes it too easy to escape the labyrinth. As a matter of fact, I think the game becomes so easy that there's almost no challenge left, which spoils most of the fun. I tried playing it a few times myself without looking to the overhead map, and I always managed to escape simply by walking towards direction NE without even paying attention to the game. Because of this, my recomendation for the release version for Labyrin3D is to remove the compass again and increase the limit back to 150 moves, as follows:
1 CLS :
DIM m(3e3):
LET m(INT (RND*5)*2+1430)=USR 7766^0:
FOR r=1 TO 31:
FOR s=1 TO 23:
READ p,z,j,i,w,m(i+i-z*(1<r>r/16)),m(i+i+(s<11)),m(i+i),n:
POKE 22496+s*32+r,15*m(i)+(i=p):
RESTORE :
NEXT s:
NEXT r:
LET k=CODE INKEY$:
POKE (k<1 OR s>174)*n,11:
READ n,n,n,n,n,n,n,n,n,u,z,j,p,c,d,q:
CLS :
PRINT ,174-s:
LET o=m(q):
LET a=c:
LET c=(d+d+a)*o-a:
LET d=INT (d-.3*o*d):
FOR e=-.5 TO 1:
LET w=INT (.35*a-d)*(1-m(q-e*2*j))*o:
PLOT 128+a*e,88-d-w:
DRAW (c-a)*e,w:
DRAW 0,d+d:
DRAW (a-c)*e,w:
NEXT e:
LET q=q+z:
POKE (p<1427)*n,8+8*o*(q<i):
DATA 110,46,1,r*z+s,RND,w*(r>2)<.7,w>.3,1,23620,(k=54)-(k=55),z+u*(j-z*u),z*(2117*(z*z=1)-1)/46,p+(k=57)*z*m(p+z),250,114,p
Normally it would be sad to remove a smart feature such as the compass even when it interferes with the gameplay instead of improving it, but fortunately this feature won't be "wasted" since we need it anyway for ChamberMaze for the reasons previously mentioned in this thread.
Although the killing rooms might be nothing more than YOU ARE KILLED BY XXXXXXX
And even when the room is short we might define just 1 killing method.
Sounds great!
I had this movie in mind when I described the original concept for ChamberMaze, but since it didn't match the visual style (the generator does not create passages up/down) and I didn't have in mind any interesting way to include "traps" in the gameplay, I didn't even mention it. Now I'm very curious to learn more about your idea!
What's your recommendation for collision detection? an if. . .then statement?
I think there'll be space for one aggressive alien at a time, hopefully which fires bullets. Anyone got a good AI for (a) a colliding alien and (b) a shooting alien?
There are basically 3 alternatives for collision detection:
a) Use ATTR to check the color attributes in a position (see Sheepdog Trials);
b) Use SCREEN$ to recognize a character (see Skier);
c) Compare with specific enemy coordinates (see One Line Invaders 2).
If you will have just 1 alien at a time, option c may work better for you. But if you want to also detect collision against the background, you may need to use option a for a colored scenery or option b for monotone.
A one-liner probably won't have enough space for a good AI, but you can implement a simplistic logic more similar to "One Line Invaders" for instance. You can find these examples at DP's homepage.
I have been doing some work on ChamberMaze this morning. Not actually on the game itself, but on a utility called "RoomTest", that I hope will allow us to finish the game with it looking exactly how we want it.
Sorry, it is very rough, it was only originally intended for my own use.
It displays the 28 lines used in drawing a room in ChamberMaze, in the order they are drawn.
Next, have a look at this program I made, called "RoomTest". It is not a oneliner, but it is a tool to generate the CODE strings needed to draw a ChamberMaze room, depending on user supplied parameters.
RUN this, and then just keep pressing ENTER to accept the default values.
Eventually a ChamberMaze room will be drawn, and then if 'g' is selected, the CODE strings for the room will be generated, for insertion into the ChamberMaze program.
This all works for the side walls and the far walls & door.
But in this attempt, I have not got the side doors to be drawn quite correctly.
The "side door" routine is at line 6000, and does need fixing, but I'm hopeful that after this is fixed, we can use this program to determine the CODE strings for the game, without having to manually calculate them ever again!
I tried to use a simple solution using "Similar triangles" to calculate the side door dimensions. Clearly this is not correct, mainly because it tries to "squeeze" a whole side wall into the available screen space, rather than allowing part of the room edges to dissapear off the side of the screen. Strictly speaking, probably some trigonometric solution with perspective transformations is needed. :D But seriously, I still think this can be done in a better way, even using the simple "similar triangles" method by allowing the room edges to be 'clipped' rather than squeezing them into the screen area!
But I hope what I done so far will be proof of concept that it can be done this way.
The advantage of using this program is that you can change the "vanishing point" height, room size, and door size, until you get something that looks correct for the game, and then I can simply copy the resultant CODE strings into the final program.
I have been doing some work on ChamberMaze this morning. Not actually on the game itself, but on a utility called "RoomTest"
Impressive!
The perspective is much better now (all doors have the same height for instance), but it still has a couple problems. The vanishing point for the ceiling is different (somewhat lower) than the vanishing point for the floor, and the vanishing point for the doors is even lower. They were all supposed to use the same vanishing point.
The perspective is much better now (all doors have the same height for instance), but it still has a couple problems. The vanishing point for the ceiling is different (somewhat lower) than the vanishing point for the floor, and the vanishing point for the doors is even lower. They were all supposed to use the same vanishing point.
Thanks, oops! That's not intentional. It must be an error in my calculations. I must admit this is quite a rushed version.
I will attempt to fix these issues in the next version of RoomTest!
Impressive!
The vanishing point for the ceiling is different (somewhat lower) than the vanishing point for the floor,
Just had a brief look at the code again. This error is now fixed. It was caused by an obvious error in the calculation.
The vanishing point is perhaps misaligned by about two pixes now (when I extend the lines in Paint shop Pro!) No doubt this due to the many rounding errors introduced due to the repeated "nearest even number" arithmetic.
Still it is good enough for the game. The very simplistic algorithm goes wrong if the vanishing point is moved outside the far wall, but we won't need to worry about that!
It looks like a vanishing point height of 88 is pretty good anyway. But we can adjust it a few times with this program if needed.
And the vanishing point for the doors is even lower. They were all supposed to use the same vanishing point.
Yes, it is very low isn't it. I still need to fix this!
.
The vanishing point is perhaps misaligned by about two pixes now (when I extend the lines in Paint shop Pro!) No doubt this due to the many rounding errors introduced due to the repeated "nearest even number" arithmetic.
No, it's not a rounding error, I realised later there is still a very small calculation error in the program. hopefully I can get a chance to fix this soon!
All the parallel lines do now point to the same vanishing point.
The side doors were too narrow in the previous verion, but this was easily fixed by decreasing the room width parameter from 168 to 148.
The default vanishing point was moved up slightly.
These two changes make it look more claustraphobic now!
I think the side doors look too low in this version though! So I'm still not totally happy with it, but at least it is getting nearer to how it should look!
I'm not yet sure how to increase the height of the side doors wthout screwing the perspective up again.
The calculations are simple - it is all ratios, but the code is now a bit of a mess, because of multple corrections, and variables that change value halfway through.
Also, only certain input parameters work perhaps because of rounding issues in the calculations.
2 dimensional with 37 rooms counted from 0 to 36.
The roomnumbering will be roomnr^2 *giving the idea of more rooms.
All primerooms are killerrooms. ( 0 and 1 are NO PRIMES).
Now I need a routine to shift the rooms.
I was thinking of shifting rows and columns like this
Column A
Row 2
Column C
Row 4
Column E
Row 6
Column A
Row 2
etc....
Comments
I agree with all of your points, in particular that the perspective is still wrong, and that the door in front of the player is indeed a little too wide. I will fix the graphics in the next version.
I now remember about the concept of vanishing point from school, but I will read the Wikipedia page, because I have not applied this since I left school. I must have forgot about it again. It will be interesting to read up on this again!
I originally tried replacing this:
with this:
The latter version seems 4 positions shorter, but this saving actually comes from removing the color difference between "rooms" and "passages" (which is important for game "ChamberMaze"). Adding back this kind of distinction would take more than 4 positions, which is the reason I abandoned this idea. Unless there's anything else I'm missing?
OK!
BTW I see no problem about a wide door, as long as the side doors are adjusted to look like they have the same size...
based on this version from you
I came up with this:
You are right about the amount of space won, but that is
due to the irregular jumps.
Good idea!
Too bad this idea doesn't allow POKEing rooms and corridors with different colors, otherwise we could use it to optimize ChamberMaze.
I have also considered using this kind of generator with the original 3D view. Right now, we have 2 different games using this 3D view:
- Labyrin3D has a very simplistic generator (actually it's so simplistic that the result is not really a maze, it's more like a "room full of obstacles", i.e. a labyrinth instead of a maze), but the generator is very fast and short enough to support additional features (a better looking overhead map and a countdown).
- 3D Maze has a more sophisticated generator, that is quite slow but generates much better (more challenging) mazes and it's still short enough to support the 3D view.
If we were successful on porting ChamberMaze's generator to the original 3D view version, the result would be better than the 2 variations we have: a maze as challenging as 3D Maze, generated almost as fast as Labyrin3D. And since this would not require differentiation between rooms and passages, the algorithm above would work fine. Unfortunately, it doesn't look like there's a way to make it fit. I tried using all tricks we discussed so far (even using CODE INKEY$ inside DATA, using LET d=d/e despite of visual distortions and removing improvements that prevented the player from start facing a wall), but even so the result I got was still 35 positions above the limit. Thus I don't think it's even worth it to pursue this idea anymore. Besides, it's not really a problem that we have to break down the game "features" into different variations, just like we did with a couple previous one-liners.
BTW I will be traveling for the next few days and so I may not have Internet connection for a while. Right now, it seems we have already finished Labyrin3D (see #499 and #508 ), 3D Maze (see #488 ), and PathFinder (see #373, #374, #381, and #399 ). Also ChamberMaze is close to completion, and the concept for the 5th game (perhaps to be called "A-Maze"?) is well defined. We didn't discuss the generator algorithm to be used in this case, but there are plenty of choices now. For instance, most generation algorithms could be changed to store 1 in rooms and 2 in passages (or vice-versa), so if there's enough space to implement the feature of activating the overhead map during the game, it would show rooms and passages differently. Or we could continue to store value 1 in all positions, and use a routine like this to print the overhead map:
OK that's all I had in mind to leave as "advice" before leaving. Have fun!
After 2 hours travelling by train I managed to cut the 3D drawing routine with
Every byte is worthwhile!
I also agree that "Maze 5" should be called A-Maze, it makes perfect sense.
The traintrip back home was more productive.
I have joined the routine to draw a frontwall with the drawingroutine for the sidewalls. This saved 3 bytes, but due to the altered code I could replace the exit-condition and skip another 11 bytes.
My latest version was therefore 38 bytes under max.
I have added the direction print to the game as discussed earlier.
This is now my code:
Still 7 bytes under the limit.
(the data is placed over 3 lines to keep it readable)
That's great Dr. BEEP!
I have travelled on trains in the Netherlands, and they run at very high speeds compared to what I am used to. In the Netherlands, I've been on the "Double-decker" trains, and some German "Deutsche Bahn" trains.
If you got the train in the UK, and travelled 130km you would have more time to work on oneliners than you could ever wish for, assuming the usual signal and track problems etc... Actually, that would probably be too much time!
Fortunately, I only live a short distance from my current place of work, and usually get the bus (10-15 minutes), but no time for oneliners at all during this short trip.
Anyway I am going offtopic. :D
I have saved your current version of the game.
Like Einar, I may also be away for the oneliners for a day or two! This is simply because I very often take a break from them to do other things. I enjoy the oneliners much more after a break, but I'll probably be back around the weekend, some time,
Regards, DP
I understand that you are busy with the CGC as well.
(therefore I won't join that competition afraid I might end last :razz: )
Playing CHAMBERMAZE gave me another idea.
At first I was planning it for the MINIGAME, but I think it can be done
as a ONELINER as well.
CUBE!
Although the killing rooms might be nothing more than YOU ARE KILLED BY XXXXXXX
And even when the room is short we might define just 1 killing method.
More info:
http://www.imdb.com/title/tt0123755/plotsummary
Yes, I also was thinking the same thing! It is a really a good idea.
I have all three of the cube films.
OK, we now have a plan for "Maze 6", "The Cube" to also be added to the Maze game package.
Could this be the most violent one-liner ever produced? (perhaps that is City Bomber so far :D )
As you say, there may only be enough room for a small message when the player dies, so the rest is up to the player's imagination.
But I really like the idea, and it should be a challenging game to play!
Mazesize defined, killerrooms defined.
Working on display first room.
Is this the fastest we can do in basic?
What's your recommendation for collision detection? an if. . .then statement?
I think there'll be space for one aggressive alien at a time, hopefully which fires bullets. Anyone got a good AI for (a) a colliding alien and (b) a shooting alien?
Easiest collision detection is with ATTR
Set aliens (and fire) in another colour than the player.
When the wants to print at an ATTR place with alien colours, he's hit
During test I got some errors in the roomnumbering so in stead of
a 32-cimal counting system I will switch to a 40-cimal counting system.
(...cimal as in decimal, hexadecimal)
Only thing to add is the cubemovement, which I have figured out and tested in EXCEL.
When everything is working we can plan on cube-display.
I have just learnt that "40-cimal" is known as a quadragesimal system, not that I've ever used that word in my life before. I suppose I would just write it as a "base 40" system.
Great to see development is progressing on that one. I've still done zero further work on mine, because I keep getting involved in other threads. Still, there's all the time in the world I guess!
I always thought it was not worth it trying to "unify" the DRAW statements, but your latest version just proved otherwise. Great catch!!! :)
I checked your idea in further detail and realized it was possible to reduce it even more, saving another 33 positions from the latest version you posted. Here's a new version optimized directly from yours:
The version above is 40 positions under the limit, which means we would have enough free positions to implement both compass and move limit, and also to put back a separate loop to improve keyboard checking (although it seems some players would find the old system annoying while others would not even notice a difference, your mileage may vary). A candidate release containing all such changes is listed below:
This version imposes a maximum of only 100 moves, since the compass makes it too easy to escape the labyrinth. As a matter of fact, I think the game becomes so easy that there's almost no challenge left, which spoils most of the fun. I tried playing it a few times myself without looking to the overhead map, and I always managed to escape simply by walking towards direction NE without even paying attention to the game. Because of this, my recomendation for the release version for Labyrin3D is to remove the compass again and increase the limit back to 150 moves, as follows:
Normally it would be sad to remove a smart feature such as the compass even when it interferes with the gameplay instead of improving it, but fortunately this feature won't be "wasted" since we need it anyway for ChamberMaze for the reasons previously mentioned in this thread.
Sounds great!
I had this movie in mind when I described the original concept for ChamberMaze, but since it didn't match the visual style (the generator does not create passages up/down) and I didn't have in mind any interesting way to include "traps" in the gameplay, I didn't even mention it. Now I'm very curious to learn more about your idea!
Looks promising!
Notice that instead of this:
you can use this:
The latter version is shorter and it will work for all Speccy models regardless of the value returned by these ports.
Also instead of this:
you can simply use this:
I suggest you take a look at game "Esquiador" ( http://www.worldofspectrum.org/infoseekid.cgi?id=0017759 ), it's a scroll game implemented 100% in BASIC and it's reasonably fast.
There are basically 3 alternatives for collision detection:
a) Use ATTR to check the color attributes in a position (see Sheepdog Trials);
b) Use SCREEN$ to recognize a character (see Skier);
c) Compare with specific enemy coordinates (see One Line Invaders 2).
If you will have just 1 alien at a time, option c may work better for you. But if you want to also detect collision against the background, you may need to use option a for a colored scenery or option b for monotone.
A one-liner probably won't have enough space for a good AI, but you can implement a simplistic logic more similar to "One Line Invaders" for instance. You can find these examples at DP's homepage.
First look at this image
http://i77.photobucket.com/albums/j71/benkid77/speccy/roomtest.png
Sorry, it is very rough, it was only originally intended for my own use.
It displays the 28 lines used in drawing a room in ChamberMaze, in the order they are drawn.
Next, have a look at this program I made, called "RoomTest". It is not a oneliner, but it is a tool to generate the CODE strings needed to draw a ChamberMaze room, depending on user supplied parameters.
http://www.mediafire.com/?0dpyc9mnznm
RUN this, and then just keep pressing ENTER to accept the default values.
Eventually a ChamberMaze room will be drawn, and then if 'g' is selected, the CODE strings for the room will be generated, for insertion into the ChamberMaze program.
This all works for the side walls and the far walls & door.
But in this attempt, I have not got the side doors to be drawn quite correctly.
The "side door" routine is at line 6000, and does need fixing, but I'm hopeful that after this is fixed, we can use this program to determine the CODE strings for the game, without having to manually calculate them ever again!
I tried to use a simple solution using "Similar triangles" to calculate the side door dimensions. Clearly this is not correct, mainly because it tries to "squeeze" a whole side wall into the available screen space, rather than allowing part of the room edges to dissapear off the side of the screen. Strictly speaking, probably some trigonometric solution with perspective transformations is needed. :D But seriously, I still think this can be done in a better way, even using the simple "similar triangles" method by allowing the room edges to be 'clipped' rather than squeezing them into the screen area!
But I hope what I done so far will be proof of concept that it can be done this way.
The advantage of using this program is that you can change the "vanishing point" height, room size, and door size, until you get something that looks correct for the game, and then I can simply copy the resultant CODE strings into the final program.
Impressive!
The perspective is much better now (all doors have the same height for instance), but it still has a couple problems. The vanishing point for the ceiling is different (somewhat lower) than the vanishing point for the floor, and the vanishing point for the doors is even lower. They were all supposed to use the same vanishing point.
Thanks, oops! That's not intentional. It must be an error in my calculations. I must admit this is quite a rushed version.
I will attempt to fix these issues in the next version of RoomTest!
great optimization on Labyrin3D.
I agree on the use of steps only.
I hope the new printing of the 3D maze gives enough room in the other
3D maze game to set all options needed.
As for CUBE:
At the moment not much done since I have been working in home decorating and painting wall alnd ceiling.
Don't worry this week a first gameplay will come.
Just had a brief look at the code again. This error is now fixed. It was caused by an obvious error in the calculation.
The vanishing point is perhaps misaligned by about two pixes now (when I extend the lines in Paint shop Pro!) No doubt this due to the many rounding errors introduced due to the repeated "nearest even number" arithmetic.
Still it is good enough for the game. The very simplistic algorithm goes wrong if the vanishing point is moved outside the far wall, but we won't need to worry about that!
It looks like a vanishing point height of 88 is pretty good anyway. But we can adjust it a few times with this program if needed.
Yes, it is very low isn't it. I still need to fix this!
No, it's not a rounding error, I realised later there is still a very small calculation error in the program. hopefully I can get a chance to fix this soon!
http://www.mediafire.com/?xzdendiudeb
All the parallel lines do now point to the same vanishing point.
The side doors were too narrow in the previous verion, but this was easily fixed by decreasing the room width parameter from 168 to 148.
The default vanishing point was moved up slightly.
These two changes make it look more claustraphobic now!
I think the side doors look too low in this version though! So I'm still not totally happy with it, but at least it is getting nearer to how it should look!
I'm not yet sure how to increase the height of the side doors wthout screwing the perspective up again.
The calculations are simple - it is all ratios, but the code is now a bit of a mess, because of multple corrections, and variables that change value halfway through.
Also, only certain input parameters work perhaps because of rounding issues in the calculations.
here is the first insight info.
My cube will look like this
2 dimensional with 37 rooms counted from 0 to 36.
The roomnumbering will be roomnr^2 *giving the idea of more rooms.
All primerooms are killerrooms. ( 0 and 1 are NO PRIMES).
Now I need a routine to shift the rooms.
I was thinking of shifting rows and columns like this
Column A
Row 2
Column C
Row 4
Column E
Row 6
Column A
Row 2
etc....
The rooms are stored as a singlestring like this
Now I need a short code to do the shift or if someone has a better
and shorter shifting idea, please tell me.
The FN will calculate the remainder of (m+1)/6, so it will return to 0 when 6 is reached.
After 528 moves the cube is back in the begincondition.
Some rooms are fixed, other shift horizontally and vertically.
The code might be something too long for the entire game.
I will make the game complete now and then we need to find spaces to win.
Some optimizations: