Recorder
vexo...@gmail.com
have on 0.7 does it save movement of every single object? or just Kye's
movement? I was planing to have that, Amazing Kye had the solutions to
every level. My problem is that the hopes to make it cross platform was
making me wonder about random numbers and if a fixed random seed would
behave in different platforms.
So knowing if you are saving each object's position and not just the
player's movement would really help me.
Colin Phipps
> hello Colin , I have a question about the recorder you are planning to
> have on 0.7 does it save movement of every single object? or just Kye's
> movement?
I'm keeping just the Kye's movement. The 'dead reckoning' approach, as
opposed to a 'full game state' approach.
> I was planing to have that, Amazing Kye had the solutions to
> every level. My problem is that the hopes to make it cross platform was
> making me wonder about random numbers and if a fixed random seed would
> behave in different platforms.
The random seed is not a big issue, I think; I am using python's default
random number generator (RNG), which is written in python and so should
be the same on any platform. I save the RNG state at the start of the
recording. And I could easily copy the code for this into kye if python
ever decided to change it under me. Equivalently, any Kye implementation
could implement its own RNG, rather than rely on the system/language one
(e.g Doom did this).
The problem isn't the RNG, it's the object behaviour which is tricky;
with the 'dead reckoning' approach, any change in the behaviour of
(existing) objects will break old recordings - including fixing bugs in
the code for objects (I have lots of stuff still to look at to see if
the behaviour of timer blocks and shooters can be got right).
The comparison with Doom is good. It took years to find all the bugs
that prevented original Doom demos playing back correctly - the RNG was
no problem, we had the code for that, but the rest was a nightmare, as
people had edited the behaviour of many objects in the game before the
source code was released.
That said, I still prefer the 'dead reckoning' approach; at least, for
now, and for Kye. It takes much less code - it's just the normal game
code, plus ten lines to substitute a different input source. I don't
plan to change the objects, as they work pretty well as-is and existing
levels expect them to work just-so. And the levels are small, so even if
I have to re-record my demonstration recordings from time to time, it
won't hurt much. I may regret it later on, of course :-)
Vexorian
- Keyboard controlling works well most of the time but it sometimes ignores the pressed state of some keys when you kept them pressed while changing to other keys hard to explain and it is a minor issue although a guy like me that uses the keyboard to control kye in the ways I do experiences it periodically.
- It is possible to have holes in the borders of the levels, Original Kye added the border walls automatically when they were missing, the real catch is that if you move kye and try to get out of the border the game will freeze, you can use the menu commands but the game state won't change.
- I think that the blackies' eating animation rules are behaving different to original Kye , but I have to take a look at Kye 2.0 first in order to confirm, and for that I have to reboot, I need to download and install some packages before doing so.
I like the new skin, you should have screenshots of it in the web page.
Colin Phipps
> - Keyboard controlling works well most of the time but it sometimes
> ignores the pressed state of some keys when you kept them pressed while
> changing to other keys
I haven't done any real work on overlapping keypresses, so it's possible
there is still room for improvement here. I only use the keyboard for
small moves, I mouse for everything else, so I don't tend to notice these.
> - It is possible to have holes in the borders of the levels, Original
> Kye added the border walls automatically when they were missing, the
> real catch is that if you move kye and try to get out of the border the
> game will freeze, you can use the menu commands but the game state won't
> change.
Yes, I'm not sure why I didn't just apply the same restriction; I did
have a go at making the game safe without the borders, but since no
levels use this, it doesn't get tested much. And really it makes no
sense, because a clear border around the level is good to have, and all
existing levels assume that the game will enforce this. I'll switch to
the original Kye behaviour and add a border, and change the editor to
retain the border.
> - I think that the blackies' eating animation rules are behaving
> different to original Kye , but I have to take a look at Kye 2.0 first
> in order to confirm, and for that I have to reboot,...
The windows Kye 2.0 works quite well in wine, btw.
The blackies animation is a little different, mainly because the
original Kye seems to randomly skip frames in the blackie animation
sometimes. I think I assumed that this was a bug, although looking again
it does seem quite consistent. I wonder what the logic is meant to be -
20% chance of skipping each frame, something like that?
The animation being different is not bad in itself, but that would
affect the rate that the black hole consumes things, which would affect
some levels. I test this again.
> I like the new skin, you should have screenshots of it in the web page.
Yes, I need to redo my animated screenshot with the new tiles.
The Kye, gnasher and twister, the blocks, walls, stickies and clockers
are good. The bouncers, snake and blob are fairly lame and need work.
vexo...@gmail.com
DIAMOND-MINE
Only one drill at a time !
"Diamonds are a girls best friends"
555555555555555555555555555555
5 5
5 5
5 K 5
5 5
555555555555555555555e55555555
5HHHHHHHHHHHHHHHHHHHHeHHHHHHH5
5HHHHHHHHHHHHHHHHHHHHelLlllHH5
5H*HHHHHHHHHHHHHHHHHHeHHHHHHH5
5H*****************HHeHHHHHHH5
5HHHHHHHHHHHHHHHHHHHHeHHHHHHH5
5HHHHHHHHHHHHHHHHHHHHelLlllHH5
5H*HHHHHHHHHHHHHHHHHHeHHHHHHH5
5H*****************HHeHHHHHHH5
5HHHHHHHHHHHHHHHHHHHHeHHHHHHH5
5HHHHHHHHHHHHHHHHHHHHelLlllHH5
5H*HHHHHHHHHHHHHHHHHHeHHHHHHH5
5H*****************HHeHHHHHHH5
5HHHHHHHHHHHHHHHHHHHHeHHHHHHH5
555555555555555555555555555555
In kye 2.0 if you unlock every bouncer immediatelly 2 of the black
holes will fail. However in Python Kye and Xye the 3 of them will work.
In Xye it was intentional to fix the behaviour of blackies, at the
moment I programmed them I thought there was a random factor that was
difficult to predict and after figuring out that it does affect
gameplay I decided to make some more rigid rules for them.
But since Python Kye is a clone I guess you should change it.
Another difference is that in Kye 2.0 blackies didn't get animations
when kye died by them. I have never seen a Kamikaze level where you
have to die in order to make a bouncer push blackies so that probably
doesn't matter too much.
Colin Phipps
> In kye 2.0 if you unlock every bouncer immediatelly 2 of the black
> holes will fail. However in Python Kye and Xye the 3 of them will work.
Very interesting, thanks for this. It seems like some kind of iterator
delayed update bug - the first time a black hole swallows something, a
flag is set, and the next active black hole is caused to also switch to
its first-swallow frame. This throws off the timing of the other black
hole/bouncer setups. At least, this is my guess :-)
> Another difference is that in Kye 2.0 blackies didn't get animations
> when kye died by them. I have never seen a Kamikaze level where you
> have to die in order to make a bouncer push blackies so that probably
> doesn't matter too much.
That, at least, will be simple to fix.