Most important documentation?

What do you think are the most important things that need to be added to the Learn area? More tutorials, object docs, references for system object, explanations of effects, UI guides etc.? I can't write it all at once, so where do you think I should start?

the learn area should consist of tutorials that will teach new developers how accomplish certain tasks like creating a basic cpm, rpg engine, etc

anything else should be in a manual of sorts

I think that function object and effects are the ones needing most explanations, tutorials and tips and tricks.

I absolutely think that a help file for the program with explanations of what every single thing does is the highest priority! Now you have to experiment with everything in order to know what it does, and sometimes it takes a veery long time to figure out even a simple thing.

You could also ask here on the forums, but i don't think questions like "What does 'linear damping' mean?" would be apprechiated if they started to show up too often.

Btw. What does 'linear damping' mean? I'm serious. <img src="{SMILIES_PATH}/icon_redface.gif" alt=":oops:" title="Embarassed" />

If you know about such equation as:

mx'' + cx' + kx = F

Then damping is c <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />.

When something flies, it loses its speed because of flying in air. Let's say "linear damping" is a force with which air reacts on flying object. It is theoretically proportional to object's speed.

There are so many interesting things to talk about in 'learn' section that is hard to choose. Actually I think those would be very helpful:

<img src="{SMILIES_PATH}/icon_arrow.gif" alt=":arrow:" title="Arrow" /> how does the quantity of for example speed or acceleration influence on object's real speed measured in pixels per second? (you know what I'm thinking about?)

<img src="{SMILIES_PATH}/icon_arrow.gif" alt=":arrow:" title="Arrow" /> how does "effects" work (some images showing for example two shapes overlapping each other and one of them or both were given a special effect from the list)

<img src="{SMILIES_PATH}/icon_arrow.gif" alt=":arrow:" title="Arrow" /> simple .cap that'll show usage of every movement and how to adjust parameters to get interesting effect (for example using bullet movement for bullets but also for walking enemies as well)

<img src="{SMILIES_PATH}/icon_arrow.gif" alt=":arrow:" title="Arrow" /> articles showing some practical aspects when making any game... like: "how to store variables like score, ammo etc."

Well, there could be more articles in 'learning' about:

<img src="{SMILIES_PATH}/icon_arrow.gif" alt=":arrow:" title="Arrow" /> how to make your own animation system

<img src="{SMILIES_PATH}/icon_arrow.gif" alt=":arrow:" title="Arrow" /> how to avoid bugs <img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" />

But sure they'll be obsolete too fast too even care about making some <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />.

Linear damping is how much the object decelerates as it moves. If you push an object, with no linear damping it would simply continue moving at the same speed forever, like in space - being a vacuum, there's nothing to stop it. The higher the linear damping, the faster the object comes to a stop. On Earth air stops an object from moving forever, so damping is a good way to simulate this.

I can add that the values of speed *are* in units of pixels per second, and acceleration/deceleration are in units of pixels per second per second.

Anyways there's a lot to do, if any of you guys feel like having a shot at anything for the Learn area, I'd welcome it!

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.

Here's my vote.

I absolutely think that a help file for the program with explanations of what every single thing does is the highest priority!

I've watched and am watching a number of projects develop. A word of advice.

Currently, everything so far is clear and well thought out. What's missing from getting big time interest is a camera mounted or chasing an object for that First Person view. When that's added, the newbies will burst through the door.

I would recommend you have all your ducks in a row and all your docs up to that point done before you take that step. A multitude of noob posts can be very distracting and you can easily loose your aim and focus.

Currently, everything so far is clear and well thought out. What's missing from getting big time interest is a camera mounted or chasing an object for that First Person view.

Sprite properties

-groups

• atributes

[x]center wiew on me!

Or was that some kind of metaphor?

You know, like a 3D First Person Shooter demo.

Edit - ??? Perhaps I'm thinking a little too far ahead?

??? So you suggest that they add to the learn-area a way of making a 3D first person shooter, with a program that doesn't even support 3D? Is that your word of advice?

I disagree completely with the general sentiment in this thread. I don't think the most important documentation is tutorials. While tutorials are great to start with, they are useless if people don't learn the basics. If all you have are tutorials, then users won't know how to make their own games, because they won't understand why the tutorials work. I think the basics on how all the features and functions work, and what you can do with them should be the priority. But that's just me.

If all you have are tutorials, then users won't know how to make their own games, because they won't understand why the tutorials work.

That all depends on how you write your tutorial.

That all depends on how you write your tutorial.

That's true, but with a tutorial, all you know how to do is whatever is described in the tutorial. What if I want to do something there isn't a tutorial or example for? For example, it took me almost a week of wrestling with the Card Game Object before I gave up and asked in the forum, and found out it's not finished. Had there been documentation that said it wasn't finished, that would have saved me a lot of time. I think it's all in how you learn. Personally, the first thing I looked for was a detailed manual on all the features and functions of Construct, and was disappointed to find there isn't one yet. As nice as the tutorials are, I would prefer to know what everything does and what can be done with it. And I don't think sifting through all the threads and comments in the forum is a replacement for that.

The Construct Wiki has partial documentation. It's a work in progress and a lot of it is subject to change. I do also appreciate how important a reference is for documentation purposes, but I think tutorials are important to help get beginners going. We should have both!

Part of the problem is with so many plugins there is a lot of reference documentation to write. We need everyone's help to write it (it's an easy way to contribute to the project if you're not a programmer).