"Aquaria-Like" Mouse Leading Possible?

Actually I'm now kinda becoming fond of a 'maths jigsaw puzzle' idea...so an equation like:

clamp( distance( .x, .y, mousex, mousey ), 0, 100)

can become

<img src="http://dl.dropbox.com/u/939828/another%20idea.PNG">

Which at first appearance looks just like the equation...but with a live preview thing and being able to drag parts around and stuff it might work out nicely.. and the space allows for text distribing what the connector does (eg min, max) ....again just brainstorming the idea ... of course in a sketch form like that it looks shit but if I made a nice design it'd probably be another story

<img src="http://dl.dropbox.com/u/939828/idea29.PNG">

Basically that could be displayed a lot nicer but to explain the concept...

I would hope it could be displayed a lot nicer, because in all honesty that hurts my brain more to look at than "clamp(distance(x1, y1, x2, y2,) * 3, 0, 100)"

And I think that's heading into the argument here about visual data flow. It's a nice idea for small, contained things, but once you get into more complicated stuff it's just a nightmare to look at. As you stated in your post things like lerp() and distance() are already taking long, complicated math problems and boiling them down into easier-to-handle chunks. If you start boiling things down much further you're going to swing the balance from "complicated abstract concept" over to "complicated practical implementation." In my opinion Construct is a rather comfortable middle-ground between the two. Yes, you still need to deal with some abstractions, but the trade off is the structure is easier to handle - rather than connecting potentially dozens of little dataflow boxes in a diagram to perform a math function you instead simply type in a couple of expressions. Those boxes may be easier for someone who is unwilling or incapable of learning to better visualize what's going on, but for those who put in the minimal effort of mastering the relatively simple math it would be too frustrating to work with.

Let's assume that each of those boxes and connections requires two clicks to create: A right-click to pop up a menu and a click to select what option you want...

Right Click -> Insert -> Math -> Click to select Distance evaluation component from menu

You navigate the menu and pick your component. Then you need to define the parameters:

Click Distance component -> Select Parameter A -> Click -> Navigate to Mouse Object -> Click

Click Distance component -> Select Parameter B -> Click -> Navigate to Player Object -> Click

Right Click -> Insert -> Math -> Click to select Multiply component from menu

Click Multiply widget -> Type "3" -> Hit Enter

Click & Drag connection from Distance component to Multiply component

Etc. etc. And that's only half the steps necessary to complete the equation. Not to mention moving the boxes around so you can see them easier when the view gets cluttered and you can't easily see your connections to figure out why your game isn't behaving the way it should be.

It's an unnecessarily bloated system when the alternative is to simply type "clamp(distance(x1, y1, x2, y2) * 3, 0, 100)" into the expression editor. If I had to click and create flow-chart boxes in Construct to perform simple math functions I would just use another program, because it would be way too much of a hassle to deal with.

David:

Very nice example and thoughtful "visual scripting" proposal. I'm glad you see the value in working this way - not for everyone, but for some - like me. Feel free to move or delete this thread, as needed. I won't be offended.

I doubt if I will ever change my views on this subject. I'm an old man of 54. I come from a totally "hands on" way of working: I make wooden geared clocks totally by hand. (I do use saws and drills and grinders). I approached this kind of work, initially, using long established tables of clock gear ratios to pendulum lengths to work out my designs. That's the extent of the math - somebody else's hard earned math. All my clocks are skeleton clocks, free form, showing all the clock works, and run by the falling of the weight which is driving the gears and the pendulum.

Many of my working designs came about by much trial and error, making and remaking. I find a lot of value in working this way. I've never played games for more than a few minutes. So, I'm coming from a different planet than most of you.

Clocks are not all that I make; I've been working in 2D and 3D graphics since the mid 80's and only recently have become interested in the "game" environment. Not because I want to make games, but because I love computer interactivity.

I actually did, and profited by, some rudimentary programming, way back in 91 or 92, using HyperCard on the Mac - and had a lot of trouble even tackling that simple language. I did sell the program I wrote to Northern Arizona University, (an Alien invasion game that taught kids base ten). Very silly, but somewhat effective. Good sound effects. That programming experience left an indelible impression upon me, however - I don't want to ever have to go through that again.

But, what I did learn, through all of these years regarding computers and good software, (Mac software, mostly), is that the best stuff "just works", (as those Unity guys love to put it). For an example of an application like this, go take a look at the new ArtRage 3. A masterpiece of friendly software engineering. Every tool is an example of some kind of "cookie cutter" behaviour.

So, anything that takes the drudgery and alienation out of making 2D or 3D animated graphics interactive, (no scores needed), is my cup of tea, right up my alley and ujah cum spiff - most definitely.

I believe strongly in that initial Steve Jobs philosophy regarding the Mac and what computers and computer software should be. Apple has deviated from this vision somewhat, over the years, but they are carrying it on, now with the iPhone and applications designed to "just work" on that platform.

I've never been afraid of any kind of hard work - I only insist that the process of creation remain fun - especially at my age. And Construct may not be the application for me. I'm just passin' through.

Psmith

Actually I'm now kinda becoming fond of a 'maths jigsaw puzzle' idea...so an equation like:

clamp( distance( .x, .y, mousex, mousey ), 0, 100)

can become

<img src="http://dl.dropbox.com/u/939828/another%20idea.PNG">

Which at first appearance looks just like the equation...but with a live preview thing and being able to drag parts around and stuff it might work out nicely.. and the space allows for text distribing what the connector does (eg min, max) ....again just brainstorming the idea ... of course in a sketch form like that it looks s**t but if I made a nice design it'd probably be another story

Cough intellisense...

I actually did, and profited by, some rudimentary programming, way back in 91 or 92, using HyperCard on the Mac - and had a lot of trouble even tackling that simple language.

Hell yeah, man! HyperCard was the bomb. I loved it to pieces. I spent countless hours making my own point-and-click adventure games and simple arcade stuff.

I still remember how easy the language was, too... it was damn near plain English. Want to toggle a button's highlight? Just type "Set the highlight of me to not the highlight of me." Too awesome.

Ah, the good old days. I wish I still had those old stacks, they might be good for a laugh . Anyway, </anecdote>.

I got into Flash a little bit a few years back, because it was pretty much the closest thing to HyperCard as far as modern software goes. I tried my hand at making some games and found coding Actionscript to be too boring, and I wasn't learning anything. So believe me, I feel your pain when it comes to learning code... I've tried learning Actionscript, C++, C#, Java, and Python and it all bores me to tears. I can make a screen say "Hello world" in each of those languages and that's about it. The only language I really have anything more than a passing knowledge of is BASIC, and that's because I learned it when I was a wee tyke and I had ample time and energy to waste learning a dying and utterly useless programming language.

That's the main reason why Construct is so appealing to me. The only code I have to learn is a handful of math functions, and even then I only bother to learn what is absolutely necessary in order to make what I want. The rest I have no clue on. How did I learn what lerp() was? I asked for help in making my game scroll in a particular way. Someone posted an example of how to do it that involved lerp(). I had no idea what it meant or what was going on, so I asked for clarification. Once I had it down, that was that. Now it's just another tool in my toolbox that I can pull out and do something cool with.

I couldn't even begin to tell you what quarp() or cosp() is, and I've never needed them for anything so I've never bothered to learn. Hell, I don't even fully understand what sin and cosin do. I'm no math whiz, and I'm no coding genius. I'm an artist first and foremost. I'm just a guy who wants to make cool stuff and I'm willing to sacrifice a little of my time to learn the barest of necessities in order to accomplish that. It's not too tough. If an old man of 36 can do it, then an old man of 54 should be able to hack it as well. Especially since you have the hard part down... you already know how to make graphics. Creating the game assets you need, and seeing that process through to the end is easily the toughest part of making a game. When you remove the coding aspect, that is.

Anyway, I say you should at least give it a try. If you try your hand at Construct and you hit a wall, there's plenty of folks here to give you a hand. It's not like you have anything to lose. Take a break from scouring the net for something that doesn't exist and give making something a shot. Who knows... it might not be as painful an experience as you expect.

Dead Eye:

Thanks for the encouragement. I have very little to lose, you are right about that. Except more of my eyesight, that is, (I had a tear in my retina about 1 year ago and nearly went blind in one eye).

It's no fun growing old.

Still, I can't let go of the possibility of seeing some of AxelEdge's functionality come back in a new way to the 2D, Construct environment, (springs you literally "fasten", hinges you attach, shock absorbing "springs" - which would be perfect for "mouse following", etc.)

What do you think the chances are of anyone creating some of these kinds of "physical" assets are?

I can still use Construct for other things, but I'm hopeful someone else will see the value in "physical" objects with built in behaviours that mimic the real world. Maybe you will.

By the way, have you seen "Algodoo" http://www.algodoo.com Right up my clock making alley.

Psmith

I can still use Construct for other things, but I'm hopeful someone else will see the value in "physical" objects with built in behaviours that mimic the real world. Maybe you will.

If you haven't heard of Phun, then you should definately go check it out. It's a free 2d physics simulator that's extremely powerful, and even has some simple options to create the "game-like" experiences I believe you are looking for. Heck, you can even build fully working clocks with it, using nothing more than the tools it gives you. . A lot of people have made scoreless "games" in Phun, and it seems like the perfect tool for you.

Still, I can't let go of the possibility of seeing some of AxelEdge's functionality come back in a new way to the 2D, Construct environment, (springs you literally "fasten", hinges you attach, shock absorbing "springs" - which would be perfect for "mouse following", etc.)

What do you think the chances are of anyone creating some of these kinds of "physical" assets are?

IMO the chances are slim to none, since construct is essentially a programming tool. What (I think) you're looking for is a numberless program like Phun or Kodu, and Construct aims to be more flexible than that.

Anyways, you should take Deadeye's advice and give Construct a chance. You might like it after you get over the slight learning curve.

What do you think the chances are of anyone creating some of these kinds of "physical" assets are?

Honestly, as far as Construct is concerned... slim to none. It would require some major overhauling of how Construct works fundamentally.

As far as some other tool somewhere down the road... I would say it's inevitable. It's just a way off, if not a long way off. The irony of the situation is that the easier the interface is to use, the harder it is to create that interface.

Davioware and Dead Eye:

Thanks for your honesty. Slim to none is what I expected.

Algodoo is the current incarnation of Phun, gone commercial. I've looked only a little into the "scripting" part of it, and I think it is at least as much work as Construct, programming-wise.

I fully intend to use Construct, I just don't have a concrete idea of what it is I could easily put together that would still be entertaining and weird. I don't need to make anything "competitive" and I shy away from the "platform" genre because of my in-suppressable urge to make things walk "into" the scene, or at least appear to do so.

Top down might be something, or changeable gravity, as I mentioned in the beginning of this thread.

Anyway, sorry for irritating so many of you. Didn't really want to do that, but it is my "magic" way.

Thanks for all of your suggestions and encouragement and for sharing your insight.

Psmith