Page 1 of 1

Guitar hero like game problem.

PostPosted: Sun Jul 29, 2012 7:40 pm
by TheRealVoid
Hi, i'm trying to make a guitar hero like game and run into this problem that couldn't solve:

I create an actor with a pseudo random symbol that moves in certain direction towards a goal like this:
----- . . . . . . . . . . . . . . -----. . .II
| -> | . . . . . . . . . . . . . |.....|. . .II
----- . . . . . . . . . . . . . . -----. . .II
new actor-----------------------goal----end line

When the created actor reaches the goal, you have to press the key corresponding to the appropriate symbol and if, it reaches the end line before doing so, you missed it.

For the end line, i'm using GE collision detection, so no problem there, but for the goal, i'm using a script like this (pseudocode):
if (newActor.name == keyPressed.name) && (newActor.xprevious > (goal.x - 20)) ) {
DestroyActor(newActor);
doSomeEffectsAndScoreStuff();
}

The problem is in the "(newActor.xprevious > (goal.x - 20))" part. For some reason, depending on the speed of the new actor, it is virtually impossible to get this script to work, is like there is a difference between what the user sees on the screen and whats going on in the model, so when you see that the new actor is on the goal and press the key, you just missed it.
Is this a GE limitation or i'm doing something wrong?

Thanks in advance.

Re: Guitar hero like game problem.

PostPosted: Tue Jul 31, 2012 6:21 pm
by TheRealVoid
Anyone? nope? nothing?....

I was thinking that maybe the problem is that the key press event lasts only for a frame and that the "new actor", since it has an xspeed of let's say 15 may miss the right position of the goal when te event is triggered.

I found that if you check the box that makes the key press event repeat as long as the key is pressed i don't have this problem but it also won't behave as a "guitar hero like game".

So i was tihinking that, as a workarond, i could use the key press event to set a counter with the ammount of frames i want to check for the key press and then in the draw actor of the goal check if that counter is greater than zero and in that case do my operations and finally decrease the counter till it reaches zero.

.... or am i not following correctly what GE does?

Re: Guitar hero like game problem.

PostPosted: Tue Jul 31, 2012 9:48 pm
by AliceXIII
I haven't tried this or tried making a guitar hero game but, you could make your goal a collide-able actor also, then on the goal actor's [key_down_event] when desired key is pressed then check whether the symbol is actually colliding with goal at that time or not instead of checking the symbols x in relation to goal just check whether it's actually colliding with the goal at the time..

Re: Guitar hero like game problem.

PostPosted: Wed Aug 01, 2012 12:09 am
by Jagmaster
Here's a small demo I a long time ago. Though it's not Guitar Hero, it might help a little. viewtopic.php?f=6&t=10874 It uses collision like Alice mentions and buttons are generated randomly and do not follow the music at all :lol:

Re: Guitar hero like game problem.

PostPosted: Wed Aug 01, 2012 5:22 pm
by TheRealVoid
Yes i know that using collision with the goal would solve that problem, but the reason why i don't use collision is that i defined the "win section" starting 20 pixels before the goal itself hence, if i use collision, the win section will start "size of moving arrow" before the goal. Anyway, if there's no other way i will have to add another actor to collide with to define the win section as i want, but since you cant collide with invisible actors, it will not look good.

Re: Guitar hero like game problem.

PostPosted: Fri Aug 03, 2012 12:26 am
by AliceXIII
Im sorry it took awhile for me to get to you but i see your problem there's actually a way to solve it, given i haven't tried this yet but in your symbols key down event put this:
Code: Select all
if(!CollisionFree("Event Actor", x+20, y))
{
    //code goes here
}


CollisionFree(); checks if theres not a collision at the specified coordinates from the specified actor before the actor moves there hence why i put the logical not operator in front of it '!' so we could check whether there is a collision there,
so if your symbol's xspeed was constant and it came up to 20 pixels before goal it would initialize..

to use correctly make your goal actor invisible by using a create actor event with a visibility state set to don't draw but allow events and this should take care of your problem if it's still not what you wanted let me know and i'll work to solve this problem :)