What you say it's right, but I was actually talking about game size.

If my beat'em up has, say, 20mb of fighter's sprites, with colliders that space would simply double. Same (or even worse) would be using huge bitmap zones for the golf game: totally unefficient, with reference to the executable size.

98% of things made in Construct will be DOWNLOADABLE games. And in downloadable games, file size really matters. 20mb more or less it's not a joke at all.

That would be great.

More morons, more glory <img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" />

..maybe a "collider" checkbox? Mmm...

Here my proposal for the "Collider Object": just like the sprite object, with the difference that it stores in the memory only a monochromatic form.

Making colliders with the sprite object it's a waste of memory, since the informations about the aspect of the object are stored as a bmp, while the object will never actually appear in the game.

That's practically unrelevant in case of, i.e., a platform game character, but it could become essential in case of a beat'em up: several big characters, each with its ows colliders -> fighter's memory occupied doubles (and in that case we talk about several MB).

It could also be used for defining areas, as it can do Overlay object in MMF (i.e. where in the point-and-click adventure the character can walk; different terrain reactions on a golf game, and so on...)

Hope I made the point clear enough. It would increase efficiency in Construct (and solve some dramatic cases, like in the Beat'em up example). Why to store useless .bmp graphics when using colliders & similar? <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

[quote:1fxq0p53]I'm soure this forum will be packed once Construct v1.0 is out!

Of course, the very most of people simply don't rely on unfinished products. Reasonably.

1.0 and a good documentation (expecially for beginners) will definitely boost the product to the very big public.

Good the choice to simply don't care about fankid trolls.. every successful product/community has its own trolls.. usually they disappear when they get a social life <img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool">

Where to start with documentation?

IMHO, the most intelligent thing to do right now would be concentrating efforts on basic tutorials, since there are out of there plenty of potential Construct users that only waits to getting started with the program in the easiest way it's possible. So that the user base grows, and the word-by-mouth boosts.

Have you ever seen the tutorial games of TGF? Something like that would be perfect (manual - sample files).

Take a look at the manual from page 16: it shows, step by step, how to create a very simple game from zero, and in the meantime it explains the basics of the program every time you meet something new (an editor an object, ecc..). Just take a look to the first 4 tutorial games (fifth is useless), you'll understand clearly what I mean.

For my personal experience, step by step tutorials are a VERY concrete and effective way to learn such a tool from zero. Ages ago I learned quickly the basics of TGF while having no programming skills. Didn't need anything else.. I looked at the rest of the manual something like a couple of times in 5 years, afterwards.

Maybe today that we have broadband connections, in the form of video tutorials, if properly made, they could result even more immediate.

I'm not sure how well it'll work out calculating the forces necessary to accurately reproduce following some coordinates, but I'll give it a shot, it'd definitely be handy. It'd be great to have a platform movement who could go round shoving bricks and such.

I don't know how much it would be doable, but more than a "physics platform movement" would be a very powerful feature to have the capability of having 2 movements on the same time, so that you could integrate physics to any movement.

For example, I remember our Magic Racer game.. the engine was enterely made in custom events, and I remember that the most difficult part was to manage the collisions between cars.

In my case, it would have been extremely comfy to be able to integrate to my custom racecar engine a "physics movement" just for this aspect.

In case of somebody using the "racecar movement" (the most of the people actually), it would be pretty easy to tho the same with the feature mentioned above:

• add racecar movement

• add physics movement

• then just play with settings and add custom events as you like

Also the explaination of the collisions on the 3D box object was very good.. why to not open an official wiki for putting togeter all the knowledge base about Construct?

Everybody could contribute and it would be perfectly in line with the open-source spirit of the project.

Raknet looks good and is free for non-commercial use, which means I could make a plugin using it and distribute it for free. However anyone wanting to sell their online game needs a license, which is only about £50 ($100) per application. This is okay I guess, a commercial game would probably make that back if they just have a handful of sales. But it's still a bit of a barrier to small time indie devs. What do you reckon?

I think $100 would be totally OK for a commercial project. And probably it would be possible to arrange a discount for Construct users (you're actually pushing their product to the market).

Besides, other people wold be free to code a brand new free extension..

Just a matter of quality of netcode, protocol etc., which I'm definitely not able to judge! <img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" />