Very impressive - aside from music issues I played through the game without noticing any gameplay or presentation glitches at all.
Thank you! These are the music issues I know about, let me know if you are talking of ones that are not covered:
- Flash mode does not have crossfading or seeking due to technical reasons. Flash does not have native Ogg Vorbis output, and I decided that I did not want to transcode MP3 alternatives for this demo - so this is actually running an Ogg Vorbis decoder written in Flash code itself (actually in haXe, but compiled to Flash). This is also I believe why there may be a noticeable pause whenever the track changes in Flash mode - it's doing a lot of work.
- Opera seems to keep the previous track playing for too long when crossfading tracks. I am unsure whether this is something I am doing that happens to not affect other browsers or if it is an actual bug in Opera.
- Safari supports the HTML5 <audio> tag, but does not support Ogg Vorbis to be played through it, only MP3. Most other browsers are the opposite way around. Helpful...
- The music doesn't go quieter for a bit after the rap battle. I just plain forgot to support this.
It's hard to deny that the open-ness of the code could be a sticking point, but for the most part I think it'd be preferable to not being able to put the games in a browser at all. The ability to run games in a browser overshadows, for now at least, protection of one's assets - particularly in smaller freeware games.
That is what I am hoping. It is always going to be up to the individual to decide, before anyone starts getting worried that this could ever potentially be forced on their games - even though I have called this the "web runtime" demo (because of that other thread), it really isn't a runtime like the existing Linux or Mac runtime projects - you would not be able to use it to run
compiled games, you need the original source code to convert a game to be able to run on this. So unless you have released the source to your game, in which case anyone can see the scripts/resources anyway, you are the only one who could make that decision.
But maybe it will be possible to make something that runs server-side:
node.js is a project for running JavaScript on the server, on Google's highly advanced V8 JIT JavaScript engine;
Socket.IO allows two-way communication between client and server; and I know there are projects out there to allow node.js to use jQuery and Canvas, which could conceivably all be put together to run this same code on the server and transfer image data to the client. Whether it could be fast enough, and how many users it could actually sustain at once, are the big questions. I have no plans to try doing this myself, but maybe someone else could do their own proof-of-concept...
I'm interested in a couple of things -
Okay...
- ability to scale beyond manually doing it with browser zooming features
The HTML5 specification quite specifically does
not allow you to control how a bitmap image is scaled, which means that if you scale something up to 2x using <canvas> features rather than browser zoom, the result is most likely going to be exactly the same. And it really is too slow to do it manually pixel by pixel, in real-time at least.
Mozilla has a proprietary CSS extension which allows you to specify that an image (or HTML5 canvas) should be rendered with sharply-edged pixels rather than that kinda blurry filtering. This is actually used in the demo, which is why it should always have nice sharp pixels when zoomed in with Firefox, but no other browser.
Flash has the advantage here. With Flash you can both specify that you want something rendered without smoothing, and Flash 10 also has
Pixel Blender which allows you to run pixel shaders that I believe could be used to do some
advanced pixel art scaling algorithms in real-time.
- support of things such as alpha channels
Alpha support is as far as I know is very good, for both Flash and Canvas.
Tinting looks much much easier to do in Flash than Canvas, though.
- the actual conversion process
While the process in this case was mostly manual, I have not done anything an editor plugin could not do automatically (I think...). The scripts are transformed using a
C# AGS-Script parser I wrote myself, the images and fonts are all exported as PNGs (and
packed into a single image using the (C#, MIT-Licensed, open-source)
Sprite Sheet Packer). I even decided not to have MP3 alternative versions of the Ogg Vorbis music, even though that would make it far easier to play on Flash (and Safari's <audio>), because transcoding music from one lossy format to another is a process that I feel the user would need to control and consent to.
- eventual support for saving/loading
All I can say at the moment is, I don't think it would be that difficult to get the game saving and loading to a JavaScript string, and from there whatever weird and wonderful methods people want to use to store and retrieve those strings can be written around it. I'll know more when I actually try to do it :P
- support for accessing other external files aside from save files (such as, but not limited to, translation files and running other .exes from )
I actually don't know much about translation files yet.
Other .exes, no. Other games similarly converted, yes, most likely.
- support for plugins (such as, but no limited to, ogg theora player)
Well, my idea is that you should be able to customise the export process so that you can supply alternatives yourself for resources like music, video and so on, and this could of course support formats that are not supported by the original AGS engine.
Also, I have ideas that you should be able to do things like this in your AGS code:
[code]
#ifdef WEB_RUNTIME
WebRuntime.CallJavascriptFunction("alert", "Hello World!");
#endif
[/code]
...so customisation of the web version of the game could be endless.
- support for things such as 8 bit colour modes
I am actually far more confident that Flash could be used to simulate 8 bit colour games, with realtime palette effects and everything, than HTML5. Surprisingly enough.
Also, ! probably is not the best simple conversion candidate due to the unconventional nature of it. Have you tried working with multiple mouse modes and inventory items?
This is true, and no, I have not. Even more significantly, it doesn't even have
walk zones. Walk zones! How do you live without them?
Once again most impressive work. If you'd like more source code to experiment with let me know and I'll happily send you some.
Thank you, that would be great. I definitely would like to try a medium sized game with walk zones, mouse modes, inventory items, many rooms, etc.
