I think users should be able to script behaviors with event logic. Where you specify inputs and outputs, as you said. The inputs may be objects or types, numbers, or strings. Once you've created your function however. You should be able to call it like any normal action/expression/condition. Through the same menus and dropdown boxes. I think an interface like this would make for a more usable, powerful, and streamlined function object. The initial creation would allow/require the user to add captions to each input. Now when it's time to use the functions, it would behave exactly like a built in behavior, except for the behind the scenes stuff. I think there should be a separate type of file that can be exported/imported specifically used for scripted event behaviors. Also,The community could work together to create a huge library of these scripted behaviors. quaz's 3d rotation is an obvious example. Aside from the sharing aspect, it would make it possible to create much more complex projects.

I would suggest predicting where the ball and the opponents paddle will go using interpolation, and fixing any discrepancies whenever the next bit of information comes in. The ball should follow some pretty straightforward rules of motion and bouncing, so the predictive algorithm wouldn't be too complex. I think most action internet games have some form of prediction.

that's correct.

you can still use python though, with the python() expression

Sprite - Custom Movement - Set X Speed to:

python("myspecialequation(1,5,x,y)+math.cos(12)/Sprite.Width")[/code:2c7nxwqa]

if it gets messy, or you want to tweak it alot:
an alternative is to set a python variable:
[code:2c7nxwqa]XSpeed=myspecialequation(1,5,x,y);[/code:2c7nxwqa]

Then in the event sheet:
[b]Sprite  -  Custom Movement   -   Set X Speed to:[/b]
[code:2c7nxwqa]python("XSpeed")[/code:2c7nxwqa]

for retrieving the value of Sprite[CustomMovement].XSpeed, the only thing I can think of is to set a private or global variable to Sprite[CustomMovement].XSpeed just before the script in the eventsheet, then using the variable in your script in place of the expression

what if you end up being the only guyon here

valve silently released a patch recently that slightly changes the ending to portal to set the stage for the sequel

thanks everyone.

That Alien Skin fur is distracting

good eye, 6Fix!

That is indeed Alien Skin fur.

I hope you are making this animator thing into a plugin still...

For now it's going to be my in-house engine for this game.

Technically it will be a plugin though, because I want to have alot of creatures on screen at any given time, and after 3 or so it's too many python commands per tick and the interpreter can't keep up, so C++ it is. for anyone considering using python, don't let this detract you though. it's an insane amount of operations. (over 1000 per creature per tick). The same amount of events or actions in construct would slow down the runtime as well

not the big demo that was discussed in chat just yet

Codename Blink is a codename, not the title of the game.

In this screenshot you can see the detail of the creature from the video you'll see below

right click - view image to see the full image

<img src="http://dl.dropbox.com/u/1013446/neweng/3leg.png">

This 3 legged creature was a test character used to gauge performance of the blink engine with very large sprites.

In the video you get a brief look at animation blending, between it's walking and running animations. With just two keyframed animations, infinite possible intermediate animations are generated, depending on the position of the slider on the bottom right.

http://www.youtube.com/user/RogueRobotsDotNet

The engine also supports scripted (procedural) animations coded within the editor you see here. Those are not demonstrated in this video. I'm not going to reveal exactly how they will be used in the upcoming game just yet, but scripted animations could be used for anything from foot placement to avoid holes and obstacles, to mixing animations-ai-and-physics data like the Euphoria engine, or generating animations determined by the size, number, and placement of limbs like Spore.

I will be revealing more on the progress of the engine, as well as details on the game itself, in this thread, until the time comes for a proper development site/blog. Any questions or comments are encouraged and appreciated of course.

>

>

> >

> > Idk, the main thing I liked about GM was how tight it was with GML. It just worked. (And the syntax was close to C based languages, the learning curve is next to nothing)

> >

> aside from python, which is insanely c-like

> you can make plugins for construct fairly easily using c++ ,

> everything you do in construct is done with a plugin, from loading an image into a sprite, to applying a platform behavior, to playing a sound, to opening a file dialogue. they are as powerful and fast as the c++ that spawns them. the possibilities are endless.

>

>

Lol the point of that was that the two are closely integrated, not that they were similar languages. GML was designed with gamemaker in mind, while python was simply designed to be an easy-to-use open-source alternative. You could code your entire game in GML if you wanted to without running into any issues (and with great ease, may i add), and it seems like the extent of python inside Construct is for nothing more than running intensive computations that wouldnt translate well into Constructs normal event system (at least it seems that way from my basic experience with it).

while python still has some issues as construct is in beta, there is no compromise in the power of python within construct. I can code most of my game (and have) in python. it isn't specialized for things that don't translate well into constructs normal event system, or running intensive computations; I don't see how it can "seem that way" from any amount of use. it's a scripting language that can be used for whatever you want to use it for. However, unlike Gamemaker, the event system is powerful enough that you don't need scripting for even very complex tasks, like Quazi's 3d What I Learned at School Today, or whatshisname's randomly generated perlin landscape thingy, let alone the superbasic stuff in gamemaker that required scripting.

[quote:3j4e15rv]

And python and the C languages really arent that alike at all. Aside from words like "if", "then", and "else", the similarities stop. I could go deep into this, but you could also do your homework and find this out yourself.

that's a silly thing to say. I had used gml enough to realize it's limitations before switching to construct. I've developed several c++ plugins for construct, and I've written thousands of lines of python code. They are very similar. I have a few hundred lines of codes I'm going to convert from python to c++, and it will begin with a copy paste action, and the only changes that will be needed are a couple of ()'s and {}'s here and there, and type information. how is gml more c like? because you can't write user defined functions?

[quote:3j4e15rv]

Finally, GM can be slow (mainly if you dont know what your doing), but it isnt weak. I wrote an entire skeletal animation program in it (for the curious: http://www.yoyogames.com/games/102929-animator) and it can maintain 127 fps running my entire animation engine AND the separate front end to it with a full skeleton across nine depth levels (on my old P4 3.2 Ghz). The source code itself is a few thousand lines long and it doesnt even choke. GM would be a great tool if... well im not going to get into all that here.

it has nothing to do with not knowing what you're doing. it is slow, weak, don't really see the difference in this context. After experimenting with simple loops of simple math functions, I discovered the interpreter for gml "chokes" once it reaches several hundred operations per frame. of course if your project never reaches that point of complexity it will never be a problem. A bone animator isn't exactly a basic project as far as most gamemaker projects go, but it also doesn't require an extraordinary amount of power. linear interpolation of a few angles, that's all, 20 bones at the most? you could run that on a celphone. construct gives you the power and speed to choke your PC due to actual computation as opposed to using too many events or scripting lines. if you want to do anything reasonably complex in gml, it always bottlenecks with the interpreter after a few hundred commands per frame. don't believe me, try looping 2+2 in gml, and see how many times you can do it per frame before you bring gamemaker to it's knees.

That isn't to say it's impossible to reach that limit on construct, since my current procedural bone animator, which executes over 1000 python commands per skeleton per tick, does in fact reach the interpreter bottleneck if I try to animate several skeletons at once. Which is again why it's nice to be able to switch off to c++ if need be.

gamemaker and gml are fun toys.

construct and python is more fun, but it's actually powerful enough to be a serious development tool as well

oh yeah, oops:

http://www.scirra.com/forum/viewtopic.php?f=7&t=4064&p=32406&hilit=loop

gotta go to bed, so I don't have time to distill the answer down, but here's a good start (especially ashley's part)

gamemake is weak and slow

I tried making a bezier curve generator with it, and if you try to make gamemaker do more than a few hundred commands in a frame, it starts to slow down, you can even make the command do nothing, like a null command, and it still slows down.

construct lets you do a few thousand things per tick before it's interpreter causes a bottleneck,

Last time I heard, Python in Construct is very weak/limited and need's alot of improvement's.

as far as python goes, python with construct makes gml look like a toy,

python is a full language, every bit as powerful and complex as a real compiled language like C++, aside from speed that is, though it is still at least an order of magnitude faster than gml, but even faster is...

Idk, the main thing I liked about GM was how tight it was with GML. It just worked. (And the syntax was close to C based languages, the learning curve is next to nothing)

aside from python, which is insanely c-like

you can make plugins for construct fairly easily using c++ ,

everything you do in construct is done with a plugin, from loading an image into a sprite, to applying a platform behavior, to playing a sound, to opening a file dialogue. they are as powerful and fast as the c++ that spawns them. the possibilities are endless.

I used gamemaker for a while, I even bought it. it's a neat little tool for what it's worth, but it's very limited. With construct, a dedicated user could create World of Goo, or Braid, Plants vs Zombies, or Aquaria.

with the speed, and the pixel shaders, it's definitely possible to create the next big thing in 2D.

one last thought, people keep saying rapid prototyping without really explaining what they mean exactly. I'll give you a quick example or two. somebody asked if it was possible to create a 2d version of katamari damacy, and upon reading it I was able to create a playable, albeit simple graphiced, example of a 2d katamari damacy prototype in 5 or 10 minutes. I haven't frequented the help forums in some time, but it was quite common for someone to ask a question starting with "is it possible to..." followed by something that has no built in object or behavior in construct, and the response within a few minutes be an actual working example of what they were asking for. it sounds too good to be true, but I mean it. The fact that there is even a such thing as a 1 hour game competition thread speaks volumes