VinniePin's Forum Posts

  • 🎉The Winners!🎉

    We want to thank everyone for participating, it was a fantastic game jam. We managed to make 36 games and had a great time playing them! Everyone involved managed to make a game in a short time and receive feedback from their peers. That's what it's all about!

    Congrats to the winners Federico Calchera and Abho!

    And Congrats to the honorable mentions Snugpig Studios, TackerTacker and Chrishie

    You can play all of the games that were submitted at this URL! We look forward to seeing everyone who participates in next year's jam!

    itch.io/jam/construct-jam-2024/entries

  • Any chance we can get an expression version so I can set text? :)

  • You'll want to ensure to only use that event if the touch.x and touch.y are not near the joystick portion of the screen!

    distance ( touch.x , touch.y , joystick.x , joystick.y ) will derive the distance

  • Last bump for this one! The jam begins in 24 hours! Anyone who might be interested in participating in a Construct 2 or Construct 3 game jam is welcome to check out the jam page.

    The prizes and the glory await!

    itch.io/jam/construct-jam-2024

  • Bumping this one! Only 7 days left to sign up. Prizes and Glory await :D

  • Hey y'all! A bunch of us have gotten together and put this game jam together. Scirra has also generously offered to help us with the prizes. Excited to see what y'all cook up!

    https://itch.io/jam/construct-jam-2024

    Tagged:

  • As per the latest change to the beta cycle: the spritesheets have an option to be disabled! This is amazing. Thanks a ton for Ashley's hard work and ear to the community.

    Now all thats left is to showcase this fantastic functionality to our players! I'll post if anything cool becomes of it

  • Perhaps there's other ways to solve this - for example if Construct could export metadata about spritesheets (i.e. the location and size of every image), then in theory some external tool could take a folder of individual image files and paste them over spritesheets, and that could be robust against future changes to the project. It would keep the benefits of spritesheets and only need a minor change to Construct, exporting some extra info it already has.

    I know for sure i won't be making a tool like this. Way beyond my skill level, but if someone else or Scirra makes it, im not opposed to instructing the users to use it for modding.

    Of course telling them "replace the pngs if you want to change the art" is much more straight forward but i won't keep beating the dead horse.

    Oh and one comment about some users wanting modding and others not wanting it. Steam allows the developer to distribute different versions based on the user's preferences. So perhaps the more performant (spritesheet enabled version) could be distributed like that :) (not applicable for web platforms, ofc. lots of considerations )

  • I don't think it's a simple thing to just turn off spritesheets. Spritesheets are always power-of-two sized, and while WebGL 2+ supports non-power-of-two texture sizes, WebGL 1 does not. There's still enough WebGL 1 systems out there that I think if it just exported a bunch of non-power-of-two individal images then your game will be broken on a small percentage of systems, but enough that you'll get a lot of "game doesn't work" reports.

    Then there's other issues like larger games losing the benefits of spritesheets could become significantly larger to download and significantly slower to load, and have a runtime performance hit too. It could be a massive deoptimisation for your game that slows things down even for players who don't want to mod anything and just play the stock game, which I think is an unfortunate trade-off.

    Perhaps some of that can be mitigated in various ways, but it's complicated. Modding is a very large area if you want to go further to adding new kinds of objects, changing game logic, adding new kinds of level themes, etc. as well. I fear this may be one of these areas people say "just add A!" then "just add B!" then "just add C!" and then on for another 20 things over months/years.

    Fair enough! I'll admit it's already possible for me to offer a set of in-game tools to the player to inject their own custom art and music and have those changes propagate through the game. I consider it a big hassle, but i guess turning off spritesheeting is equally or moreso a big hassle for Scirra.

    Oh btw, to address your concerns with larger projects being slowed down by disabling spritesheeting; my suggestion was to have a bool in the export options to enable or disable based on the preferences of the developer. With enabled being the default option of course :)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I agree that those things would be a huge benefit, but I would be enormously grateful for merely disabling the automatic atlas creation when exporting. That would at least allow the users to change all that stuff manually and for it to not get lost across tiny version differences in the game.

  • It's also considerably more messy to have essentially two copies of every image in the project. One in a local folder (for modding) and the original in the image folder. Which also includes the annoyance of teaching the players to mod the modding folder images instead of the other images. And, not to mention, a ton of refactoring to a project that has hundreds of sprites and tiled bgs, and so on

  • You can load sprite images from a URL which might work better. That bypasses the whole spritesheeting system.

    Not every object that has art in a construct project has the capacity to load from URL

  • Heyo! I submitted a suggestion and i would appreciate if y'all could have a look and perhaps upvote it. If the suggestion gets implemented, it would be an incredible step forward for modding construct games.

    construct23.ideas.aha.io/ideas/C23-I-465

    If y'all want to discuss the merits of this or suggest existing solutions, I'm all ears!

    When exporting your project using Construct 3, the engine automatically merges art assets into shared sheets for memory considerations. That is nice except when you want to encourage modding in your game.

    Modders will want to replace Shared-Sheet2.png with their art. That's all fine and good. But what happens if the developer releases an update that adds a single image into the project? It will likely break all the mods for the game.

    This is because the engine will re-combine the art assets in the project into sheets without honouring the previous sheets. This causes a cascade of changes where nearly every sheet is a different art asset and mods that reference Shared-Sheet2.png are no longer referencing the same part of the game's art.

    Currently, the only way to have users swap out the same sprite art across multiple versions is to give them access to the construct file and have them compile the game themselves. This isn't ideal. A simple boolean that disables the Shared-Sheet generation would be a saviour in this respect.

  • I orchestrated a different way of testing it. Spawned a bunch of semi transparent circles with sine behaviors until fps was consistantly below 50 then stopped and displayed object count. Looks like nw.js has a 7% performance reduction over running the game directly in chrome preview.

    Not nearly as bad!

  • I created a simple project that has no events other than setting the text object's text to the current framerate. The project is configured to use full ticks with no vysnc to compare performance. When running the game in a web preview i get 106k frames per second, when running the exact same project as a nw.js export, i get 38k frames per second. Any thoughts? Perhaps we should use Electron instead?

    Shoutout to LukeW on the discord for, more recently, discovering the descrepenacy.

    Tagged: