Refeuh's Forum Posts

  • Some details here :

    www DOT scirra DOT com/tutorials/577/construct-2s-export-time-optimisations

    (tss, I can't post links apparently, and I don't know why it doesn't take it as plain text instead of clickable...)

  • GPU details are available to registered developers ; which unfortunately excludes hobbyists and most sole/indie programmers.

    Maybe check the DirectX SDK docs, they're usually full of general "good advice" and up-to-date "best practices" when it comes to managing graphics resources. Obviously it doesn't cover engine specifics (for example the padding here already mentioned by Ashley), but it gives some understanding of the inner working.

    Though that's only true on PC... For mobile chips, good luck understanding anything at all ; between the Android and Apple, the PowerVR and whatnot, they're all different even across the same family.

  • Hi !

    it's a very general question - I won't provide a specific answer, but some guidelines depending on your scenario.

    If by "all the scores" you mean the scores of the players in that session, the host should have all the relevant information. The ending screen with the scores is then just a special scene with no gameplay and very simple logic for limited interactions

    If by "all the scores" you mean the scores of all the players including previous and other sessions as well, what you need is an online leaderboard. There are some good tutorials about this, but roughly you'll need a simple database hosted and a basic server and a connection between your game host and the shared leaderboard to look up the top scores

    'hope that helps !

  • Fair statement, and I don't deny it's a sensible request, but I think both points of view can be valid. In the end it's all about what features people think are or are not part of a "default" behaviour. Which is obviously very subjective.

    Continuing with the platformer example and the functionalities mentioned previously, many games these days have ledges, ladders, double-jump, etc. Does that mean they should be included in the default movement behaviour ? I don't know ; and I don't think there's a black/white answer to this. There's a trade-off, and a balance to find between components doing too little/too much and the amount of "glue" logic the developer needs to implement.

    My worry would be to end up with "monolith" components that try to do too much and become hard to customise every time your scenario doesn't fit nicely in the expected use-cases. If I was designing the underlying modules, I think I'd try to make the "slope/sliding" movement logic bit a separate behaviour (purely reactive, unlike input>movement) that you can add, or not, to the entities. That'd avoid unnecessary coupling in scenarios where this features is not required.

  • "My personal issue with 8 direction is it rotates sprites"

    This is actually a parameter on the behaviour ; it can be disabled, or set to preset values (smooth, 45 or 90deg. angles)

    As for the request itself, my feeling is that behaviours and components should remain as generic as possible, letting the end-user achieve the desired results with a bit of custom logic where necessary. Anything beyond this becomes too specific or too convoluted to be practical.

    Typically in a game, there will be surfaces that can have wall-slide, and some that don't ; ledges you can grab, and some you can't ; some areas that cause slipping/sliding (ice, etc.), and some that don't. Etc. We don't want behaviour parameters for each possible scenario, that would be clunky, and would imply coupling between concepts that need to remain separate (e.g. character movement <> environment mark-up).

    Can you re-create Metroid, Castlevania, Mario, Megaman II and Zelda II, all 2D side-view platformers, with the *same* player behaviour ? Hardly, because each of these have different requirements and work in different environments. You don't want a player behaviour that handles "everything" ; you want a flexible base you can customise to your needs, and that's what movement behaviours are.

  • I would second Tokinsom ; I really think C2 should focus on the game development process, i.e. the integration of resources and the ease of use to write behaviours, nothing more.

    Most of what you are asking for can easily be done already very simply, and providing built-in behaviours for these would be too restrictive for other use cases.

    What if I need a button with 3 states ? 2 states with a delay when switching ? etc. All these variants are impossible to implement as default features, and are much better done with a very simple bit of custom logic and events

    Also, any kind of resource *authoring* should happen outside of C2. There's plenty of options and software to author sprites, images, animations, etc. already ; C2 doesn't need to try to compete with these specialised tools, it's wasted effort and it's budget that doesn't go into the game "making" module itself. It should focus on resource integration and productivity of writing game logic.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well... in the end a tool is just a tool, and there's always a balance to find between genericity+flexibility and productivity+ease-of-use.

    The C2 solution to simple multiplayer is quite elegant ; it's functional and it works easily. Obviously the design choices in terms of technologies and architecture mean it won't be suitable for every project (esp. on the security side due to the host/peer approach), but it's good enough for the kind of games you would expect to do with such a high-level tool.

    Part of good development practices is to choose the right tool for the right tasks. If C2 is not suitable for your project, or if you end up fighting the existing functionalities rather than using them, maybe a different tool would be more appropriate.

    There's always the possibility of trying to run your own match-making, signalling, routing, etc. but if the goal is to make a game and not create new technologies, and would suggest working your design around the existing limitations to keep focusing on high-productivity.

  • Just a small contribution -

    I don't think there's a solution, because there's no actual problem. That's just the way Internet works at the moment, and it's a big mess.

    The "actual" solution will be finishing the transition to IPv6 which will remove the need for NAT and NAT traversal. But that's not going to happen any time soon.

    For now, both developers and end-users need some level of understanding of networking technologies, to work around the limitations and be pragmatic to find suitable and acceptable options.

    Some platforms or big developers make it seem easier by solving some of the problems via their infrastructure, but in the end making a small online multiplayer game remains difficult

  • In your situation, you cannot rely on the local webstorage, but it should be possible to "serialise" the important states and data of your game session and store the info in a shared location (remote database, etc.).

    Possibly doable, but certainly not trivial, and probably a sizeable amount of work to get to work right.

    Maybe you can design your game around this limitation, and make the "save" data minimal and easy to manage

    In the current state of things, and given the philosophy of the framework, I don't think there's an easy solution to networking multiplayer saves. Maybe someone will prove me wrong, but it sounds like you'd need at least a database, some server logic layers with php/ajax, some custom load/save mechanism, etc. It would be convoluted, and you would lose the benefits of using C2, i.e. the high productivity for simple games.

  • The whole networking in C2 is built around the idea of using a signalling server to connect peers together in rooms/sessions. You don't connect directly and specifically to a host IP ; as such, there is no exposed support for a typical closed LAN infrastructure where a player would choose to be the host and others would connect to it via its local address.

    Nevertheless, you still have options ; you can run a signalling server locally and do some extra work. Or, if your LAN also has a shared internet connection, you can use the default C2 behaviour (using the C2 signalling server and sorting the NAT for you, making the LAN irrelevant)

    If you make a game, you should try to make it playable by as many users as possible. A closed LAN without shared internet is a rare scenario, these days ; my advice would be to use the built-in C2 features, which would save you time and would cover 99% of the situations.

  • Why not just have a lobby and handle peer connections as part of the implementation of the multiplayer logic ? The host can kick/reject any unwanted player, and you would need something like this anyway to deal with players being disconnected and/or trying to reconnect.

    Unless I am missing something, I don't think this requires any new networking features ; this requires little work but helps with genericity and flexibility, anything too specific is likely to be a limiting factor for other types of games.

  • Here's an example of "pre-rendered" effect with an animated particle used for an explosion :

    (grrr, can't post URLs apparently)

    opengameart.org/content/explosion-animated

    just add the http: ...

  • I never used Construct Classic, so I can't really comment on that - but as elisamuelps already pointed out simply by running the numbers, switching your effects to simple particle systems or animated sprites sounds like a good easy win.

    If your effects are causing the slow-downs, you need to find a way to re-create a similar effect more efficiently. This usually means less naive resource handling, less objects, less object creation/destruction, more sharing between objects, etc.

  • I think the only real kind of game C2 would struggle with would be "non-WYSIWYG" gameplay.

    For example, and to illustrate what I mean, a dungeon crawler. Not a rogue-like, but an old-style fake-3D dungeon crawler (Dungeon Master, Black Crypt, Anvil of Dawn, etc.)

    Graphics resources are only 2D sprites, the environment and the movement are tile-based, etc. but the problem comes from the fact that what the user sees is not what you edit when you create the game.

    The entire level design is a 2D top-down maze, but that's not how you play the game. All the data and game logic is handled in memory, and what is presented to the user is just a different representation of the world.

    This can be programmed very easily, but tools like C2 are designed to let you play what you design. I'm not saying creating a dungeon crawler with C2 is not possible, but it would be clunky and sub-optimal in terms of productivity.

    That applies to every genre that relies heavily on data management behind the scene. Everything else should be a good candidate for C2 or similar tools.

  • You might also want to look into profiling tools (such as Chrome DevTools, Speed Tracer, etc.) ; it might be difficult to link the result of your perf analysis to the structure of your C2 project, but it might give you an hint.