I'm working on my second Decker project (the first one, 'The Key', was my submission to the game jam last month). I'm making a sort of sequel/remake, and I'm noticing that Decker is taking more time to save the files (.deck and .html). Is there a recommended limit to how large Decker file sizes can be? I'm up around 20mb now; is it possible the game might crash or run poorly for the user?
Yeah, Decker can definitely chug a bit with larger file sizes. I don't think there's a hard limit necessarily, but there's definitely a practical limit. With my own work I'd ended up with an almost 200mb deck that REALLY chugged when you saved it and wouldn't even load properly in a web browser, so I had to downscale some of the assets, and then at around 60mb it would at least load in a browser.
I think the pertinent question would be, what are you doing that the file size is so big? I've noticed the bigger Decker decks tend to be from using a LOT of imported dithered art, and unless you're being silly like me and essentially doing FMV, often what tends to make the filesize balloon out like this is having multiple copies of the same card with slight differences, the problem being that each copy has to be saved in full in the deck. Could it be possible to rework things so that instead of different cards you're showing/hiding different widgets?
I’m definitely going to start using more contraptions for the artwork instead of full-screen images; there’s a lot of repetition in the backgrounds. Hopefully that will slow down the ballooning file size. Thanks again for being so helpful! I’m going to submit it to the Solo Development jam that’s going on right now. Still about three weeks left if you want to join that one. 😊
i'm wondering if I can get your opinion on the load time for the game as it is. it shouldn't get much slower now that i'm using two or three cards per section instead of dozens, but i can always go back and speed it up further. here's the link: https://waldorfhammer.itch.io/key-2
thanks, Millie!
I don't think the load time is too bad at 20mb; it's noticeable, but compared to games made in Unity or Ren'Py loading in a few seconds is still pretty fast.
Looks like you built this game with Decker 1.62; in the 1.63 release I fixed a bottleneck that was slowing down deck loading a bit in native-decker, but it was most noticeable in debug builds. Still, upgrading might make your development a little bit snappier. I'm tinkering with some other performance improvements presently.
Using contraptions as reusable graphical assets is certainly one way to cut down on repeated background images; it looks like you're doing this pretty extensively already for puzzle elements. If any elements are one-offs you could also use canvas widgets as graphical elements you can show/hide, move around the card, or copy from place to place. I was a little surprised to see that you aren't using canvases at all in this deck!
i'm so new to using Decker, I wasn't actually aware of canvas widgets until you just mentioned them. :-) so, thanks, i will explore this!
i just finished cutting a bunch of redundant cards, so it's down to about 13mb now, but it's great to know that the loading wasn't bad at 20mb.
it's also great that you and the Decker community are all so helpful. i love being part of it!
i have a follow-up to the file size question:
in order to decrease the file size by removing cards, i'll need to increase the amount of scripting significantly. are there any issues with having particularly long card scripts? i currently have a 200-line script that i will need to expand to about 2000 lines. this won't affect performance, will it?
it's a habit i've had for about 40 years (since the days of BASIC) - writing unnecessarily long code, especially when a language is new to me. this project is particularly inefficient - i.e., multiple IF-THENs instead of loops - but it's almost done. i might ask for some tips on the next one, though. Thanks!
Sorry, took me a while to get to this but I think the loading times aren't too bad, as IJ said it's not much compared to other in-browser game engines.
The full-colour dithered art style does tend result in decks being on the bigger size in my experience. It sounds like you're on the right track in terms of keeping the size down though - basically, avoiding duplicating the same backgrounds is what should help the best. So using canvas widgets to add elements without having to duplicate the rest of the background, or enabling/disabling buttons depending on what interactions you should be able to do and such.
