Refeuh's Forum Posts

  • BasicTribe : yeah well, sorry for not knowing all the posts from all the users from the past months... Only trying to help ; I'm not wasting time re-creating a project for a problem I'm not facing.

    This thread has gone full circles too many times ; I'm done for now on this one.

  • when i make a simple Capx with 15 small objects on layer and the framerate is going down

    It sounds like it's simple enough to reproduce easily ; please submit a sample .capx for the interested parties to investigate ! I too would like to know how it's possible to bring the framerate down with only a handful of objects (unless they're all supermassive blended textures on a very old device, which would kill the fillrate and pixel units anyway, regardless of the technology)

  • Depends on your budget ; people have been creating games for decades on computers that were less powerful than a recent mobile phone. It's only a matter of scale and comfort.

    If you can, go for multiple monitors straight from the beginning ; all creative activities (art, design, programming, etc.) benefit a lot from multiple monitors in terms of productivity (develop on one screen, have the documentation opened on another, see the game running on a third, etc.)

  • Ignoring all reasons to ask for native exporters, both good and bad ones, asking for something doesn't affect its feasibility. Considering the teams behind the 3rd party exporters and wrappers, it's still not realistic to achieve better results with less people, with less resources, in less time, for less money, while maintaining sensible timescales and attractive pricetag.

  • Though you could "repeat" 1 time ; everything happens only once. That defeats a bit the point of "repeating", but from a logic point of view that should just work

  • With high-res resources, you probably won't know what you actually need until you have most of the content in place - my advice would be to :

    • keep very high-res or vector graphics in your art asset repo in parallel of the game
    • during the level design phase, use 1:1 mid-res graphics ; this gives average quality/memory for quick iterations
    • when you have most of the content in place for one given scene, do a quality/memory balancing pass and apply "per-entity" logic : because this entity will scale up you might a hi-res image for it, while this one remains small so might go with even lower res, etc.

    It's hard to find a common rule (e.g. "downscale everything 50%") that fits everything

  • It seems to be a mix of things that keep coming back ; easier exporting processes and deployment pipelines, performance, platform-specific features, etc.

    Most of the proposed "solutions" don't actually fix the problems (cpu/gpu optims when gpu/cpu limited, etc.) or are unrealistic (take ownership of all the device specific exporters, etc.).

    I think jayderyu made an interesting list of ideas to improve the creation and authoring process in a previous post ; that's the kind of things that would make a difference and that I'd rather see in future updates.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • And here is the demo !

    I've integrated the feedback of a first focus group, which should make the overall gameplay experience better.

    An up-to-date browser and a gamepad are recommended ; typically Chrome + 360/xbo controller

    The game mostly lacks options (visuals, keys, audio, etc.) and content (more areas, boss fights, etc.) but all the mechanics are in place and there's enough to do in the demo to last 1 to 2 hours for a first playthrough.

    https://dl.dropboxusercontent.com/u/526 ... index.html

    Please do let me know what you think ! There's also an online form/survey accessible from the game menu to submit detailed feedback

  • [quote:2nt1w883]so i suggest you hire people and programmers to develop it and spend some money

    i will promise you will get so much more then now

    And start competing with bigger products that have already poured $millions to get where they are ? That's terrible risk management, business strategy and financial advice.

    The differentiation factor of C2 is that it's more focused and easier to use ; but also obviously, as a result, more limited in certain areas. If it loses this differentiation factor, it dies.

  • Vote for something that cannot realistically happen ? No, thanks.

    I think people massively under-estimate the cost (or time, "same" thing) to develop these "native" exporters ; plus the on-going maintenance overhead as platforms keep changing ; plus the fact that in a given family devices themselves behave differently (e.g. many sub-categories of Android devices, etc.)

    If people like the Construct ease-of-use but want native tech for whatever reason, the ideal pipeline today is :

    • develop prototype in C2 ; this way all the gameplay-related risks can be mitigated
    • use a platform specific tool/engine/framework to develop the full game ; this way all the technical-related risks can be mitigated

    Yes that's more work, yes that's more complicated, yes that takes longer.

    But "easy creation" + "complex product" + "cross-platform" is a risky mix.

  • [quote:1mg7xub3]ashley just bring excuse because he can not make an engine like unity

    If you seriously believe any single developer in the world can compete with any advanced technology that's been around for a decade and that's been developed and maintained by dozens of specialists, you are badly mistaken -

    There's an order of magnitude of differences, people need to manage their expectations.

    Construct is not about competing with Unity ; it's about providing a more focused solution that fits well certain applications. As more focused solution, it's also simpler to learn, easier to use, more limited, less expensive.

  • Ignoring the native/non-native performance debate for a bit -

    Reading some posts, it seems some users don't see HTML5 as the way forward, want more functionalities or plugins, want 3D, want more control/scripting, want platform-specific exporters - why not use Unity ? Honest question, really. Yes the learning curve is steeper, but that's a necessity of the increased complexity.

    Tools and programming languages, none of them is "better" than the others : they all exist because they serve a purpose ; the moment a tool or language stops being useful, it dies naturally.

    Now for those wanting to stick with HTML5 but complaining about the 3rd party exporters approach - all these exporters/wrappers are developed and maintained by medium to large teams (NW.js has half-a-dozen of regular active contributors, plus the occasional pull request ; Crosswalk has many branches and up to hundreds of contributors, Intel XDK has... well, Intel, etc.). Realistically, are we expecting Scirra's team to do better, in less time, with less resources, then all these people together ? All of that while maintaining a low price-tag for the Construct product ?

    I'm not saying it's all great ; yes there are issues, but every technology has issues and it's about being realistic with expectations.

  • Jayjay Thanks for the detailed reply I wasn't trying to shut down the conversation, only trying to understand and propose some elements of answers to other previous posts as well.

    Though going back to performance issues, there are examples of moderately complex games performing reasonably well ; so I guess you'll agree with me that if something doesn't perform well, there has to be a difference of either scope, platform or use.

    Also I think we can agree we have 3 major layers regarding performance : the hardware (low level), the engine (abstraction, mid level), the application (gameplay logic, top level). Ignoring all possible preconceptions about blaming the game or the engine, were you able to identify the bottlenecks in your case ? Maybe it is the engine, e.g. not doing well with resource management and hammering the memory inefficiently ; maybe it is the hardware, e.g. dealing very badly with some scenarios, etc.

    So really I'm not pointing fingers specifically at the game logic, all I'm saying is that it'd be interesting (for us) to know what caused the problems. Maybe it would possible to make these more visible to the users through the tools.

    [quote:3la4fhto]wrappers don't just add a bit of bloat, but they are middleware unlike...

    Fair point ! Though we don't necessarily have to use Adobe, Oracle or Microsoft tools to create content for their platforms. I guess one of the issues is that nobody really "owns" HTML5, and big companies are stiring things in multiple directions (google v8, ms typescript, etc.) and it's not yet a fully mature technology

    [quote:3la4fhto]Construct 2 should live up to its advertisements...

    Isn't that true for all tools and platforms ? Maybe what C2 would need would be "platform presets" ; e.g. targetting iPad2 ? fine, let's disable all fancy stuff that we know won't run well. And so on.

  • Hi -

    1. What's wrong the already existing ping-pong mode ?

    2. Why not duplicate the animation and change only the last few frames ? Duplicate images won't be stored multiple times. This makes the animations much easier to visualise

  • Using HTML5 wrappers bloats the size of the project

    It does - but no more than, say, deploying a software made in Java (requires JRE), C# (requires .NET), Flash (requires Adobe player), Unity web (requires Unity webplayer), etc. Even pure C++ has some dependencies (requires CRT libs, typically the msvcrt.dll variants people get when installing games on Windows). People install all these without complaining.

    I don't see this as a very significant point when choosing a technology.

    [quote:1b1z6li2]bugs that wouldn't appear in an HTML5 game normally for unexplained reasons

    Pretty much all the bugs are down to standard compatibility and device specificities. Because platform "blah" doesn't implement all things defined by the webgl standards properly, the "exported" app doesn't behave perfectly. Because device "thingy" takes some "shortcuts" or doesn't have some hardware, the exported app doesn't behave perfectly.

    These don't go away with native solutions. Actually it is worse, which is why cross-platform engines usually end-up with one engine to maintain per platform they want to support, while trying to abstract all the common features as best as possible.

    In both situations, using wrapped portable or native specific, the only way to ensure the end result behaves as expected is to design the game knowing from the beginning which platform(s) to target ; because the tools / engines / frameworks / whatever is used, will need to be used differently.

    For example one shouldn't create a game and THEN decide to target the WiiU and the iPad2. These have so strong (and conflicting !) requirements they need to be factored in from the beginning (especially regarding art assets and use of alpha blending). Using native solutions doesn't remove this constraint. Just an example.