I'm a firm believer that any time one picks up a new programming language or game creation system, especially
if one is not familiar with using similar tools prior to learning the new one, one should start out small
, rather than jumping into the big 'dream game'. The consensus is usually the same at most software development discussion groups that I've frequented in the past.
Quite often, what happens when one jumps into the 'dream project' without having good knowledge in place beforehand, is that they'll end up at a point where the project can't be sustained by the existing code base any longer due to poorly written code, lack of planning for previously unthought-of features that don't fit well into the current framework, and the hard-to-find bugs that come with working around those limitations.
The good news is that when a total re-write is deemed necessary, the new result will be gotten much more quickly than the original was, and will undoubtedly be better, because of the experience that was gained from the original effort. Unfortunately, some people find themselves discouraged by having to start over, and give up. It's an exceedingly common situation, though, and should be taken in stride
Bearing that in mind, my strategy has been to learn as many different aspects of using Construct that I can, and to mull over what is possible with it, before starting the big projects that I want to create. Knowing the capabilities at hand helps to minimize the number of roadblocks that one has to break through during the process, and any previous experience will help one lay out a sustainable, expandable framework for the larger projects that seem to grow on their own, once begun.
So, if you can make mini-games out of ideas that may be used within the larger project, or even make some smaller things that also spark your interest in other ways, before you start on the big project, it will definitely help. If you're too impatient for that, then a similar strategy can be used during development of the big project, by putting it on the backburner for a short time while testing out an idea in a separate small project that borrows only what is necessary from the bigger one to work, then once it's tweaked to one's satisfaction, recreate it in the larger project. This can have the advantage of limiting the amount of code changes in the bigger project, and thus reducing potential bugs.
Another piece of advice that I'd give is to try and make the project modular. If you can break it up into modules, it tends to make it more manageable. It helps to document what each one expects (global variables, function parameters, etc.,) what it does with those, and what it returns (if it is a function.) In Construct, managing separate event sheets can help with this, if done correctly. Using the event group functionality can be very handy, as they help organize, AND can also control the execution of events by enabling and disabling them at runtime. Also, using functions is a time-tested method for reducing duplicate events and breaking a project into separate tasks that work together as expected.
However you choose to proceed, good luck!