There is currently a book on Construct put out by HobbyPress, but I haven't read it, and I do have some doubts about how comprehensive it is.

I'd love to be a "user feedback" editor of sorts for you, and lend you a hand on some of the most important aspects of a tutorial that even the best tutorial writers completely miss on a regular basis:

1. Having clear step-by-step instructions--with screenshots for critical aspects--that don't assume the reader already knows or understands what to do. This one missing piece pretty much destroys every tutorial for the beginner, and unfortunately most tutorials on the internet are like this.

2. Staying away from speaking in an overly technical manner in a way you'd expect from a person who is highly experienced with the program and/or has many years of programming experience in general. Why? Because like #1 it assumes that the person reading is going to know what you're talking about, though the reality is that they won't 9 times out of 10 which makes the tutorial practically useless for them.

3. Explaining what a specific action means, what it does, and why you're using it, and only from the perspective of what it means to Construct, not the broader idea of programming in general since it will only confuse the reader with a lot of non-Construct specific information that won't help them build anything in Construct. Let me make an example:

Say I'm a total beginner and I ask you what a Global Variable is, and you then explain it in it's deepest technical terms. You've just wasted the reader's time, because what the reader wants/needs to know is A. What is a Global Variable in the context of Construct, B. Why does he need to use it in Construct, and in what situations does he need to use it? C. What are the clear steps to creating one, step-by step?

Without A, B, and C, the tutorial is incomplete, and of course for the beginner without a step-by-step it's entirely useless.

I find that those 3 missing components make even the most content-heavy tutorials unhelpful. Tutorials are too often written without regard to the way a beginner is thinking and how a beginner will likely interpret information they've never seen before, so it winds up just being incomplete or lacking thorough enough explanations.

As one last piece of advice, I'd say that the book should be accompanied by two things: 1. Any tutorial in which a specifc type of feature is created (i.e. Mode 7, Game timer clock, etc.) it should be accompanied by A. The information on the version of Construct in which the feature was created and B. A .cap file (with the information present telling the reader what version it was created in), because example .caps always enhance a text explanation.

This thread is great, but is there a way we can know what versions of Construct are being used for each example/tutorial? Without knowing, it's a kind of a guessing game as to whether an example/tutorial will open or not, or even work if it does open.

So how is your replay example coming? I'm really anxious to see it

megatronx, yep. Project Reality was the codename, then their final name was about to be Ultra 64 but they changed it.

http://www.nesworld.com/n64system.php

I'm interested in what the final name of this new system might be. I'd imagine since they claim it's going to be a system more built for the hardcore market, they wouldn't use the name "Wii" this time around.

Wii was called REVOLUTION. and new console is confirmed

Yep, that's right.

And of course, the Nintendo 64 was called "Project Reality".

Because they're calling it "Project Cafe" doesn't mean it's fake, because Nintendo always gives codenames to their projects while they are still in formation. For example, the Gamecube was called "Project Dolphin" for some time until the project was complete. I'm sure the Wii was called "Project (insert a name)" before it was complete.

We'll just have to wait and see, but I just wanted to lend some historical perspective to the matter.

Whenever I've used a zoom event, the picture quality always gets unreasonably pixelated when I do a zoom in. Now, it's understandable when the image's dpi/resolution is low, but when it's high and it still pixelates it seems strange.

As a test, I used Windows picture viewer and zoomed in to the same image at the same distance as what I zoomed the image on in Construct. The one in picture viewer had its quality still in tact, the one in Construct was very pixelated.

Is there a type of way that Construct processes a zoomed image that causes this? And, is there any work around?

With the normaly array(like I used), I could do that.

With the S-plugin, I have to test it out how to manipulate the position of the arrys X index.

But yeah, why not .

If you could do an example of a replay system that would be awesome.

No pressure though

I wonder if this can be adapted somehow to make a replay system for sports video games? I've never been able to figure out how to do that in Construct.

MrMiller: we're sticking with HTML5 export for the time being.

I understand. I wasn't asking because I'm against HTML 5 or anything (which I'm not, I honestly don't know much about it at all since it's not a widely used or widely known standard yet), I just figured that since .exe is a staple of pretty much all game creators, that it's planned to be included at some point, and I was hoping that embedding music and sounds in the .exe would be the route this time instead of the folders system... just wondering...

I haven't been able to check out the new C2 versions yet... but will we be able to embed music and sounds automatically in .exe's (when the exe exporter becomes available), and move away from Construct 1's system of packing folders with the .exe?

If not, please consider it!

What version of Construct did you use?