Workflow dichotomy. What would you do?

0 favourites
  • 7 posts
  • Hey everyone,

    What are people's preference when creating assets (assuming you are creating mostly static bg elements). Do you create many objects and put them in families or do you create a single object and give it many frames and/or animations? Which way makes it easiest to create levels manually? What about generated levels?

    An example of this could be clouds in the sky. One could easily create 20 objects or just as easily create 1 with 20 frames or animations if they are animated.

    Why do you do it the way you do? What are the downsides and upsides to that method. I know a bit of this will come down to preference and that's okay.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It really is preference. Construct generally gives you a lot of ways to do similar things, but there will be some marginal benefits for using certain methods depending on each situation.

    For your clouds example, I would definitely use one cloud object with different animation frames for organization purposes. I generally try to keep my object count as low as possible - given that all the clouds are functionally the same and just have different looks, I would use a single object.

    Usually I try to use multiple objects of the same type only if it makes it easier to pick and manipulate them separately from the event sheet standpoint. Otherwise, use as few objects as possible.

    Another consideration is that animation frames can be handy when used in expressions. On the other hand, animation frames won't show up as the shortcuts/autocomplete Construct provides. This could be a good thing or a bad thing depending on your project.

  • oosyrag I was leaning towards the way you do it for the same reasons you mentioned. I was just trying to think of the cons before I committed to that method. I generally prefer the method that a.) scales perfectly to any size project b.) is easiest in the long run (which usually means its fastest to work with).

  • I'll use a single object for, say, collectibles. That way if an enemy drops one I can just spawn the object and set its animation from a list.

    However, if the game has a lot of floating collectibles then I'll use separate objects so I can easily pick them from a folder to place in the layout.

    For backdrops...it really is preference. You could bundle things like rocks, clouds, plants, etc. but do you want to refer to and type in the animation or frame for every instance? I'd rather have a folder of individual assets to pick from in that case.

    If they are usable you might want to bundle them into a single object and use conditions to tell them apart, since you can't refer to an object by name. For example you've got 3 different springs in a family. If you use "Player landed on spring family" then there's no way to tell them apart without a name variable. You might as well just use one object and compare the animation or something.

  • I have used both methods in the past and the workflow is pretty similar for me.

    One thing to consider though when using a single sprite with multiple frames/animations is that when you add one of these into a layout then he brings all his friends along (frames and animations are also loaded). So if you are building a stage with only one type of rock (and in your rock object you have 20 varieties), you are potentially wasting resources.

    For this reason I think it's safer to go with families instead.

  • Instancing, containers, families, none of them work well together.

    I will say I prefer instances as you can use the index in so many different ways.

  • If I can seperate things into different objects I will, especially if they aren't spawned in at the start.

    Sometimes when you create an object in a layout it could show a noticeable frame-rate hiccup if it has a lot of frames of animation.

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