Trying to do something in ZZT that I think (hope) is new...

Housing for low income families.

Moderators: nuero, Ando

craycpanda
god not again i hate you
Posts: 69
Joined: Fri Apr 23, 2004 10:58 pm
Location: SWEEEEEEEEEEEEEDEEEEEEEEEEEN
Contact:

Post by craycpanda »

will this be the long awaited first game that actually requires zzt 4.0? :agh:
JDMSonic
Ordinery
Posts: 36
Joined: Wed Mar 29, 2006 3:41 am

Post by JDMSonic »

What exactly is the ZZT4.0 difference when it comes to memory limits?
User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Post by Dr. Dos »

32kb boardsize is all i recall offhand.
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

Apologies for the old post you may have just read.
JDMSonic
Ordinery
Posts: 36
Joined: Wed Mar 29, 2006 3:41 am

Post by JDMSonic »

So I'm really thinking hard on the "space to shoot vs directional shooting" thing.

Luckily, shooting isn't a huge part of the gameplay; you shouldn't have more than 5 ammo at any given time, if I lay out the levels right. So it's not like it gets to where you're run-and-gunning mashing the space bar.

The main thing, though, is the object usage.

Let's say enemy A is walking around in a field:

Code: Select all

/--------\
|        |
|    X   |
|        |
| Y  A   |
|        |
\--------/
X is you, the player.

If it's spacebar to shoot, this is fairly simple. You shoot A, you're aligned, they check and nothing is in your way.

If it's directional shooting, let's say you shoot East. How does the game prove that you didn't really shoot South? In other words, how does the game know you're at X and not at Y?

First off, the player clone tells the game that they know you've shot West, so that's what they're checking.

The game then needs to check third objects (the walls of the area you're in) to see if the player is also aligned with them; then you've got the player's X and Y coordinates, and you can return a True or False to the object.

In a system where there were no memory constraints, this would not really be a problem. I could just make every single object along the border of the open area (well, two sides out of four, assuming a rectangle) into coordinate-checking objects.

That would quickly run into ZZT's memory limitations, however.

There's a second, less memory-intensive option: "Shadow objects". Basically, two invisible objects outside of the rectangular area outlined above that parallel the patrol route of the enemy, always staying aligned with it; by sending allignment-checking messages to these four 'shadow objects', one could easily figure out where the player is shooting from.

This would work *great*... if my game's levels were like Lebensraum, with plenty of black, empty space outside of the rooms. But it's not - it's a jungle, and doing this would essentially kill my level design options.


So, with shift-plus-direction shooting, my options are either bad level design, or an 8 by 8 room taking 16 extra objects to check alignments.

Then there's the third option; go the 'extra objects' route, but then heavily limit my use of open areas. I don't really like this either; it means I'd have to make a game that feels like it's played in corridors, with merely a jungle 'theme' on top.

Other not terribly appealing options: Just using normal bullets and /shot tags, using an object in place of the player along with a 'gems and torches' coordinate engine to have the player's exact coordinates always in memory.

Does anyone have novel ideas as to how to program direction-based shooting to get around these limitations?
User avatar
Ellypses
Whaf yew vauhnt?
Posts: 145
Joined: Tue Aug 24, 2004 2:14 pm
Location: In hell called earth
Contact:

Post by Ellypses »

Your shadow engine would work fine, if you know how to blend the objects in the jungle. A good ol' fake and object with the same design and color would do just find. Also it seem that you just need two if you also have both x and y shadow objects going.

^I should know much about it cause that's the method I use for a shotgun, but that's a totally different story.

^but on that subject anyway, I'll try to show you what I'm trying to say, instead of presenting a speech out my arse.

Code: Select all

             A
               B
     E!
   +----------------------+
   |         #  #         |
   |         #  #         |
A E|  ########@ ######    |
  !|  #              #    |
   |  #              #    |
   |  #              #    |
   |###              #    |
 B |            &    #    |
   |                 #    |
   |###              #    |
   |  #              #    |
   +----------------------+

A = Align object that follows the player
B = Align object that follows the enemy
E = Object that checks if the player exit the room
! = Object that'll check if the player enter the area
    and then activates whatever the hell
This is also the engine that makes the enemy chase the player object but later still.

For the shooting engine to work with this one, the outside A object just have to be block by the B object below it or beside it.

If you're curious about the shotgun and the follow player object, it's perdy complicated. Shotgun: The B object puts a color fake beside it while the A object checks if blocked by B object or finds a color fake. The color fake just serves an extra range to shoot the opponent, so you could be off a little up or down on alignment but you'll still clip hissaz.

My eyes are gone againImage. Yargg later.
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

there's a lot of room for hangups in all that. ZZT isn't the best at updating all the objects in a room and sometimes they hang, which means your shadow might fall behind the path of the enemy.

I think a better way might be to do something with the enemies doing #put boulder seek and then finding out which direction it's blocked from.

of course there are disavantages to this as well (no enemies near walls)

If you can find a way to do it differently in different areas without seeming like you used a different method (effectivly faking a engine that doesn't exist) you might be able to get around most situations.
*POW* *CLANK* *PING*
JDMSonic
Ordinery
Posts: 36
Joined: Wed Mar 29, 2006 3:41 am

Post by JDMSonic »

I think a better way might be to do something with the enemies doing #put boulder seek and then finding out which direction it's blocked from.
Good idea - I've been using that method already, I'll see how I can rig that up.
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post by Quantum P. »

I think a better way might be to do something with the enemies doing #put boulder seek and then finding out which direction it's blocked from.
This sounds pretty good. The "no enemies near walls" restriction isn't that big of a deal: just check to see if the object is blocked seek beforehand, and if so, don't put a boulder - after all, the object can't be shot at if there's a wall between him and the player.
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

also check for contact being true and maybe you the player wouldn't shoot but instead stab.
*POW* *CLANK* *PING*
JDMSonic
Ordinery
Posts: 36
Joined: Wed Mar 29, 2006 3:41 am

Post by JDMSonic »

Regarding contact... the idea is that if the enemy sees you, he rushes seek for the little bit of time between when he spots you and when the player clone gets duped onto the passage. It's okay for the guard to rush off of his patrol route, since after entering combat either he'll be dead or you'll be, or perhaps some third outcome - he'll never just be going back to patrolling. (Using a temporary flag to tell the battle engine what happened)

If he reaches contact with you before you head into the fight engine, you start out fighting him in melee.

if not, you have to be bulletdodging first to close into melee range (Ninja-like reflexes yay).

The third result would be if you initiate combat yourself, by touching him while at the same time being out of his line of sight. In this case, you'll enter combat by launching a sneak attack on him - a well-executed combo should mostly finish him off without too much effort.

The end result being that if you're careful and sneaky, killing the guy is easier.

(This is all separate from the shooting engine; the idea with that is that you can use limited ammo for stealth kills in certain situations, not to be a replacement for the fighting engine)

Since I earlier compared the combat system to DDR, it'd be like the difference between playing the same song on easy, normal, or maniac modes.
Ceri JC
MMMM baby
Posts: 28
Joined: Mon May 18, 2009 10:08 am

Post by Ceri JC »

Sounds really good. As to the guards' state, if you don't want to resort ro font editing how about the following system to denote states of awareness above the normal patrolling:

Guard with '?' above his head, guard is suspicious (will spend longer looking, perhaps he can see into semi-hidden areas )
Guard with '!' above his head, guard is actively searching for the player (will walk into semi-hidden areas)
Guard with red flashing "!" above his head -can presently actually see the player, will raise alarm, shoot, chase, etc.
User avatar
Zenith Nadir
this is my hammer
Posts: 2767
Joined: Wed Mar 12, 2003 11:40 am
Location: between the black and white spiders

Post by Zenith Nadir »

31 May 2006 22:32
he looked upon the world and saw it was still depraved :fvkk:

Overall: Rotton egg for breakfast
Ceri JC
MMMM baby
Posts: 28
Joined: Mon May 18, 2009 10:08 am

Post by Ceri JC »

Whoops. Sorry.
Post Reply