CaptainOblivious's Forum Posts

  • I've been away for a long time, off studying to be a 3D and digital artist. All the while, I've been reading the Scirra blog posts and supporting the project when licences went on sale. I'm very interested in the direction this project has taken.

    I'm curious about the current state and future plans of incorporating 3D objects and animations into Construct 2. Searching the forums reveals some clever users have piggybacked various ways of rendering corridors and sprites in space, but these do not currently suit my needs. I'm not looking for a 3D worldspace, but something more like the early mesh experiments from Construct Classic - the ability to import mesh and textures, light them, call their animations and render them into the 2D canvas. The inability to do this is currently my only reason for not building a project in Construct.

    I'm also well aware how tall of an order this is to request.

    So, did I miss a discussion elsewhere in the forums about this? Is this feature planned for sometime in Construct's future? How could I help make it a reality?

    Thank you for reading.

  • This $&!# is bananas. B, a-n-a-n-a-s.

  • As far as your enemy waves thing, I've been (slowly) putting together an update to my Starfox project that addresses this very thing. Please stay tuned.

  • Do an MS paint doodle to show us kinda what you want. I have tomorrow off and might be able to lend some small help.

  • It may just be my specific project allowed for this, but I had the gall and patience to force my animation frames on Construct one-at-a-time. Ended up being a good thing, as I am able to now throttle my animation "speeds" according to any number of factors now.

    But yes I agree - Ash, please make the animation system, a substantial main feature of the project, a higher priority than it currently is to fix/work/finish.

  • Many of the animation functions are incomplete. What I've done to get around common problems is to use object variable instead of animation name functions, and in certain situations adding the "Set Animation Frame to 1" condition as (opposed to MMF) animations are meant to be contiguous in Construct (switching animations retains animation frame number, currently causing problems when switching to animations with differing frame counts).

    Try doing that, and report back.

  • [quote:3kjcpvrs]There seems to be lots of rotate angle actions but none that rotate an angle towards an angle

    Wait, er.. what? How do you mean?

  • Do you mean something along the lines of the 2D Zelda games?

    "Big Layout" is by far the most intensive way of doing this, and it's not elegant. I have an idea that uses individual layouts.. I can work on it when I get off work late tonight.

    Can anybody tell me if the Canvas object can grab the screen?

  • A .. TERRIFYING .. terrorist?

    <img src="http://i87.photobucket.com/albums/k132/ladyfox17/Achmed.jpg">

  • If you mix an object that has platform movement with another object without platform movement in the same family, the system-level actions regarding platform movement will not be accessible from that family. Because events for families affect all objects within, only the controls shared by all objects are usable.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I understand where this confusion is coming from. The application properties, among other things, does seem kinda hidden away now that I think about it. At least compared to MMF where most things are menu-driven, Construct may be a little daunting at first as it often requires the user physically navigate to an option whilst not providing a traditional means of finding it (This has been my complaint about "Ribbon" systems also seen in Office products recently).

    I guess the best advice I can give is don't be afraid to explore.

  • Allow me to see if I can explain this to your liking. I'm terrible at these things, so let me know if I leave something out...

    The detector method here is really only used in a visual sense. In fact, there is only one detector and its sole purpose is to create the base XY of the character sprite. Many 2D games use this to create seamless detection (similarly, SMB1 used 8x8 box math). In modern game engines with advanced collision detection (Contruct's per-pixel) it nearly becomes a necessity as animation frames cause the intended surfaces to constantly change. The character sprite is then placed on top of it and does not affect the world movement collisions. The times when character sprite collision is useful is, say, when the player encounters an enemy or dodges a bullet.

    This system is helpful in the type of game you wish to create if only because you wish to add jumping. If your character sprite was the sole arbiter of world collisions, jumping would interact with the world and cause a number of game-breaking troubles. So I give the detector a 4-direction movement, which directly controls its associated character sprite. I then give the character sprite a gimped platform movement to allow jumping. This is what programmers call 'overloading,' but I guess we're using the term rather loosely here.

    Which brings us to your first question:

    [quote:a8wlgodc]"Sprite[Platform].VectorY equal to 0" Why/Where?

    Because we are using two movement behaviors and forcing one to be directed by the other, we run into a few immediate problems. First, both are controlled by the player's input. Second, the platform movement will forever be "falling" even as it is repositioned each frame. Because all we want the platform movement for is its jumping ability, we must then turn all other functions OFF. This is done not only in the behavior's default variables, but also selectively at run time. And here's why.

    We are already always setting the character's X coordinate to the detector's X to mirror its left/right movement. We also need to mirror its Y, but not when jumping. Therefore my solution is to turn the platform movement's gravity on and off.

    //WHILE THE GRAVITY IS TURNED OFF (player not jumping), MIRROR THE DETECTOR'S VERTICAL MOTION.
    System: 0 Sprite[Platform].Gravity Equal to 0
    

    SpriteSet Y to Detector 0 .Y

    //WHEN JUMPING, TURN THE GRAVITY BACK ON.

    MouseKeyboard: 7 On "Jump" pressed

    SpriteSet gravity to 1500

    //WHEN THE JUMP FINISHES (character sprite comes to a rest on our detector, i.e. its vertical motion [vector Y] equals zero), TURN GRAVITY BACK OFF TO AGAIN HONOR DETECTOR'S VERTICAL MOTION.

    System: 0 Sprite[Platform].VectorY Equal to 0

    SpriteSet gravity to 0[/code:a8wlgodc]

    As to where this is located, it's in the wizard under the System object. The system object can access any other object's system-level functions via "Compare" and "Evaluate," among others. Please take the time to look over what system-level functions different objects have. It opens up a whole new world as you begin to realize you can create events using mathematical comparisons instead of the visual product on the screen.

    Also, it's faster. Sure you could use 15 box objects as detectors, but if you know what purpose those detectors serve you can compare a value mathematically prior to the screen draw instead of after it has already happened. For instance, imagine you keep a detector that always sits 15 pixels to a sprite's right. Instead of "Detector collided with Enemy during previous frame," you could compare it using the system object as "Enemy's X coordinate is equal to (Sprite's X + 15)."

    [quote:a8wlgodc]"On "Jump" pressed"

    In the application properties is the default control sheet, where in this case the control named "Jump" is set to the Shift key. In the events, Construct translates the input's given name "Jump" as whatever key it is set to. This is because "Jump" IS a value, and it stands in place for yet another value. You may create any control you wish and you could use its name in your events.

    [quote:a8wlgodc]".Height/2"

    This is not something you'd generally be concerned with. I wanted to create a ceiling, but I could not use a solid object. So I force my detector to stay at the bottom of the box object representing the sky. The box object by default places a hotspot in the dead center of itself, so I use a little bit of math to ensure no matter what size you make that box Construct will always know its lowest point and stop the detector from moving past it. It goes as such:

    The Detector's Y (vertical) coordinate is less than (above, since 0 is at the top of the screen) the Box's hotspot (Y); So, reset Detector's Y to Box's hotspot PLUS (lowered by) half of its height (the remaining distance between the hotspot in the middle and its own bottom edge).[/code:a8wlgodc]
    
    It is a quick and dirty implementation to show the basic concept.  I'm sure somebody here can provide a more elegant approach to it.
    
    So, does that help you at all?  Did I leave anything out?
  • I know what the "customization" reference means. He wants to be able to have certain objects run independent of the time scale.

  • Yeah, I like that idea. Sure wouldn't hurt to have application-level control of texture filtering. Linear, Bi, Tri...

  • I can't imagine it would be easy in Construct to do what you are asking it to do. And besides, it sounds like all the time you'd spend coding that spunk could be better used for, you know, learning how to play better.