tux4kids / Tux4ME

A mind exercise game by Tux4Kids organization developed under Google summer of Code - 2015
GNU General Public License v3.0
19 stars 28 forks source link

Use of Iframe to load the games #49

Open arun1128 opened 8 years ago

arun1128 commented 8 years ago

As per my conversation with @Vigneshsekar and my understanding of the code-base i am adding this issue here.

We can see iframe tag being used to load the games. And with HTML imports of polymer not being vulcanized, this is making too many requests. @Vigneshsekar told me that this count was about 110+ and assured to vulcanize it during/before the GSoC period. Its fine.

When i recommended the use of Iron-Ajax element to load the games, he gave me the earlier version of the code where he tried it but had a weird error. We need to restructure the code to use Ajax. Interested people can try and post the results here while i am also trying to get it resolved soon.

Vigneshsekar commented 8 years ago

We were using it while polymer was at its very early stages and did not have enough documentation to help us with the issues we had then.

@arun1128 thanks for raising this issue here. We had many new contributors not noticing this iframe and felt frustrated while their local changes were not being reflected in the browser. I spent considerable time in explaining it to them.

kvk30 commented 8 years ago

@Vigneshsekar can you add this thing in readme such that it would helpful for new developers.

Vigneshsekar commented 8 years ago

As we are planning to develop a style guidelines document, we shall add all required details that any new developer may require in it.

AgrawalAmey commented 8 years ago

I guess for developers it is best to directly work on template.html and integrate it to project when it is done. And for loading games I guess we can give a shot to html imports, they will be deduping for us.

mohitagg1996 commented 8 years ago

How about using a framework for eg AngualrJS for making it a single web page application. We can then easily load any game without using Iframe. I am working on Angualrjs fork for this project

AkshayAgarwal007 commented 8 years ago

@mohitagg1996 Angular would be good. Using phaser to implement a state for level selection might also be a good idea.

AgrawalAmey commented 8 years ago

I guess angular+polymer+phaser is a very heavy stack, it would be really painful if we intend to creat hybrid apps. Moreover angular will just send ajax request anyways. Personally I feel to keep uniformity and utilize web components to its best we should try html imports.

AkshayAgarwal007 commented 8 years ago

@AgrawalAmey From a perspective of just using phaser I think implementing a state for level selection would be good, that way porting it to mobile devices and making the games responsive would be easy. But as you say and which is very true that developers might not want to use phaser and for keeping a uniformity html imports would be good.

deepakagg commented 8 years ago

Hi

I have been following development of this project closely for some time and would like to add some points from my side as well.

  1. I strongly feel we should use a framework (angular, vue) for managing the state of entire game. Every time you select a game the entire page refreshes and loads the entire game engine and refreshes the entire DOM structure which is very heavy and if we are targeting hybrid apps then it will create a major performance issues.
  2. We clearly misunderstood the purpose of web components. I can see scripts being import inside them, which is a totally wrong. Rather they should exists as a separate sandboxed entity and should be light weight as much as possible. Correct me if I am wrong :)

@AgrawalAmey : angular+polymer+phaser won't be heavy at all. I have used them in past and did get a very good performance out of it. You can use html import, it will be fix but not a solution. Because they are made for importing html code and here we will be trying to import html code with web components and maybe javascript, which will kill the entire performance optimisation (parallel parsing) that came with html import.

@AkshayAgarwal007 I think we should not do state selection from the phaser. Keep it separate. It's core to the application not to the game.

@Vigneshsekar I strongly feel that we should have better project management and structure ( we may use grunt). So that it's easier to build a distribution of the game. At least we should minify all the JS and CSS file. if we can't combine them.

deepakagg commented 8 years ago

i found a good article on web component which might help us while evaluating which direction we should go with. http://www.2ality.com/2015/08/web-component-status.html

AgrawalAmey commented 8 years ago

@deepakagg For one I don't think we need a framework to manage the games, as far as loading phaser is considered repeatedly simple caching will resolve that. We can even go for service workers in case. Web components are ment to have logical functionality hence scripts are necessary. Scripts are not scoped separately for custom elements because js is primarily single threaded. Web workers can provide similar functionality but that is not the most convinent way of coding i know of. Using propr design patterns should sort any leakage issues.

mohitagg1996 commented 8 years ago

@deepakagg I somewhat agree with you. Current structure is too limiting and does not adheres to DRY principle at all. For example there is pausegame function in each and every javascript file.

@AgrawalAmey I guess @deepakagg loading means evalution of javascript code by the parser every time a games load. He is not referring about the delivery of files

Anyways for managing the build process we can use https://github.com/ngbp/ngbp.

deepakagg commented 8 years ago

@mohitagg1996 Hi, you are correct actually I was referring the evaluation of javascript code. Sorry for the confusion.

About the management framework, Good choice I actually like it more than the yeoman.

AgrawalAmey commented 8 years ago

@deepakagg That problem would persist only with iframes. html imports would not give such problem.