Refeuh's Forum Posts

  • Technology did speed things up - the productivity has significantly increased. It's now possible with very limited knowledge, resources and time to create games that would have taken teams of experts years in the past. Think Super Mario on the NES ; it's now possible for a single person to create something better using modern software. Of course this example is a bit extreme and we usually want to do "more", but this in itself proves things are moving forward.

    If stability is the key, focus on mature platforms and technologies ; though while this mitigates the risk of "innovation" this also adds the risk of "obsolescence"

  • No "power of 2" "magic" involved here ; it's just pixel rounding, which does exactly what it says.

    As for n^2, it works "better" since content designed to work in n^2 can easily be accessed with data encoded on 8/16/32/64 bits, which are native data types, without waste, memory alignment or performance issues

  • Nowadays 2D applications are handled as a special case and subset of 3D to benefit from hardware acceleration (using pre-transformed vertices, etc.) ; sprites are textured quads, and so on.

    This makes handling 2D, 2.5D and 3D games very similar, in terms of internal resources (vertex buffers, textures, etc.).

    As with any application, it's up to the user to set the rendering settings correctly to achieve the desired style (filtering, scaling, sampling, etc.). Pixel art (e.g. sharp blocky style) is not "more" difficult in any tool, it just requires the appropriate settings.

    It's like cell shading in 3D ; the scene is the same as a traditional 3D scene, but the samplers and shaders are different.

  • Hi -

    1. You export a project as HTML5, which actually is (HTML 5 + CSS + Javascript) ; publishing to web sites is trivial, but it's also a very portable technology, so with a few additional exporting steps, plugins and wrappers you can get your HTML5 game to work "as" a desktop application (wrapped in "simplified" browser/renderer that presents itself as a normal window to the user) or mobile application.

    As long as your target platform can process HTML5 content, it's all good ; this includes Windows/MacOS/Android/iOS/WiiU. Note that depending on the platform, the export process might not be trivial, and sometimes you have to fiddle with 3rd party development tools.

    2. Java is not Javascript. Javascript is light weight and browsers are very efficient at processing it. The language will not be a limiting factor ; knowing the platform, understanding performance and dealing with restrictions (resources sizes, etc.) will be essential though ; it's very easy to create very inefficient content even with very efficient technology.

    Also, big companies are investing massively on Javascript these days ; Google are going with native compilers and javascript subsets focused on performance, while Microsoft is going with TypeScript, a superset that compiles to javascript to facilitate the job of programmers. All in all, while that won't affect you directly, it means in the long run it's a pretty safe bet.

    3. Yes

    4. Nothing comes to mind ; other interesting technologies are either lower level (frameworks for programmers), more complex (e.g. Unity, with a much steeper learning curve), or slightly dated. C2 is the right balance in terms of functionalities/accessibility and has incredible productivity. Just be aware that "events" are very similar to "programming" in terms of logic ; it removes a lot of the complexity but you'll still need to understand how to create your gameplay logic. For "big" projects, a "programmer mind" can help to structure the events in a maintainable way.

    Hope that helps

  • You still get all the hardware acceleration via wrappers like WebGL, popular libs use instruction sets that map nicely to low-level concepts (simd for physics, etc.) and so on. HTML5 (html/css/js + wrapper + apis + libs) is not responsible for bad performance.

    Native and platform specific optimisations always come last in terms of cost/benefit ratio ; there's usually a lot to be gained from higher level optimisations first (resource management, entity lifecycles, naive algorithms and sub-optimal logic, etc.)

    So I'm not too sure what the problem is If you're targeting only one specific platform and want the absolute best performance (at the cost of iteration time, design time, prototyping time, etc.) why bother with high-level tools at all, and why not go low level in the first place ?

  • Thanks to the people who took the time to read the document and provide feedback ; I will try to improve the guide with the various suggestions I received.

  • I think it's just the space in the http ; urls get removed from posts for new users

    repost :

    http://gyazo.com/378b054bd46624296b809542878c8c48

    http://gyazo.com/b87ef8cf7e62cb17a83d7c52a0f3ce95

  • Ahaaah ! Great, thank you very much, I will be experimenting with all this !

  • Interesting ! That would make peer objects persist across layouts, giving me full control of their life cycle (created by the host, destroyed when players disconnect as you said). That should remove the destroy/re-create question altogether. Thanks

    I'll investigate that ! Though I'm still curious about what actually happens to synced objects when changing layout

  • Hi all !

    I've been encountering a small glitch in multiplayer when changing/resetting layouts ; basically, peers positions' still seem to interpolate between the old position and the new one (before/after changing layout), and peers also leave a "ghost" (multiple instances of the peer's player object bound to the same peerID)

    Surely it's got something to do with the way I use Multiplayer.Associate(peerID), or some assumptions about the layout transitioning logic I don't fully understand (my guess is that all objects should be wiped clean and re-create, but are they...?)

    Bottomline question : what happens to synced objects during layout transitions ? What are the best practices in terms of object creation/destruction and peer association to deal with layout transitions ?

    I have re-created a "small" .capx example demonstrating the problem (nothing is really "small" with multiplayer, even if C2 makes it easy, but it's as minimal as I could make it) : 2+ players (blue squares) need to collect all the collectables (yellow squares), upon completion the layout is restarted (hosts restarts and broadcasts a "restarts" message to peers)

    .capx : https://db.tt/4X0NpqRh

    video : https://db.tt/5qaa0ktJ

    4 layouts to deal with the front-end and 4 stages of multiplayer setup : menu (checks for multiplayer support), login (player id), matchmaking (room id), and lobby (multiplayer set up, waiting for all players to be "ready")

    1 dummy layout containing prototypes of all entities

    1 actual "game" layout where the collection / restart logic is

    WASD to move

    Any suggestion would be greatly appreciated <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> Thanks !

  • Hi all -

    I've been writing a short 10 page article to share my experience of production and help amateurs, hobbyists and junior game developers manage their projects more efficiently using simple tools and processes, especially regarding planning and tracking.

    A first draft is available ; if anyone is interested, I am opened to feedback and criticisms to improve the guide.

    OneDrive : http://1drv.ms/1BJwiWo

    DropBox PDF : https://db.tt/Qx7ncPCe

    Thanks !

  • Hi !

    Do the samples and tutorials (ghost shooter, etc.) behave properly ?

    If they do, check your logic, setup and game updates against the samples. I couldn't open the capx, but did you disable the behaviours on the peers ? host authority vs. peer logic could cause this kind of shakiness

  • [quote:27cwxw6x]it's still an authoritative server model - the host acts as the server

    Absolutely, fair statement - my apologies for the misleading over-simplification, I only mentioned this as a quick way to make sure the OP, who doesn't seem to have used C2 yet, wouldn't expect distinct modules for the client and server sides, like some other tools do, and would need to understand the symmetry between peers to develop proper host "authority" logic

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hi !

    C2 sounds perfectly suitable for this project ; just be aware that the built-in multiplayer functionalities are designed around the host/peer architecture, not server/client. It may or may not be an issue depending on your concept

  • You're absolutely right that additional sheets can and will generate more draw calls ; what I meant by "minimal impact" is that the cost of a few extra draw calls (i.e. a few factors e.g. 2x-10x, as long as there's no order of magnitude e.g. 100+x) is pretty negligible in terms of performance. Though we should think in terms of materials, as objects and/or textures usually don't relate directly to the number or complexity of materials

    Basically there are games where each model can require dozens of drawcalls (typically, games with a lot of character customisation, like MMOs, lots of materials, armor pieces, etc. making batching difficult) ; for these, the frame time spent in the graphics drivers start to matter. Assuming a med-size 2D, not so much

    I don't have the answer to explain why the atlases don't batch everything in one sheet in your case (and I'd love to know too !), but unless you clearly identified a perf killer or bottleneck through actual profiling, I wouldn't worry and would continue to progress on other fronts while waiting from an answer from Ashley or someone who knows the internal logic of the texture batcher