Refeuh's Forum Posts

  • Scroll to the mid-point between the two players (+/- offset you want to make it easier to look ahead in one particular direction, for example), and then constrain the players to the visible area (simple rectangle clipping) so that they can't leave the screen

    Basically, you don't scroll to a player in particular ; you compute the area you want to frame, based on the position of the 2 players, and you prevent the players from going beyond that area

  • Just to add to the discussion -

    "Old-style" performance timers have also become less and less accurate and reliable due to more recently designed CPUs scaling their internal clocks dynamically (downclocking or upclocking, on a per-core basis, up to the max frequency they are sold for). Therefore you have to query the system's frequency very regularly to try to keep in sync, and you're never guaranteed the clock speed you got a few ms ago is still valid and/or is a good approximate for the core that executes your instruction.

    Low-level high resolution timers are definitely the most reliable solution. This is true for desktop computers, but also consoles and mobiles.

    As for fast moving objects and collisions ; it's much easier to make a consistent physics implementation at a stable fps (which is why certain physics modules of game engines usually run at a different constant frequency, e.g. 15 or 30 fps), and use continuous collision detections with swept surfaces/volumes specifically for objects that require it.

  • Niiice I'm really glad to see some regular updates on this ! Being a megatroidvania-fan, this seems Epic !

  • Aphrodite

    Interesting question -

    While it is possible to include even sheets in conditional statements, I would be tempted to think that this is actually resolved at export time, and that functions are either defined or not, but never generated or attached dynamically. I might be totally wrong as well, 'just a guess

    Btw I find it amusing that we have that many users well-versed in the art of programming C2 claims "no programming required" (which I personally find a bit misleading, the logic of event sheets is similar to light/gameplay-programming), yet it attracts people with a technical background ! Mostly for the productivity when creating small applications or testing prototypes, I guess.

  • frcol

    Sorry for the delay ! 'Hope this is still useful -

    The goal being to maximise reusability, I see mostly 2 scenarios. I work with the assumption that all levels follow roughly the same structure in terms of logic, but require some amount of customisation for gameplay events. I've highlighted the difference between the two approaches, where dynamically generating function names can be useful

    1. Lots of levels (layouts), each pointing to a specific event sheet

    The shareable bits are all demoted into a shared event sheet, which is included in all the levels event sheets. For a multiplayer game, the structure becomes something like (example) :

    Shared ES :

    • Common (host/peer) init
    • Host-specific init (creation of peer objects, spawn and scale enemies to numbers of players, etc.)
    • Host-specific entity management (collision, behaviours, damage, etc.)
    • Host-specific gameplay triggers & callbacks (e.g. "Call PlayersDead()" when all players are dead)
    • Peer-specific init
    • Peer-specific entity management (reacting to objects being created, etc.)
    • Peer message processing
    • Common (host/peer) logic, if any

    Level ES

    • Set level options : enemy types, scaling of spawners, etc. whatever is relevant to the gameplay and has been factored out
    • Include the shared ES
    • Implement the logic for the triggers : "on PlayersDead()" (some levels might force you to restart from the beginning, some might let you continue where you died, etc.)

    Here, we always call the same functions, and let the level-specific ES provide the implementation

    2. Lots of levels (layouts), each pointing to the same event sheet

    We still want to provide custom implementation for specific triggers on a per level basis, but the same event sheet is used as entry points by all the levels. We can't call the same trigger functions anymore, but we can generate names dynamically :

    Main ES :

    • Set level options : enemy types, scaling of spawners, etc. whatever is relevant to the gameplay that can be tweaked
    • Common (host/peer) init
    • Host-specific init (creation of peer objects, spawn and scale enemies to numbers of players, etc.)
    • Host-specific entity management (collision, behaviours, damage, etc.)
    • Host-specific gameplay triggers & callbacks (e.g. "Call LayoutName & "_PlayersDead()"" when all players are dead)
    • Peer-specific init
    • Peer-specific entity management (reacting to objects being created, etc.)
    • Peer message processing
    • Common (host/peer) logic, if any
    • Implement the logic for the triggers, using specific layout name : "on DeathStar_PlayersDead()", "on StarField_PlayersDead()" etc/ (some levels might force you to restart from the beginning, some might let you continue where you died, etc.)

  • Thanks for considering my questions in the discussion ! I am aware of general multiplayer concepts (architecture, security, not trusting the clients, etc.) but I have little hands-on experience of the server-side technologies, and setting up servers in general. That was very informative

  • Indeed -

    I personally find reflection to be most useful for tools development, where runtime performance is usually less of an issue ; being able to expose engine modules and game components for abstract tools to interface with is always very practical.

    Nowadays, that's pretty much the direction everybody is going : Entity/Systems component-based game framework, remote tools with reflection (networked if possible, to connect to consoles and mobiles), unified cross-platform mid-layer engine, and platform-specific low-level modules for performance and unique features.

    Stepping back a bit, I'm mostly after a way to make something reasonably reusable and flexible ; I'm no web or JavaScript expert, but I'm fairly hopeful I'll have enough optimisation to do at game-logic level before I start to hit any actual language bottleneck !

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks for the input ! I like the idea of registering callbacks, it's a good alternative to not being able to check if functions exist, I'll go with that

  • Greetings !

    I'm wondering if there's a way to check that a function exists, before calling it Basically I'm after the C2-equivalent for the JavaScript "if (typeof yourFunctionName == 'function')"

    I'm creating a set of generic event sheets to handle the logic of all my levels, and I have a callback-like mechanism as well as custom-triggers using dynamically generated function names, e.g. "Call LayoutName & "_EntitiesDestroyed"(), etc.

    Some levels will want to do something on "xxx_EntitiesDestroyed", and some won't, depending on the gameplay of that specific layout. This solution lets me implement bits of logic only for when it matters ; but has the disadvantage of generating some invalid function calls on level that don't need this trigger.

    This a literally no impact on the game logic or performance, but doesn't look very neat in the JavaScript console.

    Thoughts ?

  • ome6a1717

    I was thinking something along the line of :

    for each ordered (ascending)

    expression : distance^2 , i.e. (x1-x2)*(x1-x2) + (y1-y2)*(y1-y2)

    using "Stop loop" as soon as the loop entity is beyond a threshold distance (meaning all other entities after the one in the current iteration are also beyond that value, since the loop is ordered)

    I'm not sure you actually gain anything, but at least you rely on the built-in sorting of the "for each ordered", which is likely to be a quick-sort of some kind, and would be faster that using distance() on ALL the entities

    You can also run that at a capped framerate below the actual fps, a few hertz would be sufficient to enable/disable entities

  • Greetings !

    [quote:bp0f3ipg]what are the main elements that consume performance in mobile?

    Unfortunately this varies A LOT depending on the make and model ; it is not unusual to have mobile devices of the same "family" being completely different internally from an architecture point of view.

    On some platforms, memory reads are very expensive, therefore it's better to have less texture reads and more interpolator work done in the shaders. On some other platforms, it's exactly the opposite, where pixel units perform very badly but memory is fast, in which case you want more texture reads and less load on the interpolator. Typically optimising for one set of devices is counter-productive to all the other ones.

    Same with alpha blending, which can be a killer on many devices. Pretty much the same can be said about every feature :/ Which is why developing for mobiles is a pain... For "big" games, each category of devices ends up being its own platform port.

    A benchmark would need to test a bit of everything, but look mostly at memory (loading lots of resources), blending (overlapping alpha-enabled sprites), fillrate and overdraws, and shaders.

    A couple of links for a general performance overview :

    androidbenchmark.net

    iphonebenchmark.net

    These are quite reliable and are useful to check in which "band" a given device is.

    'Hope that helps.

  • Tylermon

    Fair point ! Though I think it's important to pick one target/platform and get it to work as best as possible in order to maximise the productivity of the game creators while remaining realistic with what Scirra developers can do.

    Having to support multiple underlying native engines certainly wouldn't help with that, it's an order of magnitude higher in terms of workload just to maintain a small collection of platforms and it makes the abstraction of certain features much more complicated, if possible at all. Therefore in my opinion continuing to focus on HTML5 would be the smart thing to do, letting big companies with much more resources and man-power ensure HTML5 gets better and better over time.

    As end-users of these engines and game creators, "we" don't really care about the practicality of the engine development, in the end, we just pick the best solution for our requirements that fits in our budget when the time comes. But I see in C2/3 a great tool to quickly author decent applications, using a reasonably cross-platform-ish technology ; if I'd want anything else personally I'd just go back to traditional programming because there already are development frameworks and tools that expose more. I also know it would take more time to create simple things. 'Just my point of view !

  • "Native exporters" (? it's native, or it's exported, but exporting/building native from abstracted...) keeps coming back, yet we know it means multiple underlying engines, which is not practical.

    That completely defeats the point of targeting a cross-platform technology like HTML5 and would be the end of Construct. There are other engines that do it ; so the real question is, should C3 try to compete with these at the risk of becoming a poor-quality clone, or continue to become THE solution for cross-platform HTML5 ? The later seems more unique and more interesting to me.

    On the subject (remove white spaces, 'can't post URLs...) : https:// forum/what-you-want-in-c2-for-2015_p870156? #p870156

    by Ashley

  • [quote:25jvpyb0]i2 & i31 MUST be played at the same time

    They cannot be played at the same time on the SAME entity, which is what your conditions are checking ; you're asking the system to pick entities that play both i2 AND i31, which is none, not entities that play i2 and entities that play i31 as separate sets.

    Check the link on the previous page about events, conditions and picking.

    (I can't open .capx either, 'still on r190)

  • Also, don't do "for each... distance-check" ; try to see if you can use the built-in sorting and distance-based sorting functionalities of C2. These are likely to run a quick-sort on the squared distance under the hood, which will save you a lot of computations and expensive square-roots. I haven't checked, 'just a guess really.