Whoa I've been using timers for that and it's kind of a hassle.

Thanks!

Tiles have been promised

Also an online plugin has been promised.

Now, why a MORPG in Construct? no idea. Why not? well, mostly because doing a MORPG is a Bad Idea(tm). You can try though, and find out by yourself why they say that.

Maybe you can even get it to work, which would be awesome.

Wouldn't it be cool if it picked from random Google image results (any images of size 128x128 or smaller)?

:O interesting! I'll look into it

Also considering capturing enemies to help you fight / shield, ala Galaga

It always amazes me how programmers reply to reasonable questions like the ones I have posed.

That right there, speaks volumes.

[quote:2venf2qu]� Programs must be written for people to read, and only incidentally for machines to execute. � - (Abelson / Sussman)

Funny. This is from a book that leads into the design of Scheme. Which looks like this (from wikipedia)

(define a 10)
(define eval-aplus2 (delay (+ a 2)))
(define a 20)
(force eval-aplus2)
=> 22
[/code:2venf2qu]
I spy variables. 

If we talk merely nomenclature, have fun explaining why your 'memories' have been 'forgotten' when objects disappear.

[quote:2venf2qu]One of these days the Priesthood of the code will be thoroughly disbanded.  Mark my words.

You make it sound like code was an elitist thing, when all you have to do is STUDY the subject.

Someone's just being lazy, methinks. I shall pay no more attention, as there are users who are actually interested in doing things and learning how to do them (among them, me!).

I should also base speed and health on their size right? would that make sense?

right now they just get faster after each wave. In a sort of uncontrollable way, too.

hmmm well the xaudio object can give you latency and position, which should be enough if you know bpm from before.

I've been thinking about music-based games for a long time now and perhaps it's time to give it a shot. Interested in teamwork?

edit: obligatory .cap: http://www.udec.cl/~jfuente_alba/pulsating.cap

Update! bumped up res to 800x600, a lot more playable now.

Also, death.

PS: lol, Pedobear

Shoe wheel!

<img src="http://www.udec.cl/~jfuente_alba/shoe_wheel.png">

Kodu looks interesting but at the end of the day it's still a toy.

If you were comparing Construct to something Microsoft, it would have to be XNA. And there's quite a lot of coding involved in XNA.

The nice thing about Construct is that it speeds up the learning curve and the time needed to get results. It does not "relieve you from the burden of clarifying your ideas" (http://xkcd.com/568/). I think many people here are planning releasing commercial games made with this (amazing!) tool. It's simple enough to hit the ground running with your game (insert sprite, draw something on it, give platform behavior, then insert a box and make it solid, use as a floor. TADA!) but it's powerful enough to do the kind of stuff that makes people bail out from other game-making tools and learn programming.

And no... construct's logic is nowhere NEAR as difficult as making games in C++

I'd know. I spent quite some time trying

So 'timer' is not the system timer, there's no way to retrieve it in the runtime currently, since it's difficult to apply timescaling to the system clock.

:O could we get a way to retrieve the unscaled system timer? I've been assuming it was.

Sweet, Gary Coleman XD

ADDENDUM: around 128x128 is for large enemies, 64x64 makes good smallish enemies. More or less than that and you'll wind up with either one huge enemy or a jillion small ones.

(the game spawns enough enemies to fill the screen depending on the image size)

Drag the images from the forum to your enemies folder!

Edit: here's a burger: <img src="http://www.udec.cl/~jfuente_alba/burger.png">

I don't think it is a problem actually.

One has to blow up the error almost on purpose. I could do one example anyway, but there would be glaring ways to fix it without having to rewrite anything in construct.

I'd say it's more of a design issue on the game's side. I've worked with SDL and it had a terrible timer resolution, yet I managed to make smooth accurate movement using a few tricks here and there (which are perfectly doable within Construct but somewhat unnecesary).

That said, it would be nice to redefine Timedelta before behaviors touch it. Is that doable? One could rewrite timing at will that way without having to renounce behaviors.

Right now it *can* be done (look at my frameskip example ) but you have to forget about any behaviors that use Timedelta.

Edit: it would seem I'm contradicting myself I'm not. I'm just saying that while rounding errors do accumulate (in everything), one can just avoid accumulating them. Just look at Euler versus Verlet integrators in physics, both come from the same Newton equations, but one of them accumulates rounding error while the other cancels it.

50) Add Post Processing Filters 'on top'.

That'd be a cool thing to have. Like, during compositing, it's often helpful to add that last effect to your composition to give it that last little edge - like, a sharpen filter on top of everything to make the details come out.

Seconded sorta.

In DX and GL this is done with a fullscreen square with a special shader. In Construct you'd have a fullscreen empty sprite with an effect. Then again, the effects wouldn't have access to the layers below.

One COULD write an effect that did offscreen render, so that one would put it on each layer and you could use that data in the layer on top, assuming painter's algorithm for layers.

The great thing about Construct's design is that you can "hit the ground running" with your game and with a little extra work you can make it do exactly what you want to.

Then again, I don't know much about shaders. Halp?