I feel like "Containers" should be the first thing taught/learned

I've been using strictly Construct 3 for the past few months for all of my game development projects. I'm only now learning about Containers. XD

I feel like this should be one of the first features of Construct to be taught, as they are extremely useful. They make creating objects within a game, so much easier. Previously I was adding objects at Start of Layout, then moving them to another objects position, with an offset. Then creating the other objects that need to follow the main object as a child of the main object after being repositioned. Or using a Pin behavior after moving the object at the start of a layout.

Think about things like a PlayerBox that handles the platform elements of your player, and a separate object that handles the Player sprites and animations. Then debug text above the Player to check it's current State if using a State Machine. Or any other debug text, and other objects you may want to have follow around the main objects in in your game.

This has lead to a ton of things to keep track of, and trying to alter things on each instance of objects in-game. Such as Debug Text, Collision Box Sprites, HP Meters above Objects, Checking State/Animations, Instance Variables, etc. I've been having a hell of a time on the current project I am currently focusing all my time on. Lionz, here in the community brought up using Containers for my enemies. I had not even heard of it, haha. So I immediately started researching it, to learn more last night.

I searched "Construct 3 Container Tutorial" on YouTube, and was able to pull up only two tutorials. Both for Construct 2, and one in Spanish. They seem to work the exact same way in Construct 3, now that I've read the page on Containers in the Construct 3 Documentation. I even went to the Browse Examples area of Construct 3, and tried searching for "container", "containers", "conta", etc. And, could not find any direct examples of Containers being implemented in an example project.

So, I'm learning more about them today by jumping in, and completely rebuilding my Enemy Objects using the Container feature. Which is usually the best way to learn. Just jump in and start playing around with any features you are unfamiliar with. When it comes to anything, I learn the best doing things this way anyways. But, everyone is different.

Overall, I feel like this should be one of the main/first lessons on Construct 3, for any type of game creation. I even used Construct 2 years ago, and had never heard of Containers. It definitely shows where my ignorance lies, and what I need to study/learn. Which is a main aspect of life in general that I appreciate. But, if this was one of the first Tutorials, or an Example Project, etc. It would help so many folks new to Construct, when they go ahead and start on their own project.

Either way, in the end I've found a weak spot for Construct 3 tutorials on YouTube, as well as my own knowledge on Construct 3, and it is at the top of my list to create a video tutorial on now :).

Not trying to "bring down" anyone here. I've been really enjoying my time working within Construct 3. It's been the most useful game engine I've used, and I've used many over the years. It's so easy to quickly prototype any type of gameplay, implement new gameplay mechanics, debug things going haywire, etc. At least compared to the other game engines, and pieces of software I've used over the years.

I just feel like this may be a blind spot for a lot of people who begin using Construct 3. Just my two cents :)

Hope everyone is having a fantastic Sunday :)

Peace!

I think the first thing that anyone should be taught is to read the fab**ous manual. At least up to the references section.

In an ideal world. Yes you are correct.

But, when you first started, did you sit down and read the Documentation from start to finish before beginning your first project in Construct, oosyrag?

I'm sure there are many like me. Who jump right into new software/applications to learn. Watching video tutorials in the beginning, then referencing the Documentation for things I learned about in video tutorials, but didn't completely grasp. I guess none of the tutorials I went through happened to mention using containers. Even having gone through many video/written tutorials available right here.

I even had trouble finding it in the Documentation. It's kind of buried, under Project Primitives > Objects > Containers. To find it last night, I literally searched "Containers" on the main Documentation page to locate it.

I had already read through "Best Practices" section a few times, and also many of the other areas of the Documentation, and didn't see it referenced. I now see it referenced in "Layout View", "How Events Work", and "Multiplayer". After searching the term again. Those must have been three areas I hadn't read, thinking I had all the info from following tutorials, and playing around in Construct.

I never noticed or questioned the Container field under Effects in the Layout Editor. Which I guess, I should have. I'll take a day, and read through the entire Documentation, as you suggest.

I'm not trying to put anyone down here... Just sharing my two cents. That I feel Containers, should be a highlighted feature in Construct. Maybe, I'm wrong. But, that all depends on the individual's perspective.

Nah, they do one thing very well, until that thing gets in the way.

The true power of containers is data types, but we have no pairable datatypes that aren't also contrived in usage.

Nope, I didn't. But if I could tell my past self to, I would mention that it's not really all that long, it's well written, and there's a lot of interesting information in it that would have saved me significant amounts of headache in the future.

Therefore, that's the first thing I think anyone should be taught. I understand there are many like you (and me) who jump in. I now think that not reading through the manual a bad idea, as I've seen the results of it commonly in these forums over the past ten years.

I also understand how it might have been difficult to find. But if you actually did read through the manual, this post wouldn't have been necessary since it would have been a thing that you knew existed. Even if you didn't quite understand how to use it at first, you would have known it was a thing and then looked it up again when it could have been applicable.

Sorry that's a little bit of an off topic rant. I think containers are a very useful shortcut for a very specific thing, but you can work fine without them. I don't really think they're required knowledge compared to multitudes of other things like picking, how the event sheet works, expressions, loops, and arrays.

Arrays would be my specific topic of choice to introduce outside the beginner tutorials. I die a little inside after every post where people are intimidated by the concept of arrays, when they're so useful and basically just spreadsheets that everyone is actually already familiar with. I blame high school array/matrix math for the confusion.

I've used Construct for many years but I've never used containers. I've been using hierarchys once they were added, but before this I'd link objects together by having a parent object, with all the children having an instance variable that stores the parents UID.

I still use the "store the parent's UID" when it comes to arrays and dictionaries, as you cannot add an array/dictionary as a child with hierarchys.

We all learn in different ways - I am the type of person that, when starting to use a new software, I only Google/check the manual if I get stuck on the specific thing I'm trying to do, but beyond that, I wanna click and poke around the software myself - even if I click the wrong thing, I will learn from that. As months go by, I become very familiar with the general layout of the software, and THEN I read the manual more casually, so that I can see if there's shortcuts or secrets to enhance my use of the software.

I have somehow never used containers in all these years - I see the manual mentions at the very bottom about how you can use containers to store an array/dictionary per object, which sounds VERY useful!

However, I'm not fully convinced that containers are "adaptable" enough. I have the view that containers are for relatively simple situations.

Like let's take Scirra's example with the tank object with a separate turret, both placed into a container. Now say you design your game to allow you to upgrade your tank to have a 2nd turret - I assume that containers wouldn't be good for this situation, since you must stick with your original container setup and not edit this at runtime?

You'd need to specifically clone the tank object so that you can build a new double-turret tank (then put all the tanks in a family to make it easier to handle the tanks in events) which would work fine, but then you want to have a 3rd turret upgrade - again, clone the tank, and then make a triple-turret tank in the family.

Now this sounds messy, you wouldn't want to drive around in your tank, collide with a "upgrade" power up, and suddenly your events would involve creating the upgraded tank on top of the old tank, angle/position all the values from the old tank to the new tank, then destroy the current tank... Not very elegant. Maybe you could have an invisible "player" object that handles movement and everything, and the tank simply positions on top of the player object, but you still have to transfer some data to the newly created tank as you don't want your old turrets suddenly angled the wrong way when you collect the upgrade.

Sounds like a pain! But if you used hierarchys, you can have the 1 tank object, add as many turrent children as you like in different positions easily (which can automatically follow the tank along with the angle, width, height, z elevation), maybe store a variable for the turret like TurretID or use the IID when picking the tank's turret children, so that you know which turret to pick when you wanna do stuff in events, and then you're done! If your tank needs a different shape, you can add an animation for that, so you never have to destroy your tank object at any point.

The final downside to containers, is the lack of control over destroying everything. Bad example, but let's just say you had a situation where your turret should destroy on its own for whatever reason - Well you can't do that, as it will destroy your tank entirely. You would need to set the turret to be invisible I suppose, maybe that's better design anyway, but hey I wanna destroy it and I'm not able to!

Please correct me if I'm misunderstanding the true power of containers, as I'd rather understand this better!

Thanks for the well written responses oosyrag, and Jase00

I really do need to refresh on Arrays, and hierarchies. I was much more agile with using them a couple decades ago, when I was 14 years old XD. Now I'm so used to the data structure in another game engine I was using. Similar to arrays, but rather than using columns/rows which are numbered. Creating each cell/block of data as it's own variable within that struct. So you can call it using the struct.variable(which pulls that variable from the structure of data). Similar to how Construct makes it simple to call instance variables from an object.

There are always 20 different ways to accomplish something that wants to be implemented. As of now, I've been using a lot of Parent/Child objects for everything. I'm currently working on an enemy state system, with multiple enemies, and multiple objects for each enemy(collision box, debug text, enemy object, etc). Along with tracking enemy state through the state machine. Then debug text, separate collision box, making sure that each one is switching states/animations, colliding properly based on EnemyBox object. Etc.

I'm not entirely sure yet, but using containers in this instance may be easier. As I can plop the same collision box for every enemy in the Layout editor, call the proper enemy type from the Family of enemies using an instance variable within the main object of the container. I feel like using containers, and having all the child objects automatically created and destroyed as a single object, should in theory cut down on Actions/Events along with using Family Objects. Would make it simpler in my mind, as how to have each enemy object react appropriately.

And, be more efficient, than how I am doing it now. Creating an enemy object from a family, then creating each child object. Setting each one to move to the appropriate offset compared to the parent. Setting as the child of the parent object. Then call the proper state/animation, using an instance variable in the Family. Maybe I am wrong. I'll find out either way, what works better for me personally, in this instance.

I just found out about, and began using Family Objects as well, which is really a shame on my part. I plan to make some time in the evenings this week, and read through the Documentation. Either way. I've got 4 different copies of the same project going right now. Trying to set up my enemy system to get the desired result, using different methods. I've got it mostly working in one instance(but it feels hacked together), and partially working in the others. Then see which method proves to be the most efficient in this instance. Just trying to become more efficient in how I approach different situations within Construct. I'm rebuilding a game, I threw together in 72 hours for the Ludum Dare. In that project file, I'm literally rewriting the actions/events for every enemy type, over and over. Just switching over to using a Family Object for the enemies, has cut 20+ lines of Actions/Events for their basic platform movement, down to about 5.

I do tend to overthink, overanalyze, and overcomplicate literally everything. I think way to much about things, and get in my own way constantly. Not only with development, but life in general. I still have a lot of areas to work on. Work/life balance especially, but this is going way off topic. Most of my confusion is probably from pushing, and trying to force things when I get stuck. Rather than walking away for a bit, and not get burned out with the issue.

I'll have times, where at 2am, I'll suddenly realize what the issue was, then jump back in and have it fixed in 5min. Where earlier in the evening, I was staring at it and changing things around for a couple hours.

Again, off topic. But, I should have just stuck out game development from the get go. I'd be so much further ahead right now. But, must take what I have today, and move forward. Adding onto that framework of knowledge.

I definitely appreciate the feedback. I'm ignorant in many areas. But, what is life, besides trying to improve and progress each day. Shining the light on the areas I am ignorant in by failing, gives me something to figure out/learn the next day. Which only spreads out further what I call the "horizon of ignorance". Learning through each failure.

Apologies if I've wasted anyone's time here. Take care. Peace out. Stay blessed. Have a great day. I'll see you all around. I've obviously got a lot more studying to do, and it'll never stop.