Idea: make async easier with "Then" event

Discussion and feedback on Construct 2

Post » Wed Apr 15, 2015 10:06 am

@Ashley

"cache" is a small related data set. User picks this data set at the same time then read/write it (data in this set). Not to load whole storage data into cache imo. User could release it and reload new set manually.

For writing action, each key-value is stored into different key of local storage, so that it does not write whole cache data into local storage, just one entry.
B
107
S
25
G
243
Posts: 4,389
Reputation: 137,470

Post » Wed Apr 15, 2015 10:46 am

@rexrainbow - but you still thrash the storage or lose data if you keep a cache in memory.
Scirra Founder
B
384
S
227
G
86
Posts: 24,139
Reputation: 190,761

Post » Wed Apr 15, 2015 10:53 am

@Ashley

I could not get your point about writing.

The writing action could be the same as local storage plugin. If the data had lose while using cache, it would be lose when using local storage plugin. Even "then" would lose them imo.

The benefit of cache is to reduce the read complex.


Edit:

Writing action would update value in cache (memory) and also write it into local storage (disk).
B
107
S
25
G
243
Posts: 4,389
Reputation: 137,470

Post » Wed Apr 15, 2015 12:32 pm

@rexrainbow - but it's confusing if the object looks like it is setting a value synchronously, but has only really cached it and it needs to be written asynchronously. For the caching system to perform well, you'd also have to have a per-key asynchronous write action. So to *really* write a value, you'd still need to do this:

- Set "myKey" to "myValue" (only writes to cache)
- Write "myKey" (writes for real and is asynchronous)

> On "myKey" set
- (actions to run when done)

This is even more complicated than the current system and is confusing to beginners since setting a local storage value does not actually persist it anywhere. If you want this, just implement a cache yourself: read and write to global variables, the Dictionary object, or anything else, and then write with Local Storage to save it.
Scirra Founder
B
384
S
227
G
86
Posts: 24,139
Reputation: 190,761

Post » Wed Apr 15, 2015 2:01 pm

- Pathfinding could fire "then" after the path is found

Doesn't it already work like that, "On path found"? What would be different or the benefit?

Does anyone have any thoughts about this? Good idea or bad idea? Perhaps there's an even better way it could be approached?

Im not 100% sure I understand the benefit in this. Completely agree with the "When data loaded" kind of thing, which is very useful.

But if you make a game and do a Async read of data, wont the data be to old when needed as you write the game will continue on. So when the data is actually need you would have to get it once more, in case it have changed.

Wouldn't that leave two options, either you have to make sure that the data is there when you need it, so would require you to wait for it regardless of how it is read?

The other one is that if you have a program that requires to load larger amount of data, you would wait for it to load. So you would put it at the start of layout or somewhere where you would wait for it to load, or it would be data that will not "impact" the game, so it wouldn't really matter if it was read as Async or not.

But maybe I just misunderstood the benefits?

As I see it the problem with Wait is that it just wait a specific time, which is fine for what it should be used for. But often it is used to "Trick" the code. Which is not nice I think. Whereas "Wait for signal" will allow the program to wait for something to be done or happen before moving on.

So maybe a better idea is to just add more "Finalize triggers" to different things. Like you have "On path found" etc. It could be "On local data read", "On local data written", "On audio file loaded", "On video loaded" and so forth.

Or is that not what you are trying to achieve with this?

But regardless I do agree that "Then" is probably a bit confusing name. Then "Async. completed" or something might be better.
B
44
S
11
G
2
Posts: 1,181
Reputation: 6,826

Post » Wed Apr 15, 2015 2:12 pm

How about giving us a choice?

1. Don't care about slight delay - start of layout, end of layout etc = synchronous.
2. Writing/reading data in-game and don't want to cause a frame drop = asynchronous.

I'm not a fan of Then, it will probably lead to beginner confusion.
I only occasionally visit - I'm learning C# for Unity, but c2 is still a respectable game engine imo....
B
69
S
18
G
65
Posts: 2,195
Reputation: 41,465

Post » Wed Apr 15, 2015 3:56 pm

Ashley wrote:- Set "myKey" to "myValue" (only writes to cache)
- Write "myKey" (writes for real and is asynchronous)

I agree with rex here - the only difference is I would drop the "write" action entirely. This proposed schema looks like many of the modern key-value storage schemas, which don't truly commit the data to disk until some time later, hence the term "eventually consistent". This shows that the proposed flow is a pattern (as opposed to an anti-pattern).

The system as it is implemented now is close to the way it works in javascript, and I'm used to the async nature of js, but I believe it is very hard for beginners to grasp: remember some people have difficulty with arrays and some think variables are too hard. I'm not saying constuct should be designed solely for those people (lest we become like some other game-making software out there *cough*), but it should at least cater to them if it doesn't get in the way.

The benefits of a "fake write" with posterior flush are reduced complexity for the dev (which is one of the strong suits of C2) and performance (since you don't have to wait to read values you just set). The only (slight) complication for you @Ashley would be to ensure that writes issued in order get committed in order as well, and if there's a conflict, last write wins.

It would be worth it to investigate how writes commit if the application crashes before receiving acknowledgement (different engines may do this differently). If it commits even without acks and "last write wins", as I suspect it happens, then there is no problem at all.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Wed Apr 15, 2015 4:37 pm

delete
Last edited by Everade on Sun Apr 19, 2015 7:04 am, edited 1 time in total.
B
38
S
8
G
3
Posts: 158
Reputation: 2,963

Post » Wed Apr 15, 2015 5:30 pm

Thanks for suggestion, I had made my first version of dictionary cache plugin.

Image
After loading cache completed, all read/write operations look likes synchronous.
- Read had been done while cache loaded.
- Writing actions in a tick would be fired at the same time ( in tick2() ). "Condition:On writing actions complete" will be triggered when all writing actions are done. User might wait this event or not.

Data in local storage are-
Image


Sample capx , plugin.



Edit
The reading and writing actions of local storage are embedded inside this plugin. So it does not need to work with official localstorage plugin.
B
107
S
25
G
243
Posts: 4,389
Reputation: 137,470

Post » Thu Apr 16, 2015 6:51 am

Thanks @rexrainbow for your plugin.
B
147
S
26
G
17
Posts: 905
Reputation: 32,121

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: technofou, Yahoo [Bot] and 3 guests