[quote="Chris H"]Having said that: This may just be rationalizing an engine limitation, but to some degree limitations like this are a little bit deliberate. The idea of ACK was to allow one person to put together a fairly extensive game in a fairly short period of time. When you start having to draw every creature from every angle, now you're getting into the kind of game that takes a team of developers. (Or you never get your game vision beyond the graphic-editing phase.)[/quote]

"a team of developers"? Bah! Me don't need no stinkin team of developers. lol. Hmm, wouldn't that be nice. Especially if they had no mind of their own, like I am the CEO and they are my wage slaves. Hahaha. [Mind you I've always been the wage slave so no offense to wage slaves. Now I am self-employed and have no interest in subjecting others to the wage slavery I so hated].

Yeah I can understand your objective Chris and it is a good one. I would definately love to see a growth in interest in retro gaming and especially growth in the area of retro game design. I just seriously doubt it is ever going to get much more popular than it has been for most our lifetimes.

I think it will always be a niche market just like Interactive Fiction. So really, and this is just my humble opinion, I think I would be most concerned about is keeping those who are already interested as busy as possible with fun new tricks they can play with to bring new life to our old favorites.

I don't think guys like me, if they really are like me, are ever going to grow out of our love for the retro gaming style and will never grow tired of it for very long. I have burned myself out now and then but I know after twenty years I always end up going back to the classics of my youth.

I rarely ever go back to replay the newer stuff. Hell, I rarely even finish playing the newer stuff. I think those of us into this sort of thing are far less likely to get intimidated by having too much control over what goes into our game. I think we tend to like it that way better just as I like DOS much better than Windows or driving a manual/stick shift much better than an automatic.

[quote="Chris H"]In the case of bumping an obstacle I don't know if it would work, because I think it returns the last direction you actually did move. But for setting your icon I see no reason why it shouldn't work.
[/quote]

I did a small standalone adventure to test this a bit more. Basically I started out with the Ultima kit and made two new objects. One object (LASTMOV-STEP) is a space that runs macro 100 when passed. The second (LASTMOV-BUMP) is an obstacle that runs macro 100 when bumped.

Macro 100 is:
SAYVAL LASTMOV AT 1 1
STOP

The step macro is set to macro 101, which is:
SET ICON = LASTMOV + 228
STOP

Tile 229 is a north-facing arrow, 230 is south-facing, 231 is east facing, 232 is west facing.

Created a room and put a couple of each object in the room for testing. Results are:

o Stepping on the LASTMOV-STEP space works properly - LASTMOV displays correctly for all four directions.
o Bumping the LASTMOV-BUMP obstacle results in the LASTMOV value from the previous turn displaying.
o The 'arrow' for the player displays with a one-turn lag (the arrow shows the direction the player moved or tried to move one turn ago). Bumping an obstacle (such as a wall) inside the room counts as a move. Bumping the room edge does not.

In the case of bumping an obstacle I don't know if it would work, because I think it returns the last direction you actually did move. But for setting your icon I see no reason why it shouldn't work.

Can you bundle up the adventure you were using to test that, so I can try it out? The only place I've used LASTMOV was on a portal, to have it set your entry point based on how you moved onto a town.

Having said that: This may just be rationalizing an engine limitation, but to some degree limitations like this are a little bit deliberate. The idea of ACK was to allow one person to put together a fairly extensive game in a fairly short period of time. When you start having to draw every creature from every angle, now you're getting into the kind of game that takes a team of developers. (Or you never get your game vision beyond the graphic-editing phase.)

[quote="Garth's Equipment Shop"]I wonder if there is a way to use something like this to have the PC icon change according to which direction the PC last moved in. So that you could have four different versions of the PC representing the PC facing in each of the four directions, N,S,E,W. Or Up,Down,Right,Left.[/quote]

I hadn't thought about that before. It's actually simple to implement; you just make four icons in the standard tileset that face the four directions; I used icons 151=north, 152=south, 153=east, 154=west. Then you have the following line somewhere in your step macro:

SET ICON = LASTMOV + 150

I tested this out and it works ok, except that the problem I described above still shows up. The value of LASTMOV that the step macro sees is the value from the previous turn, not the current turn. So every time you move, the player icon changes to face the direction that you stepped in the last turn. If you move the same direction two consecutive turns, the player icon will face in the expected direction.

I wonder if there is a way to use something like this to have the PC icon change according to which direction the PC last moved in. So that you could have four different versions of the PC representing the PC facing in each of the four directions, N,S,E,W. Or Up,Down,Right,Left. That is the only thing that really annoys me about this old tile based 2d top-down style RPG. What I find most difficult is trying to figure out a way to draw critter, PC/NPC icons so they look right whichever direction they are moving in.

Working on a couple of different obstacles that react when the player bumps them. One is a movable block that the player can push, and the other is a lever that changes states, but only under certain circumstances.

I had thought reading the manual that the LASTMOV variable would be set to the direction that the player had most recently tried to move, so if I bumped an obstacle, and the obstacle triggered a macro, and the macro examined LASTMOV, it should see

LASTMOV=1 if the player is south of the obstacle (moved N)
LASTMOV=2 if the player is north of the obstacle (moved S)
LASTMOV=3 if the player is west of the obstacle (moved E)
LASTMOV=4 if the player is east of the obstacle (moved W)

This allows the macro to calculate the map coordinates of the object that the player bumped.

However, when I tested this out, there appears to be a one-turn lag in the setting of the LASTMOV variable; so LASTMOV gets set to the direction that the player moved (or tried to move) on the *previous* turn, not the current turn. Or am I misunderstanding how this is supposed to work? Is there some reason that this variable will only work with portals and not with obstacles?

I figured this out by adding the following debug line to the start of my macro:
SAYVAL LASTMOV AT 1 1