Ashley's Forum Posts

  • The spritesheeting strategy is described in some detail in this blog post, although it's a little out of date now (e.g. the maximum spritesheet size is now 2048x2048 instead of 512x512).

    The spritesheets have to be square power-of-two to avoid wasting memory on some devices (even if others can do non-power-of-two). Also note that bumping up a 1024x1024 texture to 2048x2048 uses four times as much memory, not twice, so it can be very wasteful to use spritesheets which are unnecessarily large. These days memory use is the main concern, since users tend to develop intensely memory-heavy games and sometimes find it crashes the device if it runs out of memory. So one of the strategies used by the spritesheet builder is if something fits on say 1024x1024, it will also try a 512x512 tile, or two 512x512 tiles, or three, as a way to save wasting memory with empty space on a larger sheet.

    More technical concerns are: most third-party plugins aren't written for spritesheeting, and it's tricky to tile images unless they go in their own texture, so tiled background images don't get spritesheeted. Also perhaps surprisingly putting everything on to one giant spritesheet can actually significantly increase the download size of the game. Often individual objects can losslessly compress down to PNG-8 - sometimes around half the file size - because they use less than 256 different unique colors. However if you bundle everything on to one giant sheet, it becomes much more likely that there are more than 256 colors on the sheet and it gets bumped up to PNG-32, which produces larger files.

    I don't think the performance is really an issue. In extreme cases with thousands of objects the draw calls can add up, but there are ways of dealing with that. In most real-world games I don't think switching texture poses a significant performance burden.

    When I first wrote it I thought it was simple enough, just a matter of dumping lots of images on to one sheet. It turns out there are technical factors and difficult tradeoffs like download size vs. memory use. I don't believe there is one strategy which is universally better.

  • Tokinsom - some of those issues you list sound like they are probably deliberate alterations made due to bug reports. It's hard to see how we can win here: either we leave one user with a bug which we don't fix, which will frustrate them (and probably end up with us being accused of never fixing bugs), or we fix the bug and in other circumstances it materialises as a "quirk", which frustrates someone else (and ends up with us being accused of leaving in quirks forever). I guess you are right: the only way to make something that works for everyone is to provide a simple base engine for users to modify themselves. However this would mean a radical re-think of the entire way behaviors work, and is not something that we can just patch in to the next beta release. I'm definitely interested in addressing this in the long-term with C3. However I can tell you getting a bulletproof movement with no difficult edge cases is extremely difficult even as an experienced developer working with a traditional programming language. Implementing movements in events and leaving it for the user to fix to their purposes probably just shifts this difficult problem to the user, which may be suitable for expert users, but probably is not much help to the majority of less-than-expert users.

    However (mostly aimed at other posts in this thread) I don't think it's fair to say that the behaviors are useless if they don't serve your purposes or they are missing your favourite feature request - as far as I can tell, they are very useful for the majority of users, and we frequently hear positive feedback about how effective the behaviors are for many users.

  • For one in my opinion the built in pathfinding is made for an RTS type game, its especially bad for grid/board based games

    You can use pathfinding without the movement, and just get it to return a list of the nodes in the found path and implement your own movement or use for the path. You don't have to use its own movement. So doesn't that help it cover other kinds of games?

    The behaviors are one of the banes of C2's existence. They are wonky and buggy and after years of work just don't cut it, even for simple retro platformers or zelda-likes

    Behaviors are intended to help beginners get started quickly, and also provide shortcuts. For example the bullet behavior is pretty convenient if all you need is something moving in a straight line, saving you having to set up the events to move it with x += cos(angle) * speed; y += sin(angle) * speed etc. They're not intended to cover every possible genre of game - how would that even be possible through the behavior system? Only events can implement custom logic, or custom Javascript coding with the SDK. I think hoping for behaviors to cut it for everything is hoping for too much from them.

    Modularity is definitely an interesting area to explore in future, but I can tell you the platform behavior has some very complex and subtle logic to cover a couple of year's of edge cases reported via bugs. I think one of the risks of event-based behaviors is that it's actually pretty difficult to write a flexible, general purpose movement without just fragmenting it in to a bunch of entirely different behaviors. Then the question is which do you choose, why, and can you change your mind later?

  • Unfortunately, much of the way contruct operates makes assumptions about what the game dev needs. I find those assumptions to be uninspiring and somewhat limiting.

    Can you elaborate on what those things are? We've always designed C2 to be a general-purpose game engine and avoided any "cookie cutter game" type features where you're forced in to one style of gameplay. The built-in behaviors are all designed to be customisable and flexible for different purposes, at least to some extent, and if they don't work for you there's always the option of custom logic via events.

  • Most mobile devices, but not all, support WebGL. See webglstats.com for more info. For publishing any Cordova-compatible platform should work well on iOS, and Crosswalk (also Cordova compatible) for Android.

  • Apple does not allow any other browser engines on iOS other than Safari. Chrome for iOS is just Chrome's UI over Safari. So it is not actually possible to get a truly different browser on iOS.

  • You do not have permission to view this post

  • Yeah, I guess try again.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • ilimi - please file a new bug report following all the guidelines, this report is already closed and is for a different issue. You also still did not include a .capx as per the requirements.

  • I've done a bunch of testing in Edge and everything worked great. I've not run in to any problems yet.

  • ilimi - we're not aware of any issues with exporting to iOS via Cordova. Please file bug reports following all the guidelines if you have any issues with them.

  • IE8 does not support HTML5 games at all (it has no <canvas> element support). IE9+ is the minimum requirement.

  • granpa - you really should update. Microsoft dropped support for Windows XP, and we recommended XP users upgrade over a year ago. As the post says XP is so old now that if it's difficult to fix XP-specific bugs, then we probably just won't fix them.

  • Ejecta support was deprecated a long time ago, and we have not been maintaining Ejecta since then, so closing as won't fix.

  • You do not have permission to view this post