42 replies to this topic

[Dark Matter]

Just wondering here Mike - would this success be a reason to try a conversion to ActionScript 3 too? I know Flash is considered to ultimately be beaten by HTML5, but right now it still has the edge to HTML5 - an overall better performance on all browsers, better coverage, better graphic capabilities and being actually byte-compiled, therefore offering somewhat better protection of the sources than HTML5 does. Flash recently also broke into the Android platform.

I'm suggesting this because the time it took you to convert to HTML5 was ridiculously short, and if a comparable time investment (and then some) is required for an AS3 conversion then you'd have, for some time to go, a solid web platform until HTML5 outruns it. It would also make a great alternative to the YYG runner plugin you'd have to install on your browser, which right now might be an impediment to gain a larger audience to the YYG website.

I personally would not like to see a Flash compiled GM game.

[Krisando]

Implementing this would be extremely browser dependent, it would just decrease portability instantly (unless a cross-platform interpreter were to be used, but that would bloat the executables a fair bit).

I also see people using html5 in their game unaware of the OS requirements and/or browser requirements. GM has never been at the top of the chain to include the latest and innovative tech, so why should it implement html5. Html5 has been used, it is just another development platform standard.

IMO the time could be better spent improving on GM, not adding some gimmicks few can or will use.

[GameGeisha]

Work on the Javascript compiler has given us more confidence with the prospect of compiling/translating GML into other languages and targets, we still have a few issues to overcome...

... like how different browsers tend to render the same standards-compliant code differently? This one is the absolute most annoying thing that I deal with on a regular basis while developing on web platforms. Any information on how the HTML5 runner will handle these quirks?

I mean, if you can handle that, other targets will hardly be a challenge to you.

the first one being turning all the Drag and Drop into pure GML script, this will help considerably with any further efforts on compilation...

D&D has a terrible habit of allowing duplicate resource names as long as they're of different types (e.g. a sprite named "player" and another object also named "player"), as well as invalid resource names (e.g. a sprite named "bang!"). These don't translate easily into the much stricter syntax of Javascript without extensively modifying the conflicting names. But doing so carries a consequence --- it hinders debugging when a previously unknown resource name comes up in an error (or even worse, a serious bug gets hidden this way), and the compiler's interpretation of the type of a duplicated identifier can be very error-prone.

With that said, will GM8.1 be adapted so that duplicate and invalid resource names are banned? That will make compilation so much easier. And driving in good habits early never hurts.

GameGeisha

[RhysAndrews]

On the question of "how are you going to distribute this feature?", I would suggest, surprise surprise, that you do offer it as a free alternative publishing option to a stand-alone executable as part of Game Maker. Unlike Android, iOS, Windows Phone, PSP, etc, HTML5 isn't platform-specific. There's no "HTML5 Store". And distribution through YoYo Games would be difficult and a little strange. I would imagine making HTML5 games through affordable, powerful software without contracts would draw in a huge market. Additionally, knowing HTML5 / Javascript will have its security flaws means it may be better to leave that burden on us to secure the game via other means. Being able to publish the game on the YoYo Games website and have it playable in-browser without that silly InstantPlay plugin would really attract gamers, not just developers.

As you say, HTML5 doesn't run brilliantly on mobile platforms yet, and my guess is that while Apple for example are welcoming the technology with open arms (albeit also with a browser that can't handle it properly), they'd be err-ing about the potential this gives for people to make games for the iPhone without going through the app store. Therefore there's still a place for the android and iOS runners and for your distribution program.

-R

[Dark Matter]

GM has never been at the top of the chain to include the latest and innovative tech, so why should it implement html5.

Why can't it start? You should be pleased it's started!

IMO the time could be better spent improving on GM, not adding some gimmicks few can or will use.

HTML5 is not a "gimmick". Many people will use this, not just a few. You obviously have no idea what HTML5 means or is.

[amd42]

IMO the time could be better spent improving on GM, not adding some gimmicks few can or will use.

So there are two big lessons I'll take from this. First, I now have a much better idea on how to manage the C++ runner, and how to rewrite the bits I hate that are slowing everything else down (the events being the main thing for me). Second, we now also know we can do some amazing things with GML, from optimise the interpreter, to convert it to a whole new language to get it compiled - or even compile it natively ourselves. This is all pretty exciting stuff to us as it's not JUST about how well the HML5 port went, it's also how we can now use this invaluable information to make future versions of Game Maker and it's runner better for everyone! So while these aren't quick fixes or changes, we are now armed better for the future, so when we do a rewrite, we'll know exactly what we need to do to make it fly!

...

[Desert Dog]

So please do consider the implications and don't just say "yay" because It's a new feature, if it is to be reliant on IE, then it will render the feature useless. Would you rather have a large audience, or a much narrower one, due to a single feature!?

Hi Krisando,

Could you please elaborate/explain the bolded statement? It sounds like you have a definitely, and most likely erroneous idea of what this HTML5 thing does.

[round]

GML->Javascript syntax. Actually, I'm amazed at just how LIKE javascript GML is!! Aside from a few issues, its almost a perfect match! Yes, things like if( foo=bar ) needs fixing, but these are minor fixes and ones we've already done. Other things like type-less variables are actually a perfect fit! (much to my disgust!) I still think a PRO mode where we enforce "some" kind of syntax is on the cards, but it'll be purely optional. But yes... given better syntax... it "might" produce better javascript, but we don't know for sure. And yes... but going into Javascript, we get "free" compilation thanks to the browsers JIT.

Hi, Mike.Dailly,

f( foo=bar )

I agree that the above syntax should be kept. It is because many GM users like to use only one equal sign to do this. Perhaps they think that typing two equal signs wastes time. Moreover, many GM users don't like to type ; at the end of each code statement.

The idea is to be able to get to as wide an audience as possible. If you can do that with a single game and multiple exports, then where's the harm? It does mean other folk (like Linux users) could get these games as well.

WOW...I totally agree with you.

"a single game and multiple exports" <------ many non-Game Maker users will start learning and using Game Maker..sure!!!!

Edited by round, 28 February 2011 - 12:47 AM.

[Schyler]

In regards to D&D, anyone seen "Alice"?



If I remember correctly (been a while since I messed with it, and it was purely for fun) there is a button you can press that instantly toggles between code and tile view.

Edited by Schyler, 28 February 2011 - 12:52 AM.

[Desert Dog]

In regards to D&D, anyone seen "Alice"?

Yeah, I've used it. It's D&D is a lot more like D&D crossed with Code, it's very visual&easy to use.

[Schyler]

I guess theres always time for change

I think a code-action toggle editor would be neat. Mike probably won't like it though. It would require almost an entire rewrite.

[round]

...

Translating GML to another high level programming language, then compiling to native machine code. It is a good idea!!!!
.....

Work on the Javascript compiler has given us more confidence with the prospect of compiling/translating GML into other languages and targets, we still have a few issues to overcome, the first one being turning all the Drag and Drop into pure GML script, this will help considerably with any further efforts on compilation...

BUT our first big thing will be shipping GM 8.1, so watch this space...

Any of our future efforts will hinge on getting GM 8.1 out, it will be the start of exciting things in the future.

Hello, rwkay,

I understand now. Thanks a lot.

It is very nice that you participate in discussion with us about the future development of Game Maker in the GMC forum!!!
......

Edited by round, 28 February 2011 - 01:13 AM.

[Big J]

I don't really know what HTML5 is, but if it means playing GM games inside a browser, I say to that: "Why not?"

Perhaps they think that typing two equal signs wastes time.

Curse it all! That is 5 nanoseconds I will never get back! Those poor C++ and Java programmers, always having to type those long-winded comparison operators.

Edited by Big J, 28 February 2011 - 01:24 AM.

[thatshelby]

If I understand your blog post properly your converter "compiles" GML into Javascript using the canvas element.

Therefore the runner no longer needs to convert to byte and interpret, the obvious benefit is taking advantage of JIT compiling with what used to be GML code.

If this is correct, the non-strict syntax of GML is more cumbersome than it need be if GML forced a stricter C/Java/JS syntax.

That would allow conditions and statements using =(assign) ==(compare), && {} and terminated with a ; to be simply re-written with no/little conversions of :=, and, or, =(when used as compare), begin, and inserting ;.

Can we expect to see a stricter GML in the future to accommodate less cumbersome JS conversion?

I certainly hope so; this would be so helpful when sharing code with others.

[mcoot]

Just my question is: How much will this slow down GM 8.1 (& future improvement of gamemaker)...

That's all you ever think about, isn't it? If you had read the post, you would realise how much potential this has in terms of Game Maker, not just in terms of HTML5. Amd42 quoted a paragraph from Mike Dailly's blog post: do yourself a favour and read it.


This really is pretty fantastic, that you could make a workable GML-to-HTML5 system in under two weeks.

All this development is really great. I'm looking forward to seeing the final product.

As far as distribution goes:
I wouldn't expect you to distribute this feature free with GM. What I think would be the best idea would be to sell this as an 'addon' to Game Maker, or some sort of license for it. I don't think it will be well received at first (look at what happened when people had to pay $25 dollars to upgrade to Pro for the first time since 5.3, more than four years ago), but honestly, they'll get over it and Yoyo deserve some compensation for all the work they've put into Game Maker in the last years.

Great work, guys

[Rani_sputnik]

If I understand your blog post properly your converter "compiles" GML into Javascript using the canvas element.

Therefore the runner no longer needs to convert to byte and interpret, the obvious benefit is taking advantage of JIT compiling with what used to be GML code.

If this is correct, the non-strict syntax of GML is more cumbersome than it need be if GML forced a stricter C/Java/JS syntax.

That would allow conditions and statements using =(assign) ==(compare), && {} and terminated with a ; to be simply re-written with no/little conversions of :=, and, or, =(when used as compare), begin, and inserting ;.

Can we expect to see a stricter GML in the future to accommodate less cumbersome JS conversion?

This community certainly sounds like a broken record sometimes.
@Mike and Rus, great stuff! It's great to see that GMaker is on the bandwagon nice and early with HTML5, hopefully it'll give the port a good lifespan so that you don't have to worry about updating it for a while. It's really great to see GM move progress so productively.

My question (for anyone cause it's pretty basic) is why on earth is tinting not supported in the canvas (is tag the right word) for HTML5? It seems a pretty basic thing to skip out... Apologies, I am a complete noob to anything HTML.

EDIT: Oh Gosh I need some sleep methinks - fail spelling corrected
EDIT2: Does anyone want a cat? Seriously! Cat for real even

Edited by Rani_sputnik, 28 February 2011 - 11:35 AM.

[Manuel777]

Code compilation. Yes, compiling GML into native would be much quicker, however it also means you'll get far less errors and more fatal crashes. I don't like that. However... if we DO add certain optional TYPES, then the GML parsing would increase exponentially. We do all manner of runtime checks just now, but we could strip these back if we knew certain things. If the code produced was "just right", then the virtual machine being used would fly, and there would be no need for actual compilation, so we would still get nice errors etc. Being a learning language, we need the balance. Perhaps one day... a "debug" and "release" mode might happen - but not today!

I really like this idea.. And if you dont like giving a error-less compilation to your users you can always send them the debug version (useful for beta releases)
Maybe, you can make the user to select a few options; if you want all variables to be declared automatically as doubles (as now) and if you'd like to set the TYPE on the declaration? it would be useful to strip between novice and advanced users, the same goes for the option you pointed to select a stricter sintax. Not to mention the performace improovements!

Going back to HTML5; since you can include stuff like JS in normal HTML, along with PHP, is it possible we get the ability to make thoose calls at real browser speed? i mean, now we can do that but only trough a DLL with HTTP support, and thats horribly slow! Including something like this would allow us to create online games connected trough PHP and MySql databases, Faster online highscores engines, Mutiplayer connectivity, etc.. pretty much like Facebook games, why not.

Edited by manuel777, 28 February 2011 - 12:35 PM.

[TheMagicNumber]

games connected trough PHP and MySql databases

Eww, what's wrong with WebSocket?

[Manuel777]

games connected trough PHP and MySql databases

Eww, what's wrong with WebSocket?

Well, including that in the HTML source will be faster than downloading a new page each time you want to reatrieve a bit of data, right?