C-7's Forum Posts

  • I have a new devlog up about the first boss battle in my game! It's a large, projectile-firing turtle hybrid. Why not, right?

    Also, there will be a new, updated trailer coming out NEXT WEEK so be sure to check back!

  • -> On function showPages
     -> ConditionsForPage1   ::  CallFunction(GeneratePage1)
     -> ConditionsForPage2   ::  CallFunction(GeneratePage2)
-> On Enter Pressed             :: CallFunction(ShowPages)
[/code:2uy5ya2v]

Just put all of your events to show pages into its own function that you call when they press enter. Just reference whatever variables you set up in the generating functions so it shows the right stuff. No need to pause a function and wait, just make that part its own function.

  • Have you tried just making a second function that happens when the player presses enter? One function to generate, another function for the user input. That sounds like essentially what you're trying to do anyways.

  • I wouldn't think it would matter, but try turning image recompression off in your export dialog just to rule that out.

  • Oh yeah, one more thing, you don't need to use dt in "wait X seconds" events. Just put in 3--it already takes dt into account.

    I've just found that it isn't stunningly reliable to trigger things once off of variable changes. It seemed to always work before, so I'm actually not sure why that didn't work. I just knew that On collision stuff always works unless there's a framerate hiccup. I decided to just put it all under one action and let it decide from there what to do with the objects instead of doing stuff after the fact. Changing the > or = to just > also made things simpler in logic to me. Then you can just set them to "1 hit" and it'll die when you hit it. Then you don't need to worry about the 0 variable anyways.

  • Here's a screenshot of the fix:

    This way, the bricks' deaths are triggered by the collision. I also changed your greater than or equal to to just greater than. You might want it differently, but this way, they die if they're hit and have 1 health left.

  • > There's some really impressive stuff being made these days!

    >

    > Here's a shot from the cave town in Courier:

    > pretty picture

    >

    Looking atmospheric! Any ETA on when you'll put it on Steam? EA?

    It's passed Greenlight, so I'm just working my butt off to finish it. My best guess is probably April of 2016. Sooner if my game isn't a buggy mess by the end, but I've left two months at the end of development to fix things and polish it up.

  • Post your test capx so we can see what you're doing.

  • There's some really impressive stuff being made these days!

    Here's a shot from the cave town in Courier:

  • Hmm it could be the fault of so many large images. My Animations folder in Windows Explorer says I have 5,000 files (and C2 tells me I have 4,000 events). My project is an RPG, so some of that is understandable, but I also generally have smaller objects than you might in a fighting game.

    On preview with chrome closed:

    9 seconds on "Starting Preview" in C2

    29 seconds on the loading bar in Chrome.

    So it takes me 38 seconds to run a preview, but for the size of my game, that seems pretty understandable. I never get a red bar, though.

  • ultrafop Just change the preview browser in the project settings to something else. Change it to something you DO have installed.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • RTS games are notoriously difficult (the engine doesn't matter in this case). You have some benefits with C2 because pathfinding is built in, but it's a monumental task. There's seriously a ton that would need made. It makes my RPG look simple. I'm sure someone has done some small tests and such, but I haven't seen one made in C2 to my knowledge. It already has native Spriter support (literally drag the scml/scon files into C2 and voila) and someone is working on a spine plugin, however.

  • Well, you could make them unable to cross sides of the device, that way you can just measure if touch is greater or less than the midpoint. Otherwise, just compare distance from the object to the touchpoint (System>Compare two values) or pick the nearest player object to a touch instance--just remember, it'd be possible to steal a character this way.

  • It would be nice, but this is something you could easily set up on your own with events. Have a dummy emitter object, spawn your sprites in with that, and run a for each pass through them to update their states.