"Aquaria-Like" Mouse Leading Possible?

I'm generally not that fond of 2D games, but when I saw all of the effects that can exist in a 2D game as demonstrated in "Aquaria", I sort of changed my mind.

There are a lot of advanced behaviours going on in this game, but the navigation, alone, is quite compelling. Rather than verbally describe it, take a look-see at the demos:

http://www.bit-blot.com/aquaria/

Is this kind of "mouse leading" navigation a difficult thing to accomplish, for a beginner, using Construct?

Since the game takes place in a weightless, "aquatic" environment, gravity is not much of an issue. But, watching the demos of Aquaria got me thinking about how difficult it would be to make a similar game, where gravity takes the form of whichever "walking" surface you are closest to - (floors, walls, ceilings or slopes) - a kind of "magnetic" gravity involving special collision detection, I would imagine.

Anyone care to comment?

Psmith

No, leading the player with the mouse is not hard. You can do it in one event:

http://dl.dropbox.com/u/529356/mouselead.cap

Made in v0.99.62. Hold left mouse to move the circle.

If you wanted something like acceleration and deceleration it would simply be a matter of adding another event or two.

Also, this isn't the only way you could can do this. You could use a behavior like Bullet, 8Direction, Custom Movement, or even Physics, instead of coding your own. But it's such an easy movement to make I don't see why you'd need to.

As for the different gravity directions... yeah, that would be harder to do for a beginner.

DeadEye:

Thanks for putting that together for me. Only 2 events - that is economical.

But, I would have never been able to put that together for myself - not with my Zero knowledge of that kind of programming. (Lerp and all that). What or Who is Lerp? (Don't feel compelled to try and explain). I imagine that has something to do with how the ball accelerates and decelerates - or seems to, anyway.

And, thinking about the problem, again, I would probably approach that kind of simulation "physically", using a "spring" attachment of the player to the mouse cursor.

Really, thank you,

Psmith

Heres a slightly easier example:

http://dl.dropbox.com/u/939828/dolphin.cap

Basically I attached 'custom movement' which allows me to move the dolphin with more realistic physics.

Lerp lets you take a number, and another number, and find an inbetween number.

eg

lerp(0, 10, 0.5) is 5

lerp(10,20, 0.5) is 15

2 * timedelta is about 0.03 so basically in deadeyes code it means that you take a lot of the current position, and a little bit of the mouse position...and place it between.

What or Who is Lerp?

It stands for "linear interpolation," and it's a very useful and powerful math function. I had no clue what the hell it was when I first started to use Construct, but once it was explained to me (see David's post above) it made complicated stuff a lot easier. I know you're adverse to the whole coding side of things, but lerp() is a really good one to know.

In my opinion, everyone should make friends with lerp() and clamp(), which is also so useful it's sickening. There's a list of system math expressions here on the wiki:

http://sourceforge.net/apps/mediawiki/c ... xpressions

Lerp() and clamp() are under the math section.

> What or Who is Lerp?

>

It stands for "linear interpolation," and it's a very useful and powerful math function. I had no clue what the hell it was when I first started to use Construct, but once it was explained to me (see David's post above) it made complicated stuff a lot easier. I know you're adverse to the whole coding side of things, but lerp() is a really good one to know.

In my opinion, everyone should make friends with lerp() and clamp(), which is also so useful it's sickening. There's a list of system math expressions here on the wiki:

http://sourceforge.net/apps/mediawiki/c ... xpressions

Lerp() and clamp() are under the math section.

Is there a thread or post anywhere that gives practical examples of what expressions like that can be used for? For the mathematically challenged or those who suffer from Dyscalculia (such as myself) Lerp gives an inbetween number and that's it. Would be nice to see examples of possible real world uses for that and other expressions, such as "Lerp could be used for X, Y, Z among other things", just to get the old brain working. Be a handy thing to reference for new users too.

Hey, I didn't know about the Clamp() one! Awesome stuff, will save me a lot of sub-events!

Is there a thread or post anywhere that gives practical examples of what expressions like that can be used for? For the mathematically challenged or those who suffer from Dyscalculia (such as myself) Lerp gives an inbetween number and that's it. Would be nice to see examples of possible real world uses for that and other expressions, such as "Lerp could be used for X, Y, Z among other things", just to get the old brain working. Be a handy thing to reference for new users too.

Check the wiki.

just go look in older pages of the YC and uploads forums. there are litterally tons of awesome caps and exes demonstrating things that have been lost to new stuff over time, and new users are really missing out.

uses of lerp? there are way too many. even more impressive are qarp() and cubic() , theyre like lerps big brother, for interpolating beziers of 3 and 4 points respectively. cosp(), a special "lerp" which does basically the same thing, except the interpolation is denser near the ends in a sort of curved fashion, using sampling from a cosine wave. can be used with lerp or all by itself for different effects. all of them take a parameter "t" which is a value from 0-1. that value is the percentage of the way through the interpolation. .5 being 50% 1 being 100% .25 being 25% ect

lerp(a,b,t)

• where a is the starting point and b the ending point, like this:

a = bottom-most stair step

b = top-most stair step

• t is basically transition or time, a real number between 0 and 1, where 0 is the beginning and 1 is the end.

When you stand on the bottom-most stair step, you begin clocking at 0. Add a second to the time (normalized to scale of 1) and find yourself on the second step. Add another second and you are on the third step, et cetera until at time = 1.0 you are finally standing on top of the stairs.

But wait! You can rewind in time! Pick the time - where were you at half the time? Set t= 0.5 (50%) and amazingly enough you find yourself half way on the staircase! Woo, time manipulation!

|o------------|  |-----------o|  |-----o-----|
a             b  a            b  a           b
     t=0 (0%)      t=1 (100%)      t=0.5(50%)
[/code:34gg056l]

One thing to consider is that some people may not fully understand how a percentage works for this.

Since its Christmas time, and we will all be checking out those after Christmas sales lets look at how percentages apply to sales!

All right its the first day after Christmas, and in one particular store everything is 75% off.

To figure out the price of a $20 item we would multiply 20 x 75%. Ok thats fine, but what if you dont have a calculator? Well we have to remember that a percentage is always based on 100, as in 100% is full price, for one item. If you were set that equation up you could just say 20 x 1, since we're paying full price. Now if you think about that all we really did was move the decimal up two spaces, IE 20 x 1.00. With that in mind if we were to take our sale percentage, 75%, and move the decimal up two spaces we get .75, or 0.75 for Construct. We can then take our original price, 20, and multiply that times 0.75, and get 15. So we can now say 75% off of $20 is $5. If you wanted to check that in you head real quick you could say half of half. Half of 100 is 50, and half of 50 is 25, and 100 minus 25 is....75... sooooo half of 20 is 10, and half of 10 is 5. Simple ehh?

Now that we know that all we have to do is change the decimal, we can now easily figure out what the price will be on the second day when the sale price goes to 80%

20 x 0.8 =?

Anyway if you wanted to set that up in a lerp we would say lerp(0, 20,0.8).

Zero for a since thats the lowest price we can get in a sale. 20 for b, since thats the original price, and 0.6 for our current percentage. That gives us what we want to take off of our price.

But if you wanted to get the exact price we would change that to lerp(20,0,0.8)

Edit: fixed the top part...derr, Im a dumbass sometimes

Thank you all for these really excellent comments and examples. I know math is behind everything to do with sophisticated game behaviour - I just think it should work "behind the scenes" - part of what makes a thing work, but not requiring the user to implement it directly.

And, forgive me for saying so, since Construct is being aimed, primarily, at the non-coding user, I think ultimately things would be better off being given a visual counterpart, a visual method of establishing and adjusting this type of behaviour.

Really, in the example I cited, a spring that is not very springy, (which has an adjustable springiness value) would seem to do the trick, with a couple of mouse clicks and and a slider adjustment.

But I don't expect the Construct developers to make things this simple - just pointing out that it would be very nice if they did.

Psmith

I just think it should work "behind the scenes" - part of what makes a thing work, but not requiring the user to implement it directly.

The thing is, Construct is practically as simple as it gets, math wise. The math is already simplified with expressions like anglediff and so on and so forth.

And, forgive me for saying so, since Construct is being aimed, primarily, at the non-coding user, I think ultimately things would be better off being given a visual counterpart, a visual method of establishing and adjusting this type of behaviour.

It would be impossible to make everything have a visual counterpart or behavior. You can't expect to make anything you want without making a bit of an effort to look into mathy side of things. This is game development, and math shall forever be intertwined with it. Construct is aimed at the non-coding user, but non-coding does not mean non-math or non-logic.

This is game development, and math shall forever be intertwined with it. Construct is aimed at the non-coding user, but non-coding does not mean non-math or non-logic.

I couldn't have said it more plainly myself.

And now for a long-winded wall of text:

Of course, it is possible to make an entire game out of just behaviors and simple events like "Enemy.Count = 0 -> Show 'You Win!'". But anything more complex is going to need a knowledge of math and logic no matter what game creation system you're using. Having a visual representation of every object property, event command, and math function available would be extremely cumbersome, bloated, and inefficient.

It's not too hard to say "hmm... a speed of 800 is too high for my enemy, I'll type in 400 instead." And it's not to much of a leap from that to say "I want my enemy to slow down the closer it gets to my player, I bet lerp() would be useful here."

And how would one visually represent such a thing in an event-creation environment? The concept is much too abstract. To specify it in visual terms you would need a special visual representation prepared in the event editor to cover the situation should it ever happen to arise in the course of someone clicking together their game.

And unless you want to limit the power of Construct to a pre-defined, set number of conditions and actions, you would have to anticipate every possibility that someone might need when creating their game and hard-code a visual representation for each possibility into the event editor, which would pretty much be impossible.

The way it's set up now with the code-like expressions and math functions you can literally create ANY kind of 2D game you can think of, as long as you have the skill. Going visual-only would severely limit the power of Construct and pretty much cripple it to the point where it would be just a simple editor for a handful of game types.

Sure, you could plug in your own graphics and sound and whatever, but each game you make would pretty much resemble the last, and they would all be severely lacking any personality. You'd have a cookie cutter that can make a dozen shapes, but all of your cookies will still pretty much still taste the same. Want sprinkles on your cookies? Sorry, sprinkles aren't available because if we include sprinkles, then we'd have to include nuts and raisins and M&Ms and all this other stuff that's just too much work to put in.

Whereas the event system in Construct currently lets you make your own sprinkles because the abstract nature of code-like language allows for a huge amount of flexibility. Hell, you don't even have to make cookies. You could make mashed potatoes if you wanted.

So yes, you can make simple click-together games with Construct. But unless you put in the time and effort to learn what making a good game requires, then don't expect to be making very impressive games. That doesn't just go for Construct... that goes for every game creation tool out there. There is no 100% visually oriented game creation tool out there (with any real power) because it just can't be done.

At least not without intelligent computers that can understand your intentions rather than just your explicit commands, but that's a loooong way off

Dead Eye:

We have had some of this discussion before, maybe not in its entirety, but at least partially. I feel there is nearly no need to do it again. So, I'll just mention a few of my observations.

People who write applications seem to be obsessed with allowing for EVERY possibility to take place, whether or not it ever will NEED to, and that is O.K. Unless you are trying to make a specific application for a specific group of people. In fact, I'll take my observation further: the same sorts of people find it difficult to even make an application for a specific group of people, (what about the ones we are leaving out?). In essence, you guys, (for lack of a better term), write applications for yourselves.

I hear, on all the game forums I visit, over and over again the phrase "cookie cutter code" or "cookie cutter behaviours" put forth in a negative manner. I've said it there, and I'll say it here: there is nothing whatsoever wrong with cookie cutter code or behaviours - in fact, the more of them there are, the better OUR world will be.

You put enough and varied kinds of Lego blocks together and you can make a replica of nearly any kind of manufacturing facility. And, you don't need to know a stitch of math to do it - mostly things are put together in these ways by trial and error. Some of the best machines produced during the Industrial Revolution were produced by men with little theoretical or even working knowledge of advanced mathematical principles. Many were farmers, laborers and uneducated men.

And what are games if not just a kind of SEEMINGLY complicated machine. It appears the game is making decisions, but it is not - everything is running according to some sort of predefined process - processes made up of a number of very similar "gates" and junctions and switches. Run them all together and it looks complicated - but everything can be broken down into very elementary functions.

I believe I mentioned this application before, but some years ago there existed a 3D interactive "sandbox" called AxelEdge, by MindAvenue. It's approach to "games" was almost entirely visual, and even the "decision making" part of the toolset was visual in nature - 2 and 3 way switches and so forth. It didn't have every tool or component, but the ones it did have allowed for hundreds of thousands of eventualities.

Incredibly entertaining 3D experiences were being produced without any real physics or "coding" at all. It was great fun to use and a great loss when their company sold out. There were so many things you could make just by connecting things together - like an advanced set of Legos. Realistic springs, hinges, fasteners, rotators could be "physically" connected together to produce interesting and engaging results - and very quickly, indeed.

If you broke down the number of behaviours and events and processes contained in the best of all the existing "video games", you would find that they all make use of "cookie cutter code", or, at least they could - so similar are the things you see and experience in these games. You can write out the algorithms for these games in simple sentences of plain English. In fact, most of them are very linear in description. There is no magic going on at all.

Psmith