Cool, glad you settled on a solution that worked.

Personally I think if there was just a checkbox next to each object in a container which said 'Maintain Relative Position' and possibly more claririty on parent child relationships (like Unity) this would do.

I also think that the 'Pin' behavior should have a 'Automatically Pin on Start Of Layout' checkbox so we didn't require separate actions for this all the time.

I love the simplicity and ease of use of your container suggestion. It has the disadvantage (which is really a disadvantage of containers, not your suggestion) that one would still need to create a set of unique object for every single combination of objects, even if some of the sub-objects look and behave identically. So if you have a bunch of slightly differently designed dialog boxes like the one you are making, and they all use mostly identical elements, like a text object, you'd need to make a different text object for every single container rather than having a single text object that can be reused all over the place. This is one place where containers fall apart compared to more sophisticated implementations like Unity has. All that said, I'd still kill to get what you just suggested.

Unfortunately there is no parent child relationship in Construct per se right now, but you can however fake it a bit with pins and instance variables. The Pin behavior has "Pin.PinnedUID", which will return the UID of the object the Pin is attached to. So in a condition you could do something like Button -> PickByUniqueID -> Button.Pin.PinnedUID, and that will pick your frame. For the "parent" storing references to its children, you'd have to use an instance variable to store the child's UID. So you'd add "ButtonUID" number variable, and then when your button is being set up, either at runtime or design time, you'd do something like Frame -> Set Instance Variable -> Set ButtonUID to Button.UID. Then in the future you could use Frame.ButtonUID to pick the button if you needed to.

And yeah, setting Pins at design time would be pretty handy for some situations. I found it confusing that this wasn't possible when I first started playing with Construct.

Yeah, this is one of Construct's biggest limitations imo - the inability to build prefabs beyond containers. Workflows in Flash, Godot, Unity and Unreal lean heavily on this concept. I'm desperately hoping Scirra will implement a scene graph once the C3 runtime is up to snuff. The suggestion for that is already logged and has a ton of support from the community, and it sounds like they plan to look into it, but a few more votes wouldn't hurt... <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

https://construct3.ideas.aha.io/ideas/C3-I-12

In the meantime I have been looking into various ways to deal with this problem in my own project, which requires quite a few composite objects of the type you're describing. The suggestion to hard-code each one is the simplest and if you're fairly new to Construct or if you don't have many of these object groups that's what I'd suggest too.

Another (considerably more complicated) method to consider if you want to push things further would be to build an object editor for your project. Basically you'd create a level editor, but for objects. The short and incomplete version is you'll loop through the objects in your group, then save the data for each object into an array or dictionary using a combination of the objects' names and the asJSON system expression. Then you'll write the array or dictionary to a file (you will need to export to NWjs for this). Then at runtime you can recreate the object(s) from the file(s) using AJAX to load the file, create object by name to grab each object name from your array, and loadfromJSON to set all their properties like position, etc. Finally you pin them together, if that's needed - this also requires you to track some kind of pin target uid when you create the objects.

I would suggest using families for all this to make such things easier - for example, I'm using a "Serializable" family with an "ObjectType" variable to store the object names, and a "Pinnable" family with a Pin behavior for all the things that need to be pinned. This way you can use functions to simply get "Serializable.ObjectType" for every single object in your group, and loop through them more easily. I'm currently hard-coding what things in a group get pinned to based on their object types, but there is probably some good way to abstract this further with yet another family ("PinTarget" or something).

Anyway, it's a little complicated and difficult to explain fully in a short paragraph like this, and it's probably overkill for your problem, but that's the basic idea.

And one question from me: will the old Construct 3(or maybe construct 2) projects be compatible with the new c3 runtime?

Near the beginning of the blog post:

And we've even managed to keep it highly compatible, allowing many existing projects to opt-in to the new runtime with few or no changes.

It would be nice to learn what the details are, but it seems like compatibility is an important consideration for them already.

You're welcome. You could also set them at runtime with "set position to another object" actions on the start of the layout, if you want it to be more precise and automatic.

OK, I see the problem - looks like the image points you're using as your joint locations don't actually line up with the centers of the wheels. Set the wheels' opacity to 50% so you can see the body of the car behind the wheels, and then line the centers of the wheels up carefully with the black dots on the body.

I have tried to make this project as the example but why my car can not run smoothly.

Is there anyone can tell me what is wrong about my project?

this is my project: https://www.4shared.com/s/fb8epJzuJca

I'd take a look, but do you have a Dropbox or Google Drive link instead?

>

>

> Frankly your snarky attitude and manner of speaking makes it obvious that you aren't really a professional,.......

>

> So, if you're serious about being a "real dev" yourself, the first thing I'd suggest is to stop assuming you somehow know everything despite having never done any serious work in this field. Stop assuming people who disagree with you are fools. Stop wasting your time picking fights in forums. It might make you feel good to lash out and insult people, but you're not doing yourself any favors. Spend your time mastering a tool of your choosing - pick one and stick with it even when you encounter frustrating problems (which you will, usually in no time flat). Use it every single day anyway. Ask for feedback on your work and consider it carefully, and be respectful towards the people kind enough to give it to you even when you don't like what you're hearing. Read up on your craft (Gamasutra and the GDC vault are great resources). And don't give up. This stuff is difficult, and even with some of the great engines we now have access to, it takes a long, long time to get good at it or to finish anything worth finishing.

>

> Good luck.

>

You seem like a young 'un. This is a tough industry son. I'd drop the Construct and focus on true code, and don't mention Construct during an interview process. Trust me on that one.

But thank you for your insight into my lack of experience. I had no idea how inexperienced I actually was.

Haha, young I am not, sadly. Not really. I wish that it were so. Not totally old yet either, though.

Anyway, I'm happy to talk over PM and we can have the battle of the resumes there. I'm not looking to trade insults. Now you have me genuinely curious as to your background. I just can't imagine any of the people I've worked with in games hopping onto a forum like this to berate beginners for their choice of tools.

As for mentioning Construct during interviews, what sorts of interviews do you mean? Programming? Design? As I said, I'm a designer, so I'm not greeted with any particular elitism with regards to which game engines I've used. Maybe programmers are more judgmental about such things, although I can't see why mentioning it would HURT, assuming you can otherwise show that you know what you're doing and would be a good fit for the team. Using Construct admittedly doesn't prepare one to be a programmer, although many of the basic concepts are similar.

For everyone else, if you're going to interview for a game design position, don't be afraid to mention things you've done using Construct. Things like that don't count against you - why should they, unless that's your only experience and the job requires engine-specific knowledge? In game design it's more about what did you actually MAKE, not necessarily the tools you used. When I've interviewed candidates, I'm always favorably impressed when they built games on their own initiative. We hired one kid based on his positive attitude and a simple game he'd built using an engine very similar to Construct. Another junior designer I know was hired partly because of his experience making maps for Left 4 Dead. Passion and determination counts for quite a bit.

>

> >

> >

> > See you there bud. Bring your copy of Construct with you, we will all be fascinated. You could do a demo - wear one of those headset/mic thingies.

> >

>

> I'm totally serious, actually. Shoot me which talks you're going to via PM and we can talk the realities of game development face to face. My company is having us share passes, so I won't be there every day, but I'm sure we can make it work. I'm generally interested in the design track stuff since that's my day job, but whatever, the place isn't that big.

>

Well, look at you. A "serious" game designer, with all the bells and whistles, and using Construct - what are the chances? As much as I'd love to chat "shop" with a total stranger, 'face to face', from a forum, I will decline your offer.

And before you suggest it, you're right - I'm declining your invite because I've never worked at any major software company and have never written a line of code. You win my friend!

Frankly your snarky attitude and manner of speaking makes it obvious that you aren't really a professional, despite your mockery of people who consider themselves developers but don't share your opinions on tools. Real developers don't speak to one another the way you're speaking to all of us. We generally support and respect each other. We keep things civil even when we disagree. We don't mock people trying to get started in making games no matter what tools they choose. Making games is difficult enough without this kind of petty, childish sniping, and if you bring this kind of attitude to a job in this industry, you won't last long.

I don't use Construct in my day job - I use it for smaller side projects. But that doesn't make "worse" than what I do use on the job (which is Unreal Engine 4 - I've also used Unity and various proprietary engines in my career). Construct is simply a different tool for a different job. It's better suited to smaller, 2D games. "Smaller" doesn't preclude the possibility of a game being very fun or very successful. Construct is much easier to learn than Unreal or Unity, and certainly FAR easier than rolling your own solutions with code, from scratch. Construct is also a helluva lot of fun to use. A person can absolutely be a serious developer and use Construct. It has some technical and workflow issues (just like every engine I've ever used) but fewer than many of them. For example, Unreal crashes for me more often than Construct does. There are no silver bullets out there, "dev level" or otherwise.

So, if you're serious about being a "real dev" yourself, the first thing I'd suggest is to stop assuming you somehow know everything despite having never done any serious work in this field. Stop assuming people who disagree with you are fools. Stop wasting your time picking fights in forums. It might make you feel good to lash out and insult people, but you're not doing yourself any favors. Spend your time mastering a tool of your choosing - pick one and stick with it even when you encounter frustrating problems (which you will, usually in no time flat). Use it every single day anyway. Ask for feedback on your work and consider it carefully, and be respectful towards the people kind enough to give it to you even when you don't like what you're hearing. Read up on your craft (Gamasutra and the GDC vault are great resources). And don't give up. This stuff is difficult, and even with some of the great engines we now have access to, it takes a long, long time to get good at it or to finish anything worth finishing.

Good luck.

See you there bud. Bring your copy of Construct with you, we will all be fascinated. You could do a demo - wear one of those headset/mic thingies.

I'm totally serious, actually. Shoot me which talks you're going to via PM and we can talk the realities of game development face to face. My company is having us share passes, so I won't be there every day, but I'm sure we can make it work. I'm generally interested in the design track stuff since that's my day job, but whatever, the place isn't that big.

> If you don't want to read the documentation, I guess it doesn't matter how well it's written!

>

I have read many C2 docs over the years and they were in general at an amateur level. My suggestion is that if you are charging "big boy" per annum prices, that you hire a trained tech writer; at least one - and stop relying on user provided tutorials (unless they are getting part of that per annum charge?). At $99, C2 was "lifetime" and I could overlook the bugs, the lack of documentation, outdated documentation, and the lack of fixes. The new pricing structure demands a higher level of support.

Also, let's not get too carried away with what Construct can and can't do. If you guys are creating Pong via a drag-and-drop application and thinking you're 'devs', think again. What you are doing is locking yourself into an eco-system that demands that you pay yearly or your projects are useless to you. And if monetizing, with the amount of times Construct apps generate violations on Google Play / AdMob - you will be paying for years to support those apps, else you cant update/fix the Google Play violations.

I'd recommend people move over to Visual Studio, an IDE that can export to Windows/iOs/ Android. It is DEV LEVEL and its FREE. As I said earlier, Scirra is charging "big boy" prices now and with beta plugins for monetization, missing plugins for monetization, or plug-ins/bugs that sit unfixed for months, non-action isn't going to cut it.

If you have no interest in monetization, and you just want to pay $99 PER YEAR to show Granny you're a 'dev' and made a game of Pong, knock yourself out.

Cool man, let us know how that works out for you! Good luck! I'll see you at GDC this year, I'm sure!

Whoops - I got tempted after reading of export to APK. Went to purchase and the price is PER ANNUM -

hohohoho

No thanks, Scirra you are far from being stable enough to charge per year, like Adobe. My initial post was correct - a money grab.

It's a different business model than you're used to, not a "money grab". "Money grab" suggests that what they're doing is cynical and dishonest somehow - the steady stream of improvements to C3 suggests otherwise.

As to their stability, they seem pretty stable to me... they deliver upgrades consistently, they generally respond to bug reports promptly, and they're active on the forums. I think they are working hard in good faith, and have integrity. If this new business model allows them to be even more stable and more productive still, I'm happy to use it.

All I know is that he had a considerable amount of work, and helped make C2 what it is to day.

And his absence will taken some effort to recover from.

Oh. OK. I thought you had a reason for bringing him up that related to this discussion.