Hello all,
Just thought I'd introduce myself rather than ask for help out of the blue. I've been into ZZT on and off since the early-mid nineties (I wondered about mentioning this after reading your guide for newbies ;)). Mainly fairly simple games with some fairly simple ZZT-OOP. All done using just the standard editor (have recently DLed KevEdit, but not yet had a play with it). I've been using the toolkits that allow more colours since the late 90s, I've also seen/played a few games using RPG-like engines, etc. and am impressed with what people have managed to do with it, particularly with the lemmings clone, Zem. I lurked as a guest in a ZZT forum about seven years back (may well of been an earlier incarnation of here), but never participated in the community. I recently got back into ZZT and am relearning what I had forgotten and am working on a couple of new games.
I'm presently relearning ZZT-OOP and have come across a limitation that I have vague memories of from last time I played with ZZT several years back and wanted to confirm whether it's a limitation of ZZT, or if there's some workaround.
When writing code for objects,
:SHOT
seems to actually mean,
:SHOT BY PLAYER
IE when an object (such as a player-controlled gun turret in a Space Invaders clone) fires a bullet, it can destroy tigers, bears, breakable walls etc. but does not trigger :SHOT commands in any other objects it hits. Is there some other command I can use to allow me to do this as it's fairly fundamental to a Mr. Driller/Boulderdash type game I'm making.
Another quick query, can anyone provide a link to a guide to implementing player clones (or even just an example of a game where they're used, so I can have a look)?
Thanks in advance,
Ceri
Help a n00b
Moderators: Commodore, Zenith Nadir
-
RobertP
- gore Arnold
- Posts: 250
- Joined: Tue Dec 18, 2007 6:53 pm
- Location: Burning Oak retirement facility
Hey dude,
It seems to be the other way around. Objects can fire bullets that go through breakables, that's true, but they can't harm built-in enemies. Other objects do recognize the bullets - they will get :shot. They will also recognize the bullets when you check if there are any with the #if command.
Boulderdash is a fun game, I hope you can make it work.
It seems to be the other way around. Objects can fire bullets that go through breakables, that's true, but they can't harm built-in enemies. Other objects do recognize the bullets - they will get :shot. They will also recognize the bullets when you check if there are any with the #if command.
Boulderdash is a fun game, I hope you can make it work.
My waste is my weapon.
an object will get a :shot message anytime a bullet hits it, it doesn't matter what the source. there is some player clone stuff in the zzt encyclopedia and a brief discussion here too http://zzt.org/zu/wiki/Player
*POW* *CLANK* *PING*
Thanks for the comments folks. A bit of experimenting and I've narrowed it down. It appears prefab creatures and items that are effected by bullets and objects behave slightly differently.
RobertP is correct, only player-fired bullets can harm the prefab enemies/objects. In terms of being :shot, it's a little more complex. When an object is shot, whatever is shooting cannot be adjacent to it. It appears to make no difference when shooting objects whether the shot originated from: The player; An object being told to shoot; Or a spinning gun shooting bullets. This is different to the prefab creatures/items, which can be shot when the player is adjacent to them.
I've made a very basic game board that illustrates this if someone would be willing to take a closer look.
In terms of what I'm trying to do in my boulderdash game, an object which you control shoots, but only if its way is blocked. So you don't actually see the bullet and the effect is that the object tunnels through the fake walls which act like soil in the classic arcade games, Mr Do./Dig Dug. This is fine for the soil, but I'd like to have objects behave in the same way (when they are shot, they disappear, but they are only ever shot when the player is adjacent). Any ideas on how to achieve a similar result/workaround much appreciated, ta.
RobertP is correct, only player-fired bullets can harm the prefab enemies/objects. In terms of being :shot, it's a little more complex. When an object is shot, whatever is shooting cannot be adjacent to it. It appears to make no difference when shooting objects whether the shot originated from: The player; An object being told to shoot; Or a spinning gun shooting bullets. This is different to the prefab creatures/items, which can be shot when the player is adjacent to them.
I've made a very basic game board that illustrates this if someone would be willing to take a closer look.
In terms of what I'm trying to do in my boulderdash game, an object which you control shoots, but only if its way is blocked. So you don't actually see the bullet and the effect is that the object tunnels through the fake walls which act like soil in the classic arcade games, Mr Do./Dig Dug. This is fine for the soil, but I'd like to have objects behave in the same way (when they are shot, they disappear, but they are only ever shot when the player is adjacent). Any ideas on how to achieve a similar result/workaround much appreciated, ta.
-
Kjorteo
- ^o.O^
- Posts: 432
- Joined: Sat Feb 28, 2004 10:59 am
- Location: Kjorteoville or something
- Contact:
http://zzt.org/zu/wiki/Bullet I put that little compare/contrast together a while ago, hopefully it helps, though it sounds like you figured it out already. 
Regarding what you're trying to do, it sounds impossible with built-in enemies, but objects serving as the enemies can receive the :shot message from other objects, so you could potentially go that route. However, there could be another problem there: objects, from what I remember (it's been forever since I tested this) don't seem to be accept being shot at point-blank range. I know this was an issue with the player, and in an adventure game-type setting with enemies that walk toward you, you need to have some sort of #if contact code to deal with them pushing against you, because otherwise they push you against a wall and you can't shoot them at point blank range so you're basically just trapped. I have no idea whether this same issue prevents objects from shooting each other, though.
Regarding what you're trying to do, it sounds impossible with built-in enemies, but objects serving as the enemies can receive the :shot message from other objects, so you could potentially go that route. However, there could be another problem there: objects, from what I remember (it's been forever since I tested this) don't seem to be accept being shot at point-blank range. I know this was an issue with the player, and in an adventure game-type setting with enemies that walk toward you, you need to have some sort of #if contact code to deal with them pushing against you, because otherwise they push you against a wall and you can't shoot them at point blank range so you're basically just trapped. I have no idea whether this same issue prevents objects from shooting each other, though.
"You're alive," said the maker, and smiled at the aardvark.
<Kjorteo> "yiff"
<gbelo> Wanna yiff.
<Kjorteo> yes
<gbelo> No no no.
<Kjorteo> "yiff"
<gbelo> Wanna yiff.
<Kjorteo> yes
<gbelo> No no no.
this might get complex but bear with me here.
instead of shooting to dig you might try #put w empty however if you're trying to see if the enemy is blocked in that direction (like with a rock or something) you'd have to check to see what block is next to them.
let's say solid rock is made with red solids. you have the object put something (say a normal wall) and check to see what colour the wall is and do something accordingly. this works because when you put something and do not specify a colour, it takes on the colour of the block it replaced. it would look something like this:
@dude
#cycle 1
#walk rndp rndne
:loop
/i
#if blocked flow #dig
:loop
/i
#if blocked flow #dig
:loop
/i
#if blocked flow #dig
:loop
/i
#if blocked flow dig
:loop
#restore loop
#restore loop
#restore loop
#restore loop
#restart
:dig
#zap loop
#put flow normal
#if any red normal #noeast
#put flow empty
#loop
:noeast
#put flow red solid
#loop
I just sort of threw together the movement code, it might be totally worthless.
this limits you to using the 7 normal (bright) colours though. I'm pretty sure objects naturally work sequentially, so I'm pretty sure there's no threat of multiple objects putting red normals and screwing up other objects that are checking, but zzt has taken my expectations and dashed them on the rocks before, so not guarantees.
instead of shooting to dig you might try #put w empty however if you're trying to see if the enemy is blocked in that direction (like with a rock or something) you'd have to check to see what block is next to them.
let's say solid rock is made with red solids. you have the object put something (say a normal wall) and check to see what colour the wall is and do something accordingly. this works because when you put something and do not specify a colour, it takes on the colour of the block it replaced. it would look something like this:
@dude
#cycle 1
#walk rndp rndne
:loop
/i
#if blocked flow #dig
:loop
/i
#if blocked flow #dig
:loop
/i
#if blocked flow #dig
:loop
/i
#if blocked flow dig
:loop
#restore loop
#restore loop
#restore loop
#restore loop
#restart
:dig
#zap loop
#put flow normal
#if any red normal #noeast
#put flow empty
#loop
:noeast
#put flow red solid
#loop
I just sort of threw together the movement code, it might be totally worthless.
this limits you to using the 7 normal (bright) colours though. I'm pretty sure objects naturally work sequentially, so I'm pretty sure there's no threat of multiple objects putting red normals and screwing up other objects that are checking, but zzt has taken my expectations and dashed them on the rocks before, so not guarantees.
*POW* *CLANK* *PING*
Thanks for that. That's some food for thought to help me start looking at workarounds, or if necessary, altering the gameplay to fit ZZT's limitations. :)
I had thought about #PUTting a blank space over the offending square, the "dug out" empty space is blank space anyway, so no problem with that. What had posed a concern, was that the player controlled object might 'dig' out of the game area/through the solid blocks. Commodore's code looks like a good starting point for a way round this, I'll have a bit of a play at lunchtime.
Is there a way of checking "ALIGNED" to anything other than the player? I'm thinking I could have a 'perimeter' of 2 objects on the outside edge of the play area checking if the player is aligned with them. Also, does ALIGNED detect player clones?
I had thought about #PUTting a blank space over the offending square, the "dug out" empty space is blank space anyway, so no problem with that. What had posed a concern, was that the player controlled object might 'dig' out of the game area/through the solid blocks. Commodore's code looks like a good starting point for a way round this, I'll have a bit of a play at lunchtime.
Is there a way of checking "ALIGNED" to anything other than the player? I'm thinking I could have a 'perimeter' of 2 objects on the outside edge of the play area checking if the player is aligned with them. Also, does ALIGNED detect player clones?
-
Quantum P.
- Level 17 Accordion Thief
- Posts: 1433
- Joined: Fri Sep 12, 2003 1:41 am
- Location: Edmonds, WA
- Contact:
The ALLIGNED flag does not seem to respond to player clones. It only works with the "true" player.
If you've got two counters free, you can do an (x, y) coordinate thing, where you #give torches 1 if you move east, #take torches 1 if you move west, #give gems 1 if you move north, and #take gems 1 if you move south. This would allow you to keep track of your location. With some clever programming, you'd be able to keep your object within a certain rectangle on the screen.
Another thing you might consider is an object which changes bullets to empties a cycle after they're fired. This way, you wouldn't be able to shoot anything that was more than a space away from you. You'd briefly see the bullet, though.
If you've got two counters free, you can do an (x, y) coordinate thing, where you #give torches 1 if you move east, #take torches 1 if you move west, #give gems 1 if you move north, and #take gems 1 if you move south. This would allow you to keep track of your location. With some clever programming, you'd be able to keep your object within a certain rectangle on the screen.
Another thing you might consider is an object which changes bullets to empties a cycle after they're fired. This way, you wouldn't be able to shoot anything that was more than a space away from you. You'd briefly see the bullet, though.
Thanks very much for all your help folks, a variation on what Commodore suggested has cracked it. Even if I can't work the next couple of things I want to try into it, as it stands I should have enough to make something halfway playable. I've done away with the shooting completely and if the direction the player is trying to move in is blocked, it puts a normal wall there. It then detects if there are any red walls next to it and if there are, puts blank space there instead.
At the moment I have a blue solid wall "solid rock" border around the play area (all solid rock is going to be blue, unlike the soil, which is red). So when the object overwrites this with a new normal wall, it just gets turned from solid into normal. Whilst this was initially accidental, I've decided to keep it as aesthetically, it looks as if the player has "chipped" the previously smooth surface of the wall, but cannot get past it.
As an aside, for once, the famous "can't put on the bottom row" is not only not a nuisance, but actually solves what would otherwise be a (possibly unsolvable) problem within this engine! Sweeney must be smiling on me...
At the moment I have a blue solid wall "solid rock" border around the play area (all solid rock is going to be blue, unlike the soil, which is red). So when the object overwrites this with a new normal wall, it just gets turned from solid into normal. Whilst this was initially accidental, I've decided to keep it as aesthetically, it looks as if the player has "chipped" the previously smooth surface of the wall, but cannot get past it.
As an aside, for once, the famous "can't put on the bottom row" is not only not a nuisance, but actually solves what would otherwise be a (possibly unsolvable) problem within this engine! Sweeney must be smiling on me...
-
Zenith Nadir
- this is my hammer
- Posts: 2767
- Joined: Wed Mar 12, 2003 11:40 am
- Location: between the black and white spiders
