[Discussion] Feasibility of AGS native web runtime

[RickJ]

I have been researching current web technologies such as java script, ruby/rails, python, ajax, html5, etc for an upcoming project (day job).  It has occurred to me that capabilities such as html5's canvas, java script's interval timer and asynchronous request, and a little help from the server via  PHP, Python, Ruby or C that it ought to be possible to implement some sort of runtime game engine that could run in a browser.

As a mater of intellectual curiosity I would be interested in discussing this possibility and it's pro's and con's with those of you who are more familiar with the specific tech involved.  We can use AGS as a common basis for the discussion since we are all very familiar with it and it's capabilities.   

Let's limit ourselves to the technical issues.  This far removed from being a practical suggestion for AGS and talking about practical, logistical, political, and other aspects would be uninteresting and counter-productive at this point.


I have a superficial knowledge and a naive point of view at best but here is what I think I know about all this:

HTML5

• HTML5 has a canvas element that allows one to draw and do other sorts of graphical manipulations.  It supports bit map and SVG images.  I don't know the full extent of it's capabilities or how they would compare with what Allegro offers.
  
  
• HTML elements (especially <div> and <span>) can have background images and can be dynamically moved around, animated and generate events in response to user interaction.
  
  Java Script
  
• JS can be used  to perform graphical operations such as moving and animating sprites on the HTML5 canvas element.
  
  
• JS has an interval timer that can be used trigger a game scan event.
  
  
• JS can respond  to user clicks on various document elements by running event handler and event listener functions.
  
  
• S can parse and extract info from specific elements in an XML/HTML document
  
  
• JS can asynchronously request additional information from the server and then update the current browser window without reloading the entire thing.
  
  Basic Engine Design
  
• Client Side - Nearly all of the engine would execute on the client side.  The server would only be needed to download the required JS and HTML/XML game files.  Perhaps it would also be needed to work around client side limitations (SAVE GAMZE come to mind).
  
  
• Elements - For each game element  (i.e. characters, objects, hotspots, etc) there would be corresponding HTML elements so that events could be generated.
  
  
• Game Scan - Items requiring periodic execution could be handled using the JS setInterval() functionality.  Event handlers are natively e
• 
  executed asynchronously so they it's not necessary to implement a polling scheme here to implement them.   If synchronism is required/desired it could be implemented by having the asynchronous event handlers sleep until the occurrence of a game scan.
  
  
• Animation - Animation could be achieved using the above mentioned setInterval().  Animation frames and loops for a given entity could be stored in a single file.  An animation procedure would just display different portions of the file for each loop/frame.
  
  
• Sounds & Video - I don't know much about this except that HTML5 now has native support for video.  I think the same element can also be used to play audio and that there are other legacy methods.
  
  
• Built-in Functions - It's possible to create objects in JS so it ought to be possible to implement most AGS built-in functions in JS.   AGS uses managed objects so there may need to be a JS method of unloading unused objects to prevent memory leaks.
  
  
• Game Script - JS has a very similar syntax and capabilities as AGS script with a few differences that would appear to be easily translatable from one language to another.   
  
  
• Main Game Files - The main game files would consist of an XML/HTML file that would provide a basic DOM structure for the game and contain links to the required java script libraries and global game items such as character and inventory item graphics, sounds, etc, etc.   It would also contain a link to a java script equivalent to AGS's global script.
  
  
• Room Game Files - The room files could be an XML/HTML file that contains room specific definitions and links to a java script equivalent to AGS's room script and links to room specific items such as object, background, and other graphics, sounds, etc.  The room XML file would be loaded by asynchronous request (AJAX) and then used to update the current browser screen.
  
  
• Game Data - JS uses loosely typed variables which seem like they are capable of supporting all of AGS's data types.  The problem is that JS running in a browser does not have file I/O capability.  It would seem like the server would need to create a session for the player and keep track of persistent room data so that if a player interacted with a room, left and then returned the room would be in the same state as when the player left.  In this case SAVE GAME could be implemented as a download/upload of the session file.   This file could be in the form of a JS script file so restore game could just be a load and execute of the save game file?   The down side of course is that the server has to consume some CPU resources executing code; the upside is that people will need to access the website if they want to play. 
  
  
• Performance - Obviously if someone has a 386 desktop and a dial-up modem they wouldn't be pleased with the performance of such a game engine.  However with broadband and Multi-Ghz/GB machines it's not clear if performance would be an issue or not.   I suppose it would be highly dependent on the actual implementation of the JS components.  I would be surprised if loading of the game and graphical files were a problem in this respect.  My gut feel is that JS execution may be a problem.
  
  
  That's all I can think of right now.  I'd be interested in what other people think about this.  What are the potential problems and their potential solutions?  What other better ways are there of implementing such an engine?  If it were possible how useful or widely used would it be?    AZny other related ideas? 
  
  Let's just have an interesting conversation about teh tech ....

[SpacePaw]

I would keep everything but saves on the server side and just process mouse clicks. But to re-make the engine in those technologies would require much much much coding. Or even mucher! Or even the muchest!

EDIT:
and seriously...It's much better to just run the game on the server and send the rendered frames to the user just like microsoft and others are planning to do lately.

[Dualnames]

RickJ, I'm glad you're actually putting this into discussion. First, I think, without wanting to kill anyone's dream, that it would require someone to actually port/transform AGS. But if we think very simple, I think in a very short period of time, it can be done.

Also just noticed the part of your post, that includes what I've said, so I'm going to draw a line and actually get on with details.
Literally:

HTML 5
Seems very useful, if indeed it ends up equally or even more flexible than Allegro. I think it can also provide more abilities and functions to AGS.

JS
This is actual the core of your ideas, and to no wonder. JavaScript pretty much dominates the whole internet nowadays, on the sector of flash based applications.

BED
I don't think it's a bad thing to have savegames on the client side. I'm not sure however how parts of the code that run from the server side, would actually help out performance. On a room change it's like okay to load the individual room script. It should be noted that module scripts and global script should run on the client side, otherwise it would seriously mean a waste in performance.


Also, I'm not very familiar, so I'm actually wondering on two other things: D3D capabilities and performance with the equivalent Drawing Surface and Dynamic Sprite functions on JS and HTML 5.

[SSH]

Check out http://code.google.com/p/js-gam/

There was another javascript proof of concept called "Nature Boy" with a doom sprite walking around a desktop but I can't find it again...

[Wyz]

That's an exciting idea!
Well, very well put outlines there. AGS has no native network support, and hence it does not need to communicate to a server. Running something like this entirely client-side would be a great performance improvement actually. Todays JavaScript interpreters are quite good, and can do pretty amazing things even on low-end computers; It could work, absolutely. I'm not familiar with HTML 5, but I do know it's still in development. It will take some time before all browsers support it and all of it's features.

About save games: it is perfectly possible to generate a downloadable game state XML file, but I would offer the possibility to store it server-side too. Not because it would mean people have to login or something, but mostly because not all users will understand what a XML file is, and how it relates to the game. Server side will be more convenient for a lot of folks I expect. That will be the only thing that needs to communicate with the site after the game content has been downloaded, well that's not so bad. You could also generate high-scores and achievements in that fashion. But I would still allow the possibility to store it in a XML file, for the more experienced users that like to play it completely offline.

[RickJ]

... But to re-make the engine in those technologies would require much much much coding. Or even mucher! Or even the muchest!

It's given that a lot of work goes into making a runtime game engine (and even more in the IDE part of it) and that some languages are easier to work with than others.   The JS language has a syntax similar to C/C++ and Java and seems to be much more forgiving in many respects than either of the other two.  So I am curious as to why it would be so much more work in JS?  

and seriously...It's much better to just run the game on the server and send the rendered frames to the user just like microsoft and others are planning to do lately.

Again I curious, in what way would it be better?  The obvious down side is that it would not scale as well and consume much more server resources.  Performance would be held hostage by server/ISP/Internets response.  If I understand correctly a rendered screen would be downloaded every 40ms or so which would require much greater bandwidth.

I don't think it's a bad thing to have savegames on the client side. I'm not sure however how parts of the code that run from the server side, would actually help out performance.

It's preferred to keep save games on the client side.  The problem is that browsers will not allow JS to do file I/O on the client side.   So on a room change any room variables that need to be persisted will have to be sent to the server and stored in a session file.    If the player re-enters that room then the data will be sent back to the client.  If the player does a save game then the server will write the session data to a file and the client will perform a download operation.

On a room change it's like okay to load the individual room script. It should be noted that module scripts and global script should run on the client side, otherwise it would seriously mean a waste in performance.

Right, that's what I intended to say in the first post.  Sorry if it was confusing.

Also, I'm not very familiar, so I'm actually wondering on two other things: D3D capabilities and performance with the equivalent Drawing Surface and Dynamic Sprite functions on JS and HTML 5.

I believe the HTML canvas element is 2D only.   I don't think there is anything in HTML or the Canvas element that gives access to lower level drivers or optimizations.   So I guess it would be up to the specific browser to take advantage of things like D3D.  I don't know any more than you and am mostly guessing.

[SSH]

The advantage of having some game logic on the server side is that it can be used as copy protection and prevent cheating by reverse engineering. The disadvantage is that you need a working connection to play. Maybe a way in which the connection was only used rarely (savegames, changing chapters, changing rooms) might be best?

[Clarvalon]

In theory it's a great idea - HTML5 should, at some undetermined time in the future (it has been a slow process) gain support  from all the main browsers, including smartphones etc.  That near-universal support would be a fantastic way of easily distributing games to the broadest spectrum of people.

In practice, I can't help but feel that writing an engine of that size and complexity in Javascript would be an absolute nightmare.  It's hard enough in a proper language.  Even with the original source code, it would take an incredible amount of dedication and perseverance on behalf of the coder.

A lot of people are hoping that HTML5 will render RIA plugins (Flash, Java, Silverlight, Unity etc) obsolete, and I can understand the reasons for wanting reliance on proprietary technology removed.  But to be honest, I just can't see HTML5 & Javascript replacing the functionality and level of quality these plugins provide anytime soon.

[RickJ]

Firefox 3.5 supports OGG video in HTML video element.  You can see a short demo at the link below (if you have firefox of course).   It's my understanding is that it's a problem of politics rather than implementation.   It's also my understanding that Firefox and Safari are going ahead with implementation even though proprietary vendors don't want to agree.   

http://en-us.www.mozilla.com/en-US/firefox/3.5.8/firstrun/

[RickJ]

As follow-up to this discussion I found this video lecture about the capabilities of HTML 5.  It answers some of the questions that came up in this thread.  So for anyone interested please feel free to enjoy:

http://developer.yahoo.com/yui/theater/video.php?v=neuberg-html5

[InsertCoin25]

This might not fit into your discussion but you could give this a look if you are looking to put your games in a browser. Works well

http://www.osakit.com/

InsertCoin25

[Dualnames]

This might not fit into your discussion but you could give this a look if you are looking to put your games in a browser. Works well

http://www.osakit.com/

InsertCoin25

Seems totally interesting as a matter of fact I'm checking this out. Thanks a lot for that link!!

[Denzil Quixode]

(I know this is an old quote but anyway)

Game Script - JS has a very similar syntax and capabilities as AGS script with a few differences that would appear to be easily translatable from one language to another.

The main problem would be transforming "blocking"/"synchronous" functions to "non-blocking"/"asynchronous" ones. For example, the AGS script:

Code: ags

function myfunc()
{
  player.Say("Hi there!");
  npc.Say("Hello!");
  Wait(40);
  player.Say("Well... goodbye.");
}

...now, the player.Say() call may take several seconds to complete. But that isn't allowed in Javascript - if code takes too long to complete, the whole browser/tab can hang, or it will pop up a message saying something is taking too long to complete. So you would need to find a way to transform "blocking" to "nonblocking". In Javascript you can pass around functions like variables, so you can pass a function that says what to do once an action has been completed:

Code: ags

function myfunc()
{
  player.Say("Hi there!",
     function() {
       npc.Say("Hello!",
         function() {
           Wait(40,
             function() {
               player.Say("Well... goodbye.");
             });
         });
     });
}

Ugly! And also, what do you do if myfunc() wants to return a value...? And how do you deal with while() { } loops...?  

Not an impossible problem to overcome, probably, but a pretty big hurdle.

[Monsieur OUXX]

Like others I agree that it's very (too much) ambitious to start a new engine from scratch.

I'd recommend to put more work into converters, like the limited one that exists for XAGE. It'd be cool if a game could be easily exported by its maker, to be played in other, stable engines targetting other platforms.

For instance:
- a web browser (using, for example, the engine shown earlier in this thread),
- Flash (with Lassie),
- XBox (using XAGE),
- etc.

[subspark]

RickJ On HTML5:

I don't know the full extent of it's capabilities or how they would compare with what Allegro offers.

Hey Rick, I'v done some research into HTML5 (I've been developing in it lately) and tracked this down:
http://code.google.com/p/quake2-gwt-port/

HTML5 is VERY powerful indeed. I have very little doubt it could be used as a SCUMM interpreter or a platform for our AGS games.

Cheers,
Sparky.

[Dualnames]

This might not fit into your discussion but you could give this a look if you are looking to put your games in a browser. Works well

http://www.osakit.com/

InsertCoin25

Seems totally interesting as a matter of fact I'm checking this out. Thanks a lot for that link!!

I tried a lot to make this work, but the program always ended up crashing on me, and I had to re-type everything again and again.
If anyone managed to make this work, or does in the future, show us and tell us how.

HTML5 is VERY powerful indeed. I have very little doubt it could be used as a SCUMM interpreter or a platform for our AGS games.

HTML 5 is powerful but like mOUXX said. If we're gonna take lots and lots of trouble to export a game into some other platform, it's not ideal. Not to be the asshole,but we all rather script our own engine than bother to do the same amount of work to covert our AGS game to another platform.

[Shane 'ProgZmax' Stevens]

It would actually be better if CJ handed off the source to someone to build an interpreter in something like Flash since it's so widely used.  I'd actually be all behind this and would love a crack at such a project since I've been itching to make the move to web-based games in actionscript but just haven't had enough of an excuse.  It would be lovely to be able to host ags games directly through web apps so people could either play them virtually on my site or download them to play locally.  Now, I probably wouldn't use it for large games, but for short games it's a great way to get people playing your stuff without much hassle.  A quick trip to kongregate.com should convince anyone of this...I've wasted so many hours at that site!

[Calin Leafshade]

I'm with progz on this one.

I'm afraid when it comes to short games the browser is where it's at and where it will stay.

Although maybe HTML5 would be a better renderer.. i hate flash.

[subspark]

I must agree with Calin. Flash is sliding down the www gurgler.

Cheers,
Sparky.

[Denzil Quixode]

I've been working on a prototype of a port of the AGS demo game in Flash. (Sorry HTML5 fans.) It's not based on any official AGS code, so it won't be compatible with existing compiled game formats and would need a special editor plugin to export a game (which I haven't made, this is a hardcoded demo specific to the game). There's only one room and the inventory GUI doesn't work so far:

http://octospherics.com/toolbox/Loader.swf