Adventure Creator original thread

[kexter]

typeof(localStorage) is indeed "undefined" on IE11 in file://, but I don't have the required inner peace/mental strength to test js code with IE.

Also 58% for IE seems rather high (it's the NetApplications data, right? I never saw their data correlate to my real world experience). The global stats I've checked show 40% Chrome, 30% IE, and 20% Firefox (desktop numbers). I'm not saying you're wrong, just that the above mentioned percentage seems surprisingly high to me.

[tlaero]

Whether 30 or 60, it's too high to abandon those users. I tested it on IE, Chrome and Firefox online and off and it works. The next release of AC will come with the changes. Thanks Kexter!

Tlaero

[Wolfschadowe]

So, for those who are dummies, out of date, or like me...both, what does this mean for AC games, especially those in progress of being made?

I can kind of follow the conversation, only because 7 years ago I was working as a sr SysAdmin and troubleshooter in datacenters before moving to more management/administrative roles. 7 years out of date in computer years is...well, stale knowledge is an understatement. Fossilized?

Anyway, I'll set the context for the question, and maybe help out non-technical others who may be trying to following this thread:

One of my concerns with BEW and it's size, paired with cookies being used for both variables and save games is essentially the single domain cookie limit that browsers contain. Every domain gets its own cookie file, but cookies from local webpages were all stored in the same cookie file. There is also the "localhost" domain, where downloaded web content is run. (Yes, I'm simplifying.) This local file, like all domain cookie files was limited to a total of 30-50 cookies depending upon browsers, and this was shared. For example, If I played Keely 1, keely 2, keely 3 and BEW all on the same computer from the hard drive, all those save games and files would be stored in the "local" cookie file, and would begin overwriting after the cookie limit was reached for the local file, meaining older savegame data would be lost. Additionally, each individual cookie in the file is limited to 4096 characters, I believe. While cookie limits have probably increased over time for some browsers, there is a risk of lost savegame data over time, especially when I've upped the savegames in BEW to 40.

This also causes some crossover problems where I could play another AC game with a stats page, such as Coffee For Keisha, and go to the Stat's page, close the window. Open BEW to the start menu, go to the load game screen, and then press the return to game link without loading and it would take me to the last played Coffee to Keisha page instead of the BEW Menu.

What effect, if any to the above issue would this change to localStorage have? I suspect localStorage is a relatively new concept (i.e. less than 7 years old. )

Will it loosen some of the cookie limits we now have? Provide better reliability of data? Allow for savegame export and import?

Thanks for your patience in helping me understand the change!

Wolfschadowe

[kexter]

Cookies can be around 4kB, while localStorage is about 5MB per domain. So I don't think you'll have any problems storing 40 saves.

The main difference between cookies and localStorage is that cookies are communicated to the web-server with all requests in the HTTP header. The data in localStorage exists simply on the client side, it's not communicated to the server in any way. So basically localStorage helps saving bandwidth by reducing unnecessary data communication - though this only comes into play if you put your game up on a web server.

So for example if you have 20 variables, and if each variable is 7 characters long then AC will store them in about 200 bytes. Now if you have 100 pages in your game which have to be traversed by the player for a successful playthrough then at least 100 request will be made. That's 100 pages times 200 bytes (100*200), totaling in nearly 20kB of wasted bandwidth per playthrough. If only a hundred people play your game then it's already around 2MB wasted - that's over 6 minutes worth of upload time with a 56k modem (for historic reference). As I said this only comes into play if your game is played on a web server.

If you play locally (i.e. you let your players download the whole game in an archive) then the main advantage is the increased storage space. Note that for localhost (playing locally) different games would still have to share the storage space.

Exporting/importing saves is a different matter.

[tlaero]

Can we move this conversation to the AC main thread? We're getting out of the realm of tips and tricks.

Tlaero

[Arizona]

It may be better to use sessionStorage instead of localStorage for the variables, thus can have multiple instances of the game in several browser tabs. localStorage could be used to save the game and the saves were available on all tabs.

My two cents.

[Squeeky]

At Tlaero's request the comments from viewtopic.php?p=71284#p71284 to the one just above were relocated here so as to be more on topic.

[tlaero]

Wolf, to answer your main question, the storage change won't affect your code at all, so long as you're calling the "var" functions and not the internal ones like "setCookieString." What it WILL affect is your current saves. When you switch over, they'll be moved to a new location. So, if you're in the middle of a long repro, don't switch until you're ready.

All in all, the only real benefit of the change is to make Chrome work without special flags, but as Chrome continues to grow in popularity, that's a useful thing.

Tlaero

[tlaero]

I just uploaded a new version of AC.

Changes in 4.6
GameView filtering now has the ability to do case insensitive filters.
_functions.js has a different variable storage scheme that allows Chrome to work without special flags.

http://www.mediafire.com/download/six8f ... reator.zip

Tlaero

[Wolfschadowe]

Great work as always Tlaero! Thanks for all your effort on this tool.

Am I correct in understanding that this will break my test savegames in BEW when I upgrade the _function.js?

Not a problem for me, just want to make sure I'm clear so I can work it into my roadmap for the least impact.

Wolfschadowe

[tlaero]

Yes, it will break your saves once. You can upgrade AC without _functions.js this time, though.

Tlaero

[Wolfschadowe]

I'm not sure if this is the best place to ask since this isn't part of AC and may be out of scope for it, but this is my go-to spot.
Basically I'm looking for a method to effectively export a savegame.

My preferred method would be to have a screen that generates a text string that can be copy/pasted to the players format of choice, or just written down if they want to go old-school analogue. This is similar to what Shark does in some of his games.
Conversely, there should be a method to allow the player to enter that code to restore the game. For BEW it may be a complex code if it captures achievements as well as the current game stated.

A secondary method would be to export to a text file, and import that file.

This is not really a high priority for me, or for the game, but would be a nice to have, especially as a tool to bridge the Acts which may be some time apart. Any ideas?

Wolfschadowe

[Super]

All I can think of is to write a very long function that outputs a it into an array and then having another function that take the array as input and separates it again.

For instance, say you get the string "1010" as your password, with each digit having two possible outcomes. Use something like this: http://stackoverflow.com/questions/4547 ... javascript to split it into 1, 0, 1, 0, then have a function to check if each digit is 0 or 1 and import that. When you save it, you simply output the string of all the chars together (I know it's possible to output the player name so you just use the same system to get this out).

I dunno if that made sense, but I think it'd work. Would be a ton of work, but what else is new. I dunno if anyone has a better idea than a noob like me, though.

[tlaero]

There are 2 scenarios to contend with:
1) Export the entire state so that you can go to another computer, type in the state, and pick up where you left off on the same game.
2) Export a subset of the state as a "starting value" for the next game.

2 is much easier than 1. One of the bigger problems with 1 is that you need to encode the current page into the state. So it would end looking something like:
22000010345office3.htm

It's pretty obvious how the state is encoded then. People would be able to reverse engineer it and send themselves to any part of the game with any score they'd like. Also, in your game, you have so many variables, that the state string would be really long.

With 2, you can trim it down to the couple variables that need to be carried over to the next game.

Which do you need?

Tlaero

[Wolfschadowe]

It's pretty obvious how the state is encoded then. People would be able to reverse engineer it and send themselves to any part of the game with any score they'd like. Also, in your game, you have so many variables, that the state string would be really long.

With 2, you can trim it down to the couple variables that need to be carried over to the next game.

Which do you need?

I've been flip-flopping a bit about which one I need. Originally I thought the scenario 1, full savegame replacement, but the more I think about it, the more that seems like overkill. Unfortunately, I painted myself into a corner with the complexity of the game. I don't regret that complexity, but if I were to do it again, I would make it much less complex.

What I really need is a bridge from Act 1 to Act 2. I doubt savegames will survive the timing gaps. The Act 2 game will really be Act 1+2 together and will be a seamless experience. Likewise, Act 3 will really be Act 1, 2 & 3. This concept is important because it means that things like earned achievements and sub-achievements need to carry over, along with a subset of the actual gameplay variables. I doubt many people will want to extensively replay Act 1 once Act 2 comes out.

If I beat my head against it for a week or two, I'm pretty sure I could figure out how to loop through the three variable arrays (Achievements, Sub-Achievements, and Game), and build them into a simple string. More difficult for me is reversing that and reloading variables, especially since game variables are integers rather than binary like (sub)Achievements. I could probably figure out some kind of marker between variables or something to handle that but I'm hoping for a different solution.

By different solution, I'm hoping someone knows of a relatively easy way to encode and/or compress that information to make the strings shorter and easier for the players. I'm not particularly worried about reverse engineering, If someone wants to do that, more power to them, they can play the game anyway they want. I don't want that to be easy for them, but also don't want to go through the effort to purposely obfuscate and mislead. The goal is more compression of the data for ease of use. My thoughts originally went to bitwise, but all I really know about bitwise is that it exists. I have no understanding of how to use it, or even if it is a good option here.

It may also be a good idea to be able to export game variables, and achievements (including sub-achievements) separately. Achievements are binary, so may be easier to do, and if anything is encoded somehow, It should be these. Game variables are integers, but not as important in my mind to obfuscate.

Finally, I wonder if I am mentally capable of writing a post less than 250 words. Luckily I type 75 wpm, but still.... Thanks for your patience to my rambling everyone!

Wolfschadowe