61 replies to this topic

[Seeker]

Point Magic

By Seeker

Example Screenshots:





Mouse gesture recognition, RTS formation builder, you name it! Point Magic is a collection of over 120 scripts that takes point manipulation to the max.

Highly popular games such as Black & White by Lionhead Studios and Okami by Capcom allow you cast magic spells by drawing them on the screen. You can do that with Point Magic and much more. Here are some ideas:

Don't want to use D3D transformation functions to transform shapes? Try creating and drawing any shape you desire with the point scripts, and you can easily make them move, rotate, scale, and flip across the screen in various ways.

Want a substitution or supplement for Game Maker's path functions? Or maybe you would like a bridge to the easy creation, management, and assessment of particle systems?

Beyond the point scripts, there are a few supporting scripts included that you will find useful in just about any project: string_split(), draw_circle_perfect(), etc.

The example demonstrates the mouse gesture system and a formation builder. There are two secrets, one in each example, that you can unlock by deciphering the clues. Might as well make a game out of it. :-) But if you do not want the challenge and just want to see the subtle surprises, read the notes at the end of the gesture_define() script (just before the code starts), and you will be told what to do. The first script you will see is labeled 'Info'. Read it, and you will be shown the path to the most important scripts.

Please comment, request, and report any bugs! Based on feedback, I may continue adding even more scripts and examples. And if you create an advanced, new type of example with the scripts yourself that you'd like to share, please do. If you want, I can add it to the download and mention you in the credits.

Download Point Magic 1.1

An extended gesture tutorial can be found Here. You can download it in .rtf format here (thanks to Deri): Download Gesture Tutorial. The extended tutorial will be added to future distributions.

Version History

1.1: Download

- Added the ability to enable an extended scan for a gesture definition, making it so that the user can draw a shape from any vertex and in any direction. See argument4 in the gesture_define() script for more information.

- Added a few more notes to the gesture_define() script.

- Minor demo object and script changes.

1.0: Download

- Initial release

More Examples

Ink Collision, Version 2: Download

Let your objects collide with lines drawn on the screen, even move across slopes like in the Line Rider games! Press F1 for the list of controls and other information.

Stick Animator/Ragdoll Creator: Coming Soon

Bend a stick figure to your will and dress it with your own sprites. Like Pivot Stickfigure Animator, but better. A physics system and a 3D aspect may be included.

Pose/Gesture Recognition/Line Rider-type Game: Coming Soon

An Action RPG demo that makes use of the gesture recognition, a body pose recognition system created with the point scripts, and the ink collision example.

Other

Kyle_Solo has done a gesture recognition system of his own. You should check both systems out and see what you like. His topic is found here.

Edited by Seeker, 09 August 2007 - 05:12 PM.

[tdmgames]

well, not as gd as i thought it was ogign to be, very prossinally set out thou!

[Seeker]

well, not as gd as i thought it was ogign to be, very prossinally set out thou!

<{POST_SNAPBACK}>

Well...thanks? Could you explain? What don't you like about it? Keep in mind there are several options for tweaking the system to your liking. There's over 500 lines of comments in the gesture_define() script that explains how. There's no perfect way to set things up, but you can improve things just by entering a few arguments.

Make sure you look under the 'Shapes' tab and draw each shape as shown, starting from where you see the dot on the shape and going counter-clockwise. For some shapes, I enabled flips and rotations, so you can draw them in different ways. The gesture_define() script explains everything.

Edited by Seeker, 21 May 2007 - 10:27 PM.

[Kyle_Solo]

The recognition is OK, I guess... Try as I might, I could not get it to recognize a square, though. The other shapes were fine though (except for the "X", I couldn't figure out how to draw it). It uses a different method from mine. I think it could be very useful for the formations, though. Very nicely put together. I would encourage anyone reading this to check it out!

EDIT: I eventually did manage to draw the "X". You just have to do it quickly.

Edited by Kyle_Solo, 22 August 2007 - 02:12 PM.

[Seeker]

The recognition is OK, I guess... Try as I might, I could not get it to recognize a square, though.  The other shapes were fine though (except for the "X", I couldn't figure out how to draw it). It uses a different method from mine.  I think it could be very useful for the formations, though.  Very nicely put together.  I would encourage anyone reading this to check it out!

<{POST_SNAPBACK}>

Thanks, Kyle. Sorry guys, but I can get all of the shapes recognized every single time I draw them. If you are having trouble, try going into the Demo object where the gestures are defined and change the third argument in each gesture_define() call. If you lower the number you see there, it'll be easier for you to draw the shapes. (The values you see already will be at around .8 and .95. I found the shapes easy to draw, so I set the requirements high, but you can lower them and make it easy.)

For the square, make sure you start at the top left corner and go counter-clockwise. I set it up so that you have to draw each shape at a medium to large size. If you want to be able to draw it extremely small, you'll have to change the settings in the gesture_update() script.

For the X, you have to draw the line going from the top left to the bottom right. Release the mouse. Then draw the line going from the top right to the bottom left and release the mouse. You have to draw both lines within a short time period within each other, otherwise things will be reset, and you'll have to do it again.

Please read all of the notes in the gesture_define() and gesture_update() scripts.

Also, remember that some shapes can be drawn at different rotations. Try drawing the triangle clockwise, then draw it counter-clockwise. Try drawing it upside down and rotated 90 degrees in either direction. It all works perfectly, but maybe I'm just a master at drawing the shapes. Change the settings if necessary, and you'll see how good it is.

Edited by Seeker, 22 May 2007 - 12:18 AM.

[Kyle_Solo]

Does this support auto-resizing?

[Seeker]

Does this support auto-resizing?

<{POST_SNAPBACK}>

Size does not matter in this case unless you are trying the draw the shapes extremely small. This recognition is all about the angle between the points unless you are using directional string definitions. Anywhere from a small normal to an extremely large size will automatically work. To enable smaller sizes, you'd have to lower the stroke size and/or vertex angle arguments used in the gesture_update() script.

There's an argument in the gesture_define() script that also has to do with size. And you can always use the pointgrid_scale() script.

There's a script or an argument for pretty much everything! :-)

I want to point out to others that when you run the demo and see the gesture string at the top, that's not all the recognition does. You can define a gesture in two ways. You can either create a directional string or you can add point coordinates to a grid, which involves taking a dot product between vectors among other things, and is MUCH more powerful. The directional strings are tested using a string comparison script if you choose that route.

There's a very high level of customization here. The gesture_define() script alone calls for 16 arguments. You only HAVE to pass one of the arguments (the first one), but you can enter values for some of the others to customize and add interesting effects to the system.

Edited by Seeker, 23 May 2007 - 08:36 PM.

[Calle]

Wow. You've done a lot of work with that, and it shows. Really good!

[Seeker]

Wow. You've done a lot of work with that, and it shows. Really good!

<{POST_SNAPBACK}>

Thank you! That means a lot coming from you, Calle. You're also an advanced script writer who's impressed me in the past.

[Seeker]

I've created an "ink collision" example. Now with just one ink collision instance, your objects can collide with lines drawn on the screen and move across slopes! (Line Rider, anyone?) The basic movement is from the Fox Engine.

Download Ink Collision Example.zip

It's not perfect yet, but it's still pretty good, and I'll probably be working on it some more. Use the left mouse button to draw a line. Draw the line slow enough to make sure the red points cluster closely together and are as straight as possible to create smooth, navigatable terrain. Use the arrow keys to move the player.

Edited by Seeker, 02 June 2007 - 05:37 AM.

[icuurd12b42]

I've created an "ink collision" example.  Now with just one ink collision instance, your objects can collide with lines drawn on the screen and move across slopes!  (Line Rider, anyone?)  The basic movement is from the Fox Engine.

Download Ink Collision Example.zip

It's not perfect yet, but it's still pretty good, and I'll probably be working on it some more.  Use the left mouse button to draw a line.  Draw the line slow enough to make sure the red points cluster closely together and are as straight as possible to create smooth, navigatable terrain.  Use the arrow keys to move the player.

<{POST_SNAPBACK}>

Make your ink not solid. I'll be better without the freesing when the block penetrates the line.

[Seeker]

The block won't freeze if you draw the line as I explained it. Draw it slowly enough so the red points cluster closely together enough and are as straight as you can make them. And sometimes when you think you might be stuck, you can just jump right out of it. And then there are the movement and deletion gesture scripts. This is also a quick, first example that I may work on more later, but it works great when I'm using it.

EDIT: I've figured out how to make the collisions more accurate. Now the player actually collides with the lines instead of the points. Will be uploading a better example before the day is out.

Edited by Seeker, 02 June 2007 - 06:25 PM.

[Kyle_Solo]

//force_line()
//use when drawing
var dist,dir;
if !variable_exists("mxp")
{
      mxp = mouse_x
      myp = mouse_y
}
dist = point_distance(mxp,myp,mouse_x,mouse_y)
dir = point_direction(mxp,myp,mouse_x,mouse_y)
for(i = 0; i <= dist; i += 1)
{
        //create point with these x and y:
        //x =mxp+lengthdir_x(i,dir)
        //y =myp+lengthdir_y(i,dir)
}
mxp = mouse_x
myp = mouse_y

This script will force you to draw a connected trail of points. Faster room_speed, smoother line.

Edited by Kyle_Solo, 02 June 2007 - 07:27 PM.

[icuurd12b42]

The block won't freeze if you draw the line as I explained it.   Draw it slowly enough so the red points cluster closely together enough and are as straight as you can make them.  And sometimes when you think you might be stuck, you can just jump right out of it.  And then there are the movement and deletion gesture scripts.  This is also a quick, first example that I may work on more later, but it works great when I'm using it.

EDIT:  I've figured out how to make the collisions more accurate.  Now the player actually collides with the lines instead of the points.  Will be uploading a better example before the day is out.

<{POST_SNAPBACK}>

I too fixed it to be so...
Player create
OldInk = -100

end step
if (mouse_check_button(mb_left)) {

if(instance_exists(OldInk ))
{
OldInk.image_xscale = point_distance(old.x,old.y,mouse_x,mouse_y);
OldInk.image_angle = point_direction(old.x,old.y,mouse_x,mouse_y);

}
OldInk = instance_create(mouse_x,mouse_y,Ink);
}
else
{
OldInk =-100;
}

and I removed Ink Collision Code in the end step and the gesture draw in the paint and set the Ink parent to BlockP and made the Ink visible...

However that engine block collision if pretty buggy and you may end up freezing the game when the collision code gets confused on what to do.

Edited by icuurd12b42, 02 June 2007 - 08:23 PM.

[Seeker]

I uploaded a much better Ink Collision example. Upon trying it a number of times, I never got stuck in the ink. In this example, you can also right-click to clear an ink region. See the Game Information (press F1) for more details. The download is in the first post.

This script will force you to draw a connected trail of points.  Faster room_speed, smoother line.

<{POST_SNAPBACK}>

Thank you. I had considered using code like that before, but I didn't want to make the vertex list too large. I've used a modified version of that code that skips every 8 points (or the number you set in the player's creation event), and everything works very well.

I too fixed it to be so...

Your code works quite nicely. Thank you. Though the user that requested help with an ink example was looking for a way to avoid creating multiple ink instances. The new example I've uploaded takes things in a completely different direction. Now you collide with the actual lines and not the points, and no ink instances are used. I did have to use a "wall" instance to handle wall collisions. The movement is much nicer in this version.

Edited by Seeker, 03 June 2007 - 10:32 PM.

[icuurd12b42]

I uploaded a much better Ink Collision example.  Upon trying it a number of times, I never got stuck in the ink.  In this example, you can also right-click to clear an ink region.  See the Game Information (press F1) for more details.  The download is in the first post.

This script will force you to draw a connected trail of points.  Faster room_speed, smoother line.

<{POST_SNAPBACK}>

Thank you. I had considered using code like that before, but I didn't want to make the vertex list too large. I've used a modified version of that code that skips every 8 points (or the number you set in the player's creation event), and everything works very well.

I too fixed it to be so...

Your code works quite nicely. Thank you. Though the user that requested help with an ink example was looking for a way to avoid creating multiple ink instances. The new example I've uploaded takes things in a completely different direction. Now you collide with the actual lines and not the points, and no ink instances are used. I did have to use a "wall" instance to handle wall collisions. The movement is much nicer in this version.

<{POST_SNAPBACK}>

Yeah, I saw it (The no instance spec I mean). But instance that do nothing (no code) are less costly than a ds_list or map... You would need to have thowsands of instances to start seeing a difference. The ds_list method would start to fall apart much much sooner.

Cheers!

[Seeker]

Yeah, I saw it (The no instance spec I mean). But instance that do nothing (no code) are less costly than a ds_list or map... You would need to have thowsands of instances to start seeing a difference. The ds_list method would start to fall apart much much sooner.

Cheers!

<{POST_SNAPBACK}>

True. But I enjoyed making this example, :-D. I tested it by scribbling across the screen several times. Even with a massive ink blob, there was no speed hiccup on my poor little machine. But I wouldn't expect the end user to draw as many lines as I did, so they should never have to worry about speed. Things won't break unless they are trying to break it!

Since I'm probably going to use this in my game, I'll make sure the players know the limitations. I'll tell them if they ever experience a speed hiccup, all they have to do is click the middle mouse button to erase all of the ink. Either that, or I'll make it so that all of the ink is cleared when they first press the draw button, so they can only draw one platform at a time. (That's all they will need, right?) I can even use the erase_region() script to erase all of the ink outside the current view the moment the player moves outside each boundary.

Thanks for the input!

[Seeker]

For the gesture recognition part of the system, I forgot to mention that you'll find it much easier to draw the shapes if you draw them quickly, because of the settings I set for the demo. You could actually draw a perfect square for example, but if you drew it too slowly, it might not return a shape. And then you would say to yourself, "This system sucks!" and not give it a fair chance.

Here are a few tips.

1.

Go into the Demo object's End Step event. Go to the code action that says "Update system". Where you see

winner = gesture_update(mouse,15,40,7,0,1,ge);

Change it to

winner = gesture_update(mouse,1,40,7,0,1,ge);

What I just did was change the second gesture_update() argument--the "stroke size" argument--from 15 to 1. What this does is makes it so that shorter mouse movements are recognized. Before, I had it to where you had to make medium to large mouse movements for your gestures to be recognized, and that's where some of you may have had some problems.

2.

When you define your shapes using point grids, keep their size in mind. For example:

line_grid = pointgrid_create();
pointgrid_add_line(line_grid,0,0,15,0,false);

This code would create a straight horizontal line shape that runs to the right. The line would have a width of 15, so it would be a recognizable shape using the example's current stroke size setting of 15. If the line was created like this:

line_grid = pointgrid_create();
pointgrid_add_line(line_grid,0,0,14,0,false);

The line would only have a width of 14, so a stroke size of 15 would cause the line not to be recognized. So once again, you may want to set the stroke size argument to 1, as I pointed out above. In this code, I created the line at position (0,0) in the room, but you could actually create it at any position in the room (avoid negatives) and achieve the same results.

3.

Another setting to change, which I'd like to mention again, is the 'similarity bar' of each gesture defined in the Demo object.

For example, take this line of code, found in the "Init gestures" code action of the Demo object's creation event:

rectangle = gesture_define(rectangle_grid,0,.95,'','','',45,'',0,'','','',0,7000,0,'show_message("Rectangle: " + string(gesture_get_score(rectangle)*100) +"%")');

Notice the third argument value, (.95). This is the lowest possible score that gesture definition must have in order for it to return a message, like "Rectangle: 95%". If you don't draw the shape well enough to meet this number, no message will be shown. So to make things easier for you, all you have to do is lower the number indicated here a few decimal points to give you a higher probability of drawing that shape. But of course, you wouldn't want to set this number below .5 for example, as that wouldn't be a good indicator that the user has drawn that particular shape. 50% means nada. With the exception of the question mark, the shape recognition mostly uses what is called a dot product, http://en.wikipedia....iki/Dot_product, which is what some gesture recognition systems written in professional languages use.

For the question mark, I used a string similarity script for the recognition. That's what the gesture string (N,NE,SE....) you see in the demo is for. This system has two types of gesture recognition--dot product and string similarity. You can define your shapes using either. Dot product is much more accurate, but I wanted to give you some options. If you do what was mentioned in the previous tip and lower the stroke size from 15 to 1, you will most likely not be able to draw the question mark shape without extending the question mark string definition.

4.

And of course, as mentioned, you need to draw each shape as they are shown to you in the Shapes tab of the demo. Start drawing from where you see the point on the shape. The rectangle has to be drawn counter-clockwise, because that's the way I set it up in the example. But you could set it up to be drawn in any direction. And again, some shapes can be drawn from different directions and angles, because that's how I set it up in the example.

I set the demo settings with high requirements, because I never had any trouble drawing the shapes. If you are not sure on how to change something to suit you, let me know. You can also read the tutorial.

Since I'm done with the core system, I'll just be releasing more examples and creations from time-to-time, which I've listed in the first post.

Edited by Seeker, 10 June 2007 - 04:04 AM.

[oakwhiz]

I'm probably going to use this in my Nintendo DS simulator. Keep up the good work!

[Deri]

Nice system! It works quite well, but if I were to use this in a game I would make it so that you don't have to start at or end at a specific point and go in a specific direction.

The recognition is OK, I guess... Try as I might, I could not get it to recognize a square, though.  The other shapes were fine though (except for the "X", I couldn't figure out how to draw it). It uses a different method from mine.  I think it could be very useful for the formations, though.  Very nicely put together.  I would encourage anyone reading this to check it out!

<{POST_SNAPBACK}>

I can get all of the shapes except for the "X" and the "?". Even after reading what you said, it still doesn't work!

Edited by Deri, 09 June 2007 - 11:40 PM.