z2

I don't know. The counter system itself is not as accurate as a similar varible system, and I think it'd be hard to program a bug free co-ordinate engine, at least for these circumstances.

Two years or so ago I programmed an object that could seek an object based on a coordinate system. The counters would mess up at times, but it still worked pretty well. It was, at the time, the most complicated engine I ever made. I have it on my old computer which I plan to reconnect one time this summer.

Commodore wrote:The counter system itself is not as accurate as a similar varible system, and I think it'd be hard to program a bug free co-ordinate engine, at least for these circumstances.

What do you mean by saying that the counters aren't accurate, and what other variable system are you talking about?

The counters in zzt make poor replacements for varibles (which zzt lacks), and although there are situations where working around varibles using counters works, I think this sort of application might be too much for it to happen. It would work if the game didn't rely on objects (which execute commands in the order they were created in) to change the values of the counters.

Commodore wrote:It would work if the game didn't rely on objects (which execute commands in the order they were created in) to change the values of the counters.

Object execution order shouldn't be a problem, especially if you're using an external editor that allows you to change the order of items with stats. You just arrange them in whatever order you want them to run: player, controls, fake player, coordinate control, enemies. What possible problems are you thinking of?

basically I'm thinking of problems arising from the counter being given multiple messages to change value. When an object wants to check the position, it needs to take a certain amount of torches or whatever and check if it can, it has to do at least two operations to check 1) if it has enough torches, and 2) if it has more than enough torches. If you were to use multiple enemies on the board this would skyrocket the size, along with having multiple objects try to use one counter. Also the player object will be changing position, further changing the counter. And what would happen if an object was checking your position and you shot it? Either it would get a :shot message and jump out of whatever operation it was performing (not allowing it to restore the counter after #taking a certain amount to check), or you would have fixed that by locking it and the bullet would do nothing, making for a frusterating game.

The engine I was talking about before went to hell when the two objects hit each other (like when the seeking object wanted to go somewhere but was blocked). Other than that it was mostly smooth. Atrocity, I remember, made a similar engine but he was bragging about how the enemy could go around walls and shit.

Talking about zzt makes me want to work on games again. Keep up the good work, boyz.

Thanks for all your help guys, but here is my final decision. It will be a side-scroller. There will be light stealth action. (For an ex. The guards will be preoccupied with one thing or another, and there will be many ways to sneak up on him, (and many ways to mess up and he will notice you), depending on how invisible you are the enemy may do One of thee things, set off an alarm that will either call other men to the scene, or end the game.) or the enemy will be confused and wonder what made all the noise and quickly just shrug it off. (this will only happen when you are completely invisible). Or he will engage you at will. I think all this will make the game very enjoyable and new. I've also got a few more things to go with the gameplay that I wont tell right now, because I want the game to be of SOME surprise.

Thanks again.

This is a bit late, but just for the record, alignment detection using counter coordinate systems is possible. I have a working example at http://www.geocities.com/zztexpert/demos. All enemies are <i>Operation: O'Brian</i> style to show off the engine. The basic concept has already been discussed earlier in this thread, so I will not go over it again.

Details on this particular engine: Before reading the values from either torches or gems, they are copied one at a time to score using a fast binary-based algorithm; storing the values in score makes sure that they do not change while they are being read. They are read using an algorithm that #takes powers of 2, allowing the value to be read within several #take statements. Most of the engine code is kept out of the enemies, allowing code to be copied from board to board and enemies to mind other things; all they have to do is #zap and restore labels.

I have an unhealthy amount of free time on my hands. :(

Quantum sounds like MadTom. Next thing you know he'll be offering to make us some furry respite porn.

Which we would all cheerfully accept.

Dr Dos0016 (5:16:02 PM): also congratulations on winning
BlessThyFiveWits (5:16:17 PM): Thx
Dr Dos0016 (5:16:40 PM): and to think you did it without any true frost respite porn
BlessThyFiveWits (5:17:16 PM): If you really want some I could try drawing it.
BlessThyFiveWits (5:17:20 PM): I get bored enough. :-(

Hmmm, that's a cool engine...