Any tips for working on large projects?

Not favoritedFavorited Favorited 1 favourites
From the Asset Store
_______ Huge collection of metal fixtures ________
  • I've used Construct products for many years, but only for small demos and single screen games. Now, I'm working on a solitaire game for Steam that will have several different game mechanics, hundreds of levels and over 50 animated dialogue and cutscenes.

    Any tips for working on large projects? (Things I might not have needed to worry about with my smaller games and demos...)

    Tagged:

  • I suggest you keep layout's small and be able to run them stand alone so you can debug any one of them. You will find you want to go through the intro layout screens first like a real user, but it is good to be able to immediately run a layout from the debugger.

    Also, use the template for all your assets (call them basic or default but have one for every asset).

    Don't worry about optimization, do the brute force simplest thing first and get it to work. Nothing ever needs optimization, we just think it does.

    Don't use addons, they get wiped every 5 years for one reason or another or people quit keeping then up to date--I hate to say it, but every time I use an addon I end up regretting it.

    yours

    winkr7

  • Thanks for the reply, winkr7! I'm going to have to study up on templates. I've never used them and I have no idea what they even do!

    I wish I had some tips/tricks to share to return the favor. Hmmm. This might be one! On my last game I added two text files to my project and kept them on my UI. One was for bugs, and the other was a ToDo & Ideas list. It was nice to keep everything together and I never had to leave Construct!

  • Since most tasks will be waiting for a long time to be completed, using task boards can make the structure more visual for adjustments.

    Avoid polishing cross-cutting mechanics and animations - there is a high probability of reworking.

  • For cutscenes and game events I ended up writing a camera with 23 active parameters - zoom and movement via tween or lerp with various curves, optional input blocking and types of hero tracking and forced scrolling. This saves a lot of time now.

  • For a large project I would suggest saving it as a folder project and then using GitHub as source control. Using GitHub is typically used for teams, but even if you're a solo developer, it provides great tools like reviewing and reverting changes that can be really handy. It also acts as a cloud save service which means you can easily work on multiple devices and also acts as an additional cloud backup to help keep your work safe. And of course if you want to get anyone else involved, it's already set up for collaboration.

  • For cutscenes and game events I ended up writing a camera with 23 active parameters - zoom and movement via tween or lerp with various curves, optional input blocking and types of hero tracking and forced scrolling. This saves a lot of time now.

    envoys: Can you describe your cutscene camera a little bit? The story I want to tell is pretty visual with lots of "sight gags". I can't afford to pay for all that animation so I'm thinking about using static comic panels and the timeline editor to scroll and zoom as needed. (Maybe with some limited animations here and there.)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • One thing I've found useful for me working on a large project is keeping all of my global variables in their own event sheet and separating them into sections with comments/titles. Commenting stuff is pretty important, I ignored it for years, but the more complex your project gets the more you will wish you did.

  • I find it easier to store all my global stuff in a dictionary so it doesn't clog up the global scope. Seeing big lists of global variables used to bother me, though maybe now you can put them folders or something? It does effect debugging a little, but if you are tracking a variable in a dictionary you can set it to a local every tic and then track that.

    yours

    winkr7

  • I have two objects for "global stuff" - a sprite (invisible, global) and JSON. The sprite is for variables I use often, and JSON for everything else.

    The sprite also has Tween, Timer, and LineOfSight behaviors, so I can run occasional timers/tweens or cast a ray when needed.

  • I had not thought of a global sprite--that is a good idea.

    yours

    winkr7

  • One thing I've found useful for me working on a large project is keeping all of my global variables in their own event sheet and separating them into sections with comments/titles.

    This sounds like a good idea, but I'd add another suggestion which I think is an under-used approach in Construct: if you need a global variable, but you only use it within a particular group of events, then make it a static local variable instead. Being a local variable means it is only available in that group, so it doesn't clog up the global variables list; being static means it remembers its value permanently like a global variable.

  • I find that with each project I get better at organizing and structuring them.

    Therefore, if you can, try finishing multiple short games. The more games you finish, the more experience you have. And the better you'll get.

    One problem I had with Angvik 2, because it took many years to make, I was stuck with old ways of coding that I'd felt like I'd out grown.

    But afterwards, I made a short game over a few months, Nestris Legacy, and that was really refreshing. I learnt a lot from working on it, despite it being a short project. And now I feel better equiped for the next big project I'm working on.

    I think you also get better at realizing how to make code that's more efficient. Using functions (and custom actions) more. Closing and opening groups more often, especially when that code doesn't need to be checked. I think optimization does help, with Angvik 2 it seemed fine for years, but then eventually performance gradually started getting worse and it was too late.

    I have two objects for "global stuff" - a sprite (invisible, global) and JSON. The sprite is for variables I use often, and JSON for everything else.

    The sprite also has Tween, Timer, and LineOfSight behaviors, so I can run occasional timers/tweens or cast a ray when needed.

    yeah this is the best.

    Also if you make it a single letter name. Then it can make it easier/faster to reference when you're typing expressions, especially when you end up using it so often.

    Also, the commmunity Discord, has a #tips channel which is filled with hundreds of amazing ideas.

  • dop2000

    I have two objects for "global stuff" - a sprite (invisible, global) and JSON. The sprite is for variables I use often, and JSON for everything else.

    The sprite also has Tween, Timer, and LineOfSight behaviors, so I can run occasional timers/tweens or cast a ray when needed.

    Please could you expand upon this a little? What do you mean by "The sprite is for variables I use often" and how do you use the JSON?

    I understand adding Tween and Timer behaviours to some object as they can then be used anywhere else - I've always found it odd that Timers in particular had to be associated to an object and not just global.

  • citron2010 You can add variables to a Sprite (with Global setting) and now you don't have to deal with the clutter of Global Variables.

    For instance you could have a global variable called "variable" or you could just put it on a sprite instead: Sprite.Variable (or s.variable for faster access)

    The benefit of using global sprites for variables (and behaviors) is that then you're free to have as many as you want. And they can be more organized. Because if you had 300 global variables, then if you start typing an expression it's going to show a huge list of variables which may not be relevant to your current event.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)