GeometriX's Forum Posts

  • lemo Try this on your phone: https://dl.dropboxusercontent.com/u/145 ... index.html

    The event is just System: Every tick | Compass: Set angle to Touch.Alpha-90 degrees

    Not sure why it's offset by 90 degrees, but hey, it works. I tested it with a real compass right beside and it's very consistent.

    I can read values across the range, 0-360. It sometimes lags a bit if I turn quickly, but it always finds itself after a second or two.

  • lemo, it might be interpolating the values. Personally, I haven't found an occasion where that factor is so destructive that I can't work around it, considering that its most typical usage scenario would be character movement. I'm not sure what you mean by the numbers not being "proportional", though.

    I'd hazard to guess that this lag has more to do with the fact that accelerometers/gyroscopes aren't digital devices. They're analogue (albeit tiny): there's physical motion that has to happen to determine a phone's orientation.

    Depending on your phone, the polling rate for the accelerometer might be quick or slow. I tested mine (Galaxy S3) and it takes about a second to "catch up" from 90 to 0 degrees.

    I haven't seen a phone-based compass that behaves in the way you're describing - practically instant, right? Do you have an example app that you could link to? I don't know if C2 can even access a phone's compass, but I doubt that'd be too much of a challenge for a plugin to handle.

    EDIT: Actually, I'm mistaken. Alpha does read the actual, absolute, compass heading. Not sure why I thought otherwise, but it seems to work pretty well for me.

  • Oh, cheers, good to know. I'll put together a bug report when I get a chance. This is obviously not right.

  • Replying here after I was tagged in that old thread. Not sure how helpful this'll be but this is how I do it.

    • Alpha works kind-of like a compass, it's the rotation along the Z-axis of the phone. But it's not absolute, like a real compass. It resets its heading every time the app starts up. So 0 will always mean "the phone is pointing forwards". 180 means "the phone is pointing backwards."
    • Beta is the front/back swivel of the phone. A negative value means that the phone is tilted forwards. A positive value means that it's tilted backwards.
    • Gamma is the side-to-side swivel of the phone. A negative value means that the phone is tilted to the left. A positive value means that it's tilted to the right.

    Using these values you can determine if a phone is upside-down (gamma -180), lying face-up (gamma 0), is held upright (beta 90), and so on.

    Easiest example is using a tilt forwards/backwards/left/right mechanism to control a character on the screen. To do this, you want to figure out the angle that the character will move towards. Easiest way to do this is to use Construct's angle expression Angle(X1,Y1,X2,Y2) to determine the angle from the starting point to where you want to go. In our case, the starting point will always be 0,0. You're not moving a character from an actual place on the screen, just trying to figure out which angle it should face. Its position isn't important.

    Our expression therefore becomes angle(0,0,touch.Gamma,touch.Beta). You use the gamma value as the X, and the beta value as the Y. Doing it this way you're plotting a position on an arbitrary cartesian plane based on the values you receive from the touch object.

    Super important: find an initial offset when you start your app, and add/subtract it from your touch values when using them. If the player starts a game with their phone slightly tilted up, or entirely upside-down (maybe they're lying down), you need to take this into account. The touch values assume a phone is lying completely flat, and the whole thing is very twitchy. Best not to use the touch values directly for player input: smooth them out a bit first.

  • I have the same problem. It's always a smart banner the first time it loads, thereafter it's correctly sized. Haven't found a way to fix it.

  • I guess it comes down to "I'm doing what I perceive to be right, based on the level design language, but it just doesn't feel right." Sure, I could get used to the controls, but they don't feel correct right off the bat, and that'll alienate a lot of players. You must feel that too, otherwise you wouldn't have asked for input about the controls. You get that it feels a bit off. Losing players early to a game that just doesn't feel quite right is bad - these players won't say "this game sucks", or anything that's even close to helpful for you, they'll simply stop playing it.

    That's what happened to me. I got to level two, died in one of the fires, and then felt "eh, I'm done".

    With regards to the turnaround animation, I can't get it to fire unless I hold down both buttons at the same time. I don't want a stop and turn, I want a quick turn that feels fluid and doesn't kill all momentum. You have that animation in there, it's like the Prince of Persia animation, but it doesn't trigger when I'd expect it to.

  • I think the controls are good, but the initial level design doesn't complement them well.

    If you look at twitch platformers like Super Meat Boy and Mario, that have far more precise controls at the expense of animation, their levels are structured in a similar way to yours. It's about the perfect jump, solid timing, fighting against the level constantly until you get it right.

    Whereas PoP, Flashback, and other platformers that tend to be more focused on exploration (returning to areas, scoping out an area before tackling it), like your game, tend to be a bit more forgiving, especially at first, in their level design. I'm not saying that level traversal isn't a challenge in those games, but they ease you into it. Your game seems to have design that implies the game is a twitch platformer, when the animations say otherwise. Like there are two aspects at odds with each other.

    That's not to say that it can't work, but one or both aspects will need some tweaking. I'd say definitely speed up some of the animations, as a starting point, and then look at making your level design a bit looser, especially with the head-bumping-on-the-ceiling stuff.

    I'd also strongly recommend looking into adding a mantle/pull-up animation. Having to jump or "bounce" onto higher platforms is a gameplay mechanic synonymous with twitch platformers, and doing so here doesn't fit the pace very well.

    Also, the change direction animation requires a strange order of keypresses to work properly. I don't think it's right to expect the player to hold in the reverse direction that they're running in. Players will expect to press one direction or the other, not have both keys pressed down at the same time.

    Oh, and if you plan on taking this game any further, you might want to reconsider the name.

    By the the way, I love that wall-stopping animation.

  • To second volkiller's suggestion, yeah, you should really be using global layers for all UI elements. They're far easier to maintain for projects designed like yours.

  • I'd like C3 to be treated as an extension of C2. Keep C2 as a tool for education and possible free (or cheap) distribution, and make C3 the advanced version with neat things like better exporting, interface improvements, modularity support, improved behaviours, better drawing tools (I know, I know, but people keep asking for this), improved collision detection, a keyframe/timeline editor, better lighting, and all those sorts of lovely things.

    The idea here being that C2 files can be opened in C3 (possibly with a once-off conversion or the like), which would encourage existing users to migrate to C3 when the time is right for them, without pissing off those customers who don't want to feel left out in the cold after spending money on C2. This would also serve to not invalidate the huge load of tutorials, manual entries, and forum topics that have formed over the years, not to mention the development that has gone into the software.

  • This always comes up, and once you get used to working around it, it's better how it is currently.

    One way to avoid this is to put all variable clicking UI elements in one family with a boolean "canClick" or whatever. Then just change that value as needed, and check for it in your On Click events.

    Alternatively, if you're hiding items, just check on their visible status in the On Click events.

  • Nope. One licence per person. You can use one licence on multiple PCs, though, (like your home desktop, a laptop, and a work PC) as long as there's a single person using the licence at any one time.

    https://www.scirra.com/store/construct- ... license-31

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Wow, this is very impressive. I got stuck on the little plinth where the treasure chest was and died, but for the few minutes of playtime I did spend with it, I enjoyed it immensely.

    I don't have many critiques, other than perhaps the intro wore on a little too long. I was left looking at the mountain slowly rising up as the camera approached it, not really sure if I was meant to skip ahead or if more was coming. I've seen other games speed up those sorts of sequences once the text and everything is done. Or perhaps give the player an option to speed things up at this point.

    Praise-wise, there's plenty:

    • The controls are very tight - they feel incredibly responsive and movement is solid.
    • The humour is great, I love the sarcastic approach - that well being a save point actually made me laugh out loud.
    • The way that gameplay mechanisms are introduced is spot-on - I'm not sure how that beginning bit fits into the whole game but it didn't feel like a tutorial, even though it was one.
    • The music is very well suited - did you make that yourself?
    • The pixel rounding initially felt a bit irritating, but I quickly got what you were trying to achieve with it. I've played a lot of RPGs on the SNES, and this looks perfect, right down to the twitchy pixels.

    Do you have any plans to expand the two-character thing? Maybe it was still to come in the demo, as I didn't play very much, but I can imagine character-switching or true two-player support could have some interesting implications.

    Otherwise, great work! I hope you're going to go public with this and see what the rest of the world thinks of it (and throws their money at you).

  • Admob works fine. Only issue is with Intel XDK on iOS, banners don't show in fullscreen mode with orientation locked to landscape. But that's supposedly being worked on.

  • I've been playing with this plugin a bit but I'm scratching my head at something I'd think is quite simple: I can import an OBJ and its accompanying MTL file that I exported from 3DS Max, but I can't seem to find a way to make the texture work. Then I see that it's better to import a JS file. Is it possible to use OBJs and MTLs together, or how do I go about turning my OBJ into a JS file?

  • Oh wow, these are massive improvements! Nice going QuaziGNRLnose, you're really on the ball with delivering what people have asked for (and so much more). Setting up a simple 3D side-scrolling or top-down game is really easy now.

    Thanks for your hard work!