Silent Cacophony's Forum Posts

  • Hi. Construct lets you select from many expressions from any text entry field that accepts those, such as the 'Set speed' action.

    In case you don't know about any of these, I'll describe the process below.

    Also, even object selection gadgets can be right-clicked and 'Use expression' can be selected. This would be the action (copied as text from Construct) for doing what you mentioned, if the sprite were named 'Unit':

    -> Unit: Set speed to Unit[RTS].Speed - 10

    You can access that 'Unit[RTS].Speed' using the mouse by doing the following:

    • click 'new action' in the event sheet
    • double-click the sprite with RTS behavior (named 'Unit' in the above case)
    • click the 'RTS' tab at the top
    • double-click 'Set speed'

    Here's where you can access a multitude of 'expressions' that Construct provides. You can either just type them into the text entry, or select them from the usual list, or a combination of those is usually the case. From here:

    • double-click the sprite again in the object view at the bottom of the window. This brings up all of the expressions for it.
    • select the 'RTS' tab as before to get those specific to that behavior
    • double-click 'Get speed'

    Now just type in ' - 10' to the end of it.

    The System object also has many useful expressions to use in such a way.

  • I've run into a similar issue before, and I dealt with it by using a variable to keep track of it's state. Suppose that you wanted to rotate a sprite 90 degrees per press to test it out:

    + Xbox360Controller: (1): Start is down
    + System: Is global variable 'StartPressed' Equal to 0
    -> System: Set global variable 'StartPressed' to 1
    -> Sprite: Rotate 90 degrees counter-clockwise
+ System: Else
-> System: Set global variable 'StartPressed' to 0[/code:5sf9uw9a]

I suppose that you'd need a global or private variable for each button press or multi-button press that you'd want to know the 'pressed' state of.

Note that the [i]else[/i] condition is paired with the [i]Start is down[/i] condition, and the indented condition is a sub-event of the first condition.

  • There's also a nice short tutorial regarding your first question that may clear up any questions you have about that:

    Tutorial: When to use 'for each'

    .

  • Nice post, tulamide. I've seen this issue pop up a lot as well.

    The power of ELSE is not to be underestimated. It provides an elegant way to make two set of actions mutually exclusive, so that only one set will be executed per test.

    And it seems to work nicely in the newest 'unstable' (possible next release candidate) build.

  • Hi. While tulamide provided a nice write-up of the general problem here, I thought I'd reiterate it about your specific problem as well. The thread that tulamide made is definitely worth a read, though, so check that out as well.

    C: On Left Clicked on mutesprite
Inverted C: Master is Muted (an XAudio2 function)
A: Set Master Muted (an XAudio2 function)
A: mutesprite: Set animation to "Animation 1"

C: On Left Clicked on mutesprite
C: Master is Muted (an XAudio2 function)
A: Set Master Unmuted (an XAudio2 function)
A: mutesprite: Set animation to "Default"[/code:3trxyti0]

Using tulamide's 'snapshot' analogy, the thing to note here is that ALL 'On Left Clicked' conditions will be true for the one tick in which they are polled after the left click takes place. This is by design, so that you can have more than one condition testing for it, though it's usually not necessary.

However, changes that you make are generally instantaneous. So, your first event actually sets up the second to be true as well, effectively canceling each other.

The best way to do that is to check for the left click, then in a sub-event of that, check the 'muted' state, carrying out the appropriate actions if so. It's important that both conditions can't be true in the same tick, so the system->else condition comes in handy for that. Put the second set of actions under an else condition, and there is no way that both sets of actions can be run in the same tick. That's also why it worked if you used different keys for each, as that kept both from being true in the same tick.

[code:3trxyti0]C: On Left Clicked on mutesprite
---C: Master is Muted (an XAudio2 function)
---A: Set Master Unmuted (an XAudio2 function)
---A: mutesprite: Set animation to "Default"
---C: Else
---A: Set Master Muted (an XAudio2 function)
---A: mutesprite: Set animation to "Animation 1"

C = Condition
A = Action
--- = Sub-event (one level of indentation)[/code:3trxyti0]

That would look just as tulamide's good and easy 'hello world' example in the other thread, if it's hard to tell the structure from the text example.

[quote:3trxyti0]
BTW-Why isn't there a condition for seeing if the Master is muted? Also, would it be "a XAudio2" or " an XAudio2"?


I didn't see an expression for checking the muted state either. Maybe it was overlooked.

And I've always gone with 'an' with words that start with a vowel sound, and I think of that name as 'ex audio two'.

  • Your HDRes2.cap displays perfectly on my 5:4 ratio 1280x1024 display. Looks nice.

  • Hi. The most common problem that I've seen that will cause animations to get 'stuck' is having a flaw in the logic of the event sheets somewhere.

    Usually, where it's intended to set an animation upon some state change, but not taking into account that the event will continue to trigger every tick, thus resetting it to the same frame every tick. The same could go for movement, too.

    In such a case, one needs to make sure that the event triggered only once while that state remains true.

    I can't really think of another reason at the moment.

  • The site seems nice, and it's a normal thing for good products to have fan sites with news and other content related to said product.

    That said, I have to agree with Lucid's point above. Scirra is not the product name. Construct is. Scirra is the name of the dev team, and they may very well publish other products under it. Have a look here: http://www.scirra.com/about.php

    Also, nothing's stopping them from going commercial with any of their endeavors, at which point other sites using their name might be more disagreeable. I would have a talk with them before doing such a thing, myself.

  • Hmm, 'triggers' is a bit ambiguous. Any condition->action group could be considered a trigger.

    I'll take a stab at what I think you might refer to. In many games, the player walking over a certain spot might trigger an event, or some similar thing?

    For example, a hidden trigger spot can be made by making a sprite to serve as the trigger point, setting it to be 'invisible on start', giving it a private variable 'triggered', then setting a couple of events like so:

    + player: player overlaps trigger

    + trigger: Value 'triggered' Equal to 0

    -> trigger: Set 'triggered' to 1

    -> (do stuff that only happens once, unless 'triggered' is set back to 0)

    OR... for duration effects and such:

    + player: player overlaps trigger

    + trigger: Value 'triggered' Equal to 0

    -> trigger: Set 'triggered' to 1

    -> (do stuff that only happens right when triggered)

    + trigger: Value 'triggered' Equal to 1

    -> (do stuff that keeps happening until you set 'triggered' back to 0 to reset the trigger, or perhaps 2 to make it a one-time only effect)

    Anyway, if I'm way off the mark, you may want to explain in detail what you want to achieve.

  • Hi. Simple fix.

    The way that you ordered the events, you were trying to set the frame on the digit sprites before actually creating them, so it changed all of the sprites each time. You have to pick instances of objects somehow if you don't want the actions to apply to all of the instances.

    In this case, Construct will automatically pick the 3 new sprites upon their creation, if you put the actions after that, like so:

    + System: Every 5 ticks
-> Sprite4: Set 'DamageValue' to 1+random(150)
-> System: Create object Sprite on layer 1 at (-16, -13) from ene_Baddie 's pivot point
-> System: Create object Sprite2 on layer 1 at (0, -13) from ene_Baddie 's pivot point
-> System: Create object Sprite3 on layer 1 at (16, -13) from ene_Baddie 's pivot point
-> Sprite: Set animation frame to (Sprite4.Value('DamageValue')%1000)/100+1
-> Sprite2: Set animation frame to (Sprite4.Value('DamageValue')%100)/10+1
-> Sprite3: Set animation frame to (Sprite4.Value('DamageValue')%10)/1+1
[/code:1u6u1rcd]

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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!

  • So say you had a game where conversation was between 2 people and depending what what action was taken. Would you have more than 1 Time Line?

    And if so when you came back to the fist Time Line? would it pick up where you left off?

    In other words can this be a little more dynamic?

    From what I've seen so far, I'd say that if you want conditional branches in dialogue, you'd probably have to set up multiple timelines. Then, start a new timeline at the end of each timeline, based upon the player's choice.

    Maybe the timelines could go like so:

    1 ends with a question with 2 choices

    2a continues with choice 1

    2b continues with choice 2, which ends with 3 choices

    3a ...

    3b ...

    3c ...

    Could get pretty complicated that way...

    As for just having more than one character involved, with no branching dialogue, I made just a few modifications to David's original .cap to show one way to deal with that. There are a few ways to handle that, but I chose adding a second parameter to each entry to indicate the character number that it came from. Could also use different time period names, though that might get a bit more tricky in conditions.

    I ended up creating and destroying the text object for each message with the intention of allowing multiple messages to display simultaneously, but just left it at only allowing one for now. Basically, for what I ended up with, I could have just moved the text and panel for each message. Some more changes to the events would be needed for the former option, and I've got other things to work on. Here's the .cap:

    http://dl.dropbox.com/u/5868916/Multi-M ... System.cap

  • That's very cool, David. Thanks for that example. That's much simpler than I thought it could be! I guess I should study the Timeline object, soon.

  • Great to hear, David! That will make a big difference to many users, I'm sure.

  • There are certainly many ways to do almost anything in Construct.

    If I had more than a small amount of dialogue in the game, I'd probably go for something a bit more dynamic than that. I've never used the timeline object, so I'd probably go for my usual solution of creating variables of some sort to control it.

    Since the complexity of dialogue systems in various games can differ greatly, it's hard to say how well what I'd do would fit your game, but I'd most likely load all of the dialogue into an array from a separate file. Then I'd create another array that contained the indexes of the start and end of the dialogue for each segment of the story progression. If there are more 'speakers' than one, then that would also have to contain an index for said 'speaker' with each segment.

    With that in place, one can build an 'engine' to activate, display, handle input, and deactivate dialogue, so that a function call or enable group (or whatever) could be used for dynamically handling any point in the story progression.

    I made a quick mock-up of the idea here:

    http://dl.dropbox.com/u/5868916/dialogue.cap

    It's very basic, and could very well be optimized quite a bit, but it gets the point across, I think. It doesn't handle story progression, but just displays whatever array entries you tell it to, when the global variables 'DialogBeginIndex' and 'DialogEndIndex' are set to something other than zero.

    It handles instant display of the text when the spacebar is pressed during writing in much the same way as you did, but doesn't have to have duplicate text in the event sheet, because it's stored in a variable already.

    Anyway, I'm more of a hobby programmer than a game designer. The first idea is usually not the best, in my experience, so don't be discouraged at the idea of re-writing portions of code if you come up with a better way. Maybe a mix of timeline and other variables to control things may work, too.