Hey all!

So I thought of a dilemma that should be addressed and somehow solved. Though, I'm sure a million other people have brought it up before, so I'll get right to it.

Quest needs a way to compile games passed 20MB (I heard it will not work beyond 20MB) and if this cannot be done then perhaps a way to release Quest games into Episodic Content might be best (meaning the player ends one game and picks up where they left off in the next).

I've been thinking about ways of doing this/accomplishing this but because of the way Quest saves games, it keeps hitting a brick wall. So maybe Quest should save games differently, so that save files can be reused from one Episode of a game to the next.

What do you guys think? Or am I completely off-base here?

You could maybe issue a code at the end of episode 1 that could be entered into episode 2 at the start. It might be a mess to code but it's an option. My question is, can you remove a code once it's been used so you don't have "cheaters". Just an option maybe?

No, I don't think a code is a plausible way to handle it, especially if you have a bigger game with numerous variables.

That's why I suggested a save file that isn't the entire game, but maybe exactly as the game appears on the current screen the player is on or something, that way it records their stats and all that other stuff.

Anonynn wrote:
Quest needs a way to compile games passed 20MB (I heard it will not work beyond 20MB)

Why should Quest not possible to "compile" such games? Do you mean uploading large files to the server?

You could do it with a code, but you would have to put the various values in the code, plus a check system. Not trivial, but doable.

If you have five variables that can range from zero to nine, it could be encoded like this: 54245. Then add a game specific code, 542458743. You could then encrypt that and present it to the player. In your second game, you decrypt it back, check the last four digits match, and set the values from the first five.

Why should Quest not possible to "compile" such games? Do you mean uploading large files to the server?

viewtopic.php?f=10&t=5677

I'm going off of what was said here. You can't publish a game passed 20MB. I'm not sure if that's just on the website or the maximum amount Quest will allow.

You could do it with a code, but you would have to put the various values in the code, plus a check system. Not trivial, but doable.

If you have five variables that can range from zero to nine, it could be encoded like this: 54245. Then add a game specific code, 542458743. You could then encrypt that and present it to the player. In your second game, you decrypt it back, check the last four digits match, and set the values from the first five.

Well, on the surface that seems like a great idea. But for example, you've seen my game for example, Pix --- there are A LOT of variables. I don't want to give the player a code at the end that looks like this... 48923048490348293402482904284924839420839480238492048290 ...Of course, if that's the only way to do it then I guess that's fine.

But what I find most annoying is how the save systems work. For example, if someone plays a game and then it gets updated --- that person now has to start completely over...and must restart each time an update becomes available. So why not just change how the saves work so that they can be reused for games that are frequently updated. This would also likely solve the Episodic Format as well. Now given I'm a noobie programmer (if you could even label me as that lol) maybe I just don't know what I'm talking about. But to me, something is fundamentally flawed about the way the Quest system saves progress and/or the way it has a 20mb limit.

Maybe the save system should work like you suggested, Pix. Using a built in variable counter or something.

I know your game is unique in that it gets updated a bunch, but because of the way save-update-restart works, I've decided only to publicly release games after they are fully complete. Of course, when a player finds a game breaking bug, there's not much choice but to update and restart. Been there, done that... Multiple times. I thought about implementing a code that can be used to shortcut restarts for x3. Not much help, I know.

I know your game is unique in that it gets updated a bunch, but because of the way save-update-restart works, I've decided only to publicly release games after they are fully complete. Of course, when a player finds a game breaking bug, there's not much choice but to update and restart. Been there, done that... Multiple times. I thought about implementing a code that can be used to shortcut restarts for x3. Not much help, I know.

Well, it sounds like you're making excuses for the current save system, Xan! Don't be an enabler! Hahah! But still it really is silly to save the game the way it does. Maybe it should be based off the game-code or I dunno implementing what Pixie mentioned but instead of it being for episodic releases it could be based on current stats/variables in the room that the player is currently standing. I mean not only that, but it would cut down A LOT of giant save file sizes.

There has to be a better way to go about it. I mean, I'm getting a little worried myself because my game is reaching 6mb and I have NO sounds or pictures added yet (save for the title) and I only have one area partially written into the game. I estimate that by the time I finish that one place, it'll be closer to 7-9mb!! That's just about half the file-size that Quest allows for publishing! And the rest of the game is going to be much larger in scope @_@

unfortunately, with how programming works and games having multiple variables/states/stats/variations/paths/etc, there's just no easy way to do it (as you got to store every single metric/variable/state/etc of your game and then place it all back into your new game). Pixie is talking about advanced programming, encoding/decoding, to be able to do it. This isn't trivial stuff at all, for noob programmers, anyways (like myself - this level/type of programming was not easy - I'm going to take the class on it again as I was struggling with it and dropped out).

I think it is a valid point for large games that you want to be able to update them, and have your players able to play the updated game from the point there are already at.

I guess the problem for Quest is that you would need to differentiate between attributes that need to be saved and attributes that can be updated. For example, the player name could be something that the author decides tyo change in an update, or it could be something the player gets to set. How is Quest to know which it is? So it takes the easy way out and assumes every attribute is one the player can potentially change.

And that will be your problem too, potentially. Besides all the player attributes (and name), every item that can be moved, you will need to save its location. There are some attributes changing behind the scenes too, the "visited" attribute for each room for one.

And to make it more complicated, it will have to be able to cope with new items and rooms appearing in the game, but potentially absent from the saved game.

It will be a long number. But the player can copy-and-paste it, so that is not that big a deal.

The encryption itself may be pretty simple, as you can probably use JavaScript functions.
http://stackoverflow.com/questions/1827 ... decryption

I think it is a valid point for large games that you want to be able to update them, and have your players able to play the updated game from the point there are already at.

Exactly!

It will be a long number. But the player can copy-and-paste it, so that is not that big a deal.

Not big deal I suppose!

The encryption itself may be pretty simple, as you can probably use JavaScript functions.
http://stackoverflow.com/questions/1827 ... decryption

Pretty simple? Geez. I'm not even sure where to begin with that, but I'll look it over and see what I can come up with. Thank you, Pix!

Well, after looking over all that gobbly-gook I have to wonder and ask if hopefully there is a proto-type javascript/aslx encryption around that would be easy to modify?

See here:
viewtopic.php?f=18&t=6404&p=43332#p43332