Your Most Invaluable Lessons Learned in Construct 2

I've been working with Construct 2 for a year or two now, but I'm still constantly learning new things about it...often because I have to in order to efficiently execute a new game idea, but sometimes I just happen upon a helpful new feature I never knew about.

For the sake of learning even more new stuff: What are some of the most invaluable lessons you've learned in regard to working with Construct? For example, I didn't understand how Functions worked until a few projects in and I use them constantly now. Also worth mentioning is the "Replace Object" option.

there are lot's of things i could say event wise but. i think something not often thought of that applies mostly for beginners is even it you arnt looking for anything it's good to watch threads in the How-do-i section of the forums even if it currently doesn't help there are lots of great things posted there that can help you improve your work

My personnal one would be "do not overdo it", I see some people (and lets be honest, on some parts I was like them at first) that put a lot of time and efforts into:

-optimising every single event to run faster (changing conditions and actions constantly, which without measures or experience can become the opposite.)

-trying to use things they do not understand instead of either learning about it or simply not using it (the a = lerp(a,b,x*dt) is the perfect exemple of thing that is not only wrong when the calculation is done with dt variations, but also is mostly used just because it looks good rather than being needed or understood), it can demand quite a time to polish some of them pretty well

-learning by themselves how things work by doing some studies of them, whan the manual actually does this job, sure, there is a difference between reading it and proving it, but if people want to prove everything every time, it takes time for only rarely benefits.

-reinventing the wheel, seriously, why use an engine if you reinvent the wheel constantly, there are tools, and they are pretty much working in most cases, might as well learn to give them some work sometimes.

the lost time is actually time not improving the game in most cases, and the result obtained can make things worse, which means basically even more lost time.

on the same topic, backups are great to erase big f*ckups and mistakes we do, use them.

Hello;

for me it was giving up trying to write the game I want to write, and instead writing the game C2 is designed to help you write.

yours

Winkr7

My personnal one would be "do not overdo it", I see some people (and lets be honest, on some parts I was like them at first) that put a lot of time and efforts into:

-optimising every single event to run faster (changing conditions and actions constantly, which without measures or experience can become the opposite.)

-trying to use things they do not understand instead of either learning about it or simply not using it (the a = lerp(a,b,x*dt) is the perfect exemple of thing that is not only wrong when the calculation is done with dt variations, but also is mostly used just because it looks good rather than being needed or understood), it can demand quite a time to polish some of them pretty well

-learning by themselves how things work by doing some studies of them, whan the manual actually does this job, sure, there is a difference between reading it and proving it, but if people want to prove everything every time, it takes time for only rarely benefits.

-reinventing the wheel, seriously, why use an engine if you reinvent the wheel constantly, there are tools, and they are pretty much working in most cases, might as well learn to give them some work sometimes.

the lost time is actually time not improving the game in most cases, and the result obtained can make things worse, which means basically even more lost time.

on the same topic, backups are great to erase big f*ckups and mistakes we do, use them.

Good stuff here. I can especially relate to the point about backups...I often "Save as" to new files before big changes so I have a good working copy before breaking everything.

I'm also very bad about trying to "optimize" everything...often I'll waste hours trying to consolidate events and organize things into groups, which will supposedly allow me to find and edit things more easily down the road (when in reality, I won't likely need to make any major modifications to those events in the future).

I'm getting better, but old habits die hard!

Don't dream big right away is my main problem. I come up with a nice idea, get a good foundation then start dreaming of things I can add that makes it way more complicated and then overwhelm myself and end up moving on to something else.

Make small games first, those end up being the ones people play more than the ones that we pour months on and finally release it with only 2 IAPs over a month...

Have fun, use plugins, they are great. Etc etc.

— I think that organisation is important. Grouping is very helpful and I basically use it for anything that is bigger than an example I whip up for someone.

On that note, functions, grouping and callbacks. When I first started with Construct classic (seems like a long time now) I was really frustrated by having to repeating events when a function could have been used. I don't know to this day if classic had the ability to do functions, I haven't looked back. Finding out ways to better organise and abstract the event sheet are what I find really useful.

Generally speaking: Explore. Don't be afraid to get into the nitty-gritty details of Construct. That's the power of having a Javascript-based game engine, you can tinker to your heart's content. Take a look at the JS files in the exporter for plugins and behaviors. You can learn a lot of stuff that you wouldn't find in the manuals, and a lot of the code is well-commented.

— I think that organisation is important. Grouping is very helpful and I basically use it for anything that is bigger than an example I whip up for someone.

On that note, functions, grouping and callbacks. When I first started with Construct classic (seems like a long time now) I was really frustrated by having to repeating events when a function could have been used. I don't know to this day if classic had the ability to do functions, I haven't looked back. Finding out ways to better organise and abstract the event sheet are what I find really useful.

Don't get me wrong, I think keeping things organized is VERY important and helpful, but it's much more so when you do it from the get-go. Getting 200 events in and deciding that the code isn't "clean" enough for you is not a productive path to start down, but keeping things well labeled and grouped as you work is a good habit to get into.

More walking, less talking.

First, I have noticed a few posts where a person asks how to do something to which people respond, "it's not possible." The truth is, "it's not possible" is very rarely the correct answer and if you think it is, don't answer the question because you are probably wrong. In one case, one of the forum moderators told a user what they wanted was not possible, after which I posted a couple different examples showing how to do what the user wanted.

Next, I learned that there are too many times users rush to the forums to ask a question, thinking they will save time instead of searching the manual, tutorials or even previous topics. This winds up making the user wait a day or more before they can continue their project when a search would have taken only 20 mins to a few hours. In trying to save time, they wind up wasting it instead. I have used the software for more than 3 years and have not once yet created my own question topic because every thing I needed was already documented. This isn't to say there aren't times people might need a little more explanation for which the forums can be very handy. Just that a little research can save time and frustration.

I've learned that, while the information about C2 says you can make games without any programming, having a good understanding of programming techniques goes a long way toward making it easier. I am constantly using programming techniques to lessen the number of events I use and when answering questions in the forums I like to try to share some of these enhancements. The truth is, C2s event system is really an image based programming language. When we setup up our events, we are programming the game.

I've learned that people think C2 should make their game for them when in fact it is a tool. Like all tools, it's only as good as the person using it.

I think the most important thing though is, I have learned a lot about C2 simply by trying to answer questions other users have had. There are so many creative people in the community that just need a little information on their projects and taking the time to help them work through these has really pushed my own skills. If you really want be get a better understanding of C2, open the How To forum and try to answer questions there.

A little trick I find which I seem to use all the time. Since global variables are either int or text, to store a boolean use int and toggle with setvalue(variable = 0 ? 1 : 0). I've used this before C2 but I really like it.

C2 allows you to quickly throw a draft layout together. It also enables you to easily experiment with some eye pleasing visual candy using default or plugin behaviors and effects. This does not mean that a quality game can be thrown together nearly as quickly - planning and patience are not provided by the editor....

Make the game that YOU want to play, that EXCITES you.

Don't make a game that you think others want to play.