Uni Dreams Demo ***V2.2***

[me3]

Do you know what kind of limits browsers have?

Unless this has been totally changed lately, most browsers limit the number of cookies to about 50 per domain, using 1 cookie per variable would be an issue after a while.
However browsers allow up to about 4000 chars per cookie and you should very easily be able to store many variables within 1 cookie...
It shouldn't be too hard to make a system that spans the data over several cookies either, something like <gamename>1, <gamename>2 etc and then read that data as just a single cookie.

[tlaero]

me3, multiple variables per cookie is a good idea. I'll experiment with that.

Sylakone, here's how you use _game.js instead of check files.

In your editor, open _game.js and blclean_check1.html.

Highlight the "check()" function from the line that says "function check()" up to and including the last curly brace "}". Copy it and paste it in _game.js. In _game.js, change the first line from

function check()
to
function blclean_check1()

Now in AdventureCreator, open each of the ten files that reference blclean_check.html (ie map1_1.html)
Click on the hit target that has the blclean_check.html in it.
Delete the href.
In the box next to the href (onclick) write
blclean_check();

Do the same for the rest of them.

Basically, you're moving the "check" function out of the html and into _game.js, but giving it a unique name. Then you're calling it directly from the onclick rather than jumping to an html and calling it from there.

I suggest doing it in one place first and trying it. Once you've got it working, do the rest.

Does that make sense? Don't hesitate to ask if it doesn't.

Tlaero

[sylakone2]

@me3 thanks for the info.
@Tlaero thanks heaps! No hurry when you can.

I look forward to your next post.

Sylakone

[tlaero]

I had time after all and added it to the previous post.

Tlaero

[jfrancois323]

sylakone2, the game look nice, but i got a major problem. i can't go up to 1280x(something). Is there's a way to drop the files to 1024x 768 ?

[sylakone2]

@Tlaero thanks heaps I will look into it.

@jfrancois Easiest thing to do is press and hold the control key and scroll on your mouse till you can fit it in your screen.

Hope that helps

[jfrancois323]

@Tlaero thanks heaps I will look into it.

@jfrancois Easiest thing to do is press and hold the control key and scroll on your mouse till you can fit it in your screen.

Hope that helps

it work !! thank !!

[tlaero]

Okay, I did some investigation into the cookie limitations. Most of the modern browsers allow 50 cookies, so you've got room for 50 variables. I hit the limit in Christine because my way of saving the state used a second cookie for each variable, so the limit was 25. Taking me3's great suggestion, I've changed things so that the save game now takes two variables total. So, with those two and the cssSize variable, you now can have a save game and still have 47 variables. But you've got to convert to AC3 to get that.

Syl, your game doesn't do saves, so you've got room for 50 variables assuming your players use fairly recent browsers.

I can also show you how to pack 32 "yes/no" variables into a single cookie. That's what I did in Keeley3. Maybe I'll add a Tutorial for it in the future.

Tlaero

[sylakone2]

Excellent sounds good Tlaero.

I look forward to reading that tutorial Soon.
I hope to find some time to continue the game in the near future.
Unfortunatley with a 9 month old, time is a litle scarce lol.

Cheers for all of your help and suggestions.

[wagner]

I can also show you how to pack 32 "yes/no" variables into a single cookie. That's what I did in Keeley3. Maybe I'll add a Tutorial for it in the future.

RFC2109 requires browsers support at least 4096 bytes of data per cookie. That data can be any URL-safe ASCII text you want, so why not just stuff everything into one cookie? Within the game, keep everything in a single associative array. When you need to store it, serialize that object to JSON, encode to Base64 to support the limited character set, and dump the whole mess into one cookie. On the next page load, reverse the process. Accounting for encoding overhead and descriptive variable names, there should be plenty of room for a couple hundred variables. If you needed more, you could have the serializer automatically chop the array up and spread it across multiple cookies, or statically set a list of variable names in the page source and store only their indexed values to the cookie. Bit manipulation just gets messy unless you actually intend to do logical operations on them as a whole.

[tlaero]

That's what I did for the saved game storage. Bit manipulation comes pretty naturally to me, but that might be due to my background. The technique I used in Keeley3 worked well. I'll think about it. Regardless, now that saves only take two cookies, there's plenty of room for now.

Tlaero

[wagner]

Not wanting to be the type of person who claims something should be done some way and leaves, I dug into the version you posted over here, and added the described changes to the Example game.

http://filebin.ca/JujoC50EDHB

It adds a _base64.js, _json.js, and a rewrites the block of variable handlers to store everything in the 'workingset' cookie. It doesn't do anything to cache the cookies, instead parsing, modifying, and writing the whole block on each setVar, but I doubt performance is any meaningful concern.

That's what I did for the saved game storage.

After I got all the other stuff working, I dug into the saved game handling and saw it did have colon-delimited serialization. Anyway, the changes made simply store the page name as 'SaveLocation', and dump the whole thing into the cookie named by gSaveState.

[tlaero]

Thanks, wagner. I'll take a look.

Tlaero

[me3]

I can also show you how to pack 32 "yes/no" variables into a single cookie. That's what I did in Keeley3. Maybe I'll add a Tutorial for it in the future.

I haven't looked at how you're actually doing this but assuming you're just using 0 and 1 to see if they variables are "set" etc, you won't really just have to limit it to those two "options".
You could use 0-9 just as easily, storage and reading wouldn't have to change just the checking of the variables.

Warning, theories and assumptions to follow :P
Assuming you just store 0 and 1 for the variables or even the 0-9 i suggested, it should work with far far more than just 32 per cookie.
If your creator tool (sorry, i've not actually looked at it to see how it does things) keeps track of all the variables use in the game, which i assume it does, you could have an array or similar for mapping and then store just the values of the variables in a very long "string" in the cookie.
This would really allow you to store over 4000 variables within a single cookie which would be quite a lot more than games is likely to need.
Your read and set var functions would just need to use the array to pick the correct offset in the cookie during the game play and in the game creation it would just be a simple matter of appending to the array.
Hopefully some of this is understandable and not just rambling

[tlaero]

Yeah (-:

Here's what happened. Forever ago I wrote some javascript functions to turn cookies into numbers so Chaotic and other game writers could have an influence variable they could add to and subtract from. Many years later, when I ran out of variables in my own game, I had forgotten that these things were actually strings. They were ints to me (when all you have is a hammer...). So I decided to bitpack the bools to give myself more room. I've written enough drivers in my life that bitwise operations are as natural to me as logical ones. It wasn't until you reminded me that these things are 4K strings that I realized there's no need to bitpack them.

That said, the game interface I used for the packing would probably be pretty similar to what I'd use if I allowed 4000+ bools per cookie. So I'll have to think about how or if I want to address this. This weekend when I realized why I ran out of space in Christine and fixed it with your suggestion I bought a fair amount of space. So there's no real rush to change it at the moment.

Tlaero