After trying out the demo projects and giving the program a quick test, I'm split. From an engineering standpoint this an amazing feat. Achieving all of this in a browser is very impressive. The editor runs smoothly, at least for the simple sample projects that were provided. It runs on iOS and Android now, as well as Mac and Linux. Great. But I don't care about that as a Windows developer. Running in a browser is more of a hindrance than anything. Running in a browser is better for Scirra, since they can easily port the editor to all platforms. But why would I want an additional point of failure/slowdown in my IDE? Answer: I wouldn't. It's cool to be able to edit a project on a phone or tablet (the main feature of being in a browser) but it's more of a novelty than a useful feature.

It's basically just Construct 2.

The "free edition" is essentially useless. 25 events, and for some reason even more strict restrictions on layers and effects, as if "25 events" wasn't enough. The free edition is for you to try the thing, and then subscribe. There is no useful free version like Unity has. I was thinking they would make the free version actually usable with Construct 3 since it costs so much more, but I guess I was wrong.

I see this as being a very good program for education or schools, since it works on all platforms.

But as developer on windows (as is everyone here) there's no point to using it over C2. Construct 2 does everything I need if I want to make a HTML5 game. The small amount of features it adds to 2 just aren't worth the cost. It's a marvel of engineering, but why bother using it when Construct 2 exists if you're on windows? If this was a new product and there was no Construct 2, it would be much better received by the community.

Many people are upset with it because it really adds nothing new, yet costs so much more.

If you like C2's coding system, try using the Q3D plugin for C2.

Unity is a very different engine to C2. It wasn't designed around a visual coding system like Construct, and you're better off just coding in C# for it.

Finding obscure bugs in CC can be annoying as hell, so I'll share what I can remember.

Strange things which can crash the game:

-Calling a function as an action, in the same event as an "is overlapping" condition. to fix, put the function in an empty sub event.

-.WAV bit rate. Do not exceed 1411kbps for .wav sounds or crashing will occur. This one was fun to figure out..

Extremely inefficient. It would be much better to do this through a shader, or scrolling tiled textures.

That's a dumb way to do things for a fighting game. What you should be doing is spawning hitboxes as a different object which has frames/animations to choose a shape. This way you can make them move independently of the character, have them shoot out, etc. Not to mention it's a thousand times easier to tweak (which you will be doing nonstop making a fighting game) a position/offset in code, than to open up the image editor and drag points around.

I can't think of a use case for your original idea either. Why would you want to change the collision mask of an object without changing it's image? It's just confusing to the player.

Even though, if I were to buy the plugin while you are away (cause I'm waiting for the pay-check...), would I receive it anyway or does it need to be validated by hand?

You get it automatically.

ok ... is there an converter from blender file.blend to json tree .js file u know of ?

go to file -> export -> .obj

the "include UVs" box should be already checked. That's all you need.

[quote:abmx14hg]i think he means that in blender internal rendering system (cause in cycles i think after 2.71 will be bake option available) you have to bake your uv textures.

You do not need to "bake" anything in blender. The material applied in blender doesn't matter either. What I was saying about baking before was with regards to geometry. Multi-part objects which don't need to move seperately should ideally be a single mesh with a shared texture for performance reasons.

All you need to do is make a texture, and then UV map your mesh to it, for that there are countless tutorials on youtube.

[quote:abmx14hg]Imagine developing a 3D editor plugin for C2

There is no need for this (although it would makes things slightly easier no doubt), anyone can code a 3d scene editor in construct for their game, and a corresponding loader to use the saved scene files. The complexity and design of the scene editor would correspond directly to your game's architecure.

Also, how can I use multiple textures on an object? For example, most buildings and people have textures for certain aspects of the model

Texturing should be done at the mesh level, with UV's exported as part of the .obj file. That's the way I did it in the tiny tank demo, and the way it should be done for any game. A single .obj mesh can be comprised of many geometric primitives, all sharing the same texture.

You need to UV unwrap your mesh, then create a texture which contains any graphics you want (all in the same image), then map the individual polygons to the respective areas on the texture map. This can be done in most 3D programs. (I recommend blender, it's free) Alternatively, you can create multi-part objects on the Q3D level (instead of the mesh level), which each have their own materials. This isn't optimal though (and should not be done in any real game): it's highly recommended to bake as much geometry as you can into single meshes, to have minimal separate objects on the Q3D level, to minimize cpu bottlenecking.

They'll be coming soon!

Hello,

One more question, please...

if i understaind correctly... i can chose layer for Q3D?

eg.

layer 0 is C2 then

layer 1 is Q3D then

layer 2 is C2 ?

and Q3D is only on one layer... it can not be on two separate layers?

Thanks!

You can do that, but there will be a performance hit because it has to copy the Q3D canvas into the C2 canvas. The other modes are faster (putting it either in front of the C2 canvas, or behind it.)

This is simply a problem with your logic. Pressing a key will trigger all keypress events during that frame. It's necessary to have some understanding of the underlying engine if you want to truly understand what you're doing. For example, the event sheet runs top to bottom, executing code. If you place the event where it gets sets from 1 to 2 before the event where it sets from 0 to 1, then it won't get set to 1, check if it's 1, then set it to 2. It will check if it's 1 (it's not), skip that event, then set it from 0 to 1, and the frame will end. Then, next time you press it ( on a different frame), it will set it from 1 to 2. However, if you want it to loop back to 0 (like, 0,1,2,0), then the problem still exists, and can't be fixed by code order. The true solution to this problem is to create a new variable (call it "lock"), and set it to one every time you change your counter. Then, only allow the counter to change if the lock hasn't been set by another event in the same frame. (on keypress AND if lock equals 0). Then at the end of the code, set lock back to zero to prepare it for the next frame. With this solution, only one event can ever fire in a frame, and the variables wont cascade from a single press. But here's an even better way, don't use two events at all! Simply set the value to: (value+1)%(maxvalue+1) , where max value is the highest number you want the counter to reach. This makes it so every press increments the value, and then it returns to 0. (0,1,2,3,4,...,maxvalue,0,1,2,3 etc)

Art is subjective, but it can be shown that game making is analogous to painting, thus is considerable as art. The game making activity is reducible to the painting activity. Smeared paint, on a canvas, is considered art, by most people, if thought went into the final product to make it represent something (either figuratively or literally). Painting walls a single color, as a job, is not considered art by most, but painting an image is. Replace paint with text,images,sound,movement. The artist now smears text,images,sound and movement over a blank sheet (programming can be considered his brush), and the end result (the game) represents something other than the items (or medium) used, just as a painting represents something other than the colors (or paint) used. Thus, the final product (the game) is simply a more complex painting, and it is shown that an unknown artform is reducible to a known and respected artform. QED.