with this i was able to make an aim based projectile system, rather than the earlier 6-direction system.
also smart shots that look to their target.
now i have another problem... how would i translate a circular trajectory into x/y speeds?
i want to make the aim arc around a 180º angle in front of the player, and the best i've managed is one that moves in 8 directions.
i've read about a constant velocity vector, and an angular speed vector, one would move the object straight in the angle it is facing, while the other would force rotation at a constant rate.
i'm not too good in maths so it's hard for me to know and memorize the meaning of some symbols that i've seen, so if this could be broken down into simple arithmetics i'd be much appreciated.
the engine's minimum specs are p3 processors or similar, i didn't want to go too much over that, and already did. the engine creator reported that his notebook can't run my game at full speed, cpu intel atom (?).i had other reports of people with older machines getting slow performances, and i try to shave as much as possible, without sacrificing too much.
the fact that hardware drawing is not supported it probably the major source of cpu overhead. the engine was designed for maximum compatibility, but i have a habit of pushing it to higher specs. It was never designed to host this kind of game in the first place, but it's doing it pretty well and i'd like to keep going.
i'm familiar with normals. i have worked with 3d and know the concept pretty well. normal map support is on my wishlist for future engine features, when it moves to hardware acceleration.
i know a thing or two about vector maths, in fact this night i discussed with a team mate the use of atan2 for point-at-target trajectory, and we were successful on that. the engine has a good support for vector maths and trigonometry.
the sticky physics are only applied to the player. other objects have only gravity, when called. and these are the ones i want to give a new life. as for the player, in physics, it behaves just like i idealized.
i also prefer a good looking illusion than an over-calculated precision. not that i don't want any precision, but the more time saved in development and in cpu-time, the best. again, a good balance of both can be achieved (for example, i don't need to calculate the rotation of a moving body in the air, i'll just rotate it by the speed it moves)
i will study the info you passed on, and try to build something with it during the weekend. thanks again :)
I'm actually wanting to do it by myself, so i can learn some maths and physics in the process, fields in which i admit i'm not too good, but i'll try my best to keep up :)
first thing i'm wanting to try is objects that upon collision with the player, receive the player's speed. i've gotten fairly ahead in this, but i'm failing to grasp the logic of bounces and gravity combined.
also i'm not a "real" coder, i get by with an engine controlled by scripts, so i can't adopt any physics libraries.
that is awesome! i wonder how much it will cost though, it doesn't seem like it would be free, because it would save movie and game industries lots of money in human resources and technologies, as well as lots of production time.
hey i found an approach for 8 directions which works great. this is coded in a script language that uses a state machine, but the logic is all here:
if "($xdistance > 0) and ($ydistance > 0) and ($absx > 0.414*$absy) and ($absx < 2.414*$absy)" "down_right" if "($xdistance < 0) and ($ydistance > 0) and ($absx > 0.414*$absy) and ($absx < 2.414*$absy)" "down_left"
if "($xdistance > 0) and ($ydistance < 0) and ($absx > 0.414*$absy) and ($absx < 2.414*$absy)" "up_right" if "($xdistance < 0) and ($ydistance < 0) and ($absx > 0.414*$absy) and ($absx < 2.414*$absy)" "up_left"
if "($xdistance > 0) and ($absx > $absy)" "right" if "($xdistance < 0) and ($absx > $absy)" "left"
if "($ydistance > $absx) and ($absx < 0.5*$absy)" "down" if "($ydistance < $absx) and ($absx < 0.5*$absy)" "up"
$absx and $absy are variables for the absolute values of x and y distance, respectively.
X is negative to the left, positive to the right, Y is negative up, positive down.
when the IF condition is met, the script jumps to the state specified in the last word, in this case, the directions.
thank you all (and a couple other team mates who wanted this badly :P )
Unfortunately I haven't had much time to blog. Although I have been doing stuff in the site, from an updated front page, to more wiki pages, and probably the worst, getting rid of and preventing spambot attacks which happened recently.
The 2D version lives on, 3D seems a promising path for future projects, but we haven't even finished this one. UDK disappointed me in the sense that it does not offer Linux support, thus disabling or severely crippling some of the few existing fans. I just haven't had the state of mind to elaborate a blog post, because behind the scenes, there is development in all fronts.
and you're right, we should link and show examples, so here they go:
please notice that this game only uses the bleeding edge versions of the engine, so don't feel fooled when you see "Open Sonic", which is the now defunct game that originated the engine. The real thing is in the forums.
The new engine is now called "Open Surge", (hint: Redshrike's Surge for USF)
It was not coded by any of us, team SD members, we only stick to the scripting API and some hacks. The engine was built with C++ and Allegro
Windows and Linux are supported in a straightforward fashion: unzip the game, and run the right file. simple :)
The game itself is not open, as in "everybody can join freely". Although we do not restrict contributors, there is a degree of control on who makes it to the team. Just to make sure no more posers come around. we had quite a few.
Music from the first vid is from Youtube, the 3rd vid has a song i put together with some samples, which are not free. sorry, no can do on that one :\ Although the game will have its own original soundtrack which we do want to share with the world, as well as any other assets we can provide to OGA users.
i managed to create the base of what i needed to implement such physics: movement based on angle.
provided i give an angle value and a speed value it will move it accordingly, as well as rotate it correctly.
xspeed = (-sin(deg2rad(movement_angle))*speed)*player_direction"
yspeed = -cos(deg2rad(movement_angle))*speed
with this i was able to make an aim based projectile system, rather than the earlier 6-direction system.
also smart shots that look to their target.
now i have another problem... how would i translate a circular trajectory into x/y speeds?
i want to make the aim arc around a 180º angle in front of the player, and the best i've managed is one that moves in 8 directions.
i've read about a constant velocity vector, and an angular speed vector, one would move the object straight in the angle it is facing, while the other would force rotation at a constant rate.
i'm not too good in maths so it's hard for me to know and memorize the meaning of some symbols that i've seen, so if this could be broken down into simple arithmetics i'd be much appreciated.
the engine's minimum specs are p3 processors or similar, i didn't want to go too much over that, and already did. the engine creator reported that his notebook can't run my game at full speed, cpu intel atom (?).i had other reports of people with older machines getting slow performances, and i try to shave as much as possible, without sacrificing too much.
the fact that hardware drawing is not supported it probably the major source of cpu overhead. the engine was designed for maximum compatibility, but i have a habit of pushing it to higher specs. It was never designed to host this kind of game in the first place, but it's doing it pretty well and i'd like to keep going.
i'm familiar with normals. i have worked with 3d and know the concept pretty well. normal map support is on my wishlist for future engine features, when it moves to hardware acceleration.
i know a thing or two about vector maths, in fact this night i discussed with a team mate the use of atan2 for point-at-target trajectory, and we were successful on that. the engine has a good support for vector maths and trigonometry.
the sticky physics are only applied to the player. other objects have only gravity, when called. and these are the ones i want to give a new life. as for the player, in physics, it behaves just like i idealized.
i also prefer a good looking illusion than an over-calculated precision. not that i don't want any precision, but the more time saved in development and in cpu-time, the best. again, a good balance of both can be achieved (for example, i don't need to calculate the rotation of a moving body in the air, i'll just rotate it by the speed it moves)
i will study the info you passed on, and try to build something with it during the weekend. thanks again :)
thank you.
I'm actually wanting to do it by myself, so i can learn some maths and physics in the process, fields in which i admit i'm not too good, but i'll try my best to keep up :)
first thing i'm wanting to try is objects that upon collision with the player, receive the player's speed. i've gotten fairly ahead in this, but i'm failing to grasp the logic of bounces and gravity combined.
also i'm not a "real" coder, i get by with an engine controlled by scripts, so i can't adopt any physics libraries.
that is awesome! i wonder how much it will cost though, it doesn't seem like it would be free, because it would save movie and game industries lots of money in human resources and technologies, as well as lots of production time.
hey i found an approach for 8 directions which works great. this is coded in a script language that uses a state machine, but the logic is all here:
if "($xdistance > 0) and ($ydistance > 0) and ($absx > 0.414*$absy) and ($absx < 2.414*$absy)" "down_right"
if "($xdistance < 0) and ($ydistance > 0) and ($absx > 0.414*$absy) and ($absx < 2.414*$absy)" "down_left"
if "($xdistance > 0) and ($ydistance < 0) and ($absx > 0.414*$absy) and ($absx < 2.414*$absy)" "up_right"
if "($xdistance < 0) and ($ydistance < 0) and ($absx > 0.414*$absy) and ($absx < 2.414*$absy)" "up_left"
if "($xdistance > 0) and ($absx > $absy)" "right"
if "($xdistance < 0) and ($absx > $absy)" "left"
if "($ydistance > $absx) and ($absx < 0.5*$absy)" "down"
if "($ydistance < $absx) and ($absx < 0.5*$absy)" "up"
$absx and $absy are variables for the absolute values of x and y distance, respectively.
X is negative to the left, positive to the right, Y is negative up, positive down.
when the IF condition is met, the script jumps to the state specified in the last word, in this case, the directions.
thank you all (and a couple other team mates who wanted this badly :P )
@ Charlie
Unfortunately I haven't had much time to blog. Although I have been doing stuff in the site, from an updated front page, to more wiki pages, and probably the worst, getting rid of and preventing spambot attacks which happened recently.
The 2D version lives on, 3D seems a promising path for future projects, but we haven't even finished this one. UDK disappointed me in the sense that it does not offer Linux support, thus disabling or severely crippling some of the few existing fans. I just haven't had the state of mind to elaborate a blog post, because behind the scenes, there is development in all fronts.
and you're right, we should link and show examples, so here they go:
SD website
Two submissions of sprites from SD
SD Creatures
SD Enemies and playable characters
@Mumu Mumuch appreciated :D thank you!
the game engine is open, you can find it at http://opensnc.sourceforge.net
please notice that this game only uses the bleeding edge versions of the engine, so don't feel fooled when you see "Open Sonic", which is the now defunct game that originated the engine. The real thing is in the forums.
The new engine is now called "Open Surge", (hint: Redshrike's Surge for USF)
It was not coded by any of us, team SD members, we only stick to the scripting API and some hacks. The engine was built with C++ and Allegro
Windows and Linux are supported in a straightforward fashion: unzip the game, and run the right file. simple :)
The game itself is not open, as in "everybody can join freely". Although we do not restrict contributors, there is a degree of control on who makes it to the team. Just to make sure no more posers come around. we had quite a few.
website is http://shinobisensetsu.webs.com , the same you will find in my profile.
Music from the first vid is from Youtube, the 3rd vid has a song i put together with some samples, which are not free. sorry, no can do on that one :\ Although the game will have its own original soundtrack which we do want to share with the world, as well as any other assets we can provide to OGA users.
Pages