megatronx's Forum Posts

  • As some of you might have reed already, Nintendo partnered with biggest mobile dev company in Japan, to bring Nin Ip's to mobiles. Nintendo also talked briefly about their next NX console, which suppose to be part home console, part handheld playing mobile games. And with recent release of Nintendos html5 DK game, this made me suspect that it will have support for html5 ( as, as we know, N was talking about it a lot in the past), so possibly it could be something we all might benefit from.

    http://www.destructoid.com/nintendo-and-dena-enter-into-licensing-agreement-for-mobile-development-289157.phtml

    http://www.destructoid.com/nintendo-teases-new-nx-hardware-289161.phtml

  • [quote:2bl4rmxn]It would be awesome if Scirra made it's own custom desktop exporter. Or Monzilla made their own, google has a major tendency to ruin a lot of things.

    Ruin stuff like environment and economy, and what pisses me a lot too, they'll whole business plan is based around single direction links. If they would finally introduce bi-directional links, the problem of copyrights would exists only in video space.

    Also, all those news about exporters are very disheartening :/

  • > I'm still getting some slight jank, it's most noticeable when you jump. But my game is 256x224 scaled to screen. So it could be that a couple pixels still jank, although it's only happening on my player.

    >

    > When you update NW.js, what happens to the package.json files? Do they update as well? Because mine are apparently dated 27/01 but my new NW.js update is dated 06/03. Are they supposed to update as well?

    >

    You know, I think there is problem not related to nw with scaling up low res games.

    I have same "couple of px" problems with my project. Especially with vertical elevators.

  • I'm still getting some slight jank, it's most noticeable when you jump. But my game is 256x224 scaled to screen. So it could be that a couple pixels still jank, although it's only happening on my player.

    When you update NW.js, what happens to the package.json files? Do they update as well? Because mine are apparently dated 27/01 but my new NW.js update is dated 06/03. Are they supposed to update as well?

    You know, I think there is problem with scaling up low res games.

  • jayderyu

    TiAm

    Yes I understand that, but that doesn't mean that certain features should be in the ide from the start. Personally don't care how will they be implemented.

  • —

    Just an idea. You could spread out the processor load further by doing something like this: instead of updating all the enemies every time interval just update half one interval and the other half the next. Or you could spread it further if needed. That would reduce the amount of stalling when looping over a large number of enemies.

    That's what I did once, with displaying one massive array. It works great.

  • I agree c3 ide must support versatile custom extensions, but just wanted to share my thoughts on the subject and just communicate what's even more important.

  • If there are customizable windows, and associated actions. Then the architecture can already support the request down the road. Either by Scirra or some one else.

    Extensions are great and all, but I want the main software to function well from the get go. I'm already going trough nightmare of custom extensions in other software I'm using, and I don't C2 to be this way.

  • Don't know if this was brought up already, but some sort of simple but intuitive text editor for txt objects. For example, one in Rpg Maker was quite all right. It could also store the text automatically in a txt sheet of your choosing and remember which lines of text belong where. Also txt object could have some reprogrammed functionality from the start, such as text display and scrolling type.

  • Making large games: those lengthy, or full of features or both, is absolutely doable as long as you understand how C2 works, what does work best and what the limitations are. Plus you need a lot time and grit. I've made some insanely complicated state machines in the past, that worked 100% and along side each other. And hope to finish those currently alpha programs, but with time I've learned that keeping it simple is healthier for your project and your sanity.

    In terms of optimization, if your game is very dynamic, ( and I wander what you guys think about my way ), I'd personally would rather go with:

    Every X seconds

    For each object:

    -distance() <= xxx

    -- Set collisions ON

    -- Turn movement behaviors On

    -- set FX On

    Etc

    -Else

    -distance() >= xxx

    --Trigger once

    -- Turn movement behaviors Off

    -- Set collisions Off

    -- set FX Off

    The reason I went with Distance instead of Is on screen, is because I'd rather have the moving objects doing their thing before I see them to avoid awkward moments where you can see static object for a moment "turning itself" On.

  • State variable should do just fine

    X Is on collision

    varState = Colided

    Trigger once - Stuff + set varState to whatever

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You do not have permission to view this post

  • Being able to add curve paths during edit time (if possible dynamically be able to create paths at run time as well!) and making the sprites move along the curved paths is definitely on my wish list. Without such a functionality, its very complicated (with several trade-offs ) to build games like Zuma.

    True

  • You do not have permission to view this post

  • I tried it couple of times more on bigger levels, and its smooth as never before. Not even single jag at start of the layout. Will keep you posted though.