Commander Genius and Galaxy Engine progress
-
- Vorticon Elite
- Posts: 1246
- Joined: Wed Dec 31, 2008 14:44
- Location: Frankfurt - Germany
- Contact:
Thanks for the observation. I like that kind of animation and was wondering what might be different... I will see if I can freeze the camera will he climbs and then release when he finished.Nospike wrote:Awesome! I have some suggestions here:
- When Keen hangs at the end of a platform and climbs up, the screen moves too. Seems strange to me, I think it would be better if the screen moves after Keen climbs.
Not sure if it's because of the video. I have been lazy making those better. If you play it with CG yourself you will notice it much smoother.Nospike wrote:
- Keen's movement still seems a bit choppy to me, especially when he's walking down a slope.
Having fun developing stuff...
The Ledge-Grab camera is a tricky one.
The way I recommend is as previously stated - when Keen climbs a ledge, create a timer.
In the camera moving routine, if this timer is ever active, do not move the camera.
If the timer has expired, you need to calculate the difference between where the camera is, and where it *should* be. Then, adjust the camera at some set rate.
Because if you just wait a certain time before changing it, you create a flicker because it adjust by a number of pixels at one time which is not smooth. Note you need to do this in the x and y directions.
I have implemented this before - the above method works well, but is a problem if you climb a second ledge before the camera has adjusted for the first one, it gets a bit jerky. But I can live with that.
I also used this "pause camera" method for Keen looking up/down.
The way I recommend is as previously stated - when Keen climbs a ledge, create a timer.
In the camera moving routine, if this timer is ever active, do not move the camera.
If the timer has expired, you need to calculate the difference between where the camera is, and where it *should* be. Then, adjust the camera at some set rate.
Because if you just wait a certain time before changing it, you create a flicker because it adjust by a number of pixels at one time which is not smooth. Note you need to do this in the x and y directions.
I have implemented this before - the above method works well, but is a problem if you climb a second ledge before the camera has adjusted for the first one, it gets a bit jerky. But I can live with that.
I also used this "pause camera" method for Keen looking up/down.
I don't know if anyone has brought this up so far (I didn't bother to read the whole thread), but in the Galaxy engine, the camera will move vertically in the following cases:
- Keen reaches the top of the screen (his feet being around 32 pixels from the top)
- Keen reaches the bottom of the screen (his feet being around 32 pixels from the bottom)
- while in the air, Keen lands on something or grabs onto a pole or a legde (will "center" the camera vertically)
- climbing a legde will also "center" as soon as Keen "lands" on top of it
- climbing up or down a pole or walking up or down a slope will move the camera vertically by the same amount the player moves vertically
- looking up or down will also move the camera
So there's basically no reason to "pause" the camera if you only move the camera in one of the cases listed above.
I'd suggest that you handle horizontal and vertical camera movement in seperate functions. At least that's what I did in Keengine.
- Keen reaches the top of the screen (his feet being around 32 pixels from the top)
- Keen reaches the bottom of the screen (his feet being around 32 pixels from the bottom)
- while in the air, Keen lands on something or grabs onto a pole or a legde (will "center" the camera vertically)
- climbing a legde will also "center" as soon as Keen "lands" on top of it
- climbing up or down a pole or walking up or down a slope will move the camera vertically by the same amount the player moves vertically
- looking up or down will also move the camera
So there's basically no reason to "pause" the camera if you only move the camera in one of the cases listed above.
I'd suggest that you handle horizontal and vertical camera movement in seperate functions. At least that's what I did in Keengine.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
True,
But I think they did it that way because it saved processing time by only scrolling when absolutely necessary.
I think a game plays better if it scrolls with the player all the time - except for example when climbing the ledge. That's why I suggested the method above.
But of course if the idea is to clone Galaxy *exactly* then those would be the criteria to follow.
But I think they did it that way because it saved processing time by only scrolling when absolutely necessary.
I think a game plays better if it scrolls with the player all the time - except for example when climbing the ledge. That's why I suggested the method above.
But of course if the idea is to clone Galaxy *exactly* then those would be the criteria to follow.
I guess it depends on your own preferences. We've had the camera move with the player in the earliest versions of the engine that became Keengine and I found it awful to watch.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
-
- Vorticon Elite
- Posts: 1246
- Joined: Wed Dec 31, 2008 14:44
- Location: Frankfurt - Germany
- Contact:
Well as I though that those critics might come, I created a bit different camera system for the Galaxy Engine. The camera is an invisible object that follows keen. As it is connected through a pointer to him, I can control it at my wish. So I can do easily whatever I want if I trigger some player actions. No delays are other algorithms needed. I will see and implement K1n9_Duk3s idea later.
Thanks for the feedback!
A Report to trac might be nice, sometimes I forget to look here again, as I have a lot to do...
Thanks for the feedback!
A Report to trac might be nice, sometimes I forget to look here again, as I have a lot to do...
Having fun developing stuff...