CannedEssence's Forum Posts

  • I understand that Construct 2 will automatically attempt to consolidate all the Sprites to 512x512 Spritesheets.

    But say that you have a Sprite that is--for whatever reason--1 pixel wide by 1024 pixels tall. I assume that Construct 2 does not attempt to split this image up. If it did, it could theoretically be packaged into a 32x32 square, but I doubt that's what Construct 2 does.

    So, what does happen? Does it instead create a single 1024x1024 Spritesheet, attempting to put the other Sprites in it as well? Or gasp, does it create a 1024x1024 Spritesheet exclusively for that object?

    In this situation, it would make sense to break the Sprite into two Sprite objects, one lower one pinned to the top one, but that seems a bit excessive.

    Any ideas?

  • Pretty clever R0J0hound, I like your thinking.

    It's still a hack though, opposed to properly referencing an array of instances that already exists.

    It sounds like your idea is the best one so far.

  • Is there anyway to send a selected object list to a function, or otherwise use it anywhere else in an event sheet, other than the event it was picked from?

    For example, say I was making a game where I was catching butterflies with a net.

    Let's say that I caught (picked) several of the butterflies on screen with one swing, but I only wanted to keep the largest one.

    I'd want a function like GetLargestInsect, in order to not have a bunch of nasty code with local variables, loops, conditions, in the middle of a simple event like swing net. I could isolate it, and more importantly, I could reuse it, instead having the same code in multiple places.

    Is there any way to send the selected object list to the function, without populating a temporary global array with UIDs?

    Thanks

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sorry, but it the program says I cannot open it because it was saved in r133 or more recent. As far as I can tell r132 is the newest free version available.

  • I like it a lot, it's very well-polished. You might be able to add a couple of animations, like when picking up a coin, or something.

    My biggest suggestion would be in the balance of the upgrades and their accessibility.

    For instance, in order to be able to advance in the fastest, most effective way, the dominating strategy appears to be to just hold out until you can afford the best of each category of upgrade.

    I don't find that kind of grind to be very enjoyable, so when the dominating strategy is obvious and not too enjoyable, then an alternate design might be worthwhile.

    Perhaps you could stage the upgrades a bit. Force the player to try out other items they may not have considered otherwise.

    Just some ideas.

  • If this were a bug, and common enough that forum folks would be able to identify it based on your description, then it probably would have been fixed by now.

    That being said, I suggest posting your capx file in order for the community to investigate, assuming you haven't fixed it yet yourself.

  • Yeah, mine is set up the same way as yours.

    Here's my .capx, minus the Pause and Function objects: dl.dropboxusercontent.com/u/811222/temp/CiS2NoPause.capx

    I get a 404 error, not file not found.

  • Capx or screenshot of events?

  • There appears to be common confusion here.

    Events pick objects, narrowing down a selected object list (SOL), and then the actions will be performed only on those objects.

    However, the System Create Object action will apparently also pick objects, specifically the object it just created. So, if you properly placed a create object bullet action right before your set angle bullet action, then it should only apply to that created object.

  • Consider a beat-em-up like Double Dragon, Streets of Rage, or River City Ransom.

    Imagine an enemy type, say "Whip Girl", who also spawns with a whip (that other enemies use too). Of course, I'd be tempted to make a whip object, and add it to a container for whip girl, because that enemy always spawns with the whip.

    But let's say that if you defeat a whip girl, she drops the whip, and the player can start using that whip.

    The problem is that it appears that an object can only be part of one parent container.

    Is there a better way than to either make a whip sprite, a whipgirlwhip sprite, a playerwhip sprite, and assign them to their respective parent objects,

    or to have one whip sprite and try and keep track of all the instances on screen with their proper z indexes?

    I'm assuming I can't just have one whip sprite that can belong to both whipgirl and player?

  • I'm pretty new to this program, but I'm assuming that you'd make sure that both the new object and the player sprite are on the same layer.

    Then when you create this new object in the event sheet, set Z-order "move to bottom" action to that object.

    If you are making these instances in the layout view, then Construct 2 is a bit lacking. You'll have to set the Z-order "move to bottom" to all instances of those object in the on start of layout event.

    Someone can correct me if I'm wrong.

  • That answers my questions, thank you all!

    newt

    No, I agree that referencing the instance you just created is more common than referencing all instances of the just-created instance. I prefer that functionality (it makes my second example constructor work =P). I just found it fishy that it worked, because as far as I knew, no action (just events) picked instances. I was just afraid that it was incidentally picking the most recent instance because it happened to be at the "top" of the SOL or something.

    Good to know the create object action also picks the instance.

    zenox98

    I agree with the essence of what you are saying: Construct 2 is designed to be accessible to non-programmers, shirking away lots of the scary syntax, boilerplate, etc, of code. However, there are reasons for why object-oriented languages were designed the way they were, it wasn't just job security.

    Being able to clean up the on layout start event by logically grouping events into functions is smart. Notice how the Ghost Shooter example start layout event is a bit unruly? Having a constructor function to handle instantiating an object and its properties is good organization, not "programmer-minded."

    That's the kind of stuff you see in the popular thread about best event practices in Construct 2: scirra.com/forum/programming-best-and-worst-practices_topic63136.html

  • Object-oriented programming utilizes "constructors" which at its basic level allow the programmer to instantiate a bunch of member (instance) variables upon creating the object.

    Correct me if I'm wrong, but it appears Construct 2 doesn't have that built in.

    For this simple example where we just set the position and scale of Ball on creation, are these the current alternatives:

    Make the constructor simply just an On created trigger:

    <img src="http://cannedessence.com/construct2screens/constructor1.png" border="0" />

    Problem: you can't elegantly send values to the constructor. This would be desired if the place where you create the object has contextual information from some other picked object, etc.

    OR

    Make a function as a constructor replacement, and this is where it gets confusing to me:

    <img src="http://cannedessence.com/construct2screens/constructor2.png" border="0" />

    Why does this work? Notice the second action in the Create_Ball function. Shouldn't this pick all instances of Ball, since the event doesn't pick any instances of Ball? Somehow it picks the most recently created Ball, which works here. However, it doesn't seem right, so I don't want to rely on it.

    I can't put an On Created trigger inside the function definition because they are both triggers.

    Is there something I'm missing about this?

    Thanks!

  • Thanks, good to know!

  • Like many others have in the past, I'm considering creating a random background with a single sprite object repeated randomly across a layout (think: starry sky).

    Is there any way to make a sprite object static, where the only thing it holds is essentially just an array of coordinates, and the only thing it updates is drawing those coordinates to the screen?

    It's my impression that all sprite objects have a whole bunch of extra stuff that gets updated, with a bunch of unnecessary checks for something that never moves or needs to be checked for collision.

    What kind of overhead would this produce? What's the solution with maximum efficiency?

    Thanks!