HELL YES. I've been a huge advocate for procedural generation, because it is capable of absolutely incredible things, especially in 3D. Interesting city generation thing... I wonder how procedural terrain generation could work in Construct while actually looking nice?

Well, that's pretty much what it means, to my knowledge.

Also, lol. XD

Alright, I've started up a bit of a challenge for the heck of it. Now, take a look at this GIF of a room from Braid...

<img src="http://img3.imageshack.us/img3/4868/cloudmotionw30001.gif">

Looks freakn' awesome, no? Most of this room is composed of textured particles. This is what it looks like without the particles. This is the room with the particles only. For more insight into how it was done, Look here.

The challenge? Create a room that uses a similar effect using particles, doesn't have to be clouds, use your imagination. Fill your room with life! The winner will be the one with the most living, awesome-looking particle room. Bonus points if it doesn't choke the system in the process. You guys have a week!

Let's-a-go!

I've been talking with the devs about this sort of thing in the chat, but I think it warrants it own topic, too. Over at Sonic Fan Games HQ, Damizean, who is renouned in the community for his Sonic engines, noted a rather interesting suggestion...

[quote:2zh3aghk]Hmm, actually, it would be better if they actually implemented contact points list for the Box2D physics system. With proper collision detection, we could create an awesome Sonic engine with it. (Basically, there would be no need for angle detection system, as we could find out the angles from the contact points, it would fix all the problems with the current system.

Box2D actually implements the contact points as it's on the library's API. They only would need to construct the callback class and add refactor it (Plus, contact points from per pixel collisions would be suicide, this is only suitable for the Physics engine).

This could have a multitude of different applications besides angles, as David noted, it stores data on "position, veleocity, normal, fraiction, restituation(elasticity)", and others...

[quote:2zh3aghk]

(20:29:43) David: we have a collision listener used already which has access to a b2ContactPoint

(20:29:52) David: so I guess its just a case of storing point data appropriately

(20:30:24) Candescence: Wait, so could this be used in Construct at the present?

(20:30:26) Mipey: Is this stuff for the box rotating if an angle is hit?

(20:30:27) David: so you would have expressions:

GetContactPointx(index)

GetContactPointy(index)

GetContactCount()

(20:30:42) David: its not accessable to u guys no

(20:30:53) David: but it looks like we can impliment it

(20:31:04) Shviller: Hm, I guess those expressions would suffice.

(20:31:48) Candescence: Wait, so we can do contact points with expressions? Why not just go ahead and make it a full-on feature?

(20:31:53) David: ah theres more data in points

(20:31:58) David: i thought points would be points lol

(20:32:02) David: but they contain

(20:32:14) David: position, veleocity, normal, fraiction, restituation(elasticity)

(20:32:18) Mipey: DNA of aliens?

(20:32:23) Mipey: Aw.

(20:32:31) Candescence: Angle?

(20:32:43) David: angle is normal

(20:32:49) David: normal means angle i mean

(20:33:01) Candescence: Ah.

(20:33:01) Mipey: vector?

(20:33:21) Shviller: well, normal is a vector, but only it's direction (angle) is meaningful

(20:33:43) Shviller: normal is a 1-length vector perpendicular to the surface

(20:34:10) Mipey: I see

(20:35:01) David: yeah ur right it is a b2Vec2...which is vector

(20:35:07) David: but i can turn it into an angle

(20:35:52) David: i'm just not quite sure how it works heh

(20:36:03) David: like if u have a ball and drop it on the ground

(20:36:10) David: will the normal point upwards

(20:36:29) Shviller: ...or downwards.

(20:36:40) David: mm...experimentation will be the key heh

(20:36:40) Mipey: Direction of the impact force?

(20:36:52) Mipey: And you could get bounce angle from that normal.

(20:36:52) Shviller: pretty much

(20:37:14) Mipey: Or use it to push the object further

(20:37:18) Candescence: So, basically... Contact points have a variety of different purposes in this case?

(20:37:19) Mipey: Like playing Pool

(22:33:05) Candescence: Okay, before I knock off to bed, what's the chances of contact points getting into the next build?

(22:34:37) David: random(100)% chance

(22:34:49) Candescence: XD

(22:34:59) Candescence: But seriously.

(22:35:30) Mipey: I wouldn't have too high expectations... saves me from disappointments.

(22:35:33) David: well i'll pass it on to Ashley but he'll probably say its a post 1.0 feature

(22:36:31) Mipey: If it in your opinion simplifies the physics collision system, then it probably would be fundamental enough to be implemented. Otherwise... it might get tagged as feature bloat?

(22:36:32) David: which is starting to sound like our equivalent of 'it was programmed to do that'

(22:37:11) David: it wouldn't simplify or complicate, its just a feature...requires adding some new expressions and adding code into a callback

Really, it could be quite useful for a variety of detections. Good idea, or no?

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF-

So THAT'S what's causing my game to crash on runtime due to so many objects! I didn't realize it! This is a HUGE problem for large projects, methinks - I can't progress until this is out of the way.

I should also note that a palette "cycle" (having the entire palette different shades of the same colour in order, then have them cycle to create an animated effect on the sprite) also makes a good and striking effect when you want to show that something is happening to the sprite. I advocate a pallete thingy.

Well, THAT works... But why the hell does TNG work and not PNG? The latter has a smaller file size, for pete's sake.

PNG, pretty much. Pretty much black where the transparency should be.

... No, they don't. Even when after the import.

I hate to rain on everyone's parade, but I wouldn't recommend this if you're working with transparency, because it just doesn't do it, it just replaces the transparency with black.

Funny you should mention 90%, because 90% of pretty much everything is crap, according to Sturgeon's Law.

However, you could apply the arguments you just made to, say, fanfiction, fan art, or sprite comics. I don't see anyone giving THEM cease and desist orders. In fact, there's another "fan-game" that has been aknowledged by the original copyright owners... And actually gave the green light. Black Mesa, anyone? Square are just jerks. (Also, I heard that fan-sequel to King's Quest is still in development.)

Thing is, most companies see these fan-games in the same light as fan-art and such - to them, it's free advertisement. Of course, some copyright holders, and not just game companies, see fan-works in the same light, quite a few authors are known to hold distain for them. But really, there may be some isolated cases, but when there's an entire online expo devoted to fan-games, it's obvious that anyone who does have a problem with it is in the minority.

Of course, I'm doing a fan-game myself, and it's my multimedia project, but my teacher doesn't mind as long as I give credit where it's due, acknowledge what belongs to who and which bits I actually made myself.

Aria of Destiny screens!

<img src="http://img26.imageshack.us/img26/535/cronoslashscreenfa8.png">

<img src="http://img26.imageshack.us/img26/6074/bassscreenay1.png">