HTML 5 question

Discussion and feedback on Construct 2

Post » Fri Aug 17, 2012 6:15 am

If you're planning to make a CCG, I advise you to move the card images away from the client. Leave the UI, the card outlines, effects and that stuff in construct, but try to create an engine that is flexible enough to be able to download and interpret new card mechanics, display new card images, and make a cache system using localstorage.

This gets you two benefits: players don't have to download cards they don't use, and you can keep adding cards without forcing players to redownload the whole game.

If you do implement downloadable card mechanics (attributes, skills, effects, cost, whatever), make sure to build in some sort of cheat detection/prevention system - hell, you'll have to implement it either way.Fimbul2012-08-17 06:15:40
B
35
S
8
G
8
Posts: 532
Reputation: 6,868

Post » Fri Aug 17, 2012 8:07 am

I'm not exactly sure what "CCG" is, and I haven't played the game you refer to Metal_X.

The custom behaviors turn the image into a string, and allow to turn the string into an image from the client's side, so the image has only to be downloaded once from the internet, and then can be stored/processed on the client's side anyway.
New to Construct ? Where to start

Image Image
Image Image

Please attach a capx to any help request or bug report !
Moderator
B
247
S
85
G
40
Posts: 7,000
Reputation: 57,795

Post » Fri Aug 17, 2012 9:23 am

@Metal_X : I made the two plugin @Kyatric kindly mentionned.
The base64 string thing is really old, as old as the web (older, in fact, since it was made to allow people exchange binary files over mail, which allowed only text at that time...).

The idea is very simple : every byte of a file on a computer is a number between 0 and 255. However, when you want to represent a character in a text files, there are less letters in the alphabet and the punctuation thatn 255. In fact, the characters are numbered from 33 to 126 ('M' is 77 for example).
So the base64 algorithm is simple : when you encounter a byte from the file, you represent it with one or more character (i.e. the byte '34' would be 'AG', the byte 201 would be '=/' and so on. It's not the real mapping, it's there to illustrate ).

If you do that for the whole image file, you have the whole sequence of byte (each one ranging from 0 to 255) converted in a printable character sequence (each one covering 32 to 126 hence the 64 in base64).
You are going to object "Hey, if for each byte, you convert it to two or more letters, the representation in base64 is longer than in bytes !". That's true. base64 add around 33% overhead to the file size. That's the price to pay to be sure that the base64 string is always going to be readable, no matter what language the user is using on is machine (old 7 bits english ASCII, 8 bits european with '','','', letters, complex tables with ideographic characters in Asia, etc...). At least you are sure that those 64 characters are the same everywhere.

Since it's so old, browser can naturally handle those base64 string. You can specify directly a base64 string as an image source, and the browser will display it happily (that's what my behaviors are doing).
Since it's a string, you can easily store it as text directly in localStorage, WebDB, send it over WebSocket and all...

With one of my behavior, you can extract the base64 string of an image. Since a few builds, you can enter that string directly as an URL in a Sprite, @Ashley added the code to the Sprite object.

Everything you store in localStorage is going to be cached forever (at least for a long time, the decay is different for each browser, but at least 9999 days or the like ). It's not true on mobile (oh, surprise !), because the system can decide that "the phone is full, I need to do some space !" (especially true on iOS).
If you want to lighten the download for your client, you can store the images in localStorage. You need however to have a system to check the image version when you are going to add new card to your game ("is the card I'm introducing newer thatn the one cached in localStorage ?")
B
33
S
9
G
6
Posts: 709
Reputation: 6,704

Post » Fri Aug 17, 2012 9:56 am

Do not use base64 just to cache the game, it's completely unnecessary. Construct 2 games already use the HTML5 App Cache to permanently cache the entire game to disk for offline use. For more information see the tutorial Offline games in Construct 2.

The cache is permanent and never expires, so you will not ever need to re-download the game if it hasn't changed. Also since the game is saved to disk, it continues to work offline. Try visiting your game, playing it for a bit, unplugging your internet, then closing and reopening the browser to the game's URL. It will still load instantly. The tutorial also covers how updating works and how you can detect it with events.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Fri Aug 17, 2012 6:13 pm

Fimbul
Yes, a game that will be constantly updated needs a well made system to download only what is new.
Thanks for you advice.

Kyatric
CCG = Collectible card game

Pode
Thanks for the long explanation man, i tested the plugins and really appreciate the possibilities.

@Ashley
Thanks for the advice Ashley, but even if the game is cached forever, with every small update it needs to download the whole game again, am i right?
If that's true, so the problem persist, i'm want to make a game that is constantly uptading, like every 3 days a new update.
For that problem i think that using Pode plugin to store data in localstorage is the best solution, or am i wrong?
B
22
S
7
G
5
Posts: 90
Reputation: 3,430

Post » Fri Aug 17, 2012 6:32 pm

[QUOTE=Metal_X]even if the game is cached forever, with every small update it needs to download the whole game again, am i right?[/QUOTE]
No, it will only download the changed files and save them to disk. It will not download any files that have not changed. So you can even have a 100mb game, and updating a single 10kb file every few days will only download the new .appcache file (a few kb) and the single changed file. Browsers aren't that dumb, they won't waste all your bandwidth :)

In other words I believe it automatically works exactly how you want already, and you do not need to do anything special at all.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Fri Aug 17, 2012 6:45 pm

OMG, that's awesome! Thank you so much!

Edit:
Something that i read on http://www.w3schools.com:
"Note: Browsers may have different size limits for cached data (some browsers have a 5MB limit per site)."
And:
"Application cache is supported in all major browsers, except Internet Explorer."

That's something i need to be worried?Metal_X2012-08-17 18:53:55
B
22
S
7
G
5
Posts: 90
Reputation: 3,430

Post » Fri Aug 17, 2012 8:24 pm

Internet explorer is awful on many levels. It needs to die.

B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Fri Aug 17, 2012 9:23 pm

The 5mb limit applies only to WebStorage I think, although iOS and some other platforms may prompt if you store "a lot" (25mb+ ish). Usually the user just needs to OK it and it will run.

IE10 supports the app cache, but IE9 doesn't, which is a bit annoying. It should still load most resources from the normal cache, but it might re-download in future if its cache expires. App cache fixes that and IE10 should work fine.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Fri Aug 17, 2012 10:40 pm

I think it may have been mentioned, but I would check your browser settings if you find your cache is being refreshed. Unless the previous games you've played are coded to re-download old data, you may find the storage limitations placed by browsers are causing the extra download burden.

Alternatively, a fresh pack of real playing cards can last a life time. However, try not to bend them, else pain will follow. :(
B
85
S
31
G
14
Posts: 106
Reputation: 16,440

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: 99Instances2Go and 14 guests