-
ge.cpp updated before holiday
I have updated ge.cpp because there were some errors in DoHead(). Centipedes move correctly now, but there's still some bugs in the ReverseCentipede() code which I will have to fix after my holiday. I've decided to leave the laptop at home, so there'll be no more updates for about 2 weeks.
wep
2005-08-09 06:52:26 UTC by wep
-
centipede movement
Hi,
It's been a long time since my last post. I haven't been able to do much work. I've spent some of it thinking about how to move centipedes though.
This morning I wrote an important part of the movement code. There are still some bugs to iron out and I have to make sure that all zzt's quirks are included as well. So there will be a lot of testing to do.
I will upload the latest code in a minute, but I wouldn't build any houses on this. Meaning that stuff may still change. I know there have been a lot of different changes to the code, but this subject turned out to be a lot more difficult than I imagined it to be at the start.
Also, you should keep in mind that until the final object animation code is done, linking segments will behave a bit different than original zzt. Not much though...you would have to know what to look for or you won't see it.
I'm on vacation now (two weeks), one of week of which I will be spending without an internet connection. I am bringing my laptop, so work should continue if the rest of the family allows me to. Wish me luck!
wep
2005-08-07 09:08:18 UTC by wep
-
object animation (cntd)
I had a thought today. An important one I think...
While thinking about centipede movement, I have really been worrying about two problems at the same time. I have been researching how zzt updates heads and segments so deeply that I forgot to take a step back. I have taken that step now and here's what I saw.
ZZT does not update objects in a linear fashion. That would make object movement obvious and predictable: not much fun in a game. So Tim came up with a way of pseudo-randomly updating objects, using what I have come to know as the "cycle speed" parameter that is contained in each object. I now think that whoever came up with that term (cycle speed) was mistaken. Certainly, increasing the cycle speed setting slows things down. But I think that is just a side effect of the real or at least more important use for the parameter. How ZZT exactly manages to update a subset of all creatures in every game loop, but still to update them all over the course of time is not yet clear to me. That this way of working causes problems when animating objects that are related to eachother (centipedes) is obvious to me.
So segments, when they first appear, have their next and previous pointers set to MAXINT. This is to show that they have not been visited yet. Each time ZZT encounters a segment with two MAXINT settings, it sets the previous pointer to MAXINT-1. This marking tells ZZT in a later stage that these segments have not been linked to centipedes and may be turned into lone heads themselves.
In the mean time, heads are being told to link to any segments they encounter. Segments linked to centipedes have their next and previous pointers set to object numbers they are linked to, preventing them to be turned into heads.
Principally speaking, this explains why segments are sometimes linked to centipedes and sometimes not; it is determined by the haphazard order in which the objects are updated.
Just one problem: how long must a segment wait before it can turn intself into a head? When all heads have linked, and it is positively sure the segment will not get linked by a head. How does it know this? My guess is by keeping a head count: ZZT counts the number of heads at the start of a board. Then counts each head it links until the correct number is hit. That is the cue for unlinked segments to start turning into heads themselves.
Now it's just a matter of handling the special situations: heads that cannot move do not link. Segments that cannot move do not turn into heads.
So I probably have the centipede movement down. It appears I got it right the first time round, but I was thrown for a loop by the awkward way ZZT updates objects. Just think: segments have a "cycle speed" setting of 2. Segments are updates odds, then evens. When I set the "cycle speed" to 10, every tenth segment is updated in a game loop. Increasing the number will slow the movement down. Is it just taking ZZT longer to update each object when the interval is so large? What's the algorythm here? And isn't cycle speed meant to be called "interval" or something?
wep
2005-07-16 21:59:04 UTC by wep
-
object animation
The research into how centipedes move has resulted in a rather extensive project in itself.
To be clear on the situation: I have the code for linking segments to heads. Animating them shouldn't be very difficult. But the way I have come up with does not exactly match the zzt works. On the surface it will be very difficult to detect, but under water there would be major differences. I'll expand a little.
There are two things that bug me about how zzt moves centipedes:
1. ZZT marks segments before it moves them. the "previous" pointer (which segments use for linking) is set to 65534.
2. In some cases segments will link to centipedes and in other cases, the same segment in the same setup won't link.
My initial method of linking is executed before a board is started. ZZT very obviously doesn't do that, although I believe it to be a much simpler method.
The way I know this has to do with how I do my "research". It is possible to interrupt the execution of ZZT by simply saving the current game. By analysing a saved game, you get a view of the order in which ZZT does things. The view is limited to what ZZT saves to world files, so it is not complete.
The fact that I can interrupt ZZT by saving between the update of two creatures, means that those two creatures are updated in different game loops. Which leads to my current problem: in what order does ZZT update objects.
This is where the weird stuff starts. At first I thought that ZZT simply updated odd and even numbered creatures alternatively. That turns out not to be the case. Why? I made a world with a centipede containing about 90 segments. I updated the world file using a hex editor to update the cycle speed from 2 to 14. I started the world and saved a game every second or so. Analysing the saved games showed that ZZT was updating the segments in the order: 7, 21, 35, 28, 42, etc. So it was taking steps of 14. Setting the cycle speed to the value 2 results in alternating between odds and evens, depending at which creature number you start. Since segments are set to cycle speed 2 by the editor and they cannot be changed by the user, this odds-and-evens behaviour is fixed.
By the way: using the #cycle command in objects does not alter their internal update speed. Objects are always set to cycle speed 3.
Somewhere in the data I have there's the answer to how ZZT really handles objects and game speed. I find it hard to believe that ZZT uses the cycle speed to determine how many creatures to skip in the current game loop. I would rather believe that ZZT keeps an internal counter for each creature that counts down to zero, causing the creature to be updated at that moment.
Although, now that I think about it: all creatures have a fixed cycle speed. So it is possible to keep a general cycle counter against which objects' cycle speeds can be checked, only updating the creature if the counter is at a multiple of its cycle speed.
All in all, centipede movement is going to have to wait while I think more about this. ZZT++ will come out a lot better once I've got the trick.
wep
2005-07-15 09:04:08 UTC by wep
-
how centipedes behave
On Centipedes
Heads are always on the move and never stop unless there is no room to move.
Heads normally only change direction when they are at a player axis
or when they hit an obstruction. Intelligence determines the odds of
whether it will move towards or away from the player.
Deviance will influence the number of times a head will change direction
for no reason at all.
A head with the lowest intelligence will mostly just go forward until
it hits a wall and then change direction.
A higer deviance will determine how often a head will change direction.
When a head with segments cannot move in any direction but towards
its segments, the last segments becomes the head and the head becomes
the last segment.
Segments that are not part of a list will become heads.
When a centipede's head is boxed in, but there is room behind the last segment,
all segments become heads.
When a centipede's head is surrounded by segments, all segments also become
heads.
When a centipede is boxed in and there is no room to go anywhere, it just sits
there without changing. Under water, the segments aren't linked to the head.
When you save a game a split second after starting it (with centipedes on the
board), you can catch zzt setting up the centipedes. This can be seen by
looking at the "next segment" and "previous segment" pointers. Right after
saving a new board, all these segment pointer have the value 0xFFFF. But, if
you save at exactly the right moment, you will see segments with "previous
segment" pointers with a value of 0xFFFE. After the centipede has taken a single
step, this is no longer visible. This proves that zzt sets up the centipedes
at the first move of the head.
When setting up centipedes, zzt uses clock wise and counter clock wise methods:
1. a head sitting half way and to the left of a column of segments,
will link the segments in the lower half of the column (clockwise)
2. a head sitting half way and to the right of a column of segments,
will link the segments in the upper half of the column (clockwise)
3. a head sitting half way and above of a row of segments,
will link the segments in the right half of the row (counter clockwise)
4. a head sitting half way and below a row of segments,
will link the segments in the left half of the row (counter clockwise)
Regardless of these directions, a segment adjacent to a linked centipede,
will sometimes be linked at the end of the centipede and sometimes go on
as a head.
2005-07-08 22:02:56 UTC by wep
