[Oneiros]

Hi. I've just returned to messing with MZX after about 10/11 years. I started to get back into it trying to recreate an 8-directional move engine similar to the Resident Evil games. I've made it in the past & meant to release it since I haven't seen anything similar (correct me if wrong, I'm sure there has been). But I'm running into a problem right away which doesn't make sense. I remember using the labels to determine if the player is pressing a directional arrow key. Like uppressed, rightpressed, etc. It's right there in the help files too. But I try something like this & it doesn't seem to be working:

end
:uppressed
*Hello
end

Just to test it. And it doesn't seem to be registering. Am I forgetting something or doing it wrong? I must be, makes no sense.

Also, it's very doubtful after more than a decade, but if anyone has the alpha version or art folder from my game Ariandora which I had sent out for testing I would greatly appreciate a copy of it. Otherwise I'm going to have to start over! Ah well (Ariandora topic from a long time ago)

[Lachesis]

Hi! There aren't any [dir]pressed labels in MZX. There are, however, [dir]pressed conditionals:

: "loop"
wait for 1
if uppressed then "hello"
goto "loop"
: "hello"
* "Hello"
goto "loop"

There are also a few built-in counters that you can use to detect keypresses. They use a predefined set of numbers that map to different keys on the keyboard.

: "loop"
wait for 1
if "KEY_PRESSED" = 273 then "up"
if "KEY_CODE" = 72 then "up"
if "KEY72" = 1 then "up"
goto "loop"
: "up"
* "Hello"
goto "loop"

Hope that helps!

[Oneiros]

Thanks! I think I got confused by thinking it was just a built-in label you can use. Very appreciated

[Oneiros]

Another quick, easy question. I seem to remember being able to use a conditional such as:

if player char '=)' then "label"

But when I try variations of it, it gets put to, if at "player char"... & so on. Am I mistaken in thinking you can use the player character as a conditional? & thanks in advance, I'll give credit to those that helped me with this (should be..) simple engine.

[Dr Lancer-X]

correct, you are mistaken. the player char and color are write-only.

[Graham]

One thing that may be of interest to you is the online help file on DigitalMZX.net. It's exactly the same as the F1 help file in MegaZeux with one major difference; the ability to search for terms. This can make finding what you are looking for a lot easier.

Please feel free to continue to ask for help here, I just mentioned that because you will find a lot more info than you could think to ask us. I actually read through the entire help file at one point just to fill myself in on all of MegaZeux's many changes over the years. The help file by Terryn is a fantastic resource for information, just sayin'

[ThDPro]

Oneiros, on 24 January 2015 - 01:05 PM, said:

Another quick, easy question. I seem to remember being able to use a conditional such as:

if player char '=)' then "label"

But when I try variations of it, it gets put to, if at "player char"... & so on. Am I mistaken in thinking you can use the player character as a conditional? & thanks in advance, I'll give credit to those that helped me with this (should be..) simple engine.

Worth noting that while that conditional doesn't exist, you can effectively get that result by using the bchX,Y counters:

if "bch&playerx&,&playery&" = [The Char's Number] then "label"

This post has been edited by ThDPro: 25 January 2015 - 05:25 PM

[CJA]

There are several other built-in player statistics and whatnot that are "read-only" in the same way. It's very much worth keeping track of these using counters in Robotic, then using the "read-only" command to mirror them so that they take effect. The most obvious one to me is maxhealth, where you can simply have a loop of

set maxhealth "maxhealth"

Locking the player is also very easy to manipulate through Robotic. Rather than using lockplayer and unlockplayer, simply increase and decrease a "lock" counter in all your peasantry board robots, and have your global king robot do the actual locking and unlocking. This way you can "stack" the ability to lock the player. For example, you have some sort of electric stunning code that locks the player for ten cycles then unlocks them. Let's say you also have a cutscene that (of course) locks the player, and you want to use this electric stun effect in the cutscene. The electric code could accidentally unlock the player early, before the cutscene's done. Instead, if controlled through a counter, lock will go up to 1, then 2 while the player's "stunned", then back down to 1 until the cutscene's done.

While you're fiddling around in the global robot (which is a good place to put things like this), also make a counter that simply increases by one every cycle. Very handy to have!

(EDIT: It's 2015 and I'm still calling MZX cutscenes "cinemas")

This post has been edited by CJA: 25 January 2015 - 05:54 PM

[Oneiros]

Thanks very much!

Would anyone be willing to take a look at my 8-directional walking engine? I almost have it complete but there are a couple issues I can't work out. The coding is sloppy cause I'm not a professional programmer & am self-taught, I'm sure there are some shortcuts or easier ways of doing what I'm trying to do. If anyone is willing to help, post your email & I'll give you credit if you can fix it or simplify it. The problem comes when the players presses right to face northeast then presses up to go northeast without taking any other action. Instead of putting the player northeast, it puts the player to the north unless the player was already in movement. Also there are some glitchy aspects where turning a certain direction while having been turning opposite will produce undesired effects, which I can't figure out. Actually I'll just post the two robots that are running & see if anyone can help or simplify this where it's easier to predict & manage. I have it where you can walk in circles pretty neatly but there are just a few nagging problems before I could package it together as something for Robotic beginners & finally release something for once other than helping other people on projects 10+ years ago

It uses two robots. One checks if pressing up, to move the player:

: "upcheck"
if uppressed then "walk"
wait for 3
goto "upcheck"
end
: "walk"
if "dir" = 1 then "walkn"
if "dir" = 2 then "walknw"
if "dir" = 3 then "walkw"
if "dir" = 4 then "walksw"
if "dir" = 5 then "walks"
if "dir" = 6 then "walkse"
if "dir" = 7 then "walke"
if "dir" = 8 then "walkne"
end
: "walkn"
if at NORTH of player is c?? Solid "solid" then "upcheck"
move player to NORTH
goto "upcheck"
end
: "walknw"
if at WEST of player is c?? Solid "solid" then "upcheck"
if at NORTH of player is c?? Solid "solid" then "upcheck"
rel to player
put player at -1 -1
goto "upcheck"
end
: "walkw"
if at WEST of player is c?? Solid "solid" then "upcheck"
move player to WEST
goto "upcheck"
end
: "walksw"
if at WEST of player is c?? Solid "solid" then "upcheck"
if at SOUTH of player is c?? Solid "solid" then "upcheck"
rel to player
put player at -1 1
goto "upcheck"
end
: "walks"
if at SOUTH of player is c?? Solid "solid" then "upcheck"
move player to SOUTH
goto "upcheck"
end
: "walkse"
if at EAST of player is c?? Solid "solid" then "upcheck"
if at SOUTH of player is c?? Solid "solid" then "upcheck"
rel to player
put player at 1 1
goto "upcheck"
end
: "walke"
if at EAST of player is c?? Solid "solid" then "upcheck"
move player to EAST
goto "upcheck"
end
: "walkne"
if at EAST of player is c?? Solid "solid" then "upcheck"
if at NORTH of player is c?? Solid "solid" then "upcheck"
rel to player
put player at 1 -1
goto "upcheck"
end


The other checks if pressing left or right to change the player's heading/facing:


: "keycheck"
if leftpressed then "left"
if rightpressed then "right"
wait for 3
goto "keycheck"
end
: "left"
if "dir" = 1 then "northwest"
if "dir" = 2 then "west"
if "dir" = 3 then "southwest"
if "dir" = 4 then "south"
if "dir" = 5 then "southeast"
if "dir" = 6 then "east"
if "dir" = 7 then "northeast"
if "dir" = 8 then "north"
end
: "right"
if "dir2" = 1 then "northeast2"
if "dir2" = 2 then "east2"
if "dir2" = 3 then "southeast2"
if "dir2" = 4 then "south2"
if "dir2" = 5 then "southwest2"
if "dir2" = 6 then "west2"
if "dir2" = 7 then "northwest2"
if "dir2" = 8 then "north2"
end
: "northwest"
player char is ''
set "dir" to 2
set "dir2" to 8
wait for 3
goto "keycheck"
end
: "west"
player char is ''
set "dir" to 3
set "dir2" to 7
wait for 3
goto "keycheck"
end
: "southwest"
player char is '\t'
set "dir" to 4
set "dir2" to 6
wait for 3
goto "keycheck"
end
: "south"
player char is ''
set "dir" to 5
set "dir2" to 5
wait for 3
goto "keycheck"
end
: "southeast"
player char is ''
set "dir" to 6
set "dir2" to 4
wait for 3
goto "keycheck"
end
: "east"
player char is ''
set "dir" to 7
set "dir2" to 3
wait for 3
goto "keycheck"
end
: "northeast"
player char is ''
set "dir" to 8
set "dir2" to 2
wait for 3
goto "keycheck"
end
: "north"
player char is ''
set "dir" to 1
set "dir2" to 1
wait for 3
goto "keycheck"
end
: "northeast2"
player char is ''
set "dir1" to 8
set "dir2" to 2
wait for 3
goto "keycheck"
end
: "east2"
player char is ''
set "dir" to 7
set "dir2" to 3
wait for 3
goto "keycheck"
end
: "southeast2"
player char is ''
set "dir" to 6
set "dir2" to 4
wait for 3
goto "keycheck"
end
: "south2"
player char is ''
set "dir" to 5
set "dir2" to 5
wait for 3
goto "keycheck"
end
: "southwest2"
player char is '\t'
set "dir" to 4
set "dir2" to 6
wait for 3
goto "keycheck"
end
: "west2"
player char is ''
set "dir" to 3
set "dir2" to 7
wait for 3
goto "keycheck"
end
: "northwest2"
player char is ''
set "dir" to 2
set "dir2" to 8
wait for 3
goto "keycheck"
end
: "north2"
player char is ''
set "dir" to 1
set "dir2" to 1
wait for 3
goto "keycheck"
end

If it's easier just to e-mail you the game file to work with it, let me know your e-mail. I'll give full credit for the assistance if I ever release it or make something more of it, which I plan to

[Graham]

Oneiros, on 02 February 2015 - 06:45 PM, said:

Thanks very much!

Would anyone be willing to take a look at my 8-directional walking engine?

Hi Oneiros, I gave it a look and only noticed a few things. I implemented your code into a test game and noticed that you must set "dir" and "dir2" each to 1 (or some valid number, 1-8) for the keycheck program to begin working. If you do not, then those counters are set to 0 and the program will fail. no biggie, you just use

set "dir" to 1
set "dir2" to 1

at the beginning of the program and that's fixed, right?

the other thing I noticed is that on line 85 of the keycheck program you use the command

set "dir1" to 1

instead of

set "dir" to 1

and this is the reason for the undesired/unexpected performance.

Other than that it seems to work well as intended. I could re-write it and refine it for you but I don't want to do that. I think you are doing well and the fastest way for you to learn is to do it yourself. So, Keep going!

P.S. I tried to write this exact program in ZZT-OOP many years ago but could not figure out how to do it. HA!

[Graham]

Graham, on 02 February 2015 - 08:25 PM, said:

I think you are doing well and the fastest way for you to learn is to do it yourself.

Actually, that might not be true, I think you are doing very well, and it may be very beneficial to have someone show you a quicker way to do what you are doing. I learned a lot of techniques from opening other peoples games and checking out their code to see how it worked.

If I get some time, I'll see if I can duplicate your program in a different fashion. Or, maybe somebody faster than me will get to it first.

P.S. If you run into anymore trouble, don't hesitate to ask.

[Oneiros]

Graham thanks so much! That pesky "dir1" was messing it up. Oh & I do have another robot that sets dir & dir2 to 1 along with other minor things like playercolor & setting the playerchar to north facing. Thanks again! I'm going to add a few more things like being able to :touch while heading a non-cardinal direction then I'll release it & give credit to those in the topic that helped

[Dr Lancer-X]

Graham, on 03 February 2015 - 03:20 PM, said:

Actually, that might not be true, I think you are doing very well, and it may be very beneficial to have someone show you a quicker way to do what you are doing. I learned a lot of techniques from opening other peoples games and checking out their code to see how it worked.

very true. my learning of robotic was heavily accelerated by the 2001/2002 doz game "torn creation"; first, just from seeing that game and realising that everything in it was possible to do in mzx. then, gradually pulling apart the robots and learning how everything was done, seeing certain practices and realising how they were useful and a better way of doing things than the ways i had previously intuited. i had dissected plenty of mzx games before that (that's how i learned mzx, really) but none that were anything like torn creation in their use of robotic.

[Lachesis]

I've been using MZX since 2004 but I was terrible at it until around mid-2009 and never really got good at it until late 2013. Part of what took me so long was that I didn't listen to advice and I also refused to look at other peoples' code unless I had to personally fix it. I'd reinvent the wheel with a lot of concepts, and then several months/years later, I'd find out that there were far more efficient ways to do what I was trying to do

In other words, it's very helpful to look at other peoples' code

[Graham]

Oneiros, on 02 February 2015 - 06:45 PM, said:

I'm sure there are some shortcuts or easier ways of doing what I'm trying to do. If anyone is willing to help, post your email & I'll give you credit if you can fix it or simplify it.

Hey again Oneiros, so there are some simple things you can do to clean up the program and simplify it. When creating an engine, you want it to be as simple as it can be. I would combine the two robots into one program. that way, there is only one robot a designer would have to add to his board. to do this, combine the two loops at the top of each robot into one loop. You want to check whether up is pressed every cycle, otherwise it would seem unresponsive, but you only want left and right checked every second or third cycle, otherwise the turning circle would be too tight. you can accomplish this with a loop within your loop like so:

: "top"
loop start
cycle 1
if uppressed then "#&dir&"
loop for 2
if leftpressed then "#dec"
if rightpressed then "#inc"
goto "top"

This method also takes advantage of subroutines (the labels that are preceded by a '#'). They are like labels but when you are finished, they return you to the line after they were called and continue to run the program as normal. Read about them in the help file if that doesn't make sense. basically, you would use the command goto "#return" to return to the line after the subroutine was called, instead of goto "upcheck" and goto "keycheck".

Now you should think about doing away with a counter for each direction, left & right, and just go with one counter that they both share. so use "dir" for both left and right, and have left decrease the counter (until 1, resetting it to 8), and right increase the counter (until 8, resetting it to 1).

Next up, you can do away with this whole section

: "walk"
 if "dir" = 1 then "walkn"
 if "dir" = 2 then "walknw"
 if "dir" = 3 then "walkw"
 if "dir" = 4 then "walksw"
 if "dir" = 5 then "walks"
 if "dir" = 6 then "walkse"
 if "dir" = 7 then "walke"
 if "dir" = 8 then "walkne"

by utilizing the counter you already have set to represent the directions. This is where

if uppressed then "#&dir&"

comes in. See those '&' symbols? when you read that line, you should read it like "If uppressed, then go to the VALUE of the counter 'dir'."
and instead of having your labels be "walkn", "walknw", "walkw", etc. they can be "1", "2", "3" and the program will go directly to those labels from the 'if uppressed' command.

Programming is really a lot of fun, so I hope you stick with it and continue to improve your skills. I am self taught as well, I've just been doing it longer than you. You can definitely get to where I'm at with time, and even better, like some of these people in here =^)

BTW, I don't want to discourage you from releasing this engine, I definitely think you should. But have you considered a more modern approach to an 8 direction movement engine? What you are designing is called "tank controls" and it kind of fell out of fashion in the 90's. It certainly could still have it's uses, but maybe you could design and release an 8 way engine that uses all four direction buttons and release it in the same game. sort of a two-fer?

Anyway I'm happy to assist you so if you have more questions feel free to ask them. there is even room for more refinement if you want. there are other methods of moving the player around and checking for collision that may make the program even slicker.

[Old-Sckool]

Also, if you're going to use the "cycle" command as a replacement for wait 1 like this, you should read http://www.digitalmz...showtopic=15350

This post has been edited by Old-Sckool: 27 February 2015 - 04:29 AM

[Graham]

Old-Sckool, on 26 February 2015 - 08:29 PM, said:

Also, if you're going to use the "cycle" command as a replacement for wait 1 like this, you should read http://www.digitalmz...showtopic=15350

Good idea. Thanks for pointing that out.